Canonical v1 paths

New integrations should use /api/v1. Existing unversioned /api routes remain supported as legacy aliases.

No retirement is currently planned for the legacy aliases or API v1. The OpenAPI document identifies the supported routes and schemas.

Changes within a version

We may add optional fields, new endpoints and new catalog records within v1. Ignore unrecognized response fields rather than rejecting the whole response.

Catalog facts can change after source review. Model availability in the sourcing catalog can also change. Neither is a frozen commercial offer.

Store exact identifiers and retain source dates where your application needs a reproducible answer. Handle missing records and null values explicitly.

Breaking changes and notice

Our policy is to provide at least 90 days of notice before a breaking public API change or retirement. Urgent security changes are the exception.

Removing a documented field, changing its type or adding a required request field is a breaking change. A new optional response field is additive.

We will publish retirement notices and migration instructions on this page and in the OpenAPI description. No retirement notice is active.

Do not assume every legacy alias will exist indefinitely. Use versioned paths and check the policy when maintaining your integration.

Test behavior, not response wording

Validate field types and required fields against OpenAPI. Handle documented error codes independently of their explanatory messages.

Use the sandbox to test inquiry validation without creating commercial traffic. Keep production acceptance tests separate from schema checks.