Verifisha API Gateway · v1

Verify anyone.
In one request.

Identity, KYB, credit, employment and AML checks behind a single API — with consent built into the report lifecycle.

Get startedAPI reference

vrf_test_ keys never call a paid provider · consent-led & ODPC-aligned

Sources your checks reach

IPRSKRABRSMetropolCreditinfo

The whole integration

One call creates up to 500 reports and starts every check in them.

curl -X POST \
  https://sandbox-api.verifisha.com/api/v1/reports \
  -H "Authorization: Bearer vrf_test_..." \
  -H "Idempotency-Key: case-1042" \
  -d '{
    "reports": [{
      "subject": {
        "subjectType": "INDIVIDUAL",
        "fullName": "Jane Wanjiku Doe",
        "idNumber": "36901234"
      },
      "checksRequested": [
        "IDENTITY", "KRA_PIN", "CRB_STANDARD"
      ],
      "purpose": "Employment screening",
      "consent": { "mode": "VERIFISHA_HOSTED" }
    }]
  }'
{
  "count": 1,
  "reports": [{
    "id": "7f1c9a2e-4b3d-4e5f-8a90-1c2d3e4f5a6b",
    "status": "PENDING_CONSENT",
    "consentState": {
      "status": "PENDING",
      "consentUrl": "https://...",
      "expiresAt": "2026-09-16T08:14:22Z"
    },
    "paymentState": {
      "status": "NOT_REQUIRED"
    }
  }]
}

How it works

Reports are the execution boundary.

There is no /metropol or /kra. You pick check names; Verifisha calls the provider internally.

  1. 01

    You create a report

    A subject, and the check names you want. No provider endpoints — selecting CRB_STANDARD is how you call Metropol.

    POST /api/v1/reports
  2. 02

    The subject consents

    Verifisha sends the subject a consent link — or you attest to consent your own flow already collected.

    consent.mode
  3. 03

    Checks execute

    Verifisha calls the configured provider for each check, and tells your webhook when the report is ready.

    report.ready
  4. 04

    You read the result

    Per-check results — clear, review or flagged — with evidence and a 0–100 risk score.

    GET /api/v1/reports/{reportId}

Environments

The key prefix decides whether a provider is billed.

vrf_test_

Deterministic fixtures where sandbox support exists. Paid providers are never called, and a missing fixture can never become a live charge.

vrf_live_

Routes to the production platform API and can execute billable checks. Responses carry X-Request-Id; sandbox responses also carry X-Verifisha-Sandbox.

Read the introductionSandbox coverage