Skip to main content
sajn versions the REST API and webhook payloads by date. A version is named after the month it’s released, in YYYY-MM format, such as 2026-10. Within a version, sajn makes only additive changes: new endpoints, new optional request fields, new response fields, and new webhook events. Your integration must ignore fields it doesn’t recognize. A change that could break a working integration, such as removing or renaming a field or an endpoint, ships only in a new version.

​
Supported versions

The guides and the API reference describe the latest version, 2026-10. To see the 2026-09 endpoints, select 2026-09 in the version switcher of the API reference. For the changes in each version, see the changelog.

​
Choose a version

To choose the version for a request, send the Sajn-Version header:
Replace API_KEY with your API key. The header takes precedence over every default. Without the header, a request with an API key uses your organization’s default, and a request with an OAuth access token uses the OAuth app’s version. We recommend sending Sajn-Version on every request and keeping it in your code permanently. Your integration then behaves the same no matter what the organization default is, and you upgrade by changing one value after you’ve tested against the new version.

​
Organization default

Each organization has one default version, shared by all its workspaces and API keys. There’s no per-key version. An organization without a default is pinned to the latest version by its first API key request that has no Sajn-Version header. After that, the default changes only when a member who can manage the organization’s settings changes it in the API-version section under Inställningar > Utvecklare in the dashboard. That section also shows how many requests over the last 72 hours used each version, and whether they chose it with the header or relied on the default.

​
OAuth app version

Each OAuth app has its own version, set to the latest version when you create the app. A request with the app’s access token and no Sajn-Version header uses the app’s version, never the default of the organization that connected the app. An app serves many organizations, so its contract stays the same when one of them changes its default, and a request from an app never sets an organization’s default. To call another version from an app, send the Sajn-Version header.

​
Response headers

Every response states the version that served it. A response on a deprecated version also tells you when the version stops working: We recommend logging a warning when a response carries Sunset, so you notice a deprecated version long before its sunset date.

​
Errors

A request with a version problem fails with an HTTP 400 Bad Request status code before it reaches the endpoint. The message lists the supported versions:
On 2026-09, the body has only message and code. For the error shape and every other code, see Errors. An endpoint that a version removed returns 404 ROUTE_NOT_FOUND on that version and every later one. On earlier versions, it keeps working until their sunset date.

​
Webhook versions

Each webhook endpoint has its own API version, which sets the shape of the payloads it receives. The endpoint keeps its version when the organization default changes, so you can move the API and your webhook receivers separately.
  • To choose the version when you create an endpoint, set apiVersion in the POST /api/v1/webhooks request body. Without it, the endpoint gets your organization’s default version.
  • To change the version of an existing endpoint, send apiVersion in a PATCH /api/v1/webhooks/{id} request. Every delivery after the change uses the new version, including automatic retries of earlier deliveries. A retry of a delivery that you request resends that delivery’s original body, in the version it was first sent in.
Each delivery states its version twice: in the Sajn-Version request header and in the apiVersion field of the body. In the following delivery, data.object is shortened:
The version also decides the envelope and the signature headers. A 2026-09 delivery has event and payload instead of type and data, has no id, uses the attempt time as createdAt, adds webhookEndpoint, and is signed with X-Sajn-* headers instead of the Standard Webhooks headers. For the payloads, see Webhooks.

​
Version lifecycle

  • sajn releases at most two new versions a year.
  • At most two versions are supported at a time: the latest version and the one before it.
  • When a new version is released, the previous one is deprecated. It keeps working for about 12 months, until the sunset date in the supported versions table.
  • From the sunset date, every request on the version fails with 400 API_VERSION_SUNSET, including requests that rely on an organization default set to that version. Move your requests, your organization default, and your webhook endpoints to a supported version before then.
To move to 2026-10, see Upgrading to 2026-10.

​
Next steps