Skip to main content
The sajn API authenticates every request with a bearer token in the Authorization header. For a server that works with your own sajn workspace, that token is an API key, which this page covers. If you build software that other sajn customers connect to their own accounts, use OAuth 2.0 instead. If you’re not sure which applies to you, see Choosing an authentication method.

Create an API key

To create a key, you need the Hantera API-nycklar permission in the workspace, and the organization needs API access. API access is included from the Team plan, and in every sandbox.
  1. In the sajn app, open the workspace that the integration works in.
  2. Go to Inställningar > Utvecklare > API-nycklar. Utvecklare is in the workspace settings.
  3. Click Skapa API-nyckel.
  4. Enter a name that says what uses the key, such as crm-sync-production.
  5. In Utgår, choose when the key expires: after 30 days, 90 days, 1 year, or never.
  6. Click Skapa nyckel, and copy the key. sajn shows the full key only once.
sajn emails every workspace member who can manage API keys when a key is created.

Key prefixes

The prefix tells you which kind of organization a key belongs to: Both kinds use the same base URL. The key decides which environment the request reaches.

Send the key

Send the key as a bearer token in the Authorization header, together with the API version:
These samples read the key from the SAJN_API_KEY environment variable.

What a key can do

A key is bound to the workspace you created it in, and acts as the user who created it:
  • One workspace. Every request works on that workspace’s documents, contacts, and templates. You never send a workspace ID. If your organization has several workspaces, create one key per workspace.
  • The creator’s role. The key can do what the creator’s workspace role allows, and nothing more. If the role changes, so does what the key can do. A request that the role doesn’t allow fails with the code PERMISSION_DENIED.
  • No scopes. Unlike an OAuth token, an API key isn’t limited to a set of scopes.
If the creator is deactivated, or the organization is suspended, requests with the key fail with the code ACCOUNT_INACTIVE. To keep an integration running when people change roles or leave, we recommend creating its keys from an account that exists only for the integration. To check which user, workspace, and organization a key acts as, call GET /me:
The response is similar to the following:

Rotate a key

To replace a key without downtime, do the following:
  1. Create a new key, as described in Create an API key.
  2. Deploy the new key to your integration.
  3. Confirm in the Senast använd column of the API key list that the old key is no longer used.
  4. Delete the old key.
The API key list also lets you regenerate a key. Regenerating replaces the key at once: the old value stops working immediately, and the new key keeps the name and expiration date. The new key acts as the user who regenerated it. Use it when a key has leaked and must stop working now.

Keep keys safe

Store keys in environment variables or a secrets manager. Never commit a key to version control, and never send it to a browser or a mobile app.
A separate key for each integration and environment limits what a leaked key exposes, and lets you revoke one without breaking the others. Use a sandbox key for development and testing.
A key that expires limits how long a leaked key works. Rotate it before it expires.
The API key list shows when each key was last used. Delete keys you no longer use. To see individual requests, use the API logs under Inställningar > Utvecklare > Loggar.

Authentication errors

A failed authentication returns an error in the standard shape. Branch on code, not on message, show userMessage to your users, and log requestId:
The following codes relate to authentication: In API version 2026-09, the error body has no requestId, and the code values differ. For every error code, see Errors. For the request limits per organization, see Rate limits and quotas.