When creating a user file, it is mandatory to specify one or more callback_endpoints, i.e. URLs to which ID360 will automatically send notifications (via HTTP POST) throughout the identification process.

Each callback_endpoint will receive a payload containing information related to the file, including its status and the steps completed by the user.

You can define one or more callback URLs. For each callback, you can specify the desired notification level:

• Final callback only: you receive a single notification at the end of the process, indicating that the identification is complete, along with the related information.
• Intermediate + final callbacks: you are notified at each key step of the user process (start, upload, document validation, etc.), in addition to the final notification.

Note that in some cases, intermediate callbacks may arrive after the final callback. This can happen if the initial callback attempt failed (e.g. your server was temporarily unavailable): ID360 will then perform automatic retries to ensure proper delivery.

These retries may cause a temporal mismatch in the order of received messages.

→ It is therefore strongly recommended to rely on the content of the payload rather than the order in which notifications arrive.

Below is an example of a payload (in JSON format) sent by ID360 to your callback URL:

As a trusted service provider, we must comply with applicable standards, including ETSI EN 319 401, which requires the use of the latest versions of TLS to ensure the security and reliability of our exchanges.

We recommend verifying that your connection is correctly configured to support TLSv2 or TLSv3.

If you wish to allowlist our IP addresses, please contact your Customer Success Manager, who will provide them to you.

At each step completed by the user, you will receive intermediate callback notifications informing you of the nature and status of that step.

The status of an intermediate callback will always be set to “STARTED”.

The steps_status block indicates that a total of 7 control steps were identified for the process associated with this payload.

The value done = 1 means that only the ProfileDataStep (e.g. pushing the last name via API) has been completed.

The enrollment_step field provides detailed information about the step, including the result, the type of verification performed, and the list of documents involved.

Note: The “type” present in the `enrollment_step` variable is for internal use only and should not be used or relied upon.

The final callback notifies you of the completion of the identification process and provides final status details.

The status of a final callback can be: OK, KO, FAILED or CANCELED

In case of a KO, the reason field will explain the failure cause.

In `steps_status`, the value `done` will equal the value `total`.

In this case, you must return a 2XX status code (e.g. 204) within 10 seconds.

If this response is not received, up to 6 additional retry attempts will be made according to the following schedule:

These intervals follow the formula: `10 x (n+1)^3` (where `n` is the retry number), expressed in seconds.

In the body when creating a user file:

"callback_endpoints": [
  {
    "url": "https://your-server.com/callback",
    "on": [
      "F"
    ],
    "headers": [
      {
        "name": "Authorization", value: "Bearer abc123"
      }
    ]
  }
]

• url: the POST endpoint address to be called when an event is triggered.
• on: list of statuses for which this callback will be executed.
• headers: list of custom headers to include in the request (e.g., authentication, trace, etc.).

• F – Failed
• C – Canceled
• E – End (OK or KO)
• I – Intermediate
• UP – Mie User Processing
• SP – Mie Sys Processing

• You can define multiple endpoints by adding them to the callback_endpoints list.
• Each callback will only be triggered for the statuses specified in on.