Skip to content
Certivo
Request demo
Docs

Documentation

Everything you need to build on Certivo — core concepts, environments, authentication and integration patterns. For the full endpoint-by-endpoint contract, see the API reference.

Getting started

  1. 1

    Create a sandbox organization

    Sign up and you get an organization running against simulated providers — no real data or vendor accounts needed to start.

  2. 2

    Generate an API key

    In Settings → API keys, create an organization-scoped key. Sandbox keys are prefixed sk_sandbox_. Only a hash is stored, so copy it once.

  3. 3

    Run your first verification

    Call POST /api/v1/verifications (or use the console). A clear result passes; a review or decline verdict opens a case automatically.

  4. 4

    Screen a party

    Call POST /api/v1/screenings to check a person or entity against AML, sanctions or PEP data and see how hits are scored.

  5. 5

    Build a workflow

    Compose steps and thresholds in the workflow builder, test them in sandbox, and connect the workflow to your onboarding flow.

  6. 6

    Go live

    On Growth and Enterprise plans, connect real provider credentials in Settings and promote your workflow from sandbox to production.

Core concepts

Organization

Your tenant. Every record — users, keys, verifications, cases — is scoped to one organization.

Verification

A single orchestrated identity, document, face-match or liveness check on a subject.

Screening

An AML, sanctions or PEP check on a party, scored against your thresholds.

Case

A human-review record, auto-created when a verification or screening needs attention.

Workflow

Composable steps, branches and thresholds applied to an onboarding flow.

Audit event

An immutable record of a mutating action — who did what, and when.

How a decision is formed

Signals from any vendor are normalised into one consistent shape, evaluated against your rules, and recorded immutably — so your logic never depends on a single provider's response.

1

Capture

Documents, biometrics and business data collected at the point of onboarding.

2

Normalise

Every provider response is mapped to one consistent Certivo result shape.

3

Evaluate

Workflow rules and thresholds turn raw signals into a decision.

4

Record

Inputs, outputs and the decision are written immutably to the audit log.

Evidence is normalised once, so your logic never depends on any single vendor's response shape.

Environments: sandbox vs live

Every account starts in sandbox, which uses deterministic simulated providers so you can build and test your integration end to end without real data or vendor accounts. Sandbox responses include "mode": "sandbox" and must never be used for real compliance decisions. Live connects your real provider credentials and processes real data under your Order Form and DPA. Keys are environment-specific and prefixed accordingly.

Authentication

The API uses organization-scoped API keys passed as a bearer token on every request. Create and rotate keys under Settings → API keys. Only a hash of each key is stored, so copy it when it is created; missing, malformed or revoked keys return 401.

curl -X POST https://api.certivo.com/api/v1/verifications \
  -H "Authorization: Bearer sk_sandbox_..." \
  -H "Content-Type: application/json" \
  -d '{ "type": "identity", "subject": "Jane Doe" }'

Conventions

  • All requests and responses are application/json; timestamps are ISO 8601 in UTC.
  • Every resource carries an object field naming its type; lists use { "object": "list", "data": [ … ] }.
  • Errors use a stable envelope: { "error": { "type": "…", "message": "…" } } — branch on type, not on message text.
  • The API is language-agnostic REST; any HTTP client works. There is no proprietary SDK to adopt or keep in step.

Integration patterns

Synchronous onboarding

Call the API inline during signup and branch your UX on approved / review / declined.

Back-office review

Let verifications and screenings flow into cases, and have your compliance team resolve them in the console.

Batch screening

Screen a book of existing customers or counterparties and route hits to cases for review.

Ongoing monitoring

Keep approved subjects under periodic re-screening; material changes reopen a case.

Security best practices

  • Treat API keys as secrets: store them server-side, never ship them to a browser or mobile client.
  • Use separate keys per environment and per integration so you can revoke narrowly.
  • Rotate keys periodically and immediately if one may have been exposed.
  • Enforce least-privilege roles in the console, and enable SSO/SAML on Enterprise.

Reference

Ready for the full contract? API reference → Base URL, authentication, every endpoint with request and response examples, and the error model. Questions? Contact support.