Quick Start

One platform for all your digital ID needs.

For secure logins, KYC checks, onboarding, transaction approvals, signing documents and more, Scrive simplifies your digital identity journey with a single platform that gives you access to a growing suite of identity services. With one contract and one integration interface, you're ready to start implementing any of them in your own systems and services.

What you get​

• A single REST API at https://testbed-eid.scrive.com/api/v1 covering every eID Scrive supports.
• A drop-in frontend that handles provider UI, polling, QR codes, app-switching and error states, so you don't build them per provider.
• OpenID Connect as an alternative protocol, OIDC-certified, at no extra cost.
• A live demo app to click through every flow before you write a line of code.
• Test users connected to each provider's test environment.

How the flow works​

Every supported eID follows the same three-step pattern:

1. Your backend creates a transaction. You specify a provider, a method (auth or sign) and where to send the user when they're done.
2. You send the user to accessUrl. The eID Hub frontend drives the provider-specific flow.
3. Your backend reads the result. Either polled, or pushed to your callbackUrl the moment the transaction reaches a terminal state.

Transactions move through four states: new → started → complete or failed.

Quickstart: frontend integration​

The recommended path. Same code, every provider. The Hub frontend handles the differences so your application doesn't have to.

1. Create a transaction​

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 gives you a transaction id and a single-use accessUrl:

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

Persist id against the user's session.

2. Send the user to accessUrl​

// After your backend returns accessUrl:
window.location.href = accessUrl;

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

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"

You receive the transaction status, provider-specific user data and, for sign transactions, the signature.

4. 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. Recommended over polling for production integrations.

API-only usage​

For headless flows where your application controls the device (point-of-sale, server-driven signing, custom UI) you can drive the API without the Hub frontend.

API-only mode is supported by most providers, but not all, and the start-and-poll pattern differs per provider. See the per-provider sections in the API reference for the specific flow.

A few providers can only be used with the Hub frontend due to hosting requirements imposed by the provider; these are flagged in their reference pages.

In API-only mode your application owns the UI, polling cadence, QR rendering, error handling and provider-specific quirks. For most integrations, the Hub frontend is the simpler choice.

Alternative: multi-provider setup with MAS​

Operating across multiple markets? Use Multi-auth Selection (MAS) to let the end user pick their preferred eID in a single flow.

You declare a set of options — each one a (provider, method, providerParameters) combination — and the Hub frontend presents the picker. The user's choice flows through the rest of the lifecycle unchanged.

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

Read results from GET /mas/{id} once the user returns to your redirectUrl. The response includes which option the end user selected.

Environments​

Testbed credentials are issued on signup. Production credentials follow once your testbed integration is validated.

All requests authenticate with a bearer token:

Authorization: Bearer <your-token>

Treat the token like a password. A company can hold multiple tokens; all non-revoked tokens have equal access to transactions created under that company.

What's next​

• Try the demo app
• Browse the API reference
• Read the guides