Versioning

BazaarLink exposes a single stable API path, /v1 — there are no date-pinned versions or version headers to manage. The API evolves continuously rather than through numbered releases.

Non-Breaking Changes

These ship without prior notice:

New endpoints
New models added to the catalog
New optional request parameters
New response fields
New schemas with optional properties
Additional response status/error codes

Write clients defensively

Ignore response fields you don't recognize, and don't fail on unknown values in enum-like fields — new ones are added as the catalog and feature set grow.

Breaking Changes

These are rare, and cover:

Removing or renaming an endpoint, parameter, or response field
Changing a field's type
Making an optional parameter required

When they do happen, a breaking change applies to a specific endpoint rather than the whole /v1 surface — there's no single version bump that could break every integration at once. We don't yet publish a formal changelog with a Breaking-change tag (see Staying Current below); for anything integration-critical, reach out via Support before you rely on undocumented behavior.

Deprecation Policy

The one routine "breaking" event you should expect: individual models get retired as upstream providers deprecate them. Query a model's current status via GET /v1/models.

1
2
3
4
5
6
7
GET https://api.bazaarlink.ai/v1/models
Authorization: Bearer sk-bl-YOUR_API_KEY

# A model within 30 days of its deprecation date shows in the catalog
# with an "EOL" badge on the Models page. After the effective date it's
# dropped from the catalog and calls return:
# 410 { "error": { "type": "model_not_available", "code": "model_retired" } }

Staying Current

We don't yet publish a dedicated API changelog or RSS feed. For now, check this page directly, watch a model's status via GET /v1/models, or contact Support if you need advance notice for a critical integration.