Simulating Results (Test Mock)

MarkdownChatGPTClaude

In sandbox, you can simulate a process result without depending on a real biometric capture. Add the expected_result field to the Create Process request body — the rest of the integration (SDK rendering, biometric capture, Get Process) stays exactly the same as a real flow.

The mock does not skip the biometric capture step. The user (or your test script) still needs to complete the normal flow — what changes is that, once finished, the process returns the values defined in expected_result instead of the real evaluation result.

Each flow only accepts one of the two formats below, depending on how it's configured:

Format	When to use
id_cloud_one_result	Flows that return a single result (approved, denied, high risk, etc.)
authentication_info	Flows that return individual signals (UnicoId, Trust, Liveness, IdAge, IdFace...)

Sending the format that doesn't match your flow, or sending both at once, results in an error — see Errors.

Endpoint

Environment	URL
Sandbox	POST https://api.idcloud.uat.unico.app/client/v1/process

The mock is only available in sandbox. In production, the expected_result field is rejected.

Single result — id_cloud_one_result

Use this when your flow returns a single approval-style result.

Body parameters

Field	Type	Required	Description
expected_result.​id_cloud_one_result	string	yes	The single result to simulate. Must be a result your flow actually produces — check your flow's configuration for the results it recognizes.

Example

curl -X POST https://api.idcloud.uat.unico.app/client/v1/process \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "expected_result": {
      "id_cloud_one_result": "PROCESS_RESULT_APPROVED"
    }
    // ... the remaining parameters are the same ones you use on a real Create Process call
  }'

Response (200 OK)

{
  "process": {
    "id": "53060f52-f146-4c12-a234-5bb5031f6f5b",
    "state": "PROCESS_STATE_FINISHED",
    "result": "PROCESS_RESULT_OK",
    "flow": "your-sandbox-flow",
    "simulated": true,
    "capacities": ["PROCESS_CAPACITY_IDCHECK"],
    "person": { "duiType": "DUI_TYPE_BR_CPF", "duiValue": "12345678909" }
  }
}

simulated: true marks this process as having a simulated result, not a real evaluation.

The possible values of id_cloud_one_result are the same process result values documented in Interpreting results — only send a result your flow actually recognizes.

Individual signals — authentication_info

Use this when your flow returns separate signals instead of a single result.

Every signal your flow normally returns must be present in authentication_info. Sending only some of them is rejected — you can't mock one signal and leave the rest to the real evaluation.

trust_result vs. identity_fraudsters_result

trust_result and identity_fraudsters_result represent the same signal (identity fraud indication): trust_result covers the negative side, identity_fraudsters_result the positive side. Use whichever matches the result you want to simulate.

For the possible values of each field, see Capability results in authenticationInfo.

Frictionless flows are not supported in this format — see Unsupported signals.

Example

curl -X POST https://api.idcloud.uat.unico.app/client/v1/process \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "expected_result": {
      "authentication_info": {
        "authentication_result": "AUTHENTICATION_RESULT_POSITIVE",
        "liveness_result": "LIVENESS_RESULT_LIVE",
        "id_age_result": "ID_AGE_RESULT_POSITIVE"
      }
    }
    // ... the remaining parameters are the same ones you use on a real Create Process call
  }'

Response (200 OK)

{
  "process": {
    "id": "53060f52-f146-4c12-a234-5bb5031f6f5b",
    "state": "PROCESS_STATE_FINISHED",
    "result": "PROCESS_RESULT_OK",
    "flow": "your-sandbox-flow",
    "simulated": true,
    "capacities": ["PROCESS_CAPACITY_IDUNICO", "PROCESS_CAPACITY_IDAGE"],
    "authenticationInfo": {
      "authenticationResult": "AUTHENTICATION_RESULT_POSITIVE",
      "livenessResult": "LIVENESS_RESULT_LIVE",
      "idAgeResult": "ID_AGE_RESULT_POSITIVE"
    },
    "person": { "duiType": "DUI_TYPE_BR_CPF", "duiValue": "12345678909" }
  }
}

Unsupported signals

The signals below are not supported by the mock, in either format:

• multi_accounts
• data_mismatch
• serial_fraudster
• smart_revalidation_result
• passkey_result (deprecated)

Frictionless flows (authentication without biometric capture) are only supported in the id_cloud_one_result format — they don't work with authentication_info.

Notes on the response

Score is only returned when the identity result is inconclusive. The score_engine_result field only reflects a value when authentication_result is AUTHENTICATION_RESULT_INCONCLUSIVE. If you mock authentication_result as POSITIVE or NEGATIVE together with a non-zero score_engine_result, the final response returns score_enabled: SCORE_ENABLED_FALSE and score: 0, regardless of the value sent.

This is the API's normal behavior — the same rule applies to real processes, it isn't specific to the mock. If the scenario you want to test depends on the score showing up in the response, use authentication_result: AUTHENTICATION_RESULT_INCONCLUSIVE.

Errors

Situation	Error
expected_result outside sandbox	PERMISSION_DENIED
id_cloud_one_result and authentication_info sent together	INVALID_ARGUMENT
Empty authentication_info: {}	INVALID_ARGUMENT
authentication_info missing a signal the flow returns	Validation error — include every signal
id_cloud_one_result value the flow doesn't recognize	Validation error
flow doesn't support mocking	Validation error

What's next

After creating the mocked process, complete the biometric capture normally and use Get Process to retrieve the mocked result.