Skip to main content
Scrive logoeID Hub Documentation

With eID Hub Frontend

The recommended integration path. The Hub frontend handles every provider's UI so your application doesn't have to. The flow is the same three steps regardless of which eID provider the user chooses.

The flow​

1. Create a transaction​

Call POST /transaction/new from your backend, specifying the provider, method and where to send the user when they're done.

curl -X POST https://testbed-eid.scrive.com/api/v1/transaction/new \
  -H "Authorization: Bearer $SCRIVE_EID_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "seBankID",
    "method": "auth",
    "providerParameters": { "auth": { "seBankID": {} } },
    "redirectUrl": "https://your-app.example.com/eid/return",
    "callbackUrl": "https://your-app.example.com/eid/callback"
  }'

The response includes a single-use accessUrl:

{
  "id": "14619149-cdcc-48dd-aebe-aa2cfb8e87f2",
  "accessUrl": "https://testbed-eid.scrive.com/access/..."
}

Persist the transaction id against the user's session.

info

When using the eID Hub frontend you do not need to call the POST /transaction/{id}/start endpoint. The Hub frontend starts the transaction automatically when the user arrives at accessUrl.

2. Send the user to accessUrl​

Redirect the user to the accessUrl or open it in a popup:

window.location.href = accessUrl;

The user completes the authentication on the Hub and is redirected back to your redirectUrl.

warning

accessUrl is single-use and cannot be embedded in an iframe. Use a full redirect or popup only.

tip

Redirect is recommended over popup. Some platforms and in-app browsers block popup windows, which can silently break the flow for certain users.

3. Fetch the result​

When the user lands on your redirectUrl, query the transaction:

curl https://testbed-eid.scrive.com/api/v1/transaction/$TRANSACTION_ID \
  -H "Authorization: Bearer $SCRIVE_EID_TOKEN"

The response contains the transaction status and provider-specific user data. For sign transactions it also includes the signature.

Your redirectUrl endpoint should be stateless: do not rely on data stored in the browser (cookies, session storage, localStorage). Some providers return the user in a new browser tab.

If accessUrl was opened in a popup, your redirectUrl should return a script that closes the popup window. If the user was fully redirected to accessUrl, redirectUrl should be the next step in your UI.

Use callbacks instead of polling​

Set callbackUrl at transaction creation and the Hub will POST to it the moment the transaction reaches complete or failed. This is recommended over polling for production integrations.

Provider-specific notes​

Swedish BankID​

When the BankID app is on the same device as the browser, BankID cannot return the user to the original tab and opens a new tab instead. Scrive attempts to detect the user's browser to return them to the same one, but this may fail and the user may land in a different browser. The transaction carries over either way, but your redirectUrl must not rely on browser state.

For phone authentication or signing, set the callInitiator parameter to a non-null value.

Freja eID​

On mobile, when no preset user-identifying info is provided, the user is redirected to the Freja app and returned to eID Hub in a new browser tab. As with Swedish BankID, your redirectUrl must be stateless.