---
title: Simulating Results (Test Mock)
description: Simulate a process result in sandbox without a real biometric capture, using expected_result on Create Process.
canonical: https://developer.unico.io/developers/start/test-mock
locale: en
generated_by: markdown-export
---

- [/](/)
- [Start](/developers/start/)
- Simulating Results

**On this page# Simulating Results (Test Mock)

In sandbox, you can simulate a process result without depending on a real biometric capture. Add the `expected_result` field to the [Create Process](/developers/api-reference/post-processes) 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:
FormatWhen 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](#errors).
### Endpoint​

EnvironmentURL**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**
FieldTypeRequiredDescription`expected_result.​id_cloud_one_result`stringyesThe 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](/developers/start/flows#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](/developers/api-reference/get-process#capability-results-authenticationinfo).
Frictionless flows are not supported in this format — see [Unsupported signals](#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​

SituationError`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 returnsValidation error — include every signal`id_cloud_one_result` value the flow doesn't recognizeValidation error`flow` doesn't support mockingValidation error
### What's next​

After creating the mocked process, complete the biometric capture normally and use [Get Process](/developers/api-reference/get-process) to retrieve the mocked result.Last updated on Oct 8, 2026**