Changelog

Summary: every change to the partner API is recorded with its date, what changed, whether it can break an existing integration, and what to do if it can. Read it on the Changelog page of your partner portal, or have your integration poll GET /changelog.

Reading it from your integration

GET /api/inbound/{slug}/changelog (signed like any request) returns:

{
  "ok": true,
  "latest": "2026-10-23",
  "changelog": [
    {
      "date": "2026-10-23",
      "title": "Reconcile your accounting with a per-order billing feed",
      "detail": "New: GET /api/inbound/:partnerSlug/billing/orders returns, per order, ...",
      "breaking": false,
      "endpoints": ["GET /api/inbound/:partnerSlug/billing/orders"]
    }
  ]
}

• Entries are newest first. latest is the date of the newest one. Several entries can share a date, so to find what is new, compare the entries themselves (for example by date and title) with what you stored, rather than only comparing latest.
• breaking: true means an integration that worked before that date can stop working. Such an entry also has action: what you need to do, and by when.
• endpoints names the affected endpoints exactly as they appear in the API.
• Entries about the partner portal rather than the API carry "surface": "portal".

See the reference for the full field list.

Changes to the API version

Accounts on API version 1, which does not check an order before payment, are being moved to version 2. While your account is on version 1, signed responses may carry standard Deprecation, Sunset and Link headers announcing the retirement date. The move is described in the Orders lifecycle guide (check, then order) and confirmed during the go-live certification.