How do I mock the Jumio API locally?

Install stunt, add a one-service block to stunt.yaml (adapter: embedded:jumio-style), and run stunt up. You get a local, stateful stand-in for Jumio API v1 — 5 routes over rest — with no remote account, no network, and no bills.

Is the Jumio API mock data synthetic?

Yes — entirely. The adapter returns generated data only; stunt's adapter lint rejects real-looking secrets and PII at build time. It simulates the shape and behavior of Jumio API (routes, status codes, pagination, webhooks), never real records.

← all adapters

jumio-style

simulates Jumio API v1

restadapter v0.2.05 routes

verification

VMVM tier — no SDK suite yet· surface 5 · not implemented 3 · differs 6

use it

# add to stunt.yaml
services:
  jumio:
    adapter: embedded:jumio-style

# then
$ stunt up

The embedded: source extracts this adapter from the binary — no git clone, fully offline.

how to mock the Jumio API locally

Install stunt, paste the service block above into stunt.yaml, run stunt up — then point your client at localhost instead of Jumio API. It works offline, keeps state across requests and restarts, and every response is synthetic: the route shapes, status codes, pagination, and webhook delivery follow the real Jumio API v1 surface — the data is fake, the behavior is real.

backing stores

scanswebhook_events

api surface (5)

generated from the adapter manifest — exactly what boots, nothing more

5 routes

POST/netverify/v2/scans

GET/netverify/v2/scans/{scan_reference}

DELETE/netverify/v2/scans/{scan_reference}

GET/netverify/v2/scans/{scan_reference}/data

POST/netverify/v2/webhooks

VM-verified behaviors (17)

✓a missing, bare or wrong-scheme token is a 401 in the Jumio error envelope
✓a scan create answers PENDING with a synthetic decimal scan reference
✓sequential creates advance the reference sequence
✓a create without merchantScanReference is a 400
✓PENDING holds through the processing window then flips to DONE
✓a FAILED scan carries a real reject reason and its description
✓unknown scans are 404 on every parameterized route
✓extracted data is None while the scan is PENDING
✓DONE exposes the synthetic document extraction
✓FAILED scans answer data with a 409 repeating the reason
✓delete removes the scan and later reads are 404s
✓deleting after the terminal window still advances the lifecycle
✓a correctly MACed webhook body is accepted
✓a tampered body, wrong MAC or missing header is a 401
✓the terminal transition emits exactly one signed scan.completed
✓failed scans emit scan.failed carrying the rejection reason
✓a delete-driven terminal transition also emits, then nothing more

Not implemented (3)

No document or selfie image upload/retrieval endpoints
No hosted redirect verification flow; API scan creation only
No Document Verification, Data Verification, or Transaction Screening APIs

Differs from the real API (6)

Scan lifecycle on a fixed clock: PENDING ~3s then DONE or FAILED at +3s
simulate_fail and simulate_reject_reason create fields are stunt-only hooks
Webhook HMAC secret is the public constant stunt_jumio_mock_signing_key
POST /netverify/v2/webhooks is a local stand-in receiver, not a Jumio endpoint
Bearer-presence gate; real Jumio uses HTTP Basic against a server-token store
Scan references are decimal groups, not UUIDs; extracted PII is fixed synthetic

full scorecard →

want more of the Jumio API surface? adapters are YAML + Starlark — the authoring guide covers adding routes, fixtures, and state machines. Open an issue for anything big first, or just file a PR — merged routes ship in the next release.