Verification sessions

Open a hosted verification, send the link, poll to the decision.

A session is one customer's trip through one work flow. You open it, you get a link, and your customer does the rest on pages the institution designed and the platform hosts.

curl
curl -X POST https://api.example.com/api/v1/integration/sessions \
  -H "X-API-Key: pmt_live_..." \
  -H "Content-Type: application/json" \
  -d '{"workFlowId":"...","locale":"en","vendorData":"crm-ref-48213"}'
JSON
{
  "session": { "sessionId": "...", "reference": "VS-000123", "status": "CREATED" },
  "verificationUrl": "https://acme.example.com/verify/3Fq8xZ...",
  "handoffExpiresAt": "2026-10-13T15:10:00Z"
}

The link is single use, and shorter-lived than the session

  • The first browser to open the link spends it. A second attempt fails.
  • handoffExpiresAt is sooner than the session's own expiry, so a link forwarded hours later is dead while the session is still readable.
  • Send it to one person, in one channel. A link scanner or a chat preview that opens it will spend it.

Statuses

StatusMeans
CREATEDOpened. The link has not been used.
IN_PROGRESSYour customer is working through the journey.
SUBMITTEDThey finished. A case exists and is with the institution.
DECIDEDA decision is ready. The decision read will answer.
EXPIREDNobody finished it in time.
CANCELLEDYou abandoned it.

What a decision does and does not carry

Once a session reads DECIDED, GET /sessions/{sessionId}/decision returns the outcome and the data behind it, filtered to the fields your scopes allow.