The integration partner who needs a stable API

Stripe ships breaking changes because every caller is pinned

Stripe's versioning page, checked today, says that since the 2024-09-30.acacia release it publishes a new API version every month with no breaking changes, and twice a year issues a major release that does contain them. The current version is 2026-09-30.endive. You send a Stripe-Version header and keep getting that shape until you decide to move. Webhook endpoints carry a version pinned at the moment you create them, so a payload cannot quietly change under a listener you wrote eighteen months ago.

None of that needs Stripe's engineering budget. It needs a version in the route or the header, a serializer that owns what leaves the building, and a test that fails when the shape moves. You can put that on your own backend in a day. What you cannot do is bolt it onto an endpoint a platform generates for you, because you do not own the thing that decides the shape.

A platform endpoint has one version, and it is now

Xano's docs define an endpoint by its name, its verb and the URL it answers on. Endpoints live in groups, and Xano builds the base path from the group's canonical ID, which gives you something like /api:awesome/user_list. Nothing in that path says v1. There is no header a caller can send to ask for last month's response shape, because last month's shape was never recorded as a contract.

Xano does keep history. Schema versioning stores previous versions of tables, endpoints, functions and background tasks, with ten retained on the Essential plan and twenty on Pro, and you can roll back when an edit goes wrong. That history serves the person editing. It says nothing to the partner calling. Rolling an endpoint back will not tell an integration that its parser should change too, and promoting a branch with xano branch set_live swaps what every caller sees at the same instant.

Airtable is more candid about the risk. Its list-records docs recommend table IDs over table names so a rename does not force you to rewrite the request, and returnFieldsByFieldId keys cell values by field ID for the same reason. The field model page goes further: Airtable may add new field types, that will not count as a breaking change, and API consumers are expected to handle unknown types gracefully. Airtable gives its own Web API twelve months of notice before a breaking change and six months for the scripting extension, while reserving the right to deprecate any API without notice. The platform runs real version discipline at its own boundary. It cannot run it at yours, because your endpoints are shaped by whatever your base looks like this afternoon.

The contract layer is cheaper than the conversation about it

What fixes this is thin. One versioned route, one serializer that decides what the outside world receives, one test that fails when the response changes shape. The database underneath can churn all it likes. The partner keeps getting what you promised them.

Stay World Class ran on Webflow and Xano. We moved it to Next.js with a NestJS API over Supabase, and the whole point of that middle layer is that a column rename stays a column rename instead of becoming someone else's incident. The migration ETL kept every legacy record ID and mapped it to a PostgreSQL UUID, so references held by outside systems still resolved after cutover.

The work is boring, and worth saying so. Writing a serializer is less satisfying than dragging a field into a table and watching it show up in the response two seconds later. You only collect on it the day a partner's build does not break.

When you should leave it alone

If the only caller is your own frontend and the two ship together, you have no version skew to manage, and a versioned contract is paperwork. Plenty of good internal tools on Airtable will never acquire a second consumer. Building a contract layer for an audience of one costs you a week and buys nothing.

The pressure starts when a caller appears whose deploy schedule you do not control. A client's dev shop. A mobile app sitting in review for a week. Even then you can buy most of the safety cheaply by referencing fields and tables by ID rather than by name, and by writing the response shape down somewhere both sides can see it. Move to a backend you own when the caller list grows past one, or the first time someone asks you to serve an old shape and a new one at once. That request is the one a platform endpoint has no way to answer.