This page exists to answer one question without hedging: what do I pin?
There is no API version header
Nothing in the platform reads one. Do not send one, and do not build around one. A header that is ignored is worse than no header: it makes an integration look pinned when it is not.
The MCP endpoint has two paths
| Path | For |
|---|---|
| /api/mcp/<storeId> | The original. Kept indefinitely — installed clients hold it in their config |
| /api/mcp/v1/<storeId> | New connections |
They are one endpoint with two names. Same handlers, and a token minted through either works on either. The versioned alias is 21 lines that re-export the same handlers.
Nothing has been deprecated yet
So there is no retention window to quote, and quoting one would describe a policy that has never applied to anything.
The page this replaced promised "previous versions stay online for 24 months" alongside a version header that did not exist. Both were invented.
When a deprecation does apply, it will be published before the change rather than after, on the changelog and here.
What you can rely on today
- Tool names in the MCP catalogue. Adding a tool is additive; renaming one would be a deprecation and would be announced.
- Scope strings such as
boostecom:catalog.read. A consented grant keeps meaning what it meant. - The
bei_Intelligence key format and its read-only contract. - Webhook signature schemes per provider.
What you should not rely on
- The shape of an undocumented JSON field. If it is not in these docs, it can move.
- Rate limit ceilings as a contract. They are operational, and Errors & rate limits says what to do when you hit one.
- Anything an older marketing page claimed about versioning. This page is the one that is guarded.