Overview
Mojo Verify orchestrates government ID, liveness, SSN, OFAC, phone, email, address, adverse media, signature, and custom-data checks through a single verification request. Your server creates the request; the person completes the hosted flow; your system receives a signed terminal event.
Base workflow
- Create a request with the checks required for this risk decision.
- Deliver the returned verification link by email, SMS, both, or your own channel.
- Listen for terminal webhooks and fetch the final detail server-to-server.
Authentication
Send the key in the Authorization header using the apikey scheme. Sandbox keys begin with mvs-; production keys begin with mvp-.
Authorization: apikey mvs-••••••••
Content-Type: application/jsonCreate a request
Choose each required check explicitly. The response includes the request identifier and hosted verification URL.
POST https://api.mojoverify.com/api/verify/requests/create
Authorization: apikey mvs-••••••••
{
"first_name": "Alex",
"last_name": "Morgan",
"email": "alex@example.com",
"require_gov_id": true,
"require_liveness": true,
"require_ofac": true,
"notification_method": "both"
}Lifecycle
| Status | Meaning | Typical action |
|---|---|---|
| pending | The request exists but the person has not finished. | Wait or send a reminder. |
| in_progress | At least one required step is underway. | Keep the session open. |
| completed | All required checks reached a terminal result. | Fetch results and continue. |
| failed | The request could not meet the required verification. | Review reason or offer support. |
| expired | The hosted link is no longer valid. | Create a new request. |
Government ID
The hosted client obtains presigned upload destinations, sends document images directly, and begins processing. Mojo Verify can extract OCR, PDF417, and MRZ evidence; compare document surfaces; score authenticity; and return pass, review, or fail reasons.
Decision bands
- 85–100: pass
- 70–84: manual review, with promotion possible when all required fields are strong
- Below 70: fail
Authenticity weighting combines face comparison (30%), security evidence (40%), and completeness (30%).
Liveness
A liveness session uses an opaque client token and temporary credentials to start a guided AWS Rekognition Face Liveness experience. The result includes liveness confidence and can include a comparison against a reference face.
{
"require_liveness": true,
"require_gov_id": true
}Use both flags when the live person should be matched to the portrait extracted from the submitted document.
Verified document signing
Create a document signing request for a known customer and use require_liveness to gate signing behind a live-person check. The returned UUID signing link is a bearer token and must be treated as a secret.
POST https://api.mojoverify.com/api/docsign/request/create
Authorization: apikey mvp-••••••••
{
"customer_id": 42,
"template_id": 10,
"require_liveness": true,
"notification_method": "disabled",
"expires_hours": 168
}Identity trail
Use GET https://api.mojoverify.com/api/docsign/request/events/<pk> to retrieve the append-only lifecycle. Events can include created, viewed, liveness started or passed, signing started, signature captured, PDF generated, completed, downloaded, and securely shared. Each event can carry IP address, geolocation, user agent, actor, and event-specific metadata.
Signed webhooks
Terminal events are signed and intentionally contain no personally identifiable information. Verify the signature, acknowledge quickly, then fetch protected detail using your server credentials.
{
"event": "verification.completed",
"request_id": "vrf-A91K",
"occurred_at": "2026-08-05T19:20:00Z"
}