Skip to content
rigid.fi

Authentication

OAuth2 client credentials, org-wide and programme-pinned clients.

Every request other than the token endpoint itself requires a bearer token, minted with the OAuth2 client_credentials grant.

Client credentials

POST https://api.rigid.fi/v1/oauth/token accepts your client ID and secret two ways: as HTTP Basic credentials, or in the request body (form-encoded or JSON) as client_id / client_secret alongside grant_type=client_credentials. Basic auth is the simplest:

curl -X POST https://api.rigid.fi/v1/oauth/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -d 'grant_type=client_credentials'

Tokens expire after 30 minutes (expires_in: 1800). There is no refresh grant — re-mint a new token with the same credentials once the old one expires or a request comes back 401. The token endpoint is rate-limited to 30 requests per 15 minutes per client; exceeding it returns 429.

Client types

Every API client is one of two types, chosen when it's created in the console:

  • Org-wide clients act across every programme in your organisation. They're created from the organisation's own API clients page and require org admin access to set up.
  • Programme-pinned clients are restricted to a single programme. They're created from that programme's API clients page and can only read and write data belonging to it — any request touching another programme is rejected.

Some operations are gated to org-wide clients regardless of which client type made the surrounding request, because they cross the tenant's admin boundary rather than a single programme's — the final transactions-list step in the quickstart is an example.

Cardholder attestation is different: it is not reachable by any API client, org-wide or programme-pinned. Attestation is an admin-only override of the KYC gate, so it requires a console admin session — an unattended integration (or a non-admin console user) can never self-attest the cardholder it represents. Attestation flips kyc_complete to true while kyc_state continues to record what the verification engine concluded.

Using the token

Send the minted token as a bearer token on every subsequent request:

Authorization: Bearer <access_token>

Key material

Access tokens are ES256-signed JWTs — treat them as opaque bearer credentials and rely on the API to validate them; verifying a token's signature yourself is not something a typical integration needs to do.