Skip to content
KivraDevelopers
This is a new version of the Kivra Developer Docs. Report issues or share feedback at avsandare.support@kivra.se. The previous version can be found here.

Authentication

The Tenant API uses OAuth 2.0 client credentials. Kivra provides a client_id, client_secret, and the tenant key or keys the client may use. The client is the OAuth identity making the request; the access token represents that client and is scoped to its authorised tenants.

The endpoint is also available in the Tenant API reference. Partner integrations use the same endpoint; see the Partner API authentication guide.

Encode the credentials without a trailing newline and request a token:

Terminal window
BASE64_CREDENTIALS=$(printf '%s' "$KIVRA_CLIENT_ID:$KIVRA_CLIENT_SECRET" | base64)


curl -X POST \
  "https://sender.sandbox-api.kivra.com/v1/auth" \
  -H "Authorization: Basic $BASE64_CREDENTIALS" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials"

Send the returned token with every protected request:

Authorization: Bearer <access_token>

Tenant API access tokens are valid for eight hours. Reuse a token until shortly before it expires rather than requesting one per delivery.

Tenant scoping

Section titled “Tenant scoping”

The tenant key identifies the sender tenant, not the OAuth client, in a request:

POST /v2/tenant/{tenantKey}/content

Your client can act only on tenants in its assigned scope. If a new tenant is created for a client, authenticate again before using it so the new scope takes effect. A client may be acting as a partner for the tenant in the path, but the tenant remains the sender and owner of the content. Do not expose client credentials or access tokens in browser or mobile code, repositories, or logs.