Skip to main content
The REST alternative to OpenID Connect. Two calls: one to start a login, one to read the result. Same hosted page, same BankID engine, same claims — only the plumbing differs. Use it when running an OIDC client is more trouble than it is worth. The typical case is a native mobile app: your server starts the login, the app opens the URL in an in-app browser, and a custom-scheme redirect drops the user straight back into the app.
Authenticated with your normal sajn API key, scoped login:write and login:read. See Authentication.

​
1. Start a login

The response is the session, the same object that step 3 reads, with loginUrl and expiresAt set:
Response
Later reads return loginUrl and expiresAt as null. The user must finish authenticating by expiresAt, 15 minutes after the request. redirectUri must be registered on the client. Custom schemes are supported so an in-app browser can dismiss itself back into your app.

​
2. Send the user to loginUrl

Open it in a browser, in-app browser or web view. The user authenticates with BankID on sajn’s hosted page. When they finish, we redirect to your redirectUri:
The redirect is only a handle — never treat it as proof of authentication. Anyone can craft that URL. The identity lives behind step 3, which is authenticated as your organization.

​
3. Read the result, from your server

Completed
sub and claims are null until status is COMPLETED. claims then has every claim key; a claim your client isn’t approved for is null, as nin and nin_type are in the preceding example for a client without the nin scope. The projection is the same one the OIDC id_token uses. In API version 2026-09, status is lowercase: pending, complete, failed, or expired, and method is BANKID_SE instead of SE_BANKID. A completed result stays readable for 30 minutes, which is room for a retry or a brief outage on your side. After that it is gone; the authentication itself is still recorded for billing. A session that has run out without completing, or that belongs to another workspace, returns 404 NOT_FOUND, not 403: “exists but isn’t yours” is itself information. For every error code, see Errors.

​
Handling the user who never comes back

The in-app browser case has a real failure mode: the user completes BankID, then closes the browser before the redirect fires. Your app never learns what happened. Two ways to cover it:

Webhook

Subscribe to login.completed. It fires whether or not the redirect arrives.

Poll

GET the session until it leaves PENDING. Simple, and fine at low volume.
The authentication completes on our side regardless — a background watchdog finishes the flow if the browser stops responding, so the result is there when you ask for it.

​
Differences from OIDC

​
Reference

POST /api/v1/login/sessions

Full request and response schema

GET /api/v1/login/sessions/{id}

Full response schema