Packages
All packages require Node.js 18 or newer for Node-based builds and tooling.
Start by stack
Server client
UseAuthboundClient for server-side API calls.
Verification policies
Useauthbound.policies to create project-scoped policies, then pass the returned ID to verification creation.
Policy creation requires @authbound/server 0.4.0 or later.
{ claim, values } for exact typed requirements, such as { claim: "age_over_18", values: [true] }. Values can be strings, booleans, or safe integers; they are not coerced. Eligibility claims accept only [true]; an age gate can request an age proof without requesting a birth date. Claims must be unique after alias resolution. Scalar equality constraints are not supported for EUDI PID nationality, whose result is an array.
Choose exactly one target: attestationType, credentialDefinitionId, or vct. Built-in attestations also require ecosystem and format; custom definition and VCT targets support dc+sd-jwt. Policy creation requires policies:write; list and get require policies:read.
SDK 0.4.0 rejects creation-time returnAttrs (REST return_attrs). The returned policy.returnAttrs describes the output keys, including canonical aliases such as birth_date; it is read-only metadata. Existing saved policies retain their stored selections. Select only the claims your application needs. Matching returned identity details to an existing customer record remains your application’s responsibility.
Policy presets
UsePolicyPresets for starter policies with concrete, versioned IDs.
For setup UIs, call
fetchPresetRegistry("https://api.authbound.io") to load cacheable public preset metadata from /v1/presets.
React UI
UseAuthboundProvider once near the app root and render VerificationWall where the user should verify.
For Vite React apps, use import.meta.env with the VITE_ prefix. Next.js apps should use @authbound/nextjs/client and NEXT_PUBLIC_* instead. See Verify with Next.js.
Station BFF routes
Station access depends on organization feature enablement. SDK exports alone do not enable Stations in the dashboard. Nuxt auto-registers station entry, display, operator, and disclosure routes under/api/authbound/stations/*. Next.js requires manual App Router route files; import the createStation*Route helpers from @authbound/nextjs/server. See Verify with Next.js.
API origin
All packages should point to:Status auth
Browser SDKs use the publishable key and the short-livedclientToken returned by a verification create call. Secret keys stay on your server.
SDK-managed same-origin sessions can finalize browser route UX after a verified status. The session route checks the pending browser binding, uses the secret key to fetch the signed result, and only then sets the SDK cookie. Continue to use webhooks or signed result lookups for durable backend reconciliation.
Browser session coordination
The default SDK-managed session mode requires the Web Locks API. Same-origin tabs serialize verification creation and session finalization under a lock keyed by the resolved endpoint origin. Ifnavigator.locks is unavailable or a lock cannot be acquired, the SDK fails with session_coordination_unsupported instead of risking a session race.
Use manual session mode when you support a browser or embedded webview without Web Locks, or when several origins share a parent-domain session cookie. In manual mode, your server owns session creation and cross-origin coordination.
Calls to start() while a verification start is already pending share the same promise only when their options match. Different options fail with verification_invalid_state. Keep metadata and provider objects stable when more than one component can start the same flow.
Time limits
Verifications and theirclientToken expire after 15 minutes by default.
SDK-managed sessions set a __authbound_pending cookie when a verification is created. This cookie is capped at 10 minutes, regardless of your session cookie maxAge. Session finalization requires the pending cookie to still be present. Long wallet flows can fail with VERIFICATION_BINDING_REQUIRED if the user takes longer than 10 minutes before the browser finalizes the session.
AuthboundClient API surface
AuthboundClient from @authbound/server exposes thin Gateway API connectors:
Use
verifications.getStatus(verificationId, { clientToken, publishableKey }) when you need server-side status checks with browser credentials. Use verifications.getResult(verificationId) for signed, high-trust reconciliation.
See Issue credentials for issuance guides and Verify overview for verification statuses and failure codes.
Status subscriptions
Framework packages subscribe to verification progress automatically. Custom UI can callclient.subscribeToStatus on the client returned by createClient from @authbound/core.
The SDK uses SSE at /v1/verifications/{id}/events/sse, with polling at /v1/verifications/{id}/status as fallback. Both use Authorization: Bearer <clientToken> and X-Authbound-Publishable-Key. The SSE client uses fetch so credentials stay in headers.
Pass { expiresAt: verification.expiresAt } as the fourth argument to client.subscribeToStatus(verification.verificationId, verification.clientToken, onEvent, options). Polling stops at terminal status or that deadline; without an expiry, the default polling ceiling is five minutes. Polling intervals start at one second and increase to thirty seconds. A 503 realtime_unavailable response switches to polling when fallback is enabled.
A local timeout is not a successful verification. Offer a restart and reconcile the result on your server.