> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # API para confirmar propriedade de carteira na Travel Rule > Confirme ou negue via API da Didit que seu cliente controla a carteira beneficiária da transferência Travel Rule recebida em UNCONFIRMED_OWNERSHIP. Prompt da API para confirmar a propriedade da carteira Copiar o prompt para a área de transferência \

\`Confirm or deny wallet ownership on a Travel Rule transfer waiting on the beneficiary side - typically the beneficiary leg of an INTERNAL-rail transfer whose wallet address book entry has not been ownership-verified yet, a transfer whose counterparty wallet was declared self-hosted (counterparty.payment_method.method_type: "unhosted_wallet"), an inbound transfer in ON_HOLD, or an inbound TRP inquiry a compliance officer resolves by hand.

Endpoint:
POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/

Authentication:
Use the x-api-key header with my Didit API key. {transaction_id} is the Didit transaction uuid of the transfer your own application holds: on an INTERNAL-rail transfer that is your (beneficiary) side; on a declared self-hosted wallet it is the transaction you created, outbound or inbound.

Request body:
\{"confirmed": true}   or   {"confirmed": false}
Optionally {"confirmed": true, "wallet_address": "0x..."} - the payment address to return to the counterparty on an inbound TRP transfer.
On a declared self-hosted wallet transfer with no counterparty wallet on it, "wallet_address" supplies the wallet to verify; if neither the transfer nor the request names one, the request is rejected with 400.

Accepted states (anything else -> 409 "Transfer is not awaiting ownership confirmation."):
\- UNCONFIRMED_OWNERSHIP, in either direction.
\- ON_HOLD on an inbound transfer.
\- UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA on an inbound TRP transfer.

Behavior on a transfer Didit created itself (INTERNAL rail, sunrise registration, declared self-hosted wallet):
\- confirmed: true - marks the matching wallet address book entry ownership-verified, then runs the beneficiary name match on both sides: COMPLETED on a pass, COUNTERPARTY_MISMATCHED_DATA on a fail.
An inbound transfer whose deposit already settled then moves on to FINISHED.
\- confirmed: true on a declared self-hosted wallet - records that the customer verified who controls the counterparty wallet and completes the transfer (COMPLETED), outbound or inbound; an inbound deposit whose on-chain hash is already known moves on to FINISHED. The wallet is the counterparty's: the destination of a withdrawal, the originator's source wallet of a deposit. If it is not in the wallet address book yet, it is added as ownership-verified under the counterparty's name; if the book already holds it under a different holder name, the transfer goes to COUNTERPARTY_MISMATCHED_DATA.
\- confirmed: false - moves both sides of the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.
\- Resolving an inbound ON_HOLD with no matching entry, or confirming a declared self-hosted wallet, creates the entry from the transfer's wallet address and marks it verified.

Behavior on an inbound TRP transfer (answering the counterparty's inquiry):
\- confirmed: true - needs a payment address, taken from the request's wallet_address, then the matched entry, then beneficiary_data.wallet_address.
Didit creates or verifies the entry, posts the inquiry-resolution callback to the counterparty, sets ownership_confirmed and moves the transfer to COMPLETED.
\- confirmed: false - posts a declined resolution and moves the transfer to COUNTERPARTY_VASP_GENERAL_DECLINE.

Transfers a network delivered (GTR or Sygna Bridge):
\- An inbound transfer that waits for your review (UNCONFIRMED_OWNERSHIP, ON_HOLD or COUNTERPARTY_MISMATCHED_DATA) is decided here: confirmed: true approves it (send wallet_address when the transfer names none), confirmed: false declines it. Didit answers the network after the response, with retries; the response's delivery field shows that answer.
\- VerifyVASP takes its answer when it asks, so a VerifyVASP transfer that would need your review is declined at once and cannot be decided here.
\- Receiving over a network is switched on by Didit per network, and none is switched on today.

What to read from the response:
\- The full transfer object. originator_data/beneficiary_data stay masked on inbound transfers (data_masked: true) until ownership is confirmed; data_unmasked then records when, why and by whom. data_match and mismatched_fields name the fields that differ after a mismatch.

Alternative: instead of this API call, send the end customer through the hosted wallet-ownership widget (POST /v3/travel-rule/widget-session/) and let them prove control cryptographically.

Failure modes:
\- 400 - on an inbound TRP approval with no payment address available: {"wallet_address": ["wallet_address is required to approve."]}.
\- 409 - the transfer is not in one of the accepted states, no entry in your wallet address book matches the transfer's wallet address (an inbound TRP approval, and an inbound ON_HOLD transfer that carries beneficiary_data.wallet_address, and a declared self-hosted wallet, create the missing entry instead), an INTERNAL transfer from another Didit customer needs a control proof (signed message or test deposit) first, or a network transfer was already answered over its network (a VerifyVASP transfer, or a GTR or Sygna Bridge transfer already decided).
\- 502 - the counterparty's TRP inquiry-resolution callback could not be delivered; the transfer keeps its current status.
\- 404 - unknown transaction or no Travel Rule transfer attached.

Full guide: /transaction-monitoring/travel-rule#confirming-wallet-ownership.`

\
Colar em ## Carteiras autocustodiadasQuando a carteira da contraparte foi declarada autocustodiada (`counterparty.payment_method.method_type: "unhosted_wallet"`), a transferência fica aguardando em `UNCONFIRMED_OWNERSHIP`. Chamar este endpoint com `confirmed: true` registra que o seu cliente verificou quem controla essa carteira e conclui a transferência (`COMPLETED`), tanto para saques de saída quanto para depósitos de entrada. Um depósito de entrada cujo hash on-chain já é conhecido avança para `FINISHED`.A carteira verificada é a da contraparte: o destino de um saque de saída ou a origem (a carteira do remetente) de um depósito de entrada. A Didit a adiciona ao catálogo de endereços de carteiras com a propriedade verificada, em nome da contraparte, para que seja comparada ao nome da contraparte (o remetente, no caso de um depósito). Se o catálogo de endereços já tiver essa carteira registrada sob um nome de titular diferente, a transferência passa para `COUNTERPARTY_MISMATCHED_DATA`.Se a transferência não indicar nenhuma carteira da contraparte, envie `wallet_address` no corpo da requisição. Quando nem a transferência nem a requisição fornecem um endereço de carteira, a requisição é rejeitada com `400`.`confirmed: false` recusa a transferência (`COUNTERPARTY_VASP_GENERAL_DECLINE`). ## OpenAPI ````yaml pt-br/openapi-25.json POST /v3/transactions/{transaction_id}/travel-rule/ownership/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API de verificação de identidade. Autentique-se com o cabeçalho x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/transactions/{transaction_id}/travel-rule/ownership/: post: tags: - Travel Rule summary: Confirmar ou negar a propriedade da carteira description: >- Resolve uma transferência que aguarda a confirmação de propriedade da carteira: chame-o do seu lado da transferência quando ela estiver em UNCONFIRMED_OWNERSHIP, ou quando for uma transferência de entrada em ON_HOLD. A confirmação marca a entrada correspondente no catálogo de endereços de carteiras como tendo a propriedade verificada (para uma transferência de entrada em ON_HOLD sem entrada, a Didit cria uma a partir de beneficiary_data.wallet_address) e executa a verificação do nome do beneficiário nos dois lados da transferência; a negação recusa os dois lados. Uma transferência de entrada cujo depósito já foi liquidado passa para FINISHED quando a correspondência é bem-sucedida. Quando a carteira da contraparte foi declarada autocustodiada (counterparty.payment_method.method_type: unhosted_wallet), a confirmação registra que o cliente verificou quem controla essa carteira e conclui a transferência (COMPLETED) nas duas direções, ou FINISHED para um depósito de entrada cujo hash on-chain já é conhecido. A carteira verificada é a da contraparte: o destino de um saque de saída, ou a origem (carteira do remetente) de um depósito de entrada. Se ela ainda não estiver no seu catálogo de endereços de carteiras, a Didit a adiciona com a propriedade verificada em nome da contraparte; se o catálogo já a tiver em nome de um titular diferente, a transferência passa para COUNTERPARTY_MISMATCHED_DATA. Para uma transferência TRP de entrada em UNCONFIRMED_OWNERSHIP, ON_HOLD ou COUNTERPARTY_MISMATCHED_DATA, a Didit envia a sua decisão ao VASP de origem: a aprovação retorna o endereço de pagamento (wallet_address, ou o endereço da entrada correspondente) e move a transferência para COMPLETED, e a negação a recusa. A mesma chamada também decide uma transferência de entrada enviada por uma contraparte GTR ou Sygna Bridge que aguarda a sua revisão (`UNCONFIRMED_OWNERSHIP`, `ON_HOLD` ou `COUNTERPARTY_MISMATCHED_DATA`): `confirmed: true` a aprova (informe `wallet_address` quando a transferência não indicar nenhum) e `confirmed: false` a recusa, e a rede recebe a resposta depois da resposta da API, com novas tentativas. A VerifyVASP recebe a resposta no momento em que pergunta, por isso uma transferência VerifyVASP que precisaria da sua revisão é recusada imediatamente e não pode ser decidida depois. operationId: confirmTravelRuleOwnership parameters: - name: transaction_id in: path required: true description: >- UUID estável da Didit da transação que sua aplicação mantém para esta transferência: a transação do lado do beneficiário em uma transferência pelo trilho INTERNAL, ou a transação que você criou (de saída ou de entrada) quando a carteira da contraparte foi declarada autocustodiada. schema: type: string format: uuid requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/TravelRuleOwnershipConfirmRequest' example: confirmed: true responses: '200': description: >- A transferência atualizada. Em uma transferência recebida, os originator_data/beneficiary_data da contraparte permanecem mascarados (`data_masked: true`) até que a propriedade seja confirmada; então `data_unmasked` registra quando, por que e por quem. content: application/json: schema: $ref: '#/components/schemas/TravelRuleTransferDetail' '400': description: >- Erro de validação: confirmed ausente, uma aprovação TRP de entrada sem wallet_address e sem endereço para usar como alternativa, ou `confirmed: true` em uma transferência declarada de carteira autocustodiada que não indica nenhuma carteira da contraparte, sem que um `wallet_address` tenha sido enviado. content: application/json: examples: No payment address: value: wallet_address: - wallet_address is required to approve. '404': description: >- Transação desconhecida, ou a transação não tem transferência de Travel Rule. '409': description: >- A transferência não está aguardando confirmação de propriedade, nenhuma entrada do catálogo de endereços de carteiras corresponde à carteira da contraparte, uma transferência INTERNAL de outro cliente da Didit precisa de uma prova de controle (uma mensagem assinada ou um depósito de teste) antes de poder ser confirmada, ou uma transferência de rede já foi respondida pela própria rede (uma transferência VerifyVASP, ou uma transferência GTR ou Sygna Bridge sobre a qual você ou a Didit já decidiram). content: application/json: examples: Not awaiting confirmation: value: detail: Transfer is not awaiting ownership confirmation. No matching address book entry: value: detail: wallet address entry no longer available '502': description: >- Somente para transferências TRP recebidas: a Didit não conseguiu entregar sua decisão ao VASP de origem, então o status da transferência não muda. content: application/json: examples: Callback not delivered: value: detail: >- Counterparty inquiry-resolution callback could not be delivered. security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X POST https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/ownership/ \ -H 'x-api-key: YOUR_API_KEY' -H 'Content-Type: application/json' \ -d '{"confirmed": true}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed=True, ) print(result) - lang: javascript label: Node.js source: >- import Didit from "@didit-protocol/sdk-node"; // Reads DIDIT_API_KEY. const didit = new Didit(); const result = await didit.transactions.travelRule.confirmOwnership("11111111-2222-3333-4444-555555555555", { confirmed: true, }); console.log(result); - lang: go label: Go source: "ctx := context.Background()\n// Reads DIDIT_API_KEY.\nclient := didit.NewClient()\n\nresult, err := client.Transactions.TravelRule.ConfirmOwnership(ctx, \"11111111-2222-3333-4444-555555555555\", didit.TravelRuleOwnershipConfirmRequest{\n\tConfirmed: true,\n})\nif err != nil {\n\tlog.Fatal(err)\n}\nfmt.Printf(\"%+v\\n\", result)" - lang: java label: Java source: >- import me.didit.Didit; import me.didit.types.TravelRuleOwnershipConfirmRequest; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().travelRule().confirmOwnership("11111111-2222-3333-4444-555555555555", TravelRuleOwnershipConfirmRequest.builder() .confirmed(true) .build()); System.out.println(result); - lang: php label: PHP source: >- transactions->travelRule->confirmOwnership('11111111-2222-3333-4444-555555555555', [ 'confirmed' => true, ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.travel_rule.confirm_ownership( "11111111-2222-3333-4444-555555555555", confirmed: true ) puts result.to_h - lang: csharp label: .NET source: >- using System; using System.Text.Json; using Didit; // Reads DIDIT_API_KEY. using var client = new DiditClient(); var result = await client.Transactions.TravelRule.ConfirmOwnershipAsync("11111111-2222-3333-4444-555555555555", new TravelRuleOwnershipConfirmRequest { Confirmed = true, }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleOwnershipConfirmRequest: type: object required: - confirmed properties: confirmed: type: boolean description: true para confirmar a propriedade, false para negá-la. wallet_address: type: string default: '' description: >- Transferências TRP recebidas: o endereço de pagamento que a Didit retorna ao VASP de origem quando você aprova. O padrão é o endereço da entrada correspondente no catálogo de endereços e, depois, beneficiary_data.wallet_address. Em uma transferência declarada de carteira autocustodiada que não indica nenhuma carteira da contraparte, é a carteira cuja propriedade você verificou; sem ela, a requisição é rejeitada com 400. Ignorado nas demais transferências. TravelRuleTransferDetail: type: object description: >- Objeto de transferência completo retornado pelos endpoints de confirmação de propriedade e de finalização/cancelamento. Enquanto a propriedade da carteira de uma transferência recebida não for confirmada, os campos `originator_data` e `beneficiary_data` da contraparte são retornados mascarados (a primeira letra de cada palavra é mantida; a carteira, a blockchain e o roteamento do VASP continuam legíveis) e `data_masked` é true. properties: uuid: type: string format: uuid status: type: string enum: - AWAITING_COUNTERPARTY - ON_HOLD - COMPLETED - FINISHED - CANCELLED - EXPIRED - COUNTERPARTY_MISMATCHED_DATA - COUNTERPARTY_VASP_NOT_FOUND - COUNTERPARTY_VASP_NOT_REACHABLE - UNCONFIRMED_OWNERSHIP - COUNTERPARTY_VASP_GENERAL_DECLINE - NOT_ENOUGH_COUNTERPARTY_DATA - NOT_APPLICABLE direction: type: string enum: - INBOUND - OUTBOUND rail: type: string nullable: true enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - TEST_VASP - null description: >- O canal pelo qual a transferência foi roteada, ou null quando nenhum canal foi selecionado (por exemplo, abaixo do limiar, uma carteira autocustodiada da contraparte, um registro após o depósito ou nenhuma contraparte alcançável). INTERNAL significa que ambos os lados são aplicações da Didit; EMAIL significa que a contraparte foi alcançada por um link de retirada enviado por e-mail. TEST_VASP significa que o Didit Test VASP respondeu à transferência no sandbox. Em GTR, VERIFYVASP e SYGNA, a Didit lê a resposta da contraparte a partir da resposta da rede ou consultando-a a cada 5 minutos. TRUST apenas envia, portanto uma transferência TRUST permanece em AWAITING_COUNTERPARTY até expirar. Um canal de rede só é usado quando você conectou sua própria associação a essa rede. Ele é escolhido depois que a criação da transação retorna, por isso é null nessa resposta. protocol: type: string nullable: true ivms_version: type: string example: ivms101.2023 required: type: boolean ownership_confirmed: type: boolean nullable: true deadline_at: type: string format: date-time nullable: true timeline: type: array items: type: object properties: status: type: string at: type: string format: date-time detail: type: string name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- A comparação de nomes que esta entrada decidiu, ao lado de `detail`. Ausente nas entradas que não compararam nenhum nome. reason: type: string description: >- Presente somente na entrada de uma transição causada por uma falha de entrega: `email_undeliverable` ou `delivery_failed`, o valor que o `reason` da transferência informa. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Pontuação de due diligence de 0 a 100, em que valores maiores são melhores. Mesma escala do diretório de VASPs. dd_score_breakdown: type: object description: >- Contribuições de cada componente para o dd_score, um objeto por componente, como no diretório de VASPs (jurisdiction, verification, protocol, lei, history, essentials, responsiveness), cada um com {points, max, reason, detail}. {} até que a contraparte tenha sido avaliada. additionalProperties: type: object properties: points: type: number description: Pontos atribuídos a este componente. max: type: integer description: Pontuação máxima que este componente pode conceder. reason: type: string description: Código legível por máquina do veredito do componente. detail: type: string description: Motivo legível dos pontos atribuídos. dd_assessed_at: type: string format: date-time nullable: true description: >- Quando a avaliação de devida diligência foi executada pela última vez. Nulo até que a contraparte tenha sido avaliada. originator_data: type: object description: >- Parte remetente. Em uma transferência de entrada, os valores da contraparte ficam mascarados até que a propriedade seja confirmada. beneficiary_data: type: object description: >- Parte beneficiária. Em uma transferência recebida, os valores da contraparte ficam mascarados até que a propriedade seja confirmada. name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- A comparação de nomes que decidiu a transferência, ou nula até que uma seja executada. Enquanto as partes estão mascaradas, e na cópia do outro cliente de uma troca INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` ficam ocultos. `score` e `matched` podem divergir: `matched` segue o rigor, enquanto `score` é a similaridade entre os dois nomes completos. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Atalho para `data_match.mismatched_fields`. Vazio quando nada difere. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- True enquanto os dados pessoais da contraparte estão mascarados nesta resposta. created_at: type: string format: date-time delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Situação da mensagem mais recente que esta transferência deve à outra parte. Nulo quando a transferência nunca deveu uma mensagem (por exemplo, abaixo de `threshold_amount`, em uma carteira autocustodiada declarada ou em um registro de sunrise). discovery: type: array description: >- Como a Didit procurou a contraparte, com uma entrada por etapa executada. Vazio quando nenhuma descoberta foi executada, por exemplo, em uma transferência de entrada. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Motivo pelo qual uma transferência `COUNTERPARTY_VASP_NOT_FOUND` ou `COUNTERPARTY_VASP_NOT_REACHABLE` está parada; `""` para qualquer outro status. Uma falha de entrega decide primeiro, apenas em `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (o provedor de e-mail recusou o e-mail de conformidade e não resta nenhum endereço para tentar: no envio, em um lembrete ou como uma devolução permanente informada depois) ou `delivery_failed` (o canal que fazia a entrega falhou definitivamente: um canal de rede recusou a mensagem ou esgotou as novas tentativas, um host de identidade `TRP` não respondeu ou o host `TRP` da contraparte não aceitou a consulta). Caso contrário, o rastro de `discovery` decide: `awaiting_end_user` (nenhuma etapa indicou uma contraparte que a Didit consiga alcançar), `directory_match_no_route` (uma etapa indicou um VASP do diretório que não tem rota), `picked_member_without_proven_wallet` (o usuário final escolheu um cliente da Didit que não comprovou o controle da carteira) ou `no_directory_match` quando o rastro não indica nenhum outro motivo. Um reenvio faz a transferência avançar, e o motivo é então limpo. Veja [Por que uma transferência está parada](/pt-br/transaction-monitoring/travel-rule#por-que-uma-transferência-fica-travada). next_actions: type: array description: >- O que faz a transferência avançar; `[]` para qualquer status que não seja `COUNTERPARTY_VASP_NOT_FOUND` ou `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` oferece `update_compliance_email` e depois `resend`. `delivery_failed` oferece `resend`. Um motivo de descoberta oferece `select_counterparty_vasp`, `declare_self_hosted`, `add_vasp_hint` e `resend`. items: $ref: '#/components/schemas/TravelRuleNextAction' chain_details: $ref: '#/components/schemas/TravelRuleChainDetails' TravelRuleNameMatch: type: object nullable: true description: >- A comparação de nomes que decidiu a transferência, ou nula até que uma seja executada. Enquanto as partes estão mascaradas, e na cópia do outro cliente de uma troca INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` ficam ocultos. `score` e `matched` podem divergir: `matched` segue o rigor, enquanto `score` é a similaridade entre os dois nomes completos. properties: score: type: integer minimum: 0 maximum: 100 description: >- Similaridade entre os dois nomes completos, de 0 a 100. É 0 quando qualquer um dos nomes está em branco. matched: type: boolean description: >- Se os nomes atendem a `strictness`. O resultado da transferência segue `data_match`, que compara todos os campos, então uma transferência pode ser COUNTERPARTY_MISMATCHED_DATA mesmo quando este valor é verdadeiro. method: type: string enum: - none - exact_token - token_subset - token_containment - sequence_ratio description: >- Como `matched` foi decidido: none (`NONE`), exact_token (`STRICT`), token_subset (`DEFAULT`), token_containment (`CONTAINS`) ou sequence_ratio (`FUZZY`). strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY compared_with: type: string enum: - wallet_holder - counterparty_vasp description: >- wallet_holder: o titular registrado para a carteira. counterparty_vasp: o nome que a contraparte informou na página de resposta por e-mail, ou a resposta do Didit Test VASP no sandbox. transfer_name: type: string description: O nome na transferência. compared_name: type: string description: O nome com o qual ele foi comparado. matched_names: type: array items: type: string description: Palavras de `transfer_name` encontradas em `compared_name`. mismatched_names: type: array items: type: string description: >- Palavras de `transfer_name` ausentes em `compared_name` e, em seguida, palavras de `compared_name` ausentes em `transfer_name`. TravelRuleDataMatch: type: object nullable: true description: >- Comparação campo a campo entre os dados das partes da transferência e o que o outro lado sabe sobre o titular da carteira. Ela indica campos e resultados, nunca valores, por isso continua legível enquanto os dados da contraparte estão mascarados. Nulo até que uma comparação seja executada. properties: matched: type: boolean description: True quando nenhum campo comparado é diferente. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: Os campos que diferem. fields: type: object description: >- Uma entrada por campo comparado para o tipo de entidade da parte (`name`, `date_of_birth`, `address`, `account`; uma empresa não tem `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared` quando a regra é `NONE` ou um dos lados não tem valor para o campo. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Registro de auditoria do momento em que os dados da contraparte foram desmascarados. É nulo enquanto os dados ainda estão mascarados e em transferências de saída. properties: at: type: string format: date-time reason: type: string enum: - ownership_confirmed - wallet_proof - address_book_match - own_verified_wallet - inquiry_approved - known_payment_method - travel_address description: >- O que confirmou a propriedade: ownership_confirmed (sua confirmação pelo console ou pela API), wallet_proof (uma prova de carteira no widget ou uma transferência de entrada INTERNAL, definida quando é criada), address_book_match (uma carteira verificada do catálogo de endereços), own_verified_wallet (a carteira verificada do próprio usuário), inquiry_approved (sua aprovação de uma consulta TRP de entrada ou de uma mensagem GTR ou Sygna), known_payment_method (uma carteira com a qual seu usuário já pagou) ou travel_address (o travel address por carteira identificou a carteira). actor: type: string description: >- Quem confirmou: o e-mail do usuário do console ou o rótulo da chave de API. Em branco para uma decisão automática. TravelRuleDelivery: type: object description: >- Situação da mensagem mais recente que a transferência deve à outra parte. A Didit contata a contraparte depois que a requisição que criou ou alterou a transferência retorna, então este objeto indica se essa mensagem foi entregue: na fila, em envio, aguardando nova tentativa após um erro, entregue ou com falha. Uma falha da qual a rede ainda pode se recuperar (sem resposta a tempo, falha de conexão, HTTP `408`, `429` ou `5xx`) é tentada novamente após 30 segundos, 2 minutos, 10 minutos, 30 minutos e 1 hora. Quando uma primeira mensagem (`kind: SEND`) falha definitivamente, porque a rede a recusou ou porque a sexta tentativa também falhou, a transferência passa para `COUNTERPARTY_VASP_NOT_REACHABLE` com `last_error` em sua `timeline`; qualquer outra mensagem que falhe definitivamente é registrada na `timeline`. O `status` da transferência continua sendo a fonte da verdade sobre a troca em si. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- O que a mensagem transporta. `SEND`: a primeira mensagem da transferência para a contraparte (de saída; o canal é escolhido no momento do envio). `ANSWER`: sua aceitação ou recusa, devida à rede que fez a solicitação (de entrada). `TXID`: o hash da transação on-chain, depois que você conclui a transferência. `CANCEL`: o cancelamento, depois que você cancela a transferência. `POLL`: uma consulta de status a uma rede que oferece esse recurso, repetida a cada 5 minutos enquanto a transferência aguarda a contraparte. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: aguardando envio. `SENDING`: uma tentativa está em andamento. `RETRYING`: uma tentativa falhou e a próxima será executada em `next_attempt_at`. `DELIVERED`: o outro lado recebeu a mensagem. `FAILED`: o outro lado a recusou, ou a última tentativa falhou. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- O canal que transporta a mensagem. Fica vazio até que a Didit escolha um para uma primeira mensagem. attempts: type: integer minimum: 0 description: >- Tentativas feitas até agora para esta mensagem. Uma mensagem que não seja uma consulta de status é tentada no máximo 6 vezes. last_error: type: string description: >- O tipo de falha que a última tentativa encontrou, `""` quando não houve nenhuma: por exemplo `email undeliverable`, `trp identity endpoint unreachable` ou `trp transfer inquiry delivery failed`. Nunca inclui a resposta da própria contraparte, que fica na `timeline` da transferência. Quando o GTR responde com um erro, o código de status e a mensagem dele são incluídos. Os corpos de resposta nunca são incluídos. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Quando a próxima tentativa é executada enquanto a mensagem está `QUEUED` ou `RETRYING`. delivered_at: type: string format: date-time nullable: true description: Quando o outro lado recebeu a mensagem. TravelRuleDiscoveryStep: type: object description: >- Uma etapa da descoberta de contraparte que a Didit executou para uma transferência de saída, na ordem em que as executou. A primeira etapa que identifica um VASP com rota encerra a cadeia. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: outro cliente da Didit que comprovou o controle da carteira de destino. `wallet_attribution`: a atribuição da carteira feita por análise de blockchain. `network_lookup`: uma rede capaz de informar qual VASP detém o endereço. `customer_hint`: o nome do VASP, o LEI ou a jurisdição que você enviou em `beneficiary_data`. `end_user`: a contraparte que o usuário final (ou você) escolheu, ou o pedido para escolher uma. outcome: type: string enum: - match - miss - skipped description: >- `match`: a etapa identificou uma contraparte. `miss`: ela foi executada e não encontrou nenhuma. `skipped`: ela não pôde ser executada, e `reason` informa o motivo. reason: type: string description: >- Motivo legível por máquina, `""` quando há correspondência: `no_proven_internal_wallet`, `attribution_disabled`, `already_attributed`, `no_attributed_entity`, `directory_match_no_route`, `gtr_address_lookup_runs_on_dispatch`, `no_membership`, `network_switched_off`, `no_network_address_lookup`, `no_directory_match`, `awaiting_end_user` ou `picked_member_without_proven_wallet`. vasp: type: string format: uuid nullable: true description: O VASP do diretório indicado pela etapa, quando ela indicou um. rail: type: string nullable: true description: O canal que alcança essa contraparte, quando a etapa encontrou um. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Algo que faz avançar uma transferência `COUNTERPARTY_VASP_NOT_FOUND` ou `COUNTERPARTY_VASP_NOT_REACHABLE`. Consulte [Por que uma transferência está parada](/pt-br/transaction-monitoring/travel-rule#por-que-uma-transferência-fica-travada). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: o usuário final escolhe o VASP de destino no widget de propriedade da carteira, ou você faz um PATCH com `action=beneficiary_vasp`. `declare_self_hosted`: o usuário final declara no widget que a carteira é autocustodiada. `add_vasp_hint`: informe à Didit quem é a contraparte, com um nome de VASP, um LEI ou um travel address (por exemplo, um `travel_address` na entrada do catálogo de endereços da carteira de destino) e depois reenvie. `update_compliance_email` e `resend` são valores de `action` de `PATCH /v3/transactions/{transaction_id}/travel-rule/`: informe novamente o e-mail de conformidade da contraparte e execute o roteamento outra vez. url: type: string format: uri description: >- O link do widget de propriedade da carteira, em `select_counterparty_vasp` e `declare_self_hosted`, enquanto a transferência tiver uma sessão de widget aberta. required: - action TravelRuleChainDetails: type: object description: >- Como a blockchain da transferência identifica suas duas carteiras, quando isso vai além de um endereço pagando a outro. Vazio (`{}`) para uma transferência em blockchain baseada em contas (EVM, Solana, Tron), em que os dois endereços são as próprias carteiras. A correspondência, o roteamento e o catálogo de endereços leem as carteiras primeiro a partir daqui. properties: chain: type: string description: >- Blockchain canônica, por exemplo, `BTC`, `XRP` ou `LIGHTNING` para uma transferência Lightning. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- Em uma transferência UTXO: as entradas e saídas conforme armazenadas (valores como strings decimais) e como a Didit interpretou cada saída. properties: inputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' outputs: type: array items: $ref: '#/components/schemas/TravelRuleUtxoEntry' change_output_indexes: type: array items: type: integer description: Saídas que pagam de volta a um endereço de entrada. beneficiary_output_index: type: integer nullable: true description: >- A saída que paga o beneficiário; null quando nenhuma pôde ser distinguida. lightning: type: object description: >- Em uma transferência Lightning: o que a requisição de pagamento informa. Sempre `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` ou `unknown`); uma fatura BOLT11 acrescenta `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` e `expires_at`; uma string BOLT12, `blinded_paths` e `payee_node_id`; uma LNURL ou um Lightning Address, o respectivo `domain`. Nada é resolvido pela rede: a requisição é apenas decodificada. additionalProperties: true warnings: type: array items: type: string enum: - declared_originator_not_an_input - declared_beneficiary_not_an_output - beneficiary_output_ambiguous - beneficiary_output_amount_differs description: >- Inconsistências de UTXO que merecem atenção: o remetente declarado não é uma entrada, o beneficiário declarado não é uma saída, não foi possível distinguir uma única saída do beneficiário, ou a saída do beneficiário paga um valor diferente do informado na transação. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- Em uma transferência Lightning de saída cuja requisição de pagamento não indica nenhum beneficiário: o motivo pelo qual a transferência é `NOT_APPLICABLE`. `LIGHTNING_NO_PAYEE_IDENTIFIER` (a requisição não indica nenhum nó beneficiário ou não pôde ser decodificada), `LIGHTNING_BOLT12_BLINDED_PAYEE` (a oferta oculta o beneficiário atrás de blinded paths), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (uma LNURL indica um serviço, não um beneficiário). O mesmo código abre a última entrada de `timeline` da transferência. TravelRuleChainSide: type: object description: >- A carteira de uma das partes, conforme a Didit a resolveu a partir dos dados da blockchain. properties: address: type: string description: >- A carteira. Em uma rede com memo, o endereço clássico (um X-address da XRP é dividido em endereço clássico e tag); na Lightning, o ID do nó do beneficiário ou o Lightning Address. memo: type: string description: >- A destination tag ou o memo que faz parte da carteira; `""` para nenhum. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Origem da carteira: `declared` (sua requisição), `x_address` (extraída de um X-address do XRP), `largest_input` (o endereço de entrada UTXO que mais contribuiu), `only_non_change_output` (a única saída UTXO que não é troco), `amount_match` (a única saída UTXO que paga o valor da transferência), `invoice_payee` (o beneficiário indicado em uma solicitação de pagamento Lightning), `updated` (definida posteriormente com `action: update_originator_wallet`). TravelRuleUtxoEntry: type: object description: >- Uma entrada ou saída de uma transação UTXO, conforme registrada na blockchain. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- String decimal na própria unidade da moeda (BTC, não satoshis). Opcional. example: '0.0125' txid: type: string maxLength: 128 description: Opcional. A transação que uma entrada gasta. vout: type: integer nullable: true minimum: 0 description: Opcional. O índice da saída que uma entrada gasta. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- Chave de API da sua aplicação, em Developers -> API keys no Business Console. A chave principal tem acesso total. Uma chave nomeada pode ter escopo restrito: nenhum acesso, leitura ou escrita por recurso, limitada a alguns fluxos ou a sessões aprovadas, a uma lista de endereços IP e a uma data de validade. 401 significa que a chave está errada, revogada ou expirada; 403 significa que nenhuma chave foi enviada, que a chave não tem acesso a este recurso ou ação, ou que a requisição veio de um endereço fora da sua lista de IPs; 404 em uma rota de sessão significa que a sessão está fora dos fluxos ou status da chave. Uma chave sem acesso a mídia recebe URLs de imagem, vídeo e PDF como null, e uma chave sem permissão de escrita em sessões recebe links e tokens de sessão como null. Consulte https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.