This page describes possible status event codes that are returned during the identity validation transaction workflow with Capture.

Status event code categories

The codes are categorized as follows:

100s, 10xx. Events for transaction details, URLs, and Telesign events.

11xx Landing. Events for initialization and setup.

12xx Capture Guide and Capture Front. Events that track pre-capture guide instructions and frontside capture.

13xx Capture Back. Events that track the status of the backside capture.

14xx Capture Barcode. Events that track the status of the barcode scan.

15xx Biometrics. Events that track biometric policy review.

16xx Capture Selfie. Events that track the status of selfie capture.

17xx Network. Events for connection-speed and slow-connection handling.

18xx Complete. Events that track the complete page.

19xx, 20xx Failure. Events that track errors, denials, timeouts, and other drop-off events.

Postback responses and polling requests

Status event codes are returned either by a postback response or alternatively by polling requests.

• Postback response (preferred) - The status_url location, as specified in the /start request body, provides a postback response endpoint. The advantage to this approach is real-time updates. Your client receives immediate notifications when events occur. This is the preferred method for gathering status event codes.
• Polling requests (alternative) - The get-status endpoint provides an alternative approach to poll for status event codes. The disadvantage to this approach is its inefficiency. Frequent requests must be made, even when no updates are available.

Example status event code log

Status event codes are returned in reverse chronological order with the newest status event code at the top of the list.

The following text shows a sample status event code log from the get-status endpoint.

{
  "public_data": {
    "version": "3.12.1",
    "endpoint": "get-status"
  },
  "private_data": {
    "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
    "status": [
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:34:37.348000",
        "server_time": "2026-07-23 16:34:37.450320",
        "event": 1800,
        "message": "User navigates to complete page",
        "sequence": "2026-07-23 16:34:37.348000",
        "timestamp": "2026-07-23 16:34:37.450320"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": null,
        "server_time": "2026-07-23 16:34:36.139888",
        "event": 1825,
        "message": "Transaction ended - processing results",
        "sequence": null,
        "timestamp": "2026-07-23 16:34:36.139888"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": null,
        "server_time": "2026-07-23 16:34:30.347357",
        "event": 1625,
        "message": "/submit/selfie API call is made",
        "sequence": null,
        "timestamp": "2026-07-23 16:34:30.347357"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:34:13.941000",
        "server_time": "2026-07-23 16:34:13.984214",
        "event": 1410,
        "message": "Barcode is captured",
        "sequence": "2026-07-23 16:34:13.941000",
        "timestamp": "2026-07-23 16:34:13.984214"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": null,
        "server_time": "2026-07-23 16:34:06.589449",
        "event": 1225,
        "message": "/submit/front API call made",
        "sequence": null,
        "timestamp": "2026-07-23 16:34:06.589449"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:34:05.992000",
        "server_time": "2026-07-23 16:34:06.103942",
        "event": 1226,
        "message": "{\"method\":\"manual\",\"attempt_number\":1}",
        "sequence": "2026-07-23 16:34:05.992000",
        "timestamp": "2026-07-23 16:34:06.103942"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:34:05.990000",
        "server_time": "2026-07-23 16:34:06.097397",
        "event": 1210,
        "message": "{\"method\":\"manual\",\"attempt_number\":1}",
        "sequence": "2026-07-23 16:34:05.990000",
        "timestamp": "2026-07-23 16:34:06.097397"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:33:55.977000",
        "server_time": "2026-07-23 16:33:56.064921",
        "event": 1213,
        "message": "{\"attempt_number\":1}",
        "sequence": "2026-07-23 16:33:55.977000",
        "timestamp": "2026-07-23 16:33:56.064921"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:33:49.849000",
        "server_time": "2026-07-23 16:33:49.949120",
        "event": 1202,
        "message": "{\"method\":\"button\",\"dwell_ms\":2763}",
        "sequence": "2026-07-23 16:33:49.849000",
        "timestamp": "2026-07-23 16:33:49.949120"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:33:47.087000",
        "server_time": "2026-07-23 16:33:47.123971",
        "event": 1201,
        "message": "User lands on the front pre-capture guide screen",
        "sequence": "2026-07-23 16:33:47.087000",
        "timestamp": "2026-07-23 16:33:47.123971"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:33:47.052000",
        "server_time": "2026-07-23 16:33:47.092244",
        "event": 1190,
        "message": "User taps start button",
        "sequence": "2026-07-23 16:33:47.052000",
        "timestamp": "2026-07-23 16:33:47.092244"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": "2026-07-23 16:33:42.476000",
        "server_time": "2026-07-23 16:33:42.623358",
        "event": 1105,
        "message": "/user/get-config API call made",
        "sequence": "2026-07-23 16:33:42.476000",
        "timestamp": "2026-07-23 16:33:42.623358"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": null,
        "server_time": "2026-07-23 16:33:26.931981",
        "event": 100,
        "message": "Transaction type: portal",
        "sequence": null,
        "timestamp": "2026-07-23 16:33:26.931981"
      },
      {
        "transaction_id": "12345678-abcd-1234-abcd-123456789abc",
        "customer_id": "00000000-0000-0000-0000-000000000000",
        "client_time": null,
        "server_time": "2026-07-23 16:33:26.912557",
        "event": 505,
        "message": "Document type: na_dl",
        "sequence": null,
        "timestamp": "2026-07-23 16:33:26.912557"
      }
    ]
  }
}

Event order and repeated codes

Events are returned in reverse chronological order by server_time.

sequence duplicates client_time, and timestamp duplicates server_time. Despite its name, sequence is a timestamp rather than an ordinal, and it is null on events the server originates, so no single field orders every event in a transaction. Order by server_time and treat the result as the order in which the server received events, not as a literal record of what the user did. Events logged within the same few milliseconds can appear in either order.

A status event code can appear more than once in the same transaction for three reasons:

• The client and the server both logged it. For example, 1140, 1141, 1142, 1225, 1325, and 1425 are recorded from both vantage points. The client-logged instance carries a client_time value; the server-logged instance has client_time: null.
• The step occurred more than once. The camera permission events 1207 and 1208, for example, are emitted each time a capture component initializes. The component tears down and re-initializes on every retake, so these appear once per capture attempt, not once per side.
• The user retried. A retry repeats the capture events with an incremented attempt_number.

Handle events idempotently, keyed on the event code together with server_time.

Status event code list

The following table shows status event codes and corresponding event messages grouped by page type.

Transaction codes

Landing page codes

Capture guide codes

Capture front codes

Capture back codes

Capture barcode codes

Biometrics accept codes

Capture selfie codes

Network codes

Complete codes

404, denied, and timeout codes

Understanding the message field

For most events, message is a fixed description that matches the table above. A handful of events return extra detail, so treat message as free-form text rather than a string you can match against.

Some events return a dynamic string — a label followed by a value. 1001 and 1002 return the capture URL and the browser user-agent; 100 and 105 return the transaction type and 505 the document type.

Two groups of events return a JSON object.

The Capture Guide events 1202 and 1203 report how the user left the guide. Exactly one of the two is emitted.

• 1202 — the user tapped the ready button. method is button, and dwell_ms is the time in milliseconds the user spent on the guide.
• 1203 — the guide advanced on its own after the idle timeout. method is auto, and dwell_ms is the configured timeout (typically 15 seconds returned as 15000 milliseconds).

The Capture Guide precedes the first capture. There is no back-side equivalent of 1201, 1202, or 1203.

The capture events report how the image was taken. The document is captured automatically when it is well-positioned and the image is clear; if automatic capture cannot complete, the user takes the photo with the capture button.

• method — auto when the image was captured automatically, manual when the user tapped the capture button.
• attempt_number — the capture attempt this event belongs to, starting at 1 and increasing with each retry.

An automatic front capture produces events like these:

1202  {"method":"button","dwell_ms":2640}
1210  {"method":"auto","attempt_number":1}
1227  {"method":"auto","attempt_number":1}
1220  User taps use image button
1225  /submit/front API call made

A front capture that falls back to manual produces:

1202  {"method":"button","dwell_ms":2763}
1213  {"attempt_number":1}
1210  {"method":"manual","attempt_number":1}
1226  {"method":"manual","attempt_number":1}
1225  /submit/front API call made

Exactly one of 1226 and 1227 is emitted per front capture, and one of 1326 and 1327 per back capture. The two paths also differ in confirmation: an automatic capture is followed by a confirmation screen, where accepting the image emits 1220 and choosing to retake emits 1215 and starts a new attempt. A manual capture is submitted immediately, with no confirmation screen and no 1220. 1213 is emitted only on the manual path.

The back-side capture events mirror the front, offset by 100: 1310 corresponds to 1210, 1326 to 1226, and so on. 1207 and 1208 are shared by both sides rather than mirrored.

For the capture events, message is the JSON object rather than the plain description shown in the table. Parse it as JSON instead of matching against the table text.