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.
vrf_test_ keys never call a paid provider · consent-led & ODPC-aligned
Sources your checks reach today
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.
- 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 - 02
The subject consents
Verifisha sends the subject a consent link — or you attest to consent your own flow already collected.
consent.mode - 03
Checks execute
Verifisha calls the configured provider for each check, and tells your webhook when the report is ready.
report.ready - 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}
What you can check
8 checks are runnable today.
The rest appear in the catalogue API but have no execution strategy yet — listed here so you know why you cannot select them. Read the live catalogue from GET /api/v1/checks/definitions rather than hard-coding it — prices are workspace-specific.
Identity
IDENTITYLiveValidates a Kenyan national ID against IPRS records.
IPRS · INDIVIDUAL
KRA_PINLiveConfirms an active KRA PIN record from the national ID.
KRA · INDIVIDUAL
IDENTITY_WITH_IMAGENot yet activeImage-backed IPRS identity details. No execution strategy yet.
IPRS · INDIVIDUAL
FACE_MATCHNot yet activeSelfie against the identity image, with liveness. No execution strategy yet.
— · INDIVIDUAL
Business
BUSINESS_VERIFICATIONLiveBRS.
BRS · COMPANY
Credit
CRB_STANDARDLiveSummary credit report.
Metropol · INDIVIDUAL
CRB_FULLLiveFull credit report.
Metropol · INDIVIDUAL
CREDITINFO_SCORELiveCredit score and risk grade.
Creditinfo · INDIVIDUAL
CRB_SCOREDetails to followIn the API contract. Description to follow.
— · INDIVIDUAL
CREDITINFO_STATUSDetails to followIn the API contract. Description to follow.
— · INDIVIDUAL
CREDITINFO_COMPLiveContracts, balances, arrears and fraud report.
Creditinfo · INDIVIDUAL
Employment
EMPLOYER_VERIFICATIONLiveVerifies declared employer information.
Employer records · INDIVIDUAL
Risk & AML
SANCTIONS_PEPNot yet activeSanctions, watchlist and PEP screening with fuzzy-name matching. Implemented, not yet active.
Sanctions & PEP lists · INDIVIDUAL
AML_PEPNot yet activeCatalogue alias for combined AML screening. No separate execution strategy.
AMLSCAN · INDIVIDUAL
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.