POST
/v1/verifySingle identity verification
Real-time deceased check for one identity. Returns a verdict, confidence score and date of death.
Developer platform
The death verification API that answers in under 300ms
One authenticated POST returns a deterministic deceased verdict, a confidence score and the date of death. No ingestion pipeline to build, no matching engine to maintain, no flat files to reconcile.
200 OK
curl -X POST https://api.verifydeceased.com/v1/verify \
-H "Authorization: Bearer $VD_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"firstName": "Robert",
"lastName": "Hensley",
"dateOfBirth": "1948-03-11",
"ssn": "***-**-4417",
"address": {
"line1": "8023 Jennet Street",
"city": "Alta Loma",
"state": "CA",
"postalCode": "91701"
}
}' Endpoints
Four endpoints cover every workflow
Real-time checks, portfolio batches, audit retrieval and continuous monitoring, all under one API key.
POST
/v1/verify/batchBatch verification
Submit up to 10,000 identities per request for asynchronous portfolio screening.
GET
/v1/verify/{referenceId}Retrieve a prior result
Fetch a stored verification by reference ID for audit, dispute handling or reconciliation.
POST
/v1/monitoring/subscribeContinuous monitoring
Register a portfolio for ongoing surveillance and receive a webhook the moment a match appears.
Platform
Engineered for production traffic
Sub-second responses
A median response under 300ms means the check runs inline without slowing your application flow.
Sandbox before you sign
Deterministic sandbox fixtures let your team build and test the full integration ahead of contracting.
Webhook monitoring
Subscribe a portfolio once and get pushed a notification the moment any enrolled identity matches.
Idempotent and retry-safe
Every request accepts an idempotency key so network retries never double-bill or duplicate a record.
Usage analytics
Track volume, match rate and latency by environment and API key from the dashboard.
Built for scale
Rate limits and throughput tiers sized for high-volume onboarding and nightly portfolio runs.
Onboarding
Sandbox to production in four stages
You build and certify the full integration before commercial terms are finalized, not after.
STAGE 01
Request sandbox access
Tell us your use case and volume. We issue sandbox credentials and the full API reference.
STAGE 02
Build against fixtures
Deterministic test identities cover deceased, not-found and low-confidence paths end to end.
STAGE 03
Certify and contract
We review your permissible use, agree throughput tiers and countersign the data agreement.
STAGE 04
Go live with support
Production keys are issued and a named engineer monitors your first weeks of live traffic.
Keep reading
Understand the problem the API solves
Death verification overviewHow source-level collection delivers records within about seven days of death.Deceased identity fraudThe mechanics of ghosting, synthetic identities and why the first weeks matter most.vs SSA Death Master FileUpdate speed, coverage, access model and the engineering effort each one demands.
Developer FAQ
Integration questions, answered
Frequently asked questions
How do I authenticate with the death verification API?
Every request carries a bearer token in the Authorization header. Keys are scoped per environment, so your sandbox key cannot reach production data and vice versa. Keys can be rotated from the dashboard at any time without downtime, and usage is tracked separately per key.
What is the response time and what are the rate limits?
Median response time for a single verification is under 300 milliseconds, which is fast enough to run inline in an onboarding or underwriting decision. Rate limits and throughput tiers are sized to your expected volume and agreed during onboarding rather than fixed at a single ceiling.
How does batch verification work?
Post up to 10,000 identities to the batch endpoint and receive a job reference immediately. The job is processed asynchronously and you can either poll for completion or register a webhook. Results come back with the same verdict, confidence score and matched-field structure as single verifications.
Is the API idempotent and safe to retry?
Yes. Every request accepts an idempotency key. If a network failure causes your client to retry, the original result is returned rather than a duplicate verification being created, so retries never double-bill or corrupt your audit trail.
How does continuous monitoring differ from one-off verification?
With monitoring you enrol a portfolio of identities once. Whenever a newly published decedent record matches an enrolled identity, we push a webhook to your endpoint. This is the right pattern for existing customer books, annuitant files and active collection inventory, where the risk is a death occurring after your initial check.
Can we test before signing a contract?
Yes. We issue sandbox credentials with deterministic test identities covering every response path, including deceased, not-found and deliberately low-confidence matches, so you can build and certify the complete integration before commercial terms are finalised.
Get sandbox credentials this week
Tell us your use case and expected volume and we will issue keys plus the full API reference so your team can start building immediately.
