Skip to main content
Resold by Frayme. No client API key required. Credentials and billing are managed end-to-end.
Sumsub is the workhorse of Frayme’s identity stack. It bundles three logical surfaces — KYC, AML and FRAUD — inside one applicant lifecycle, and it’s the default identity orchestrator for natural-person KYC workflows.

​
How Frayme calls Sumsub

The standard pattern across natural-person KYC workflows:
1

Create applicant

A POST to Sumsub creates the applicant skeleton and returns applicant_id + sdk_token.
2

Hand off to the client app

Frayme notifies the client app with the applicant id and an SDK launch hint. The client app opens the Sumsub SDK; selfie and document binaries flow directly to Sumsub — they never touch Frayme.
3

Wait for the terminal review

A long-poll dataSource node (timeout 600s, retry 0) waits for Sumsub to return review_answer: GREEN | RED plus reject labels.
4

Triage in Frayme

A rule node partitions the outcome: GREEN → proceed; RED + soft labels → AI false-positive synthesis; RED + hard labels → manual review with deterministic-fail recommendation.

​
Real-time actions on a paused node

While a Sumsub dataSource node is paused awaiting review_answer, you can invoke named pending actions on it. Address each by the node’s pending_handle — from the node.notification webhook or GET /cases/{caseId}/pending — and POST /pending/{handle}/actions/{actionId} with the cases:callback scope. The handle and invoke mechanics are covered in Integration guide → Pending actions on a paused node. All three Sumsub actions are side effects: they return data and leave the node paused — the review still completes through the applicantReviewed webhook.
actionIdPurposeReturns
refresh_sdk_tokenRe-mint a WebSDK access token for the same applicant (SDK integration).sdk_token, sdk_token_expires_at, sdk_user_id, customization_name
regenerate_linkRe-mint the hosted verification link for the same applicant (direct-link integration).verification_url
prefill_applicant_infoPush identity data onto the applicant’s Sumsub fixedInfo (a PATCH). Only the fields you send are written.applicant_id, fixed_info (the updated object Sumsub echoes back)

​
Request bodies

{ "params": { "token_ttl_secs": 1200 } }
token_ttl_secs is optional on the token and link actions (defaults: 600s for the SDK token, 1800s for the link). Every prefill_applicant_info field is optional — send only what you want written; empty values are skipped, and re-sending the same body is idempotent.
Scalar fields map to Sumsub fixedInfo keys: first_name→firstName, last_name→lastName, middle_name→middleName, legal_name→legalName, gender (M | F | X), dob (YYYY-MM-DD), place_of_birth→placeOfBirth, country_of_birth→countryOfBirth, country, nationality, tin, phone.Each entry in addresses accepts: country, post_code→postCode, town, street, sub_street→subStreet, state, building_number→buildingNumber, flat_number→flatNumber.Country fields are ISO 3166-1 alpha-3. firstName/lastName accept original-language scripts (Sumsub stores them verbatim and derives a Latin firstNameEn/lastNameEn). Values are forwarded to Sumsub as-is and validated there — for example, a dob more than 150 years in the past is rejected.