When you control both front-end and back-end, you don't have to make a breaking change that will affect anyone at all, if you're willing to do a multiple deploy

When you control both front-end and back-end, you don't have to make a breaking change that will affect anyone at all, if you're willing to do a multiple deploys and maybe wait a little bit. If your want to change from A to B, your first deploy is deploying B without stopping A from working. It could be a totally new endpoint, or you could just throw a version field into the request body or querystring. Once everyone has switched off of A, you can remove it from your codebase so only B remains without actually affecting anyone's session. If you don't want to pollute all your querystrings or request bodies with version fields, you could have an optional newVersion boolean field that only needs to appear during a switchover or make a temporary endpoint for updated clients to hit instead of the old endpoint: # state at start /foo <- uses API A # deploy new endpoint /foo <- uses API A /foo/new <- uses API B # wait for everyone to swtich to /foo/new, then deploy API to /foo, removing support for API A (this could be split into two deploys if you wanted) /foo <- uses API B /foo/new <- uses API B # wait for everyone to switch over to /foo, then remove /foo/new /foo <- uses API B