> ## 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. # Trigger trasferimento in entrata da VASP di test API > Solo sandbox: fai inviare da Didit Test VASP un trasferimento Travel Rule in entrata e verifica decisione, inbox e assetto proprietario. Prompt API per il test del trigger dei trasferimenti VASP in entrata Copia il prompt negli appunti \

\`Make the Didit Test VASP send my sandbox application an inbound Travel Rule transfer, to exercise the receiving side of an exchange before going live.

Endpoint:
POST https://verification.didit.me/v3/travel-rule/test-vasp/inbound/

Authentication:
Use the x-api-key header with my SANDBOX application's API key. A live application receives 400.

Request body (application/json):
\{
"beneficiary_wallet_address": "0xYourSandboxWallet",  // required: the destination wallet address
"scenario": "accept",                                // optional: accept (default) or name_mismatch
"chain": "ETH",                                      // optional
"amount": "1",                                       // optional, decimal string
"currency": "ETH",                                   // optional
"reference": "demo-001"                              // optional: repeat calls with it return the first transfer
}

Behavior:
\- The transfer is decided by the same logic a real inbound transfer runs, against my wallet address book: a verified wallet with the holder's name completes, an unverified wallet waits for ownership, a wallet with no matching address book entry is booked ON_HOLD, and name_mismatch ends as COUNTERPARTY_MISMATCHED_DATA.
\- Nothing leaves Didit. travel_rule.status.updated webhooks fire with environment "sandbox", test_vasp true and the scenario name.

What to read from the response:
\- transaction_id, txn_id - the booked inbound transaction.
\- travel_rule_status and detail - how my application decided it.
\- travel_rule - the full transfer.

Full guide: /transaction-monitoring/travel-rule#testing-without-network-credentials.`

\
Incolla in ## OpenAPI ````yaml it/openapi-25.json POST /v3/travel-rule/test-vasp/inbound/ openapi: 3.0.0 info: version: 3.0.0 title: Didit Verification API description: API di verifica dell'identità. Autenticati con l'intestazione x-api-key. servers: - url: https://verification.didit.me security: [] tags: [] paths: /v3/travel-rule/test-vasp/inbound/: post: tags: - Travel Rule summary: Attiva un trasferimento in entrata dal VASP di test di Didit (sandbox) description: >- Solo per applicazioni sandbox. Il Test VASP di Didit invia alla tua applicazione un trasferimento Travel Rule in entrata, consentendoti di testare end-to-end il lato ricevente di un exchange prima di passare in produzione. Il trasferimento viene registrato e valutato con la stessa logica applicata da un trasferimento reale in entrata proveniente da una rete alla tua rubrica degli indirizzi wallet; pertanto la casella di posta, la decisione e il flusso di proprietà del wallet operano esattamente come in produzione. Nulla esce da Didit. Un'applicazione in produzione riceve 400. Invia nuovamente lo stesso `reference` per recuperare il trasferimento registrato dalla prima chiamata anziché crearne un secondo. operationId: triggerTravelRuleTestVaspInbound requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/TravelRuleTestVaspInboundRequest' example: beneficiary_wallet_address: 0xYourSandboxWallet scenario: accept amount: '1' reference: demo-001 responses: '201': description: >- Il trasferimento in entrata è stato registrato e deciso. Una ripetizione con lo stesso `reference` restituisce il medesimo corpo. content: application/json: schema: $ref: '#/components/schemas/TravelRuleTestVaspInboundResponse' '400': description: >- Corpo non valido, uno `scenario` sconosciuto o non supportato, oppure l'applicazione è in produzione. content: application/json: schema: type: object '409': description: >- Impossibile registrare il trasferimento, ad esempio perché Travel Rule non è abilitata per l'applicazione. content: application/json: schema: type: object properties: detail: type: string security: - ApiKeyAuth: [] x-codeSamples: - lang: curl label: curl source: >- curl -X POST https://verification.didit.me/v3/travel-rule/test-vasp/inbound/ \ -H 'x-api-key: YOUR_SANDBOX_API_KEY' -H 'Content-Type: application/json' \ -d '{"beneficiary_wallet_address":"0xYourSandboxWallet","scenario":"accept","reference":"demo-001"}' - lang: python label: Python source: |- from didit import Didit # Reads DIDIT_API_KEY. client = Didit() result = client.transactions.travel_rule.trigger_test_vasp_inbound( beneficiary_wallet_address="0xYourSandboxWallet", scenario="accept", amount="1", reference="demo-001", ) 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.triggerTestVaspInbound({ beneficiary_wallet_address: "0xYourSandboxWallet", scenario: "accept", amount: "1", reference: "demo-001", }); 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.TriggerTestVASPInbound(ctx, didit.TravelRuleTestVASPInboundRequest{\n\tBeneficiaryWalletAddress: \"0xYourSandboxWallet\",\n\tScenario: didit.Some(didit.TravelRuleTestVASPInboundRequestScenario(\"accept\")),\n\tAmount: didit.String(\"1\"),\n\tReference: didit.String(\"demo-001\"),\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.TravelRuleTestVaspInboundRequest; // Reads DIDIT_API_KEY. Didit client = new Didit(); var result = client.transactions().travelRule().triggerTestVaspInbound(TravelRuleTestVaspInboundRequest.builder() .beneficiaryWalletAddress("0xYourSandboxWallet") .scenario(TravelRuleTestVaspInboundRequest.Scenario.of("accept")) .amount("1") .reference("demo-001") .build()); System.out.println(result); - lang: php label: PHP source: |- transactions->travelRule->triggerTestVaspInbound([ 'beneficiary_wallet_address' => '0xYourSandboxWallet', 'scenario' => 'accept', 'amount' => '1', 'reference' => 'demo-001', ]); print_r($result->toArray()); - lang: ruby label: Ruby source: |- require "didit" # Reads DIDIT_API_KEY. didit = Didit::Client.new result = didit.transactions.travel_rule.trigger_test_vasp_inbound( beneficiary_wallet_address: "0xYourSandboxWallet", scenario: "accept", amount: "1", reference: "demo-001" ) 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.TriggerTestVaspInboundAsync(new TravelRuleTestVaspInboundRequest { BeneficiaryWalletAddress = "0xYourSandboxWallet", Scenario = new TravelRuleTestVaspInboundRequestScenario("accept"), Amount = "1", Reference = "demo-001", }); Console.WriteLine(JsonSerializer.Serialize(result)); components: schemas: TravelRuleTestVaspInboundRequest: type: object required: - beneficiary_wallet_address properties: beneficiary_wallet_address: type: string description: >- L'indirizzo del wallet di destinazione. Il Test VASP di Didit invia verso questo indirizzo, confrontandolo con la rubrica dei wallet dell'asset sulla relativa blockchain. Un wallet senza una voce corrispondente viene accettato e la transazione in entrata viene registrata con stato ON_HOLD. scenario: type: string enum: - accept - name_mismatch default: accept description: >- Cosa dichiara il Didit Test VASP in merito al beneficiario. `accept` dichiara il nome effettivo del titolare; `name_mismatch` dichiara un nome con cui nessun titolare concorda. La decisione finale spetta sempre a te. chain: type: string default: ETH description: Chain dell'asset. amount: type: string default: '1' description: Importo come stringa decimale. currency: type: string default: ETH description: Codice dell'asset. reference: type: string description: >- Chiave di idempotenza opzionale. Una ripetizione con lo stesso valore restituisce il trasferimento prenotato dalla prima chiamata. TravelRuleTestVaspInboundResponse: type: object properties: transaction_id: type: string format: uuid description: UUID della transazione Didit per il trasferimento in entrata. txn_id: type: string description: txn_id generato da Didit. scenario: type: string description: Lo scenario eseguito. travel_rule_status: type: string description: Lo stato stabilito dalla decisione della tua applicazione. detail: type: string description: Il motivo per cui il trasferimento si è risolto in tale stato. test_vasp: type: boolean description: 'Sempre true: il mittente era il Didit Test VASP.' travel_rule: $ref: '#/components/schemas/TravelRuleTransferDetail' TravelRuleTransferDetail: type: object description: >- Oggetto di trasferimento completo restituito dagli endpoint di conferma della titolarità e di completamento/annullamento. Finché la titolarità del wallet di un trasferimento in entrata non è confermata, i campi `originator_data` e `beneficiary_data` della controparte vengono restituiti mascherati (viene mantenuta la prima lettera di ogni parola; il wallet, la chain e l'instradamento VASP rimangono leggibili) 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: >- Il canale (rail) su cui è stato instradato il trasferimento, o null quando non è stato selezionato alcun canale (ad esempio sotto la soglia, un wallet della controparte in autocustodia, una registrazione post-deposito o nessuna controparte raggiungibile). INTERNAL indica che entrambe le parti sono applicazioni Didit; EMAIL indica che la controparte è stata raggiunta tramite un link di ritiro inviato via email. TEST_VASP indica che il Didit Test VASP ha risposto al trasferimento sandbox. Tramite GTR, VERIFYVASP e SYGNA, Didit legge la risposta della controparte dalla risposta della rete o effettuando un polling ogni 5 minuti. TRUST invia soltanto, quindi un trasferimento TRUST rimane AWAITING_COUNTERPARTY fino alla scadenza. Un canale di rete viene utilizzato solo dopo aver collegato la propria iscrizione per tale rete. Viene scelto dopo che la creazione della transazione ha restituito risposta, quindi è null in tale risposta. 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: >- Il confronto dei nomi che ha determinato questa voce, accanto a `detail`. Assente nelle voci che non hanno confrontato alcun nome. reason: type: string description: >- Presente solo sulla voce di una transizione causata da una mancata consegna: `email_undeliverable` o `delivery_failed`, il valore riportato da `reason` del trasferimento. counterparty_vasp: type: object nullable: true properties: name: type: string lei: type: string dd_score: type: integer description: >- Punteggio di due diligence da 0 a 100, dove un valore più alto è migliore. Stessa scala utilizzata nella directory dei VASP. dd_score_breakdown: type: object description: >- Contributi per componente a dd_score, un oggetto per componente come nella directory VASP (giurisdizione, verifica, protocollo, lei, cronologia, elementi essenziali, reattività), ciascuno con {points, max, reason, detail}. {} finché la controparte non è stata valutata. additionalProperties: type: object properties: points: type: number description: Punti assegnati per questo componente. max: type: integer description: Punti massimi che questo componente può assegnare. reason: type: string description: Codice leggibile dalla macchina dell'esito del componente. detail: type: string description: Motivo leggibile dall'utente per i punti assegnati. dd_assessed_at: type: string format: date-time nullable: true description: >- Data e ora dell'ultima esecuzione della valutazione di adeguata verifica. Null finché la controparte non è stata valutata. originator_data: type: object description: >- Soggetto ordinante. Per un trasferimento in entrata, i valori della controparte sono oscurati fino alla conferma dell'assetto proprietario. beneficiary_data: type: object description: >- Parte beneficiaria. Per un trasferimento in entrata i valori della controparte sono mascherati fino a quando non viene confermato l'assetto proprietario. name_match: allOf: - $ref: '#/components/schemas/TravelRuleNameMatch' nullable: true description: >- Il confronto dei nomi che ha determinato il trasferimento, o null fino all'esecuzione. Mentre le parti sono oscurate, e sulla copia dell'altro cliente di uno scambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` rimangono nascosti. `score` e `matched` possono discordare: `matched` segue il livello di rigore, `score` è la somiglianza dei due nomi completi. data_match: $ref: '#/components/schemas/TravelRuleDataMatch' mismatched_fields: type: array items: type: string description: >- Scorciatoia per `data_match.mismatched_fields`. Vuoto quando non ci sono differenze. data_unmasked: $ref: '#/components/schemas/TravelRuleDataUnmasked' data_masked: type: boolean description: >- True mentre i dati personali della controparte sono mascherati in questa risposta. created_at: type: string format: date-time delivery: nullable: true allOf: - $ref: '#/components/schemas/TravelRuleDelivery' description: >- Lo stato dell'ultimo messaggio dovuto da questo trasferimento alla controparte. Null quando il trasferimento non ha mai dovuto inviarne uno (ad esempio al di sotto di `threshold_amount`, un wallet in autocustodia dichiarato o una registrazione sunrise). discovery: type: array description: >- Modalità con cui Didit ha cercato la controparte, una voce per ogni passaggio eseguito. Vuoto se non è stata eseguita alcuna ricerca, ad esempio per un trasferimento in entrata. items: $ref: '#/components/schemas/TravelRuleDiscoveryStep' reason: type: string description: >- Il motivo per cui un trasferimento `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE` è bloccato; `""` per qualsiasi altro stato. Una consegna non riuscita lo determina per prima, solo su `COUNTERPARTY_VASP_NOT_REACHABLE`: `email_undeliverable` (il provider di posta ha rifiutato l'email di compliance e non è rimasto alcun indirizzo da provare: quando è stata inviata, in un promemoria o come bounce permanente segnalato successivamente) o `delivery_failed` (il canale che effettuava la consegna è fallito definitivamente: un canale di rete ha rifiutato il messaggio o ha esaurito i tentativi, un host di identità `TRP` non ha risposto o l'host `TRP` della controparte non ha accettato la richiesta). Altrimenti lo determina la traccia di `discovery`: `awaiting_end_user` (nessun passaggio ha indicato una controparte raggiungibile da Didit), `directory_match_no_route` (un passaggio ha indicato un VASP della directory privo di rotta), `picked_member_without_proven_wallet` (l'utente finale ha scelto un cliente Didit che non ha dimostrato il controllo del wallet) o `no_directory_match` quando la traccia non fornisce altri motivi. Un nuovo invio fa avanzare il trasferimento, quindi il motivo viene azzerato. Consulta [Perché un trasferimento è bloccato](/it/transaction-monitoring/travel-rule#perché-un-trasferimento-è-bloccato). next_actions: type: array description: >- Cosa fa procedere il trasferimento; `[]` per qualsiasi stato tranne `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` propone `update_compliance_email`, poi `resend`. `delivery_failed` propone `resend`. Un motivo di discovery propone `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: >- Il confronto dei nomi che ha determinato il trasferimento, o null fino all'esecuzione. Mentre le parti sono oscurate, e sulla copia dell'altro cliente di uno scambio INTERNAL, `transfer_name`, `compared_name`, `matched_names` e `mismatched_names` rimangono nascosti. `score` e `matched` possono discordare: `matched` segue il livello di rigore, `score` è la somiglianza dei due nomi completi. properties: score: type: integer minimum: 0 maximum: 100 description: >- Somiglianza dei due nomi completi, da 0 a 100. 0 quando uno dei due nomi è vuoto. matched: type: boolean description: >- Indica se i nomi soddisfano `strictness`. L'esito del trasferimento segue `data_match`, che confronta ogni campo, pertanto un trasferimento può essere COUNTERPARTY_MISMATCHED_DATA anche quando questo valore è true. method: type: string enum: - none - exact_token - token_subset - token_containment - sequence_ratio description: >- Modalità con cui è stato determinato `matched`: nessuno (`NONE`), exact_token (`STRICT`), token_subset (`DEFAULT`), token_containment (`CONTAINS`) o sequence_ratio (`FUZZY`). strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY compared_with: type: string enum: - wallet_holder - counterparty_vasp description: >- wallet_holder: il titolare registrato per il wallet. counterparty_vasp: il nome indicato dalla controparte nella pagina di risposta via email, o la risposta di Didit Test VASP in sandbox. transfer_name: type: string description: Il nome sul trasferimento. compared_name: type: string description: Il nome con cui è stato confrontato. matched_names: type: array items: type: string description: Parole di `transfer_name` trovate in `compared_name`. mismatched_names: type: array items: type: string description: >- Parole di `transfer_name` mancanti da `compared_name`, seguite dalle parole di `compared_name` mancanti da `transfer_name`. TravelRuleDataMatch: type: object nullable: true description: >- Confronto campo per campo tra i dati della parte del trasferimento e ciò che l'altra parte sa sul titolare del wallet. Riporta i nomi dei campi e i risultati, mai i valori, in modo che rimanga leggibile mentre i dati della controparte sono oscurati. Null finché non viene eseguito un confronto. properties: matched: type: boolean description: True quando nessun campo confrontato differisce. mismatched_fields: type: array items: type: string enum: - name - date_of_birth - address - account description: I campi che differiscono. fields: type: object description: >- Una voce per ciascun campo confrontato per il tipo di entità della parte (`name`, `date_of_birth`, `address`, `account`; un'azienda non ha `date_of_birth`). additionalProperties: type: object properties: result: type: string enum: - matched - mismatched - not_compared description: >- `not_compared` quando la regola è `NONE` o una delle due parti non ha un valore per il campo. strictness: type: string enum: - NONE - STRICT - CONTAINS - DEFAULT - FUZZY TravelRuleDataUnmasked: type: object nullable: true description: >- Registro di audit del momento in cui i dati della controparte sono stati smascherati. Null finché i dati sono ancora mascherati e per i trasferimenti in uscita. 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: >- Cosa ha confermato l'assetto proprietario: ownership_confirmed (la tua conferma tramite la console o l'API), wallet_proof (una prova del wallet nel widget o un trasferimento in entrata INTERNAL, impostato al momento della creazione), address_book_match (un wallet verificato nella rubrica), own_verified_wallet (il wallet verificato del tuo utente), inquiry_approved (la tua approvazione di una richiesta TRP in entrata o di un messaggio GTR o Sygna), known_payment_method (un wallet con cui il tuo utente ha già pagato) o travel_address (il Travel Address associato al wallet ha denominato il wallet). actor: type: string description: >- Chi l'ha confermata: l'email dell'utente della console o l'etichetta della chiave API. Vuoto per una decisione automatica. TravelRuleDelivery: type: object description: >- Lo stato dell'ultimo messaggio dovuto dal trasferimento alla controparte. Didit contatta la controparte dopo la restituzione della richiesta che ha creato o modificato il trasferimento, quindi questo oggetto indica se tale messaggio è andato a buon fine: in coda, in fase di invio, in attesa di un nuovo tentativo dopo un errore, consegnato o non riuscito. In caso di errore da cui la rete può ancora riprendersi (nessuna risposta in tempo, connessione non riuscita, HTTP `408`, `429` o `5xx`), viene effettuato un nuovo tentativo dopo 30 secondi, 2 minuti, 10 minuti, 30 minuti e 1 ora. Quando un primo messaggio (`kind: SEND`) fallisce definitivamente, perché la rete lo ha rifiutato o anche il sesto tentativo non è riuscito, il trasferimento passa a `COUNTERPARTY_VASP_NOT_REACHABLE` con `last_error` nella sua `timeline`; qualsiasi altro messaggio che fallisce definitivamente viene annotato nella `timeline`. Lo `status` del trasferimento rimane l'unica fonte di verità per lo scambio stesso. required: - kind - status - rail - attempts - last_error - next_attempt_at - delivered_at properties: kind: type: string enum: - SEND - ANSWER - TXID - CANCEL - POLL description: >- Cosa trasporta il messaggio. `SEND`: il primo messaggio del trasferimento verso la controparte (in uscita; il canale viene scelto al momento dell'invio). `ANSWER`: la tua accettazione o rifiuto, dovuta alla rete che ha effettuato la richiesta (in entrata). `TXID`: l'hash della transazione on-chain, dopo aver completato il trasferimento. `CANCEL`: l'annullamento, dopo averlo cancellato. `POLL`: una richiesta di stato verso una rete che la supporta, ripetuta ogni 5 minuti mentre il trasferimento è in attesa della controparte. status: type: string enum: - QUEUED - SENDING - RETRYING - DELIVERED - FAILED description: >- `QUEUED`: in attesa di invio. `SENDING`: tentativo in corso. `RETRYING`: un tentativo non è riuscito e il prossimo verrà eseguito alle `next_attempt_at`. `DELIVERED`: l'altra parte ha ricevuto il messaggio. `FAILED`: l'altra parte lo ha rifiutato o l'ultimo tentativo non è riuscito. rail: type: string enum: - INTERNAL - TRP - GTR - TRUST - VERIFYVASP - SYGNA - EMAIL - '' description: >- Il canale (rail) che trasporta il messaggio. Vuoto finché Didit non ne sceglie uno per un primo messaggio. attempts: type: integer minimum: 0 description: >- Tentativi effettuati finora per questo messaggio. Per un messaggio che non è un polling di stato vengono effettuati al massimo 6 tentativi. last_error: type: string description: >- Il tipo di errore riscontrato nell'ultimo tentativo, `""` se non ce ne sono stati: ad esempio `email undeliverable`, `trp identity endpoint unreachable` o `trp transfer inquiry delivery failed`. Non contiene mai la risposta della controparte stessa, che rimane nella `timeline` del trasferimento. Quando GTR risponde con un errore, vengono inclusi il codice di stato e il messaggio restituiti. I corpi della risposta non vengono mai inclusi. example: email undeliverable next_attempt_at: type: string format: date-time nullable: true description: >- Quando verrà eseguito il prossimo tentativo mentre il messaggio è in stato `QUEUED` o `RETRYING`. delivered_at: type: string format: date-time nullable: true description: Quando l'altra parte ha preso in carico il messaggio. TravelRuleDiscoveryStep: type: object description: >- Un passaggio del rilevamento della controparte eseguito da Didit per un trasferimento in uscita, nell'ordine in cui è stato eseguito. Il primo passaggio che identifica un VASP con un percorso conclude la catena. properties: step: type: string enum: - internal_address_book - wallet_attribution - network_lookup - customer_hint - end_user description: >- `internal_address_book`: un altro cliente Didit che ha dimostrato il controllo del wallet di destinazione. `wallet_attribution`: l'attribuzione di analisi blockchain del wallet. `network_lookup`: una rete in grado di indicare quale VASP detiene l'indirizzo. `customer_hint`: il nome del VASP, LEI o la giurisdizione che hai inviato in `beneficiary_data`. `end_user`: la controparte scelta dall'utente finale (o da te), oppure la richiesta di sceglierne una. outcome: type: string enum: - match - miss - skipped description: >- `match`: il passaggio ha indicato una controparte. `miss`: è stato eseguito e non ne ha trovata nessuna. `skipped`: non è stato possibile eseguirlo e `reason` ne indica il motivo. reason: type: string description: >- Motivo leggibile dalla macchina, `""` in caso di corrispondenza: `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` o `picked_member_without_proven_wallet`. vasp: type: string format: uuid nullable: true description: >- Il VASP della directory indicato dal passaggio, qualora ne abbia indicato uno. rail: type: string nullable: true description: >- Il canale (rail) che raggiunge tale controparte, quando il passaggio ne ha trovato uno. at: type: string format: date-time TravelRuleNextAction: type: object description: >- Un elemento che consente di far progredire un trasferimento bloccato nello stato `COUNTERPARTY_VASP_NOT_FOUND` o `COUNTERPARTY_VASP_NOT_REACHABLE`. Consulta [Perché un trasferimento è bloccato](/it/transaction-monitoring/travel-rule#perché-un-trasferimento-è-bloccato). properties: action: type: string enum: - select_counterparty_vasp - declare_self_hosted - add_vasp_hint - update_compliance_email - resend description: >- `select_counterparty_vasp`: l'utente finale seleziona il VASP di destinazione nel widget di titolarità del wallet, oppure invii una richiesta PATCH con `action=beneficiary_vasp`. `declare_self_hosted`: l'utente finale dichiara che il wallet è in autocustodia nel widget. `add_vasp_hint`: indica a Didit chi è la controparte specificando nome del VASP, LEI o Travel Address (ad esempio un `travel_address` nella voce della rubrica del wallet di destinazione), quindi invia nuovamente. `update_compliance_email` e `resend` sono valori di `action` per `PATCH /v3/transactions/{transaction_id}/travel-rule/`: fornisci nuovamente l'email di compliance della controparte ed esegui nuovamente l'instradamento. url: type: string format: uri description: >- Il link al widget di verifica della proprietà del wallet, su `select_counterparty_vasp` e `declare_self_hosted` mentre il trasferimento ha una sessione widget aperta. required: - action TravelRuleChainDetails: type: object description: >- In che modo la blockchain del trasferimento identifica i suoi due wallet, quando si tratta di più di un indirizzo che ne paga un altro. Vuoto (`{}`) per un trasferimento su blockchain basata su account (EVM, Solana, Tron), dove i due indirizzi corrispondono ai wallet. La corrispondenza, l'instradamento e la rubrica leggono innanzitutto i wallet da qui. properties: chain: type: string description: >- Rete blockchain canonica, ad es. `BTC`, `XRP` o `LIGHTNING` per un trasferimento Lightning. shape: type: string enum: - utxo - memo - lightning originator: $ref: '#/components/schemas/TravelRuleChainSide' beneficiary: $ref: '#/components/schemas/TravelRuleChainSide' utxo: type: object description: >- Su un trasferimento UTXO: gli input e gli output come memorizzati (importi come stringhe decimali) e quali output Didit ha interpretato come cosa. 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: Output che rimborsano un indirizzo di input. beneficiary_output_index: type: integer nullable: true description: >- L'output che paga il beneficiario; null quando non è stato possibile distinguerne alcuno. lightning: type: object description: >- Su un trasferimento Lightning: ciò che indica la richiesta di pagamento. Sempre `kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`, `bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id` o `unknown`); una fattura BOLT11 aggiunge `network`, `payee_node_id`, `payment_hash`, `amount_msat`, `created_at` e `expires_at`; una stringa BOLT12 `blinded_paths` e `payee_node_id`; un LNURL o un Lightning Address il suo `domain`. Nulla viene risolto sulla rete: la richiesta viene solo decodificata. 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: >- Incongruenze UTXO da esaminare: l'ordinante dichiarato non è un input, il beneficiario dichiarato non è un output, non è stato possibile distinguere un singolo output del beneficiario, oppure l'output del beneficiario corrisponde a un importo diverso rispetto a quello indicato nella transazione. not_applicable_reason: type: string enum: - LIGHTNING_NO_PAYEE_IDENTIFIER - LIGHTNING_BOLT12_BLINDED_PAYEE - LIGHTNING_LNURL_NAMES_NO_PAYEE description: >- Su un trasferimento Lightning in uscita la cui richiesta di pagamento non indica alcun beneficiario: perché il trasferimento è `NOT_APPLICABLE`. `LIGHTNING_NO_PAYEE_IDENTIFIER` (la richiesta non indica alcun nodo beneficiario o non è stato possibile decodificarla), `LIGHTNING_BOLT12_BLINDED_PAYEE` (l'offerta nasconde il proprio beneficiario dietro percorsi ciechi), `LIGHTNING_LNURL_NAMES_NO_PAYEE` (un LNURL indica un servizio, non un beneficiario). Lo stesso codice apre l'ultima voce `timeline` del trasferimento. TravelRuleChainSide: type: object description: >- Il wallet di una delle parti, così come Didit lo ha risolto a partire dai dati della blockchain. properties: address: type: string description: >- Il wallet. Su una rete con memo l'indirizzo classico (un X-address XRP viene suddiviso nel relativo indirizzo classico e tag); su Lightning l'ID del nodo del beneficiario o il Lightning Address. memo: type: string description: Il destination tag o memo che fa parte del wallet; `""` se assente. source: type: string enum: - declared - x_address - largest_input - only_non_change_output - amount_match - invoice_payee - updated description: >- Origine del wallet: `declared` (la tua richiesta), `x_address` (estratto da un X-address XRP), `largest_input` (l'indirizzo di input UTXO che ha contribuito maggiormente), `only_non_change_output` (l'unico output UTXO non di resto), `amount_match` (l'unico output UTXO che paga l'importo del trasferimento), `invoice_payee` (il beneficiario indicato in una richiesta di pagamento Lightning), `updated` (impostato successivamente con `action: update_originator_wallet`). TravelRuleUtxoEntry: type: object description: >- Un input o output di una transazione UTXO, così come registrato dalla blockchain. required: - address properties: address: type: string maxLength: 128 amount: type: string nullable: true description: >- Stringa decimale nell'unità propria della moneta (BTC, non satoshi). Facoltativo. example: '0.0125' txid: type: string maxLength: 128 description: Opzionale. La transazione utilizzata da un input. vout: type: integer nullable: true minimum: 0 description: Opzionale. L'indice di output speso da un input. securitySchemes: ApiKeyAuth: type: apiKey in: header name: x-api-key description: >- La chiave API della tua applicazione, da Developers -> API keys nella Business Console. La chiave primaria ha accesso completo. Una chiave con nome può avere un ambito definito: nessuno, lettura o scrittura per risorsa, limitata ad alcuni workflow o a sessioni approvate, a un elenco di indirizzi IP e a una data di scadenza. 401 indica che la chiave è errata, revocata o scaduta; 403 indica che non è stata inviata alcuna chiave, che la chiave non ha accesso a questa risorsa o azione, oppure che la richiesta proviene da un indirizzo non incluso nel suo elenco IP; 404 su una route di sessione indica che la sessione non rientra nei workflow o negli stati previsti dalla chiave. Una chiave senza accesso ai media riceve gli URL di immagini, video e PDF come null, e una chiave senza permessi di scrittura sulle sessioni riceve link e token di sessione come null. Consulta https://docs.didit.me/console/api-keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.