B Group

Developers

Developer overview

A REST API, a web SDK and webhooks. The sandbox exposes the same contract as production with mock providers, so you can integrate end to end before you sign anything.

How a flow works

  1. Create a flow. Choose a rulebook pack (for example the EU MiCA/AML pack), the checks, their order and thresholds. Flows can be built in the dashboard or with POST /v1/flows.
  2. Start a verification. POST /v1/verifications with the flow id and your own applicant reference returns a verification id and a short-lived session token for the SDK or hosted link.
  3. The user completes document capture. Auto-detection, quality guidance, MRZ and NFC reading; authenticity checks run in seconds and a retake is requested only when necessary.
  4. Liveness and proof of address. A certified liveness check and face match against the document portrait, then a proof-of-address upload or open-banking confirmation cross-matched to the identity record.
  5. Screening runs. PEP, sanctions and adverse-media screening, and wallet screening if the flow requires it. A risk score is produced under your configured rules.
  6. Decision or review. Automatic approval, automatic decline, or routing to your review queue with the evidence pack attached. Ongoing monitoring starts. Adverse outcomes always involve a human.
  7. Evidence pack. A time-stamped, hashed and signed evidence pack is retained as your regulatory record and available at GET /v1/verifications/{id}/evidence.
  8. Optional "save my details". The user may save their verified identity to an encrypted vault only they can open. Your evidence pack stays with you exactly as it would without the vault.

Authentication

Server-to-server

OAuth 2.0 client credentials. Exchange your client id and secret for a bearer token and send it in the Authorization header. Also send your x-api-key header; it meters usage against your tier's included volume.

Dashboard users

Your compliance and operations team sign in through managed login with multi-factor authentication. Roles and permissions are set per team member.

Vault users

The people being verified sign in to their vault with passkeys (Face ID, Touch ID, Windows Hello or a hardware key). B Group never holds the vault key.

curl https://api.bgroup.io/v1/verifications \
  -H "Authorization: Bearer $TOKEN" \
  -H "x-api-key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"flowId":"flow_01H...","applicantRef":"your-customer-id"}'

Endpoints

All endpoints are versioned under /v1, accept and return JSON, and are idempotent on retry when you send an Idempotency-Key header.

MethodPathPurpose
POST/v1/flowsCreate a flow from a rulebook pack and your configuration
GET/v1/flowsList your flows
GET/v1/rulebook/packsList available rulebook packs and versions
GET/v1/rulebook/packs/{packId}Read a pack: required checks, controls and change log
POST/v1/verificationsStart a verification for an applicant
GET/v1/verifications/{id}Read verification status and result
POST/v1/verifications/{id}/documentsRegister a document capture and obtain an upload target
POST/v1/verifications/{id}/liveness/sessionCreate a liveness session for the SDK
POST/v1/verifications/{id}/submitSubmit the completed capture for checks and decision
GET/v1/verifications/{id}/evidenceRetrieve the signed evidence pack
GET/v1/casesList review cases and alerts
GET/v1/cases/{caseId}Read a case with its evidence and history
POST/v1/cases/{caseId}/decisionRecord a human decision on a case
POST/v1/reuse/sessionsStart a vault reuse session for a returning user
GET/v1/reuse/sessions/{id}Read reuse session status
POST/v1/reuse/sessions/{id}/consentRecord the user's consent to share the listed data with you
POST/v1/reuse/sessions/{id}/completeComplete reuse after the fresh liveness check
POST/v1/vaultCreate a vault from a completed verification (user-initiated)
GET/v1/vault/meThe user's own vault metadata and sharing history
DELETE/v1/vault/meErase the user's vault (cryptographic erasure)
GET/v1/billing/usageCurrent period usage against included volume
GET/v1/billing/invoicesInvoices with credits applied
GET/v1/billing/creditsCredit ledger: counts and amounts, never other clients' identities
POST/v1/gdpr/requestsOpen a data-subject request (erasure, export, restriction)
GET/v1/gdpr/requests/{id}Read request status and the legal basis for anything retained
POST/v1/attestationsIssue a privacy-preserving attestation from a verification
GET/v1/attestations/{id}Read or verify an attestation
POST/v1/attestations/{id}/revokeRevoke an attestation

Webhooks

Register an HTTPS endpoint per flow or per client. Every delivery is signed and retried with backoff.

Events

  • verification.completed
  • verification.review_required
  • reuse.completed
  • credit.issued
  • case.decided
  • monitoring.alert
  • invoice.issued

Signature

Each request carries an X-BGroup-Signature header with a timestamp and an HMAC-SHA256 signature over timestamp + "." + body using your webhook secret.

X-BGroup-Signature: t=1760000000,v1=5257a869e7...

Reject deliveries older than five minutes and compare signatures in constant time.

Sandbox and SDKs

Sandbox

The sandbox exposes the same API contract as production. Document authenticity, liveness, screening and wallet checks are served by mock providers with deterministic test personas, so you can exercise approvals, declines, review routing and reuse without real personal data.

SDKs

  • Web SDK: available in the platform repository. Handles capture, liveness, proof of address and the optional client-side vault encryption.
  • iOS and Android SDKs: planned.
  • Hosted link: send users to a B Group-hosted flow under your brand with no SDK integration.