Submit a selfie and ID
Deprecated
Deprecated — use POST /applications/{id}/verification with channel: "server_upload". Kept as a thin alias over the same engine. Server-side capture-then-submit: the browser captures a liveness selfie (with its liveness frames) and the ID document (front + optional back) with Smile ID’s smart-camera-web component and POSTs the base64 images here. They are submitted server-side to Smile ID Enhanced Document Verification (job_type 11) — keeping the government database cross-check while also capturing the back of the ID, which the hosted widget cannot. Include liveness_images to run Smile ID’s active-liveness / anti-spoofing check (a lone selfie only gets the passive check). The result arrives asynchronously via the provider callback, so the application is left ID_VERIFICATION_PENDING. Answers with a Deprecation header and a Link to the Versions page.
Authorization
oauth2 Create a client with POST /v1/oauth/clients, then exchange its credentials for an access token. AUTHORIZATION_CODE clients act on behalf of a signed-in user and always use PKCE; CLIENT_CREDENTIALS clients act as themselves. A client may only be granted scopes its creator already holds — read the grantable list from GET /v1/oauth/clients/scopes.
In: header
Path Parameters
KYC application id.
uuidHeader Parameters
Comma-separated Smile ID API versions this client’s bundled SDK can run, newest last or in any order (e.g. v2, v3). The job is started on the newest version listed that the server also speaks, and that version is pinned for the life of the job. Omitted, empty or unrecognised means v2 — so a client only upgrades when it says it can. Send the same value to the requirements GET and the verification POST: they resolve the version independently, and disagreeing between the two gets the capture rejected.
Request Body
application/json
Server-side capture-then-submit body: a captured selfie and ID document, for the deprecated server_upload capture flow.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/kyc/applications/550e8400-e29b-41d4-a716-446655440000/capture" \ -H "Content-Type: application/json" \ -d '{ "selfie": "string" }'{ "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "status": "DRAFT", "can_submit": true, "needs_review": true, "message": "string"}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}{ "code": "INVALID_PARAMS", "description": "user_id must be a UUID", "identifier": "string", "invalid_params": [ { "path": "user_id", "reason": "must be a UUID", "sub_code": "string" } ]}Get what the client must capture GET
Deprecated — use GET /applications/{id}/verification, which returns the same payload. Returns what to capture for the active provider — whether a selfie, liveness frames (`requires_liveness`), and/or a document are required, and the backend-owned catalogue of supported documents (country + id types, each with `has_back`). Side-effect-free: the application stays in its current status, so the client fetches this before capturing and renders its document picker from it (no hard-coded document types). Answers with a `Deprecation` header and a `Link` to the Versions page.
Send an application back to DRAFT POST
Admin override that resets an application to DRAFT from any status, clearing the provider session, verification result, rejection reason and reapply cooldown so it can re-run verification from scratch. resubmission_count is preserved. Optionally set `force_new_enroll` to make the applicant’s next Smile ID session a fresh enrollment (overwriting the enrolled biometric). Org-scoped and gated on the backend `accounts.write` permission (override with KYC_REVIEWER_PERMISSION).