Skip to main content
POST
Submit Workflow Step
Submits the data for one workflow step and executes it synchronously. The request body’s shape is config-driven — it depends on both step_id and the settings configured on that step within the workflow — see Step submission schemas below. Steps must be submitted in order: the step_id in the URL must match the session’s current_step (as returned by Create Workflow Session or Get Workflow State), and that step must be PENDING or IN_PROGRESS.

Request

Headers

Path parameters

Body parameters

The request body depends on step_id:

Step submission schemas

ID_VERIFICATION

Get uploads values from Create Session Uploads — upload each image to its presigned URL first, then submit the returned file_key values here.
Which of these fields are required or accepted for a given session depends on that step’s configuration (whether it requires a secondary/tertiary ID), not on this table alone — check the step’s requirements from Create Workflow Session or Get Workflow State.

FACE_LIVENESS

The body is a discriminated union on action. All variants also accept frame_count and clip_mime_type, but those are only meaningful — and only validated — when action is upload-url.

Response

The response is a common envelope for both step types; FACE_LIVENESS additionally includes a liveness object.

200 — Success

Advisory checks (age, expiry, document validity period, state) never fail an ID_VERIFICATION step and are not included in the response — only the blocking checks below can produce a failure_reason.

ID_VERIFICATION failure reasons

FACE_LIVENESS results

liveness depends on the submitted action: start complete

FACE_LIVENESS failure reasons

Calling complete before start, or before Rekognition has finished processing, returns a 409 with failure_reason of FACE_LIVENESS_NOT_STARTED or FACE_LIVENESS_RESULT_NOT_READY — see Error responses. These are retryable and don’t consume an attempt.

Error responses