Surviving exchange API changes
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
Exchange APIs change, client libraries change faster, and the changes that hurt are not the ones that produce errors. They are the ones where your code keeps running and quietly does something different.
The categories
Breaking, loud. An endpoint removed, a required parameter added. Your code fails immediately. Annoying and safe.
Breaking, quiet. A field renamed while the old one still returns null, a
default changed, precision altered. Your code runs. The behaviour differs.
Additive. New fields. Harmless unless you validate strictly and reject unknown keys — which is a real failure mode for schema-validating clients.
Semantic. Same endpoint, same shape, different meaning. The worst kind, because nothing about the response signals it.
Only the first produces an alert. The rest are found by noticing that something is wrong.
Real examples worth knowing
Alpaca’s MCP server V2 is a complete rewrite on FastMCP and OpenAPI, and the documentation states plainly: “None of the V1 tools exist in V2.” Tool names, parameters and configuration all changed. Any prompt, script or tutorial written against V1 is invalid — see Alpaca MCP server setup.
IBKR is consolidating its web API products into a unified Web API using OAuth 2.0, with existing endpoints described as not deprecated. Directional information rather than a dated roadmap, and a reason not to build deeply against something in transition.
CCXT’s exception hierarchy is source code, not a contract. It lives in
ts/src/base/errors.ts and is stable in practice — but a major version bump is
a reason to re-check it rather than assume, since
your error handling depends on it.
MCP tool lists change at runtime. notifications/tools/list_changed exists
because this is normal. A server you reviewed as read-only can gain an
order-placement tool in an update.
Defences that work
Pin versions. Everything: the client library, the MCP server, the SDK. A trading integration is not the place for automatic dependency updates.
Read changelogs before upgrading, and upgrade deliberately rather than as a side effect of a build.
Validate responses rather than trusting them. If a price comes back null
because a field was renamed, you want a failure at parse time, not a 0 flowing
into a
position size calculation.
Assert what you depend on at startup. Query permissions, check that expected fields are present, log the API and library versions. A process that verifies its assumptions on boot fails legibly instead of at the first order.
Record the tool list for MCP setups, so an addition is a diff rather than a discovery — see monitoring a trading integration.
Test on testnet after upgrading. Obvious, routinely skipped, and it catches the loud category cheaply.
The silent failures to plan for
A field renamed with the old one still present. Reads as null or zero. A
zero price or zero quantity flowing into sizing produces an order that is
wrong in an interesting way.
A default changed. Time in force, order type, margin mode. Your orders behave differently and nothing in your code changed — this is why explicitly specifying every parameter beats relying on defaults.
Precision changed. More decimal places allowed, or fewer. Fewer means rejections; more means your rounding is now unnecessarily coarse — see symbol filters and minimum order sizes.
Rate limit weights adjusted. Your throttling was tuned to the old numbers, so you now hit limits you did not before — Binance meters weight, not count.
Error codes repurposed. Your handler routes a code to the wrong branch, which for ambiguous versus refused is the difference between reconciling and retrying.
Depending on an abstraction
A library like CCXT absorbs venue changes on your behalf, which is most of why it is worth using — see getting started with CCXT.
The trade: you now depend on the library’s own release cadence, and its fix for a venue change may itself be a breaking change for you. You have not removed version risk, you have moved it somewhere more central — and more visible, which is usually a net gain.
The rule that costs nothing
Log the versions of everything, on every start. API version, library version, server version, and which environment you are in.
When something behaves unexpectedly, the first question is what changed. Without this line you are reconstructing it from memory; with it, it is in the log already. It is one line and it pays for itself the first time.
FAQ
How do I handle exchange API breaking changes?
Pin versions, read changelogs before upgrading, validate responses rather than trusting their shape, and assert your assumptions at startup so failures are loud. The changes that hurt are the quiet ones — a renamed field or a changed default — which is why validation matters more than reacting to errors.
Should I pin my exchange client library version?
Yes. A trading integration is not the place for automatic dependency updates, since a library’s fix for a venue change can itself break your code. Upgrade deliberately, read the changelog, and test on testnet before the upgraded version touches a live account.
What happens if an MCP server changes its tools?
It is a normal part of the protocol — notifications/tools/list_changed exists
for it — and it means a server you reviewed as read-only can acquire an
order-placement tool in an update. Pin the version and record the tool list at
startup so an addition shows up as a diff.
Why did my orders start behaving differently without any code change?
Most likely a changed default on the venue or in a library — time in force, order type, margin mode. Explicitly specifying every parameter rather than relying on defaults removes this class of surprise entirely, and logging versions at startup tells you what changed.