Upgrade & compatibility
Will your integration break when we ship an update? No — as long as you build against the documented HTTP routes below, not internal implementation details.
What is stable
These are the parts of the contract we commit to for integrators:
| Contract element | Where it's documented |
|---|---|
| Wallet operation routes and request/response shapes | Tokens |
Error envelope ({ error: { code, message } }) | Errors |
Authentication (X-Api-Key) | Authentication |
| Webhook ingest route and shape | Webhook ingest |
The published API reference tracks this same public surface. Admin-only routes are excluded from this stability promise — see Tokens → Admin routes.
How we roll out changes
We can upgrade the software behind the scenes without changing what you call. Existing networks keep working on the same routes; new capabilities (like multi-token support) are additive — nothing you already call changes shape or breaks.
If a route needs to change in a way that isn't additive, we publish the change here and give integrators advance notice before it takes effect.
What is not promised yet
A larger data-layer migration is on our roadmap with no public timeline. When we schedule it, we'll publish a dedicated migration guide — not a silent break. Until then, don't design around it.
Rules for integrators
- Build against documented HTTP routes, not internal implementation details.
- New fields are additive and safe to ignore. Removing or changing the meaning of an existing field gets advance notice.
- Admin routes (
X-Admin-Api-Key) are operator tooling, not part of the partner stability promise. - Use documented error codes for feature detection rather than probing behavior.