Dados de teste da sandbox: cenários, valores e documentos

O sandbox da Didit é o equivalente aos cartões de teste da Stripe ou aos modelos de documentos da Sumsub: permite reproduzir de forma determinística qualquer resultado de verificação, sem chamar fornecedores reais, sem tratar dados pessoais reais e sem afetar o seu saldo.

A fonte de verdade para estes dados é serialize_catalog() no serviço de verificação, disponibilizada em tempo real em GET /v1/sandbox/scenarios/. Uma cópia testada quanto a desvios é gerada em docs/sandbox/SANDBOX_REFERENCE.md no repositório service-didit-verification, com pipenv run python scripts/generate_sandbox_reference.py. Esta página reproduz essa referência: se algo aqui parecer desatualizado, confie sempre no endpoint do catálogo em tempo real. O endpoint do catálogo exige autenticação: envie a sua chave de API (x-api-key) como em qualquer outro pedido, ou um token de sessão se o estiver a consultar a partir de uma sessão em execução.

Modelo de ambientes

O sandbox é um modo por aplicação (ApplicationDetail.mode == SANDBOX), à semelhança do modo de teste da Stripe. Enquanto uma sessão corre numa aplicação em sandbox:

Todos os fornecedores externos (OCR, AML, correspondência facial, prova de vida, NFC, telefone, e-mail, IP, comprovativo de morada, validação de base de dados e Document AI) são simulados. Nenhum terceiro é chamado.
A prova de vida funciona exatamente como em produção. Um fluxo de prova de vida ativa executa a captura ativa real no sandbox, tanto no fluxo alojado como na transferência para a web a partir dos SDKs nativos, para que possa testar a experiência que os seus utilizadores terão. Só o resultado da prova de vida é simulado, pelo cenário ou pelo valor mágico, e o relatório regista o método que o seu fluxo configura.
Os domínios personalizados existem apenas em produção. Uma aplicação em sandbox não pode adicionar um domínio personalizado; as sessões em sandbox usam sempre o domínio de verificação alojado por defeito.
As sessões nunca são cobradas e a verificação de saldo é ignorada.
É aplicada uma quota de 500 criações de sessão / 24 h por aplicação.
Os webhooks incluem "environment": "sandbox" (as sessões em produção incluem "environment": "live").
O fluxo alojado expõe o ambiente da sessão para que a interface possa avisar os utilizadores para não carregarem dados pessoais reais.
Os resultados nunca dependem dos pixels: os dados extraídos e os estados vêm do cenário ou do valor mágico. Os próprios ficheiros capturados (documentos, selfie, vídeo, ficheiros de comprovativo de morada) são guardados de facto, exatamente como numa sessão em produção.

Monitorização de transações no sandbox

O sandbox tem a forma de uma sessão: simula os fornecedores que uma sessão de verificação chamaria. A Monitorização de transações não tem fornecedor para simular, por isso uma aplicação sandbox segue o outro caminho: a transação é guardada, mas nada que decida, faça triagem, notifique ou fature é executado sobre ela. Uma transação criada numa aplicação sandbox é guardada e devolvida como habitualmente, e nada do seguinte acontece com ela:

Sem avaliação de regras. rule_runs fica vazio, independentemente do modo em que estejam as suas regras. Uma regra ACTIVE numa aplicação sandbox nunca dispara, por isso a transação mantém-se APPROVED com pontuação 0 e não é aberto qualquer alerta nem caso.
Sem triagem AML nem de carteiras. provider_results fica vazio, mesmo em transações de cripto numa aplicação com monitorização ativada.
Sem webhooks. Nem transaction.created nem transaction.status.updated são enviados para uma transação sandbox.
Sem faturação. É registado um evento de utilização com preço 0.0000, e o seu saldo não é alterado.

Cada resposta de transação inclui um campo environment ("live" ou "sandbox"), para que um rule_runs vazio nunca seja ambíguo: "sandbox" significa que as regras não foram avaliadas, e não que nenhuma delas correspondeu. A Business Console diz o mesmo no cartão Risk & decision da transação, em vez de apresentar apenas “No rules evaluated”.

A Travel Rule é a única exceção a “nada é executado”. Numa aplicação com a Travel Rule ativada, uma transação travelRule sandbox continua a executar o motor de exchange: o registo da transferência é criado e avança pelos seus estados. O que o sandbox nunca faz é comunicar com alguém fora da Didit. A sua única contraparte é o Didit Test VASP, integrado na plataforma: nenhuma mensagem de conformidade chega a um VASP contraparte real por nenhum canal (TRP, uma rede à qual se tenha ligado, e-mail ou INTERNAL), a atribuição de VASP contraparte na triagem é ignorada, e um cancelamento não envia nada à contraparte. Os webhooks travel_rule.status.updated são enviados, marcados com "environment": "sandbox".Saída - uma transação travelRule que submete. A verificação de threshold_amount é feita primeiro e, no sandbox, só se aplica quando envia transaction_details.amount_in_default_currency, porque o sandbox não converte moedas; sem este campo, cada transferência sandbox conta como acima do limiar. Uma transferência sem resposta expira após confirmation_timeout_hours, e o seu timeout_outcome aplica-se então à transação. Acima do limiar, a verificação de carteira autocustodiada aplica-se como habitualmente: uma transferência para uma carteira autocustodiada declarada passa para UNCONFIRMED_OWNERSHIP sem nada ser enviado, e pode concluí-la no sandbox através do widget de verificação de propriedade da carteira, ou através de confirmar propriedade quando a carteira de destino já está na sua lista de endereços de carteiras. Qualquer outra transferência acima do limiar é enviada para o Didit Test VASP no canal TEST_VASP, que lhe responde dentro da Didit com o cenário que escolher pela carteira ou pelo nome do beneficiário: é concluída, é recusada, não coincide, passa para COUNTERPARTY_VASP_NOT_REACHABLE, expira (e o seu timeout_outcome aplica-se então à transação) ou fica a aguardar a propriedade da carteira. Veja Testar a Travel Rule no sandbox para todos os cenários.Entrada - POST /v3/travel-rule/inbound/. O registo nunca é enviado por um canal, por isso nada nele é simulado: o sandbox resolve o depósito contra a sua lista de endereços de carteiras e liquida de forma síncrona, exatamente como em produção. Resulta num resultado real e não em AWAITING_COUNTERPARTY: ON_HOLD (sem correspondência na lista de endereços), UNCONFIRMED_OWNERSHIP (a propriedade da entrada correspondente não foi verificada), COUNTERPARTY_MISMATCHED_DATA (o nome do beneficiário não corresponde ao titular da carteira), ou COMPLETED e depois FINISHED (correspondeu a uma entrada verificada). Para receber uma transferência do Didit Test VASP, use Acionar transferência de entrada do Test VASP com uma das carteiras da sua lista de endereços.

Cenários do Test VASP da Travel Rule

O travel_rule.scenarios do catálogo lista estes cenários de saída. Defina o nome do beneficiário abaixo numa transação travelRule de saída depois de ativar a Travel Rule na sua aplicação sandbox. As verificações de limiar e de carteira autocustodiada declarada descritas acima são executadas primeiro.

Cenário	Nome do beneficiário	Resultado
`accept`	`Didit Test VASP`	`COMPLETED`
`decline`	`Didit Test VASP Decline`	`COUNTERPARTY_VASP_GENERAL_DECLINE`
`name_mismatch`	`Didit Test VASP Name Mismatch`	`COUNTERPARTY_MISMATCHED_DATA`
`not_reachable`	`Didit Test VASP Not Reachable`	`COUNTERPARTY_VASP_NOT_REACHABLE` após novas tentativas de entrega
`timeout`	`Didit Test VASP Timeout`	`EXPIRED` quando a verificação de expiração é executada depois do prazo de um minuto
`self_hosted`	`Didit Test VASP Self Hosted`	`UNCONFIRMED_OWNERSHIP`

Também pode escolher um cenário com o endereço da carteira do beneficiário em vez do nome (a carteira prevalece quando ambos estão definidos), e uma transferência que não indique nenhum dos dois é concluída como accept. Testar a Travel Rule no sandbox lista o endereço de carteira de cada cenário e o seu resultado exato. O acionador de entrada do Test VASP aceita apenas accept e name_mismatch no seu campo scenario.

Como testar uma regra antes de a colocar em produção. Utilize o Backtest: reexecuta a regra sobre o seu histórico real de transações e apresenta evaluated / matched / affected_entities sem alterar o estado de nenhuma transação. Combine-o com o modo TEST na aplicação de produção - uma regra TEST é avaliada em cada nova transação real e regista aquilo a que teria correspondido, sem alterar a pontuação nem o estado - e passe para ACTIVE quando a seletividade estiver adequada.

Como alternar entre produção e sandbox

A produção e o sandbox são aplicações separadas, pelo que o tráfego de teste e os dados de produção nunca se misturam. Cada aplicação tem um mode de live ou sandbox:

Use a chave de API de uma aplicação em modo sandbox para obter sessões simuladas, não faturadas e passíveis de simulação.
Use a chave de API de uma aplicação em modo de produção para verificações reais.

O campo sandbox_scenario (na criação de sessões e na API AML autónoma) e os endpoints de simulação só são aceites em aplicações sandbox; são rejeitados em aplicações de produção.

Sandbox no fluxo de verificação alojado

As sessões criadas numa aplicação sandbox apresentam elementos de interface adicionais no fluxo de verificação alojado (o url devolvido por POST /v3/session/):

Banner sandbox no cartão. Todos os ecrãs apresentam um banner dentro do cartão - “Apenas dados de teste - sem chamadas reais” - para que fique sempre evidente que a sessão nunca chama fornecedores reais nem afeta o seu saldo. Os conteúdos multimédia capturados são conservados como em qualquer sessão, por isso use os documentos de exemplo e os dados de teste em vez de documentos de identidade reais ou informações pessoais.
Seletor de cenários antes do fluxo. Antes de a captura começar, um seletor no cartão guia o utilizador na escolha de um resultado de teste: escolher um resultado e, em seguida, um acionador para esse resultado. A confirmação chama POST /v3/session/{session_id}/sandbox/arm/ (ver Preparar (ou preparar novamente) a sessão antes de o fluxo começar abaixo) e continua o fluxo com os valores mágicos desse cenário já aplicados.
Faixa de documentos de exemplo. Uma única linha de documentos de exemplo do sandbox (até 3) fica diretamente abaixo do componente de carregamento e captura de documentos. Toque num deles para o usar em vez de um carregamento real.

As sessões sandbox guardam os conteúdos multimédia reais capturados - documentos, selfie, vídeo de prova de vida e ficheiros de comprovativo de morada são carregados e conservados exatamente como numa sessão de produção. Os dados extraídos (campos de verificação de identidade, pontuações de correspondência facial, resultados de prova de vida e semelhantes) e o próprio resultado da sessão (Aprovada / Em análise / Recusada) são simulados pelo cenário ou pelo valor mágico, nunca derivados dos conteúdos capturados. A Business Console assinala as secções de dados extraídos de uma sessão sandbox com um chip Dados simulados, para que os revisores percebam de imediato que partes da sessão correspondem à captura real e quais são guiadas por cenário.

Cenários

Cada cenário é um conjunto nomeado de valores mágicos. Passe o respetivo slug como sandbox_scenario ao criar a sessão (ou ao endpoint de simulação) para reproduzir o resultado.

Slug	Título	Estado predefinido	Descrição
`approve`	Caminho feliz – todas as funcionalidades aprovam	Aprovada	Comportamento predefinido do sandbox: cada funcionalidade simulada devolve o resultado limpo APPROVED. A sessão termina com o estado APPROVED.
`decline_aml_hit`	AML – pessoa politicamente exposta	Recusada	O mock de AML devolve uma correspondência e a sessão é recusada na funcionalidade de AML. A correspondência usa o mesmo Esquema de correspondência dos fornecedores de AML em produção: `url`, `match_score`, `risk_score`, `review_status`, `properties`, `pep_matches[]` e `score_breakdown` ficam todos preenchidos, e é escrito um registo de aviso POSSIBLE_MATCH_FOUND.
`decline_document_expired`	Verificação de identidade – documento expirado	Recusada	O mock de verificação de identidade devolve um passaporte cuja data de validade está no passado. A sessão é recusada na verificação de identidade, com um registo de aviso DOCUMENT_EXPIRED.
`decline_minimum_age`	Verificação de identidade – abaixo da política de idade mínima	Recusada	O mock de verificação de identidade devolve uma data de nascimento que faz com que o utilizador tenha cerca de 10 anos. A verificação de idade em produção emite MINIMUM_AGE_NOT_MET e o fluxo recusa a sessão.
`decline_mrz_validation`	Verificação de identidade – falha na soma de verificação do MRZ	Recusada	O mock de verificação de identidade devolve um passaporte com a soma de verificação do MRZ corrompida. O validador de MRZ em produção emite MRZ_VALIDATION_FAILED e a sessão é recusada.
`decline_could_not_recognize_document`	Verificação de identidade – documento ilegível	Recusada	O mock de verificação de identidade devolve uma resposta vazia. Em produção, é gerado COULD_NOT_RECOGNIZE_DOCUMENT e esse erro é apresentado ao SDK.
`decline_face_match_low_similarity`	Correspondência facial – similaridade abaixo do limiar de recusa	Recusada	O mock de correspondência facial devolve uma pontuação baixa. Em produção, é emitido LOW_FACE_MATCH_SIMILARITY e o mapeamento de ação do nó do fluxo recusa a sessão.
`decline_database_no_match`	Validação de base de dados – sem correspondência em todos os serviços	Recusada	Cada serviço de base de dados selecionado devolve NO_MATCH. Em produção, é emitido DATABASE_VALIDATION_NO_MATCH e o fluxo recusa a sessão.
`decline_phone_high_risk`	Telefone – número de teste de risco elevado reservado	Recusada	O mock de verificação de telefone bloqueia a verificação (intervalo reservado para testes). A verificação de telefone termina como BLOCKED e emite HIGH_RISK_PHONE_NUMBER.
`decline_email_breach`	E-mail – correspondência numa base de dados de violações	Recusada	O mock de violações de e-mail devolve um resultado de violação para o endereço. A verificação de e-mail emite BREACHED_EMAIL_DETECTED.
`decline_ip_blocklist`	Análise de IP – endereço IP na lista de bloqueio	Recusada	O mock de análise de IP recusa a localização com IP_ADDRESS_IN_BLOCKLIST. A sessão é recusada na análise de IP.
`decline_poa_address_mismatch`	POA – morada divergente da fornecida	Recusada	O mock de POA recusa o comprovativo de morada com ADDRESS_MISMATCH_WITH_PROVIDED. A sessão é recusada no POA.
`decline_liveness_attack`	Prova de vida – ataque facial detetado	Recusada	O mock de prova de vida passiva deteta um sinal de ataque facial e emite LIVENESS_FACE_ATTACK. A sessão é recusada na prova de vida.
`decline_nfc_chip_not_verified`	NFC – chip do ePassport não verificado	Recusada	O mock do ePassport devolve um chip cuja assinatura SOD/DG falha na verificação de integridade. Em produção, é emitido NFC_CHIP_NOT_VERIFIED e a sessão é recusada no NFC quando o fluxo recusa chips não verificados.
`decline_nfc_trust_anchor_missing`	NFC – âncora de confiança da entidade emissora indisponível	Recusada	O mock do ePassport devolve um chip assinado por uma DSC cuja CSCA emissora está ausente do repositório de confiança. Em produção, é emitido NFC_TRUST_ANCHOR_MISSING e a sessão é recusada quando o fluxo recusa chips não verificados.
`decline_document_ai_unreadable`	Document AI – documento ilegível	Recusada	O mock do Document AI não devolve campos legíveis. Em produção, é emitido DOCUMENT_AI_UNREADABLE_DOCUMENT e o documento é considerado recusado quando se esgota o número de tentativas.
`review_aml_possible_match`	AML – possível correspondência que requer revisão	Em análise	O mock de AML devolve uma correspondência com menor confiança. A sessão fica Em análise, com um registo de aviso POSSIBLE_MATCH_FOUND para um analista resolver.
`review_face_match_borderline`	Correspondência facial – similaridade limítrofe	Em análise	O mock de correspondência facial devolve uma pontuação entre os limiares de revisão e de recusa. A sessão fica Em análise na correspondência facial.
`review_document_borderline_age`	Verificação de identidade – menor enviado para revisão	Em análise	O mock de verificação de identidade devolve uma data de nascimento abaixo da idade mínima configurada no fluxo. O minimum_age_action do fluxo está definido como REVIEW em vez de DECLINE, pelo que a sessão fica Em análise na verificação de identidade em vez de ser recusada.
`review_poa_partial_match`	POA – correspondência parcial de morada	Em análise	O mock de POA devolve uma morada que só corresponde parcialmente à fornecida. A sessão fica Em análise no comprovativo de morada.
`review_database_partial_match`	Validação de base de dados – correspondência parcial	Em análise	Os serviços de base de dados devolvem correspondências parciais no nome e na data de nascimento. A sessão fica Em análise na validação de base de dados.
`decline_kyb_registry_mismatch`	KYB – dados do registo divergentes	Recusada	O mock do registo devolve uma empresa cujos dados de registo não coincidem com os detalhes esperados. A sessão empresarial é recusada na verificação do registo.
`review_kyb_registry_partial`	KYB – dados do registo parcialmente correspondentes	Em análise	O mock do registo devolve uma empresa cujo nome só corresponde parcialmente. A sessão empresarial fica Em análise na verificação do registo.

Os cenários review_* existem para poder testar a experiência de revisão manual (a fila de revisão na consola, webhooks de In Review, ações de aprovação e recusa do revisor) sem precisar de uma entrada que provoque uma recusa. Os dois cenários kyb_* acima definem expected_details.registration_number em vez de expected_details.first_name: aplicam-se apenas a sessões de Verificação de empresas (KYB).

Valores mágicos

Um valor mágico é uma entrada específica que faz uma funcionalidade simulada gerar um risco específico. Defina o campo de entrada com o valor mágico (diretamente ou através de um cenário) para acionar esse risco.

Funcionalidade	Campo de entrada	Valor mágico	Risco	Descrição
AML	`user_email`	`sandbox+aml_hit@didit.test`	`POSSIBLE_MATCH_FOUND`	AML — pessoa politicamente exposta; a simulação de AML devolve uma correspondência e a sessão é recusada na verificação AML.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOCUMENT_EXPIRED`	`DOCUMENT_EXPIRED`	OCR — documento expirado; a sessão é recusada na verificação de identidade.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_MINIMUM_AGE_NOT_MET`	`MINIMUM_AGE_NOT_MET`	OCR — a data de nascimento indica que o utilizador tem uma idade inferior à idade mínima configurada; a sessão é recusada.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_MAXIMUM_AGE_EXCEEDED`	`MAXIMUM_AGE_EXCEEDED`	OCR — a data de nascimento extraída excede a política de idade máxima configurada.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOCUMENT_NUMBER_FORMAT_MISMATCH`	`DOCUMENT_NUMBER_FORMAT_MISMATCH`	OCR — o número do documento extraído não corresponde à expressão regular de formato esperada para o documento, definida no registo de documentos.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_PERSONAL_NUMBER_FORMAT_MISMATCH`	`PERSONAL_NUMBER_FORMAT_MISMATCH`	OCR — o número pessoal extraído não passa a verificação de formato do registo de documentos.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION`	`DOCUMENT_NOT_SUPPORTED_FOR_APPLICATION`	OCR — o tipo de documento extraído está fora da política `documents_allowed` da aplicação.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED`	`FULL_NAME_MISMATCH_WITH_PROVIDED`	OCR — o nome no documento não corresponde ao nome que o cliente pré-preencheu em `expected_details`, acima do limiar de correspondência de nomes.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_GENDER_MISMATCH_WITH_PROVIDED`	`GENDER_MISMATCH_WITH_PROVIDED`	OCR — o género extraído não coincide com `expected_details.gender`.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED`	`DOB_MISMATCH_WITH_PROVIDED`	OCR — a data de nascimento extraída não coincide com `expected_details.date_of_birth`.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_COUNTRY_MISMATCH_WITH_PROVIDED`	`COUNTRY_MISMATCH_WITH_PROVIDED`	OCR — o país emissor não coincide com `expected_details.country` (ou `id_country`).
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_NATIONALITY_MISMATCH_WITH_PROVIDED`	`NATIONALITY_MISMATCH_WITH_PROVIDED`	OCR — a nacionalidade extraída não coincide com `expected_details.nationality`.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED`	`IDENTIFICATION_NUMBER_MISMATCH_WITH_PROVIDED`	OCR — o número do documento, pessoal ou fiscal extraído não coincide com `expected_details.identification_number`.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_COULD_NOT_RECOGNIZE_DOCUMENT`	`COULD_NOT_RECOGNIZE_DOCUMENT`	O pipeline de OCR devolve um resultado vazio ou não reconhecível; em produção, gera COULD_NOT_RECOGNIZE_DOCUMENT.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_MRZ_NOT_DETECTED`	`MRZ_NOT_DETECTED`	OCR — o documento requer uma MRZ, mas o pipeline não a conseguiu localizar.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_MRZ_VALIDATION_FAILED`	`MRZ_VALIDATION_FAILED`	OCR — a MRZ foi encontrada, mas falhou a validação de soma de verificação ou de formato.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME`	`MRZ_AND_DATA_EXTRACTED_FROM_OCR_NOT_SAME`	OCR — os campos de identidade da MRZ não coincidem com os campos extraídos da VIZ.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_BARCODE_NOT_DETECTED`	`BARCODE_NOT_DETECTED`	OCR — o documento requer um código de barras, mas não foi encontrado nenhum.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_BARCODE_VALIDATION_FAILED`	`BARCODE_VALIDATION_FAILED`	OCR — o código de barras foi descodificado, mas falhou a validação cruzada entre campos.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_QR_NOT_DETECTED`	`QR_NOT_DETECTED`	OCR — o documento requer um código QR, mas não foi encontrado nenhum.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_QR_VALIDATION_FAILED`	`QR_VALIDATION_FAILED`	OCR — o código QR foi descodificado, mas falhou a validação cruzada entre campos.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DATA_INCONSISTENT`	`DATA_INCONSISTENT`	OCR — as verificações de consistência interna dos campos da VIZ não coincidem entre si.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOCUMENT_SIDES_MISMATCH`	`DOCUMENT_SIDES_MISMATCH`	OCR — a frente e o verso do document_name não correspondem ao mesmo documento.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_NAME_NOT_DETECTED`	`NAME_NOT_DETECTED`	OCR — não foi possível extrair nem o primeiro nome nem o apelido do documento.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DATE_OF_BIRTH_NOT_DETECTED`	`DATE_OF_BIRTH_NOT_DETECTED`	OCR — a classe do documento exige uma data de nascimento, mas a extração não devolveu nenhuma.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_EXPIRATION_DATE_NOT_DETECTED`	`EXPIRATION_DATE_NOT_DETECTED`	OCR — a classe do documento exige uma data de validade, mas a extração não devolveu nenhuma.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_DOCUMENT_NUMBER_NOT_DETECTED`	`DOCUMENT_NUMBER_NOT_DETECTED`	OCR — não foi possível extrair nem o número do documento nem o número pessoal.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_COULD_NOT_DETECT_DOCUMENT_TYPE`	`COULD_NOT_DETECT_DOCUMENT_TYPE`	OCR — o classificador não conseguiu associar a captura a um tipo de documento suportado.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_PORTRAIT_IMAGE_NOT_DETECTED`	`PORTRAIT_IMAGE_NOT_DETECTED`	OCR — o pipeline não conseguiu isolar uma região de retrato no documento.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_UNPARSED_ADDRESS`	`UNPARSED_ADDRESS`	OCR — o documento tem um campo de morada, mas a geocodificação / análise não devolveu nada utilizável.
DATABASE_VALIDATION	`expected_details.first_name`	`SANDBOX_DB_NO_MATCH`	`DATABASE_VALIDATION_NO_MATCH`	Validação de base de dados — todos os serviços governamentais/de registo devolvem NO_MATCH; a sessão é recusada na validação de base de dados.
FACEMATCH	`expected_details.first_name`	`SANDBOX_FACE_LOW_MATCH`	`LOW_FACE_MATCH_SIMILARITY`	Correspondência facial — pontuação de semelhança abaixo do limiar de recusa; a sessão é recusada na correspondência facial.
PHONE	`phone_number`	`+15005550009`	`HIGH_RISK_PHONE_NUMBER`	Telefone — número de teste reservado, não entregável / de risco elevado; a simulação da verificação de telefone devolve uma falha.
EMAIL	`user_email`	`sandbox+breach@didit.test`	`BREACHED_EMAIL_DETECTED`	E-mail — a base de dados de violações de dados devolve uma correspondência para este endereço.
LOCATION	`expected_details.first_name`	`SANDBOX_IP_BLOCKLIST`	`IP_ADDRESS_IN_BLOCKLIST`	Análise de IP — o endereço IP do chamador consta da lista de bloqueio da aplicação; a sessão é recusada na análise de IP.
PROOF_OF_ADDRESS	`expected_details.first_name`	`SANDBOX_POA_ADDRESS_MISMATCH`	`ADDRESS_MISMATCH_WITH_PROVIDED`	POA — a morada no documento carregado não coincide com a morada que o cliente preencheu em `expected_details`; a sessão é recusada na POA.
LIVENESS	`expected_details.first_name`	`SANDBOX_LIVENESS_ATTACK`	`LIVENESS_FACE_ATTACK`	Prova de vida — a simulação de prova de vida passiva deteta um sinal de ataque facial; a sessão é recusada na prova de vida.
NFC	`expected_details.first_name`	`SANDBOX_NFC_CHIP_NOT_VERIFIED`	`NFC_CHIP_NOT_VERIFIED`	NFC — o mock do ePassport devolve um chip cuja assinatura SOD/DG falha na verificação de integridade; em produção, emite NFC_CHIP_NOT_VERIFIED e recusa quando o fluxo recusa chips não verificados.
NFC	`expected_details.first_name`	`SANDBOX_NFC_TRUST_ANCHOR_MISSING`	`NFC_TRUST_ANCHOR_MISSING`	NFC — o DSC forma uma cadeia até uma CSCA ausente do repositório de confiança; em produção, emite NFC_TRUST_ANCHOR_MISSING e aplica a ação configurada para chips não verificados.
DOCUMENT_AI	`expected_details.first_name`	`SANDBOX_DOCUMENT_AI_UNREADABLE`	`DOCUMENT_AI_UNREADABLE_DOCUMENT`	Document AI — a extração não devolve quaisquer campos legíveis; em produção, emite DOCUMENT_AI_UNREADABLE_DOCUMENT e o documento fica recusado quando o limite de tentativas é esgotado.
AML	`user_email`	`sandbox+aml_review@didit.test`	`POSSIBLE_MATCH_FOUND`	AML — possível correspondência que precisa de resolução manual; a sessão fica em análise.
FACEMATCH	`expected_details.first_name`	`SANDBOX_FACE_BORDERLINE_MATCH`	`LOW_FACE_MATCH_SIMILARITY`	Correspondência facial — semelhança limítrofe entre os limiares de análise e de recusa; a sessão fica em análise.
ID_VERIFICATION	`expected_details.first_name`	`SANDBOX_OCR_BORDERLINE_AGE`	`MINIMUM_AGE_NOT_MET`	OCR — a data de nascimento é inferior à idade mínima, mas o fluxo analisa em vez de recusar falhas de idade mínima; a sessão fica em análise.
DATABASE_VALIDATION	`expected_details.first_name`	`SANDBOX_DB_PARTIAL_MATCH`	`DATABASE_VALIDATION_PARTIAL_MATCH`	Validação de base de dados — a identificação coincide, mas o nome e a data de nascimento coincidem apenas parcialmente; a sessão fica em análise.
PROOF_OF_ADDRESS	`expected_details.first_name`	`SANDBOX_POA_PARTIAL_MATCH`	`ADDRESS_MISMATCH_WITH_PROVIDED`	POA — a morada no documento carregado coincide parcialmente com a morada fornecida; a sessão fica em análise.
KYB_REGISTRY	`expected_details.registration_number`	`SANDBOX-KYB-MISMATCH`	`KYB_REGISTRY_DATA_MISMATCH_WITH_EXPECTED`	KYB - os dados da empresa no registo não coincidem com os dados esperados; a sessão é recusada.
KYB_REGISTRY	`expected_details.registration_number`	`SANDBOX-KYB-REVIEW`	`KYB_REGISTRY_DATA_PARTIAL_MATCH_WITH_EXPECTED`	KYB - os dados da empresa no registo coincidem parcialmente; a sessão fica em análise.

Consulta sem documento e carteiras de identidade

As aplicações sandbox podem ativar todas as carteiras de identidade do catálogo do país, incluindo carteiras indisponíveis em aplicações de produção. O cenário predefinido approve simula uma identidade verificada sem iniciar sessão numa carteira externa. O resultado fica guardado na sessão e segue o próximo passo normal do fluxo. O sandbox não valida uma credencial de carteira real nem cobra pelas tentativas simuladas. Os pedidos de consulta continuam a validar os campos introduzidos e a usar o limite de tentativas configurado, que por predefinição é de um. Use os cenários seguintes para testar novas tentativas e as regras de recurso:

Cenário	Resultado simulado
`lookup_partial_match`	Correspondência parcial no registo; conta para o limite de tentativas.
`lookup_no_match`	O registo responde sem correspondência; conta para o limite de tentativas.
`lookup_provider_error`	O registo não devolve resposta; pede-se ao utilizador que tente novamente e, após três tentativas sem resposta, aplica-se a regra de recurso por erro do fornecedor.
`wallet_cancelled`	O utilizador cancela o início de sessão na carteira.
`wallet_timeout`	O início de sessão na carteira expira.
`wallet_provider_error`	A carteira não consegue concluir o início de sessão.

As falhas da carteira seguem a definição do país: recorrer à captura do documento ou recusar. As tentativas de consulta concluídas são registadas separadamente; assim, duas tentativas permitidas produzem dois resultados antes do recurso. Toda a utilização do sandbox continua gratuita.

Verificação bancária e verificação de conta

Um passo de Verificação bancária no sandbox oferece ambos os métodos em todos os países, pela ordem definida pelo passo, num serviço simulado, sem banco real e sem custos. Com a ordem predefinida, a pessoa começa no início de sessão no banco e seleciona Introduza os dados da sua conta para executar a verificação de conta; defina bank_method_order como ["account_lookup", "open_banking"] para começar por esta opção. Os últimos quatro caracteres da conta introduzida determinam a resposta; consulte Testar no sandbox para ver todas as terminações e uma conta válida por formato. A API de verificação de conta devolve uma chave de sandbox com base nas mesmas terminações.

Os documentos de exemplo

Nunca carregue documentos de identidade reais no sandbox. Use, em vez disso, os documentos de exemplo incorporados.

O fluxo alojado oferece três documentos de exemplo, um por tipo de documento:

País	Tipo de documento
Espanha	Cartão de identidade nacional
Argentina	Passaporte
Polónia	Carta de condução

Toque num exemplo na faixa para o usar em vez de uma captura real. Os dados extraídos e o resultado da sessão vêm sempre do cenário ou do valor mágico selecionado, pelo que qualquer exemplo funciona com qualquer cenário.

Identidade de exemplo: testar `expected_details`

Todos os documentos de sandbox são fabricados a partir de uma única identidade fixa. Os valores extraídos são iguais em todas as sessões e nunca são derivados da data atual, pelo que pode pré-preencher expected_details com eles e verificar de ponta a ponta a comparação de campos e o tratamento de avisos. Se passar os valores abaixo, as verificações de comparação passam; se passar outros valores, o aviso *_MISMATCH_WITH_PROVIDED correspondente é disparado de propósito. As datas são partilhadas por todos os documentos de exemplo:

Campo	Valor
`date_of_birth`	`1990-06-15`
Data de emissão	`2025-06-15`
Data de validade	`2035-06-15`

O restante da identidade depende do documento utilizado:

`sandbox_sample`	Documento	`first_name`	`last_name`	`gender`	`nationality`	`id_country`	`identification_number`
(padrão, nenhum exemplo selecionado)	Passaporte eletrónico do Brasil	`GUSTAVO`	`MATSUMOTO`	`M`	`BRA`	`BRA`	`YC531181`
`spain-id-card-2021`	Cartão de identidade nacional de Espanha	`CARMEN`	`ESPAÑOLA ESPAÑOLA`	`F`	`ESP`	`ESP`	`CAA000000`
`argentina-passport-2009`	Passaporte da Argentina	`MARIA VICTORIA`	`VILLAREAL`	`F`	`ARG`	`ARG`	`AAF794880`
`poland-driving-license-2019`	Carta de condução da Polónia	`JAN`	`KOWALSKI`	não consta neste documento	`POL`	`POL`	`SP005/89/5`

{
  "workflow_id": "<your-workflow-uuid>",
  "expected_details": {
    "date_of_birth": "1990-06-15",
    "gender": "M",
    "nationality": "BRA",
    "identification_number": "YC531181"
  }
}

first_name e last_name são a exceção: o sandbox repete no documento fabricado os nomes que envia em expected_details, pelo que a correspondência de nomes passa com qualquer nome. Use o valor mágico SANDBOX_OCR_FULL_NAME_MISMATCH_WITH_PROVIDED para testar uma divergência de nome, e SANDBOX_OCR_DOB_MISMATCH_WITH_PROVIDED para uma divergência na data de nascimento.

Se o seu fluxo restringir documents_allowed a um país ou tipo de documento que exclua o passaporte eletrónico do Brasil, o sandbox fabrica, em vez disso, um documento a partir do primeiro país permitido, pelo que nationality, id_country e o nome do documento acompanham esse país. As datas acima mantêm-se.

O que o documento fabricado não contém

O documento fabricado é o modelo genérico do país e do tipo de documento permitidos, pelo que os campos que só um documento real emitido por um estado fornece ficam vazios. O que mais importa para o encaminhamento é a região / estado dos EUA (kyc.region): uma carta de condução ou um cartão de identificação dos EUA de sandbox não tem estado, pelo que uma condição de ramificação como Region equals IL nunca é satisfeita no sandbox e, quando também nenhuma outra ramificação do nó corresponde, o fluxo segue a ramificação de fallback do nó (a ramificação sem condições). Isto não é uma revisão nem uma falha da ramificação - a condição simplesmente não tem o que ler. Um campo em falta também faz falhar not equals e not in; veja como as condições de ramificação leem os dados da sessão para a diferença entre um campo em falta e uma string vazia. Para testar um fluxo que depende do estado no sandbox, baseie a decisão num valor que controla na sessão, e não no documento:

Envie o estado em metadata ao criar a sessão (por exemplo, "metadata": {"credential_state": "IL"}) e crie a ramificação com base em metadata.credential_state. Os metadados são avaliados no sandbox exatamente como em produção.
Mantenha a condição kyc.region, baseada no documento, para o tráfego real, se também precisar que o documento comprove o estado; em produção, a região é lida do documento real.

Tudo o resto no encaminhamento é idêntico ao modo real: o grafo do fluxo, as condições de ramificação, os valores de metadata e expected_details, os nós de ação e os nós de estado são todos executados a sério. O sandbox nunca força uma sessão para revisão por iniciativa própria - uma sessão do sandbox só passa para Em análise quando o fluxo a encaminha para lá (um cenário review_*, um valor mágico mapeado para uma ação de revisão ou um nó de estado no grafo).

Códigos OTP e adesão ao envio de e-mails

OTP por telefone: a verificação de telefone do sandbox aceita qualquer código bem formado (de 4 a 8 dígitos; inclui 123456). Uma entrada mal formada continua a devolver 400.
OTP por e-mail: a verificação de e-mail do sandbox aceita qualquer código bem formado (inclui 123456). Uma entrada mal formada continua a devolver 400.

Por predefinição, as sessões do sandbox não enviam e-mails (alertas de revisão, alterações de estado, OTP, reenvio, nova ligação de sessão, etc.). Para entregar um e-mail mesmo assim, use um destes padrões de adesão no endereço do destinatário:

Padrão de adesão	Exemplo
`<local>+sandbox@<domain>`	`alice+sandbox@example.com`
`*@didit.test`	`alice@didit.test`

Condução dos resultados: cenários, valores mágicos, armação e o endpoint de simulação

Existem cinco formas de controlar um resultado sandbox.

1. `sandbox_scenario` na criação da sessão

Defina o slug do cenário ao criar a sessão (POST /v3/session/). O fluxo de criação expande os valores mágicos agrupados no cenário para os campos de entrada da sessão, de modo que os fornecedores simulados emitam o resultado pretendido através do pipeline real do fluxo.

{
  "workflow_id": "<your-workflow-uuid>",
  "sandbox_scenario": "decline_document_expired"
}

2. Valores mágicos introduzidos manualmente

Defina os campos de entrada individualmente (por exemplo, expected_details.first_name = "SANDBOX_OCR_DOCUMENT_EXPIRED" ou user_email = "sandbox+aml_hit@didit.test"). Consulte a tabela de valores mágicos acima para o registo completo.

3. Armar (ou voltar a armar) a sessão antes de o fluxo começar

Defina ou substitua o cenário armado numa sessão já existente, desde que esta não tenha avançado para além de Not Started. Este é o endpoint que o seletor de cenário anterior ao fluxo chama, e pode chamá-lo diretamente para criar um seletor personalizado ou um ambiente de teste:

POST /v3/session/{session_id}/sandbox/arm/
Session-Token: <session_token>

{
  "scenario": "decline_document_expired"
}

Resposta 200:

{
  "session_id": "<session_id>",
  "scenario": "decline_document_expired",
  "status": "Not Started"
}

Autentique-se com o Session-Token da própria sessão (devolvido como session_token na criação da sessão), e não com a chave de API da aplicação: trata-se de um endpoint voltado para o cliente.
Devolve 400 para um slug de cenário desconhecido, e 400 quando a sessão já avançou para além de Not Started ("Scenario can only be armed before the verification starts.").
Devolve 404 quando o Session-Token pertence a uma aplicação de produção (não sandbox), ou quando não corresponde ao session_id do caminho.
Voltar a armar substitui o cenário anterior. Limpa apenas os valores mágicos que o cenário anterior escreveu e deixa intacto tudo o que o utilizador já tenha introduzido manualmente (e-mail, nome próprio, etc.). Por exemplo: arme decline_phone_high_risk e depois arme approve. O número de telefone volta a ficar por definir, mas um e-mail introduzido pelo cliente sobrevive às duas chamadas.

4. O endpoint de simulação

Force um estado final a posteriori:

Consola / chave de API (requer o privilégio write:sessions; uma chave de API com âmbito limitado precisa de acesso de escrita às sessões): POST /v3/session/{session_id}/simulate/
Fluxo alojado (cabeçalho Session-Token): POST /v3/session/{session_id}/sandbox/simulate/

Ambos funcionam em sessões sandbox KYC e KYB. Uma sessão de produção (não sandbox) devolve 404, e o mesmo acontece com um Session-Token que não corresponda ao session_id do caminho. Todos os campos do corpo são opcionais, mas é obrigatório pelo menos um de new_status, scenario ou risk:

Campo	Tipo	O que faz
`new_status`	string	`Approved`, `Declined`, `In Review`, `Expired` ou `Abandoned`. Quando o omite, assume o estado predefinido do caso de risco (`risk`, ou o primeiro risco que os valores mágicos do cenário trazem) ou, na sua falta, o estado predefinido do cenário.
`scenario`	string, até 100 caracteres	Um slug de cenário. Sem `risk`, é aplicado o primeiro risco que os seus valores mágicos incluem.
`risk`	string, até 128 caracteres	Um caso de risco. O respetivo aviso é adicionado à sessão.
`node_id`	string, até 128 caracteres	O nó do fluxo ao qual o aviso fica associado. O valor predefinido é o nó atual da sessão.
`comment`	string, até 500 caracteres	Nota adicionada à entrada de atividade que regista a alteração de estado.
`send_webhooks`	booleano, predefinido `true`	Se a alteração de estado envia webhooks.

Com send_webhooks: true, são enviados exatamente os webhooks que uma alteração de estado real envia: status.updated, além dos eventos user.status.updated e user.data.updated (ou business.status.updated e business.data.updated numa sessão de empresa) que a alteração provoca, para os destinos que subscreveram esses eventos. Com send_webhooks: false, o estado continua a mudar, mas nenhum webhook é registado nem enviado. A recuperação de webhooks perdidos nunca reenvia essa decisão, e a consola continua a atualizar-se em tempo real. A próxima alteração de estado da sessão envia webhooks como habitualmente.

{
  "scenario": "decline_aml_hit",
  "send_webhooks": false
}

Resposta 200:

{
  "session_id": "<session_id>",
  "previous_status": "In Progress",
  "status": "Declined",
  "scenario": "decline_aml_hit",
  "risk": "POSSIBLE_MATCH_FOUND",
  "send_webhooks": false
}

status é o estado que a simulação definiu, e previous_status o estado que a sessão tinha antes.
scenario repete o slug enviado e risk é o caso de risco aplicado; cada um é null quando não existe.
send_webhooks repete o valor aplicado.
Devolve 400 para um cenário ou risco desconhecido, quando não é possível derivar nenhum new_status, para qualquer outro new_status, e quando a sessão já tem o estado pedido (["The new status is the same as the current status."]).

5. `sandbox_scenario` na API AML autónoma

A triagem AML em back-end não tem utilizador final nem sessão para armar, por isso o slug vai no próprio pedido de triagem (POST /v3/aml/):

{
  "full_name": "Ada Lovelace",
  "save_api_request": true,
  "sandbox_scenario": "decline_aml_hit"
}

decline_aml_hit devolve uma correspondência com o formato de produção e fecha a triagem como Declined; review_aml_possible_match fecha-a como In Review. Um cenário que não arma nenhum resultado AML deixa a triagem limpa.
Com save_api_request: true (valor predefinido), a triagem é guardada exatamente como numa chave de produção, pelo que o request_id devolvido é resolvido através de GET /v3/session/{request_id}/decision/ e GET /v3/session/{request_id}/generate-pdf/.
Devolve 400 para um slug de cenário desconhecido, e 400 quando a chave de API pertence a uma aplicação de produção.

Onde aparece `sandbox_scenario`

O slug do cenário armado (null se nenhum estiver armado) é devolvido em algumas superfícies e intencionalmente omitido noutras:

Superfície	Exposta?
Payload do passo atual (KYC e KYB)	Sim, como `sandbox_scenario`
`GET /v1/session/{id}/decision/`	Sim, como `sandbox_scenario`
`GET /v3/session/{id}/decision/` (ver Obter sessão)	Sim, `sandbox_scenario` de primeiro nível (null quando não armado)
Webhooks de sessão (`status.updated`, `data.updated`)	Sim, como `sandbox_scenario`; `null` em sessões de produção ou em sessões sandbox sem cenário armado

Se a sua integração precisar de ramificar com base no cenário armado do lado do servidor, leia-o do envelope do webhook ou de qualquer um dos endpoints de decisão (v1 ou v3).

Utilização e faturação

A utilização de sandbox é registada, mas nunca faturada:

Cada chamada simulada continua a registar um evento de utilização (is_sandbox: true, com preço 0.0000), para que o volume de sandbox fique visível para depuração. No entanto, esse evento nunca é somado aos seus totais de utilização, nunca é descontado do saldo e nunca aparece numa fatura.
O saldo, o carregamento de saldo e as vistas de utilização em produção da Business Console excluem a utilização de sandbox por defeito. Os endpoints de utilização de carregamento de saldo aceitam um parâmetro environment (live, o valor por defeito, ou sandbox) para que o volume de sandbox possa ser consultado separadamente, sempre a custo zero e sem consumo do plano gratuito.
A verificação de e-mail e de telefone é faturada por pedido e não por resultado de sessão, e o sandbox não consegue replicar totalmente este comportamento ao nível do webhook. As verificações de e-mail e de telefone em sandbox continuam a registar um evento de utilização por pedido, ao preço 0.0000, tal como qualquer outra funcionalidade simulada. Trata-se de uma divergência aceite e conhecida em relação ao comportamento de faturação em produção, e não de um erro.
A estrutura da resposta da validação de base de dados em sandbox diverge intencionalmente da estrutura específica de cada fornecedor em produção, uma vez que não existe um fornecedor real a replicar. Trate os payloads de validação de base de dados em sandbox como um substituto do resultado (estado e código de aviso), e não como uma pré-visualização, byte a byte, de uma resposta real de um fornecedor.

Guias

Autenticação

Model Context Protocol (MCP)

SDKs web

SDKs nativos

SDKs de servidor

Integrações

Dados de teste da sandbox: cenários, valores e documentos

Modelo de ambientes

Monitorização de transações no sandbox

Cenários do Test VASP da Travel Rule

Como alternar entre produção e sandbox

Sandbox no fluxo de verificação alojado

Cenários

Valores mágicos

Consulta sem documento e carteiras de identidade

Verificação bancária e verificação de conta

Os documentos de exemplo

Identidade de exemplo: testar `expected_details`

O que o documento fabricado não contém

Códigos OTP e adesão ao envio de e-mails

Condução dos resultados: cenários, valores mágicos, armação e o endpoint de simulação

1. `sandbox_scenario` na criação da sessão

2. Valores mágicos introduzidos manualmente

3. Armar (ou voltar a armar) a sessão antes de o fluxo começar

4. O endpoint de simulação

5. `sandbox_scenario` na API AML autónoma

Onde aparece `sandbox_scenario`

Utilização e faturação

​Modelo de ambientes

​Monitorização de transações no sandbox

​Cenários do Test VASP da Travel Rule

​Como alternar entre produção e sandbox

​Sandbox no fluxo de verificação alojado

​Cenários

​Valores mágicos

​Consulta sem documento e carteiras de identidade

​Verificação bancária e verificação de conta

​Os documentos de exemplo

​Identidade de exemplo: testar expected_details

​O que o documento fabricado não contém

​Códigos OTP e adesão ao envio de e-mails

​Condução dos resultados: cenários, valores mágicos, armação e o endpoint de simulação

​1. sandbox_scenario na criação da sessão

​2. Valores mágicos introduzidos manualmente

​3. Armar (ou voltar a armar) a sessão antes de o fluxo começar

​4. O endpoint de simulação

​5. sandbox_scenario na API AML autónoma

​Onde aparece sandbox_scenario

​Utilização e faturação

Modelo de ambientes

Monitorização de transações no sandbox

Cenários do Test VASP da Travel Rule

Como alternar entre produção e sandbox

Sandbox no fluxo de verificação alojado

Cenários

Valores mágicos

Consulta sem documento e carteiras de identidade

Verificação bancária e verificação de conta

Os documentos de exemplo

Identidade de exemplo: testar `expected_details`

O que o documento fabricado não contém

Códigos OTP e adesão ao envio de e-mails

Condução dos resultados: cenários, valores mágicos, armação e o endpoint de simulação

1. `sandbox_scenario` na criação da sessão

2. Valores mágicos introduzidos manualmente

3. Armar (ou voltar a armar) a sessão antes de o fluxo começar

4. O endpoint de simulação

5. `sandbox_scenario` na API AML autónoma

Onde aparece `sandbox_scenario`

Utilização e faturação