Versioning and changes

The API is in preview: it runs on the sandbox, and its version is 0.1.0. Here's how it changes, and how to build so that changes don't break you.

What stays put

• Endpoints: their paths and methods.
• Operation names: the operationId of each endpoint, such as search_rates and get_quote. Generated clients, the SDK and AI tools name their methods after them.
• Field names and types in requests and responses.
• Error codes: errors[].code, such as insufficient_scope and rate_limited.

A change to any of these is a breaking change, and it's announced in the changelog before it happens.

What can be added at any time

• New endpoints.
• New optional parameters on an existing endpoint.
• New fields in a response.
• New error codes.
• Better wording in message and errors[].message, which are written for people.

Build to tolerate additions

• Ignore fields you don't know. Don't fail when a response has a field your code doesn't expect.
• Branch on errors[].code, never on the message text.
• Have a fallback for codes and values you haven't seen, such as a new error code or a new container type.
• Send only the parameters you need. Defaults are documented in the API reference.

Staying informed

Subscribe to the changelog's RSS feed. Every change that affects an integration is listed there, by date.