Verify a user

Build the server side of an Authbound verification flow. Your app creates a verification with a secret key, then returns a short-lived wallet handoff that the browser SDK can render.

1. Get keys and a policy ID

In the Authbound dashboard, copy:

a secret key that starts with sk_test_
a publishable key that starts with pk_test_

Every verification runs against a policy, which decides what to ask the user for and what counts as verified. Start with one of these common presets — these IDs work in every project, no setup needed:

Preset	Policy ID	Verifies
`KYC_BASIC_EUDI`	`pol_kyc_basic_eudi_v1`	KYC via an EU Digital Identity Wallet
`KYC_BASIC`	`pol_kyc_basic_authbound_v1`	KYC via an Authbound PID
`AGE_GATE_18`	`pol_age_over_18_authbound_v1`	That the user is 18 or older

See SDKs and frameworks for the complete preset list.

AUTHBOUND_SECRET_KEY=sk_test_...
AUTHBOUND_PUBLISHABLE_KEY=pk_test_...
AUTHBOUND_POLICY_ID=pol_kyc_basic_eudi_v1

Presets are built in and resolve when you create a verification, so don’t worry if they don’t show up under your project’s policy list. When you outgrow them, create your own policy with @authbound/server or POST /v1/policies and use its ID instead.

2. Install the server SDK

pnpm add @authbound/server

3. Create the verification

Your server calls Authbound with a secret key, then returns only the fields the browser needs.

import {
  AuthboundClient,
  toBrowserVerificationResponse,
} from "@authbound/server";

const authbound = new AuthboundClient({
  apiKey: process.env.AUTHBOUND_SECRET_KEY!,
});

export async function createUserVerification(userId: string) {
  const verification = await authbound.verifications.create({
    policyId: process.env.AUTHBOUND_POLICY_ID!,
    customerUserRef: userId,
    idempotencyKey: `verify:${userId}`,
  });

  return toBrowserVerificationResponse(verification);
}

4. Return the browser contract

Every UI SDK guide returns this shape from your create route.

Field	Meaning
`verificationId`	The verification ID returned by Authbound.
`authorizationRequestUrl`	Browser-compatible wallet invocation data resolved from `clientAction.data`. Do not use the hosted `verificationUrl` as a QR or wallet deep link.
`clientToken`	Short-lived token for this verification’s browser status checks.
`expiresAt`	When the wallet handoff expires.
`deepLink`	Optional mobile wallet link. SDK routers return the resolved wallet invocation URL when it is safe to open on the current device.
`walletHandoffKind`	Optional original handoff kind, such as `request_blob`, so custom UI can avoid treating raw request payloads as deep links.

The SDK server routers normalize this contract for you. Only build this mapping yourself when you are writing a custom backend route instead of mounting the SDK router.

5. Render the wallet flow

Choose the framework guide that matches your app.

Next.js

Start here for a full App Router example.

React

React UI with a small backend create route.

Vue

Vue plugin and VerificationWall.

Nuxt

Nuxt module, server route, and route middleware.

Express

Build the create route yourself.

Hono

Add a verification route to a Hono backend.

Browser status headers

The browser uses the returned clientToken for this one verification. Authbound SDKs send:

Authorization: Bearer <clientToken>
X-Authbound-Publishable-Key: pk_test_...

You do not need to expose your secret key or build a custom status endpoint for the standard browser SDK flow. Framework packages subscribe automatically. For custom UI, pass expiresAt into subscribeToStatus. See status subscriptions for SSE fallback and polling deadlines.

Direct REST action kinds

If you use the REST API directly, client_action.kind tells you how to handle client_action.data.

Kind	Data
`link`	A wallet URL or deep link. This can be used as `authorizationRequestUrl`.
`qr`	Wallet invocation URI or HTTPS request URL to encode in a QR code.
`request_blob`	Raw OpenID4VP request data. SDK UI renders it as QR payload and does not synthesize a deep link from it.
`dc_api`	JSON-encoded Digital Credentials API request data. Treat it as an opaque browser-native handoff payload; create responses intentionally omit `verification_url`.

Terminal verifications (verified, failed, canceled, expired) do not include client_action. Wallet handoff fields are only present while the verification can still be handed to a wallet.

Production next steps

Handle webhooks and signed results.
Store a verified flag in your own user or session model.
Protect application routes after the trusted server-side result is stored.

Start here

Identity verification

Credential issuance

AI

1. Get keys and a policy ID

2. Install the server SDK

3. Create the verification

4. Return the browser contract

5. Render the wallet flow

Next.js

React

Vue

Nuxt

Express

Hono

Browser status headers

Direct REST action kinds

Production next steps

​1. Get keys and a policy ID

​2. Install the server SDK

​3. Create the verification

​4. Return the browser contract

​5. Render the wallet flow

Next.js

React

Vue

Nuxt

Express

Hono

​Browser status headers

​Direct REST action kinds

​Production next steps

1. Get keys and a policy ID

2. Install the server SDK

3. Create the verification

4. Return the browser contract

5. Render the wallet flow

Browser status headers

Direct REST action kinds

Production next steps