API versioning and deprecation
The full policy is in base URL and versioning.
This page covers the practical stuff: what can change without warning, what needs a new version, and what you need to do in your integration.
Build for additive change
The major version is in the path (/v1). Within a major version, we can add
things without announcing each change. Your integration should be able to
handle:
- new fields in a response
- new values in an existing enum
- new webhook event types
- new error
codevalues within an existing errortype - new optional request parameters
Two of these cause problems more often than the others.
Unknown enum values. A client that exhaustively switches over a status and throws on the default branch will break when we add a new value. Treat an unknown value as unknown, rather than as an error.
Unknown event types. Your webhook handler should return 200 for an event
type it doesn't recognise. A 4xx response causes the delivery to be retried,
and enough retries can disable your endpoint.
What gets a new version
Anything that could break an existing integration gets a new major version.
That includes removing or renaming a field, changing a field's type or meaning, making an optional parameter required, or removing a webhook event type.
These changes won't happen inside /v1.
Deprecation
When we deprecate an endpoint, it keeps working for a while and starts telling you about it:
Deprecation: true
Sunset: Sat, 31 Jul 2027 23:59:59 GMT
We give 12 months' notice before removing an endpoint or field, and 24 months' notice before a major version reaches end of life.
Security-related removals may happen faster. If that happens, we'll communicate with you directly.
If you only alert on one response header from this API, make it Sunset.
Pinning behaviour
Aleta-Version lets you pin behavioural defaults to a specific dated release
within the major version:
Aleta-Version: 2026-07-28
Additive changes can still reach you. If you leave the header out, you get the current release.
Webhook payloads keep track of their version separately. Each event includes the
api_version it was serialized with, so replaying an event from last month
gives you the same payload shape it had then.
Related
- Base URL and versioning — the full policy.
- Card issuing events — every event type and payload.