API changelog

Every entry is dated. Newest first.

The compatibility promise

Inside /v1 we only add. That means:

• new endpoints, new optional request fields and new response fields can appear at any time;
• an existing field will not be removed, renamed, or change type or meaning;
• an existing endpoint will not change its status codes or its error code vocabulary for the same condition;
• a webhook event's existing data fields will not change shape — new fields may be added.

So: ignore fields you do not recognise, and do not validate responses with a strict schema that rejects unknown keys. An integration that treats a new optional field as an error breaks on our next additive release, and that is the one avoidable failure mode in this list.

Anything that cannot be done additively goes to /api/public/v2 and both versions run side by side. There is no plan for a v2.

Webhook payloads are versioned separately and per webhook: an existing webhook keeps the payload version it was created with, byte for byte, until you change it deliberately. See Webhooks → Payload versions.

Entries

Unreleased

The Business API is in development. This page starts recording changes with the first release; nothing here is live yet, and this entry exists so the page cannot be mistaken for an empty changelog after a release.

• /api/public/v1 — REST surface, tsk_ API keys, scopes, location restriction, cursor pagination, Idempotency-Key on every write.
• Webhooks widened to shop scope with a much larger event catalogue and payload v2. Existing program-scoped webhooks keep their behaviour and their payload bytes.
• The MCP connector with tmk_ keys.