Education & Workforce
Credential Verification API
Checking a degree is a twenty-minute phone call to a registry that may not answer. Doing it for every hire, across thirty countries, is a staffing problem disguised as a data problem.
- Background screening firms
- Applicant tracking vendors
- Staffing agencies
- Regulated employers
- Professional bodies
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Credential fraud is persistent and mundane. Invented qualifications, upgraded classifications, real institutions with fabricated dates, and a healthy industry selling convincing certificates from institutions that exist only as a website. Screening firms catch a steady proportion of it, mostly by contacting issuers directly, which is slow and does not scale with hiring volume.
The verification routes that do scale are uneven. Some countries have a national clearinghouse covering most of higher education. Some professional registers publish a searchable licence status that is authoritative and current. Many institutions answer only by email, in their own time, in their own language, and some charge per enquiry. A verification product is therefore an orchestration problem: route each check to the best available authorised channel, fall back sensibly, and be clear about what each channel actually proves.
The temptation is to fill the gaps with inference — scraping a profile site, matching a name against an alumni list, scoring plausibility. That produces an answer that looks like verification and is not one. The distinction between 'confirmed by the issuer' and 'consistent with other records' has to survive into the response, because a hiring decision will be made on it and someone may later have to defend it.
Who buys this
Background screening firms, Applicant tracking vendors, Staffing agencies, Regulated employers, Professional bodies
What the API returns
What comes back
- Verification status per credential — confirmed, not confirmed, unable to verify, or disputed
- Evidence record naming the channel, the responding authority and the response date
- Confirmed attributes where the issuer provides them — award, classification, dates, awarding body
- Professional licence status including restrictions, conditions and expiry where the register publishes them
- Institution legitimacy check against recognised accreditation registers
- Turnaround expectation per check, since manual channels take days rather than seconds
- Discrepancy detail where the claim and the issuer record differ, stated factually
- Full audit trail suitable for a regulated employer's file
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/verifications | Submit one or more credentials for verification |
| GET | /v1/verifications/{id} | Status, result and evidence record for a submitted check |
| GET | /v1/institutions/{id} | Recognition and accreditation status of an awarding body |
| GET | /v1/registers/{register}/licence | Live professional licence status lookup |
| POST | /v1/consent | Register the subject's consent and authorisation for a check |
| GET | /v1/coverage | Verifiable routes and expected turnaround by country and issuer |
Request and response
illustrativeRequest
{
"subject": { "ref": "cand_41822", "consent_id": "cons_9f12" },
"credentials": [
{ "type": "degree", "institution_id": "gb-univ-0142",
"award": "BSc Computer Science", "classification": "2:1",
"awarded_year": 2019 },
{ "type": "professional_licence", "register": "gb-nmc",
"registration_number": "21A4471B" }
],
"priority": "standard"
}Response
{
"verification_id": "ver_61b8d2",
"submitted_at": "2026-10-21T10:02:11Z",
"results": [
{
"credential": "degree",
"status": "confirmed",
"confirmed": { "award": "BSc Computer Science", "classification": "2:1",
"conferred": "2019-07-12" },
"evidence": { "channel": "national_clearinghouse",
"authority": "HE verification service",
"responded_at": "2026-10-21T10:02:48Z",
"proves": "issuer_record_match" }
},
{
"credential": "professional_licence",
"status": "confirmed_with_conditions",
"confirmed": { "status": "registered", "expires": "2027-04-30",
"conditions": ["supervised practice order"] },
"evidence": { "channel": "public_register",
"authority": "statutory regulator",
"responded_at": "2026-10-21T10:02:50Z",
"proves": "current_register_entry" }
}
],
"pending": [],
"unverifiable": [],
"note": "Status reflects issuer and register records only. No inference used."
}Where the data comes from
| National education clearinghouses | Where they exist, these are the authoritative route and cover a large share of higher education in those countries |
| Institution registrars | Direct authorised enquiry, which is the fallback for most of the world and operates on human timescales |
| Statutory professional registers | Licence status for regulated occupations, usually published and current — the strongest evidence available anywhere in this product |
| Accreditation and recognition registers | Official lists of recognised awarding bodies, which is how an unaccredited certificate mill is identified |
| Digital credential infrastructure | Verifiable credentials and signed digital diplomas, where an issuer has adopted them — instant and cryptographically checkable, but coverage is still patchy |
| The subject's consent record | Not a data source but a precondition: verification without the candidate's documented authorisation is unlawful in most jurisdictions and refused by most issuers |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Channel routing per credential, choosing the most authoritative available route and recording which one answered rather than presenting all results as equivalent
- Strict separation of confirmation from corroboration — an issuer record match and a consistency check are different statuses and never collapse into one
- Entity resolution on institutions, which is harder than it sounds given mergers, renamings, campus splits and transliteration
- Name and date matching tolerant of transliteration, married names, diacritics and local date conventions, with the match basis recorded
- Certificate-mill detection from accreditation registers rather than from reputation signals, so the finding is about recognition status and nothing else
- Explicit 'unable to verify' as a first-class outcome with the reason, because the alternative is a guess presented as a result
- Consent capture and expiry enforced at the API level, so a check cannot be run on a stale authorisation
- Full immutable audit logging of request, channel, response and timing, which is what a regulated employer's file and any later dispute both require
What it changes for the business
Faster screening
Instant channels resolve a large share of checks in seconds, leaving human effort for the ones that genuinely need it.
Documented evidence
An evidence record naming the authority and date is what stands up in a regulatory inspection or an employment dispute.
Fewer bad hires
Classification inflation and unrecognised awarding bodies are both caught by routes a manual process often skips.
Honest coverage
Knowing which countries and issuers are verifiable, and how fast, lets you price and promise accurately.
How it fits into your product
How it embeds
- REST submission with webhooks on completion, since manual channels can take days and polling is wasteful
- Consent capture endpoint you can embed in your candidate flow, with the authorisation record linked to every check
- Batch submission for high-volume screening with per-channel rate handling
- Evidence record export in a form that drops straight into a screening report or personnel file
- Coverage endpoint so your product can tell a user up front what is verifiable and what is not
- Deployment inside your infrastructure where candidate identity documents cannot leave your environment
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you verify any qualification anywhere?
No, and any supplier who says otherwise is overstating. Coverage depends entirely on whether an authorised route exists. Some countries have a clearinghouse covering most degrees; elsewhere it is institution-by-institution email, sometimes paid, sometimes unanswered. The coverage endpoint states the real position per country and issuer, and 'unable to verify' is a legitimate result we return rather than paper over.
What if the institution never responds?
The check closes as unable to verify, with the channel attempted, the dates of attempts and the reason. We will not substitute an inference. A non-response tells you the claim is unconfirmed, which is genuinely different from the claim being false, and presenting it as the latter would be both wrong and actionable.
Do you detect fake certificates from the document itself?
That is a separate question and a separate product. This API verifies against issuer and register records, which is far stronger evidence than document inspection. If you also need tampering analysis on an uploaded certificate image, that belongs in a document authenticity check — and even then the output is indicators, not proof.
How long does a verification take?
Seconds for digital credentials and public registers, minutes to hours for clearinghouses, and typically three to fifteen working days for direct registrar enquiry, longer across some vacation periods. The API returns an expected turnaround per check at submission so your product can set the right expectation.
Is consent really necessary?
Yes, in both directions. Most jurisdictions require the subject's authorisation to process their data for a background check, and most issuers refuse enquiries without evidence of it. The API enforces a live consent record on every submission, with expiry, rather than treating it as a box your customer ticks once.
Related blueprints
Skills Assessment API
Standardised skill tests, scoring and gap analysis delivered as an API your HR or learning platform embeds under its own brand.
Document Authenticity API
Tampering indicators, internal inconsistencies and validation signals for submitted documents — evidence for a human reviewer, not a verdict.
Job Market Intelligence API
Structured labour-market signal — salary ranges, skill demand and hiring trends — as a data layer inside your HR, recruitment or education product.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.