Developer Platform
Build Bonafide into your workflow.
REST API · Webhooks · Bulk · Intelligence
The external API surface is organized around cases, uploads, results, document verification, evidence requests, source requests, intelligence search, disputes/appeals and evidence receipts.
Developer platformRequest → Evidence → Result
POST /v1/cases
{
"policy": "institution_default",
"applicant": { "external_id": "A-1042" }
}
POST /v1/cases/{id}/uploads
GET /v1/cases/{id}/result
API naming remains verification-oriented even though the master product brand is DCS Bonafide.
Source-firstAuthoritative routes outrank appearanceMinimum evidenceEscalate only what can resolve uncertaintyHuman gateSerious adverse outcomes require reviewAuditableMaterial actions preserve lineage
WHAT BONAFIDE DOES
Purpose-built verification capabilities.
Each capability is a visible part of the verification workflow—not a hidden AI score.
◇Case & upload APIs
Create cases, upload packets and retrieve case/result state with tenant authorization.
✓Document verification
Trigger document verification under a customer policy profile.
◎Verification requests
Create official-channel source verification requests through approved workflows.
↗Issuer/employer search
Search registry intelligence and verification routes.
▦Rights APIs
Create disputes and appeals without bypassing review governance.
⌁Receipts
Retrieve/verify evidence receipts when the conditional R-Series integration is enabled after repository validation.
EVIDENCE MODELIdempotent, asynchronous and evidence-aware by design.
External POST operations use Idempotency-Key. Long-running source checks can move through pending states and produce events without forcing the client to hold a synchronous request open.
- Jobs use deterministic case/document/lane keys to prevent duplicate expensive processing
- Manual verification messages carry thread/correlation IDs
- Receipts bind to immutable decision/version IDs, not a mutable case summary
- Connector authorization, terms and legal basis are explicit metadata—public accessibility alone does not make a source “automatic”
API SEQUENCEPartial states are first-class
Create caseIdempotent request
→Upload evidenceHash + object commit
→PendingExternal source may wait
→WebhookState transition
→Final resultEvidence + receipt
WORKFLOW
From input to defensible evidence.
Bonafide follows the strongest available verification route and resumes only the affected lane when new evidence arrives.
01Authenticate tenant→
02Create case/upload→
03Receive processing state→
04Consume events→
05Retrieve result/receipt
DESIGNED FOR
One evidence model. Role-specific operations.
The same underlying case can be viewed differently by institutions, employers, reviewers, operations and candidates.
01Education platforms
Embedded admissions verification
02BGV systems
Academic/employment orchestration
03Enterprise engineering teams
APIs, webhooks and service accounts
DECISION DISCIPLINEUnknown ≠ fake.
Unmapped issuer, new template, legacy document or unavailable source must route to uncertainty/manual verification rather than an automatic accusation.
Authority VerifiedAuthoritative source evidence is consistent.Highly ConsistentStrong supporting evidence; independent source not complete.Evidence RequiredA targeted item can likely resolve the case.Unable to DetermineEvidence remains insufficient; no fraud conclusion.
DCS BONAFIDE · CREDENTIAL INTELLIGENCE PLATFORM
Establish what is bona fide.
Preserve the evidence.