> ## 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.
# Travel Rule Transfer-Aktionen API: Abschließen, Update
> Mit Didit Travel-Rule-Transfers per On-Chain-Hash abschließen, abbrechen, erneut senden oder die tatsächliche Auftraggeber-Wallet aktualisieren.
API-Prompt für Transferaktionen nach der Travel Rule
Prompt in die Zwischenablage kopieren
\
\`Act on an existing Travel Rule transfer: report the on-chain hash to finish it, cancel it, re-run counterparty routing, replace a refused compliance email, or record the wallet the funds left from.
Endpoint:
PATCH https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/
Authentication:
Use the x-api-key header with my Didit API key. {transaction_id} is the Didit transaction uuid.
Four mutually exclusive bodies:
1\. Finish (close out after broadcasting on-chain):
\{"payment_txn_id": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060"}
\- Requires an OUTBOUND transfer in COMPLETED status - otherwise 409.
\- Moves the transfer (and its INTERNAL-rail counterpart, if any) to FINISHED and stores the hash on the transaction.
\- Over GTR, VerifyVASP or Sygna Bridge, the network learns the hash after the response, with retries (see delivery below).
\- On the TRP rail, Didit also posts the hash to the counterparty's confirmation callback.
2\. Cancel:
\{"action": "cancel"}
\- Allowed from any non-terminal status; moves the transfer (and its INTERNAL-rail counterpart, if any) to CANCELLED.
\- From a terminal status (FINISHED, CANCELLED, EXPIRED) it returns 409.
\- On an outbound TRP transfer, Didit also sends a cancellation to the counterparty.
\- Over GTR, VerifyVASP or Sygna Bridge, the network is told after the response, with retries.
3\. Resend (re-run the routing ladder):
\{"action": "resend"}
\- Allowed only on an OUTBOUND transfer in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, or NOT_ENOUGH_COUNTERPARTY_DATA - otherwise 409.
\- Resets the deadline and re-runs routing; a transfer whose destination wallet was declared unhosted moves to UNCONFIRMED_OWNERSHIP.
\- First give Didit a route, for example by registering the destination wallet in your address book (same chain as the transfer, or a blank chain) with the counterparty's travel_address (TRP carries BTC, ETH, and USDC on a named network), or by adding a compliance contact for the counterparty's directory entry with POST /v3/travel-rule/counterparty-contacts/, then resend.
\- Resend reuses the transfer's beneficiary_data, which you cannot change after creation except for the compliance email (body 4), so submit a new transaction to send different beneficiary data.
\- A previously recorded blockchain-analytics attribution is reused - no new lookup, no new charge.
\- Discovery runs again from the first step (internal address book, wallet attribution, network lookup, your VASP hint, then the end user); the transfer's "discovery" list shows what each step found.
\- Queued, not run inside the request: the response shows the transfer back in AWAITING_COUNTERPARTY with a "resend queued" timeline entry, and the outcome arrives as a travel_rule.status.updated webhook. A resend sent while an earlier attempt is still running is sent once that attempt settles.
\- If routing still resolves nothing, the transfer lands back in COUNTERPARTY_VASP_NOT_FOUND.
4\. Update the compliance email (the fix for reason email_undeliverable):
\{"action": "update_compliance_email", "compliance_email": "desk@bene-casp.example"}
\- Allowed only on an OUTBOUND transfer in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, or NOT_ENOUGH_COUNTERPARTY_DATA - otherwise 409.
\- A missing or malformed compliance_email returns 400.
\- Stores the address as this transfer's beneficiary_data.counterparty_vasp_email; it belongs to this transfer only and joins no directory entry or contact list.
\- The status does not change and the timeline gains "compliance email updated". The transfer keeps reason email_undeliverable until you send {"action": "resend"}, which sends the request to the new address.
4\. Update the originator wallet (the wallet the funds actually left from):
\{"action": "update_originator_wallet", "wallet_address": "bc1q...", "memo": ""}
\- Outbound transfers only (an inbound transfer -> 409), and never a CANCELLED or EXPIRED one (-> 409).
\- Use it when a withdrawal is broadcast from another address than the one declared, typically a UTXO withdrawal spending whichever addresses held the coins. When the transfer's UTXO inputs are known, wallet_address must be one of them (-> 400 otherwise).
\- Changes the record only: nothing is sent to the counterparty again and the status stays. chain_details.originator becomes the new wallet with source "updated", the timeline records the previous and the new wallet, and the INTERNAL-rail counterpart is updated the same way.
5\. Name the counterparty (when discovery could not):
\{"action": "beneficiary_vasp", "beneficiary_vasp": ""}
\- The id comes from GET /v3/travel-rule/vasps/.
\- Allowed only for an outbound transfer in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, or NOT_ENOUGH_COUNTERPARTY_DATA - otherwise 409.
\- Routes the transfer to that VASP and sends it again; automatic discovery never overrides your choice.
\- 400 if beneficiary_vasp is missing or not a valid id, 404 if no directory entry has that id.
What to read from the response:
\- The full transfer object: status, rail, direction, ownership_confirmed, deadline_at, timeline, counterparty_vasp, delivery, discovery, reason, next_actions.
\- delivery: the latest message the transfer owes the other side - kind (SEND, ANSWER, TXID, CANCEL, POLL), status (QUEUED, SENDING, RETRYING, DELIVERED, FAILED), rail, attempts, last_error, next_attempt_at, delivered_at. Failures a network may recover from are retried after 30 s, 2, 10, 30 and 60 minutes; when a first message fails for good the transfer moves to COUNTERPARTY_VASP_NOT_REACHABLE. null when the transfer never owed a message.
\- reason and next_actions say why a COUNTERPARTY_VASP_NOT_FOUND or COUNTERPARTY_VASP_NOT_REACHABLE transfer is stuck and what moves it on: email_undeliverable offers update_compliance_email then resend, delivery_failed offers resend, and a discovery reason offers select_counterparty_vasp, declare_self_hosted, add_vasp_hint and resend. Both are empty for any other status, so they clear once a resend moves the transfer on.
Order of operations for outbound transfers:
submit transaction -> wait for travel_rule.status == "COMPLETED" -> broadcast on-chain -> PATCH with payment_txn_id -> FINISHED.
Never broadcast before COMPLETED.
A transfer sent over TRUST cannot reach COMPLETED, because TRUST sends back nothing Didit can read; it stays AWAITING_COUNTERPARTY until it expires. Over GTR, VerifyVASP and Sygna Bridge, Didit reads the counterparty's answer from the network.
If the message cannot be delivered, the transfer moves to COUNTERPARTY_VASP_NOT_REACHABLE instead.
Failure modes:
\- 400 - the body has none of payment_txn_id or a supported action, update_compliance_email has a missing or malformed compliance_email, or a wallet_address or memo the transfer's chain cannot carry.
\- 409 - action not allowed from the transfer's current status or direction (see the per-action rules above).
\- 400 - action=beneficiary_vasp without a valid beneficiary_vasp.
\- 404 - unknown transaction, no Travel Rule transfer attached, or (action=beneficiary_vasp) no directory entry has that id.
Full guide: /transaction-monitoring/travel-rule#sending-a-transfer and /transaction-monitoring/travel-rule#why-a-transfer-is-stuck.`
\
Einfügen in
## OpenAPI
````yaml de/openapi-25.json PATCH /v3/transactions/{transaction_id}/travel-rule/
openapi: 3.0.0
info:
version: 3.0.0
title: Didit Verification API
description: API für Ausweisverifizierung. Authentifizierung über den x-api-key-Header.
servers:
- url: https://verification.didit.me
security: []
tags: []
paths:
/v3/transactions/{transaction_id}/travel-rule/:
patch:
tags:
- Travel Rule
summary: >-
Auftraggeber-Wallet eines Travel-Rule-Transfers abschließen, abbrechen,
erneut senden oder aktualisieren
description: >-
Geben Sie `payment_txn_id` an, um den On-Chain-Hash zu melden und einen
ausgehenden COMPLETED-Transfer auf FINISHED zu setzen (sein Gegenstück
auf der INTERNAL-Schiene wird ebenfalls auf FINISHED gesetzt),
`{"action": "cancel"}`, um einen nicht-terminalen Transfer abzubrechen,
oder `{"action": "resend"}` zu verwenden, um einen ausgehenden Transfer,
der in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE oder
NOT_ENOUGH_COUNTERPARTY_DATA feststeckt, erneut weiterzuleiten
(verbessern Sie zuerst die Daten der Gegenpartei, z. B. durch Hinzufügen
einer travel_address zum Eintrag der Ziel-Wallet). resend gilt nur für
ausgehende Transfers. `{"action": "update_compliance_email",
"compliance_email": "desk@example.com"}` ersetzt die Compliance-E-Mail
eines ausgehenden Transfers in einem dieser drei Status, die Behebung
des Problems `reason: email_undeliverable`: Der Status ändert sich
nicht, und das nächste `resend` sendet die Anfrage an diese Adresse. Ein
erneutes Senden wird in eine Warteschlange eingereiht und nicht
innerhalb der Anfrage ausgeführt: Die Antwort zeigt den Transfer wieder
in AWAITING_COUNTERPARTY mit einem Timeline-Eintrag `resend queued` und
einer eingereihten `delivery`, und wohin der Transfer geleitet wurde,
wird als Webhook-Ereignis `travel_rule.status.updated` übermittelt. Wenn
der Transfer über GTR, VerifyVASP oder Sygna Bridge lief, erfährt das
Netzwerk den On-Chain-Hash oder den Abbruch nach der Antwort mit
Wiederholungsversuchen; `delivery` zeigt den Status dieser Nachricht an.
`{"action": "update_originator_wallet", "wallet_address": "..."}`
erfasst die Wallet, von der das Guthaben bei einem ausgehenden Transfer
tatsächlich abging, beispielsweise die Adresse, von der eine
UTXO-Auszahlung gesendet wurde, anstelle der von Ihnen deklarierten
Haupt-Wallet. Dadurch wird nur der Datensatz geändert: Es wird nichts
erneut an die Gegenpartei gesendet und der Status bleibt erhalten. Der
Auftraggeber wird zu `chain_details.originator` mit `source: updated`,
die Änderung wird mit der vorherigen und der neuen Wallet zur `timeline`
hinzugefügt, und das Gegenstück des Transfers auf der INTERNAL-Schiene
wird auf die gleiche Weise aktualisiert. `{"action": "beneficiary_vasp",
"beneficiary_vasp": ""}` benennt die Gegenpartei
selbst, wenn die Ermittlung fehlgeschlagen ist, bei einem ausgehenden
Transfer in COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE
oder NOT_ENOUGH_COUNTERPARTY_DATA: Der Transfer wird an diesen VASP
weitergeleitet und erneut gesendet.
operationId: patchTravelRuleTransfer
parameters:
- name: transaction_id
in: path
required: true
description: Stabile Transaktions-UUID von Didit, zu der der Transfer gehört.
schema:
type: string
format: uuid
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/TravelRuleTransferPatchRequest'
examples:
Finish:
value:
payment_txn_id: 0xchainhash
Cancel:
value:
action: cancel
Resend:
value:
action: resend
Update compliance email:
value:
action: update_compliance_email
compliance_email: desk@example.com
Update originator wallet:
value:
action: update_originator_wallet
wallet_address: bc1qOriginatorInputAddress01
Name the counterparty:
value:
action: beneficiary_vasp
beneficiary_vasp: 9f1c2b34-5d6e-4f70-8a91-b2c3d4e5f607
responses:
'200':
description: >-
Der aktualisierte Transfer. Nach `update_compliance_email` bleibt
sein Status unverändert und er behält `reason: email_undeliverable`
bis zum nächsten `resend` bei.
content:
application/json:
schema:
$ref: '#/components/schemas/TravelRuleTransferDetail'
'400':
description: >-
Weder payment_txn_id noch eine unterstützte Aktion wurde angegeben,
`compliance_email` fehlt oder ist bei `update_compliance_email`
keine E-Mail-Adresse, oder, bei `update_originator_wallet`, keine
wallet_address, eine Wallet oder ein Memo, die bzw. das die
Blockchain des Transfers nicht übertragen kann, oder eine Wallet,
die nicht zu den UTXO-Inputs des Transfers gehört, oder
`beneficiary_vasp` fehlt oder ist keine gültige Verzeichnis-VASP-ID.
content:
application/json:
examples:
No action:
value:
detail:
- >-
Provide payment_txn_id, action=cancel, action=resend,
action=beneficiary_vasp, action=update_originator_wallet
or action=update_compliance_email.
Invalid compliance email:
value:
compliance_email:
- Enter a valid email address.
'404':
description: >-
Unbekannte Transaktion, die Transaktion weist keinen
Travel-Rule-Transfer auf oder (bei der Aktion `beneficiary_vasp`) es
ist kein Verzeichniseintrag mit dieser ID vorhanden.
'409':
description: >-
Der Transfer befindet sich nicht in einem Status, der diesen Vorgang
erlaubt (z. B. nicht COMPLETED/ausgehend für finish, bereits
endgültig für cancel oder kein ausgehender Transfer in einem erneut
sendbaren Status für resend). `update_compliance_email` antwortet
mit `409` bei einem eingehenden Transfer sowie bei einem ausgehenden
Transfer außerhalb von COUNTERPARTY_VASP_NOT_FOUND,
COUNTERPARTY_VASP_NOT_REACHABLE und NOT_ENOUGH_COUNTERPARTY_DATA.
`update_originator_wallet` antwortet mit `409` bei einem
eingehenden, abgebrochenen oder abgelaufenen Transfer.
`beneficiary_vasp` antwortet mit `409`, es sei denn, der Transfer
ist ausgehend und befindet sich in COUNTERPARTY_VASP_NOT_FOUND,
COUNTERPARTY_VASP_NOT_REACHABLE oder NOT_ENOUGH_COUNTERPARTY_DATA.
content:
application/json:
examples:
Cancel from a terminal status:
value:
detail: Transfer is already in a terminal state.
Resend not allowed:
value:
detail: Transfer cannot be resent from its current state.
Finish not allowed:
value:
detail: >-
Transfer must be an outbound transfer in COMPLETED status
to finish.
Compliance email cannot change:
value:
detail: >-
The compliance email of this transfer cannot change from
its current state.
security:
- ApiKeyAuth: []
x-codeSamples:
- lang: curl
label: curl
source: >-
curl -X PATCH
https://verification.didit.me/v3/transactions/{transaction_id}/travel-rule/
\
-H 'x-api-key: YOUR_API_KEY' -H 'Content-Type: application/json' \
-d '{"payment_txn_id": "0xchainhash"}'
- lang: python
label: Python
source: |-
from didit import Didit
# Reads DIDIT_API_KEY.
client = Didit()
result = client.transactions.travel_rule.update_transfer(
"11111111-2222-3333-4444-555555555555",
payment_txn_id="0xchainhash",
)
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.updateTransfer("11111111-2222-3333-4444-555555555555",
{
payment_txn_id: "0xchainhash",
});
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.UpdateTransfer(ctx, \"11111111-2222-3333-4444-555555555555\", didit.TravelRuleTransferPatchRequest{\n\tPaymentTxnID: didit.String(\"0xchainhash\"),\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.TravelRuleTransferPatchRequest;
// Reads DIDIT_API_KEY.
Didit client = new Didit();
var result =
client.transactions().travelRule().updateTransfer("11111111-2222-3333-4444-555555555555",
TravelRuleTransferPatchRequest.builder()
.paymentTxnId("0xchainhash")
.build());
System.out.println(result);
- lang: php
label: PHP
source: >-
transactions->travelRule->updateTransfer('11111111-2222-3333-4444-555555555555',
[
'payment_txn_id' => '0xchainhash',
]);
print_r($result->toArray());
- lang: ruby
label: Ruby
source: |-
require "didit"
# Reads DIDIT_API_KEY.
didit = Didit::Client.new
result = didit.transactions.travel_rule.update_transfer(
"11111111-2222-3333-4444-555555555555",
payment_txn_id: "0xchainhash"
)
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.UpdateTransferAsync("11111111-2222-3333-4444-555555555555",
new TravelRuleTransferPatchRequest
{
PaymentTxnId = "0xchainhash",
});
Console.WriteLine(JsonSerializer.Serialize(result));
components:
schemas:
TravelRuleTransferPatchRequest:
type: object
description: >-
Geben Sie genau eines der folgenden Elemente an: payment_txn_id
(finish), action=cancel, action=resend, action=update_compliance_email
mit compliance_email, action=update_originator_wallet mit wallet_address
oder action=beneficiary_vasp mit beneficiary_vasp.
properties:
payment_txn_id:
type: string
description: >-
Der On-Chain-Transaktions-Hash. Erfordert, dass der Transfer ein
ausgehender Transfer im Status COMPLETED ist.
action:
type: string
enum:
- cancel
- resend
- update_compliance_email
- update_originator_wallet
- beneficiary_vasp
description: >-
"cancel" bricht einen nicht-terminalen Transfer ab. "resend" führt
das Routing für einen ausgehenden Transfer erneut aus, der im Status
COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE oder
NOT_ENOUGH_COUNTERPARTY_DATA feststeckt. "update_compliance_email"
ersetzt die Compliance-E-Mail-Adresse, an die die Anfrage gesendet
wird, bei einem ausgehenden Transfer in einem dieser drei Status;
senden Sie danach "resend". "update_originator_wallet" erfasst die
Wallet, von der die Mittel tatsächlich abgebucht wurden
(`wallet_address`, `memo`). "beneficiary_vasp" gibt den
Gegenpartei-VASP selbst an (erfordert `beneficiary_vasp`) für einen
ausgehenden Transfer in einem dieser Status: Er wird an diesen VASP
geroutet und erneut gesendet.
compliance_email:
type: string
format: email
maxLength: 254
description: >-
Erforderlich bei `action: update_compliance_email`. Wird als
`beneficiary_data.counterparty_vasp_email` dieses Transfers
gespeichert: Es gehört ausschließlich zu diesem Transfer und wird
weder einem Verzeichniseintrag noch einer Kontaktliste hinzugefügt.
wallet_address:
type: string
maxLength: 128
description: >-
Mit `action: update_originator_wallet`: Die Wallet, von der die
Mittel ausgegangen sind. Wenn die UTXO-Inputs des Transfers bekannt
sind, muss sie eine davon sein.
memo:
type: string
maxLength: 256
description: >-
Mit `action: update_originator_wallet`: Das Memo oder Tag der Wallet
in einem Memo-Netzwerk. Optional.
beneficiary_vasp:
type: string
format: uuid
description: >-
Erforderlich bei action=beneficiary_vasp: Die `id` eines
Verzeichnis-VASPs aus `GET /v3/travel-rule/vasps/`. Ihre Auswahl hat
Vorrang vor jedem automatischen Erkennungsschritt, der sie niemals
überschreibt.
TravelRuleTransferDetail:
type: object
description: >-
Vollständiges Transfer-Objekt, das von den Endpoints zur
Eigentümerbestätigung und zum Abschließen/Abbrechen zurückgegeben wird.
Solange das Wallet-Eigentum eines eingehenden Transfers unbestätigt ist,
werden `originator_data` und `beneficiary_data` der Gegenpartei maskiert
zurückgegeben (der erste Buchstabe jedes Wortes bleibt erhalten; Wallet,
Chain und VASP-Routing bleiben lesbar) und `data_masked` ist 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: >-
Die Schiene (Rail), über die der Transfer geroutet wurde, oder null,
wenn keine Schiene ausgewählt wurde (z. B. unterhalb des
Schwellenwerts, eine selbstverwahrte Gegenpartei-Wallet, eine
Registrierung nach Einzahlung oder keine erreichbare Gegenpartei).
INTERNAL bedeutet, dass beide Seiten Didit-Anwendungen sind; EMAIL
bedeutet, dass die Gegenpartei über einen per E-Mail gesendeten
Abhol-Link erreicht wurde. TEST_VASP bedeutet, dass der Didit Test
VASP den Sandbox-Transfer beantwortet hat. Über GTR, VERIFYVASP und
SYGNA liest Didit die Antwort der Gegenpartei aus der Antwort des
Netzwerks oder durch Abrufen alle 5 Minuten. TRUST sendet nur,
sodass ein TRUST-Transfer auf AWAITING_COUNTERPARTY bleibt, bis er
abläuft. Eine Netzwerk-Schiene wird nur verwendet, wenn Sie Ihre
eigene Mitgliedschaft für dieses Netzwerk verknüpft haben. Sie wird
nach der Rückgabe der Antwort auf die Transaktionserstellung
ausgewählt, weshalb sie in dieser Antwort null ist.
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: >-
Der Namensabgleich, über den dieser Eintrag entschieden hat,
neben `detail`. Fehlt bei Einträgen, bei denen kein Name
verglichen wurde.
reason:
type: string
description: >-
Nur beim Eintrag eines Übergangs vorhanden, der durch eine
fehlgeschlagene Zustellung verursacht wurde:
`email_undeliverable` oder `delivery_failed`, der Wert, den
`reason` des Transfers meldet.
counterparty_vasp:
type: object
nullable: true
properties:
name:
type: string
lei:
type: string
dd_score:
type: integer
description: >-
Due-Diligence-Score von 0 bis 100, wobei ein höherer Wert besser
ist. Gleiche Skala wie im VASP-Verzeichnis.
dd_score_breakdown:
type: object
description: >-
Beiträge pro Komponente zu dd_score, ein Objekt pro Komponente
wie im VASP-Verzeichnis (jurisdiction, verification, protocol,
lei, history, essentials, responsiveness), jeweils {points, max,
reason, detail}. {}, bis die Gegenpartei bewertet wurde.
additionalProperties:
type: object
properties:
points:
type: number
description: Für diese Komponente vergebene Punkte.
max:
type: integer
description: Maximale Punktzahl, die diese Komponente vergeben kann.
reason:
type: string
description: Maschinenlesbarer Code der Entscheidung der Komponente.
detail:
type: string
description: Für Menschen lesbare Begründung für die vergebenen Punkte.
dd_assessed_at:
type: string
format: date-time
nullable: true
description: >-
Wann die Due-Diligence-Bewertung zuletzt durchgeführt wurde.
Null, bis die Gegenpartei bewertet wurde.
originator_data:
type: object
description: >-
Auftraggeber-Partei. Bei einer eingehenden Überweisung werden die
Werte der Gegenpartei maskiert, bis die Eigentümerstruktur bestätigt
ist.
beneficiary_data:
type: object
description: >-
Begünstigter. Bei eingehenden Übertragungen werden die Werte der
Gegenpartei maskiert, bis die Eigentümerschaft bestätigt ist.
name_match:
allOf:
- $ref: '#/components/schemas/TravelRuleNameMatch'
nullable: true
description: >-
Der Namensabgleich, der über die Überweisung entschieden hat, oder
null, bis einer ausgeführt wurde. Solange die Parteien maskiert sind
und auf der Kopie des anderen Kunden eines INTERNAL-Austauschs,
werden `transfer_name`, `compared_name`, `matched_names` und
`mismatched_names` ausgeblendet. `score` und `matched` können
voneinander abweichen: `matched` richtet sich nach der Strenge,
`score` ist die Ähnlichkeit der beiden vollständigen Namen.
data_match:
$ref: '#/components/schemas/TravelRuleDataMatch'
mismatched_fields:
type: array
items:
type: string
description: >-
Kürzel für `data_match.mismatched_fields`. Leer, wenn keine
Unterschiede vorliegen.
data_unmasked:
$ref: '#/components/schemas/TravelRuleDataUnmasked'
data_masked:
type: boolean
description: >-
Wahr, solange die personenbezogenen Daten der Gegenpartei in dieser
Antwort maskiert sind.
created_at:
type: string
format: date-time
delivery:
nullable: true
allOf:
- $ref: '#/components/schemas/TravelRuleDelivery'
description: >-
Status der neuesten Nachricht, die dieser Transfer der anderen Seite
schuldet. Null, wenn der Transfer nie eine geschuldet hat (zum
Beispiel bei einem Wert unter `threshold_amount`, bei einer
deklarierten selbstverwahrten Wallet oder bei einer
Sunrise-Registrierung).
discovery:
type: array
description: >-
Wie Didit nach der Gegenpartei gesucht hat, ein Eintrag pro
ausgeführtem Schritt. Leer, wenn keine Ermittlung stattgefunden hat,
beispielsweise bei einem eingehenden Transfer.
items:
$ref: '#/components/schemas/TravelRuleDiscoveryStep'
reason:
type: string
description: >-
Warum ein Transfer mit `COUNTERPARTY_VASP_NOT_FOUND` oder
`COUNTERPARTY_VASP_NOT_REACHABLE` feststeckt; `""` für jeden anderen
Status. Eine fehlgeschlagene Zustellung bestimmt dies zuerst,
ausschließlich bei `COUNTERPARTY_VASP_NOT_REACHABLE`:
`email_undeliverable` (der E-Mail-Provider hat die Compliance-E-Mail
abgelehnt und es bleibt keine Adresse mehr zum Ausprobieren: beim
Senden, bei einer Erinnerung oder als später gemeldeter permanenter
Bounce) oder `delivery_failed` (die zustellende Schiene ist
endgültig fehlgeschlagen: eine Netzwerkschiene hat die Nachricht
abgelehnt oder keine Wiederholungsversuche mehr übrig, ein
`TRP`-Identitäts-Host hat nicht geantwortet oder der `TRP`-Host der
Gegenpartei hat die Anfrage nicht akzeptiert). Andernfalls bestimmt
es der `discovery`-Trace: `awaiting_end_user` (kein Schritt hat eine
Gegenpartei benannt, die Didit erreichen kann),
`directory_match_no_route` (ein Schritt hat einen Verzeichnis-VASP
benannt, der keine Route hat), `picked_member_without_proven_wallet`
(der Endbenutzer hat einen Didit-Kunden ausgewählt, der die
Kontrolle über die Wallet nicht nachgewiesen hat) oder
`no_directory_match`, wenn der Trace keinen anderen Grund liefert.
Ein erneutes Senden bringt den Transfer voran, sodass der Grund
zurückgesetzt wird. Siehe [Warum ein Transfer
feststeckt](/de/transaction-monitoring/travel-rule#warum-ein-transfer-blockiert-ist).
next_actions:
type: array
description: >-
Was den Transfer voranbringt; `[]` für jeden Status außer
`COUNTERPARTY_VASP_NOT_FOUND` oder
`COUNTERPARTY_VASP_NOT_REACHABLE`. `email_undeliverable` bietet
`update_compliance_email`, dann `resend`. `delivery_failed` bietet
`resend`. Ein Discovery-Grund bietet `select_counterparty_vasp`,
`declare_self_hosted`, `add_vasp_hint` und `resend`.
items:
$ref: '#/components/schemas/TravelRuleNextAction'
chain_details:
$ref: '#/components/schemas/TravelRuleChainDetails'
TravelRuleNameMatch:
type: object
nullable: true
description: >-
Der Namensabgleich, der über die Überweisung entschieden hat, oder null,
bis einer ausgeführt wurde. Solange die Parteien maskiert sind und auf
der Kopie des anderen Kunden eines INTERNAL-Austauschs, werden
`transfer_name`, `compared_name`, `matched_names` und `mismatched_names`
ausgeblendet. `score` und `matched` können voneinander abweichen:
`matched` richtet sich nach der Strenge, `score` ist die Ähnlichkeit der
beiden vollständigen Namen.
properties:
score:
type: integer
minimum: 0
maximum: 100
description: >-
Ähnlichkeit der beiden vollständigen Namen, 0 bis 100. 0, wenn einer
der Namen leer ist.
matched:
type: boolean
description: >-
Gibt an, ob die Namen die Bedingung `strictness` erfüllen. Das
Ergebnis des Transfers folgt `data_match`, das jedes Feld
vergleicht, sodass ein Transfer COUNTERPARTY_MISMATCHED_DATA sein
kann, während dies wahr ist.
method:
type: string
enum:
- none
- exact_token
- token_subset
- token_containment
- sequence_ratio
description: >-
Wie über `matched` entschieden wurde: none (`NONE`), exact_token
(`STRICT`), token_subset (`DEFAULT`), token_containment (`CONTAINS`)
oder sequence_ratio (`FUZZY`).
strictness:
type: string
enum:
- NONE
- STRICT
- CONTAINS
- DEFAULT
- FUZZY
compared_with:
type: string
enum:
- wallet_holder
- counterparty_vasp
description: >-
wallet_holder: Der für die Wallet hinterlegte Inhaber.
counterparty_vasp: Der Name, den die Gegenpartei auf der
E-Mail-Antwortseite angegeben hat, oder die Antwort des
Didit-Test-VASP in der Sandbox.
transfer_name:
type: string
description: Der Name auf der Überweisung.
compared_name:
type: string
description: Der Name, mit dem verglichen wurde.
matched_names:
type: array
items:
type: string
description: Wörter aus `transfer_name`, die in `compared_name` gefunden wurden.
mismatched_names:
type: array
items:
type: string
description: >-
Wörter aus `transfer_name`, die in `compared_name` fehlen, gefolgt
von Wörtern aus `compared_name`, die in `transfer_name` fehlen.
TravelRuleDataMatch:
type: object
nullable: true
description: >-
Feldweiser Abgleich der Daten der an der Übertragung beteiligten Partei
mit den Informationen der Gegenseite über den Wallet-Inhaber. Nennt
Felder und Ergebnisse, niemals Werte, damit die Lesbarkeit erhalten
bleibt, während die Daten der Gegenpartei maskiert sind. Null, bis ein
Abgleich ausgeführt wurde.
properties:
matched:
type: boolean
description: True, wenn kein verglichenes Feld abweicht.
mismatched_fields:
type: array
items:
type: string
enum:
- name
- date_of_birth
- address
- account
description: Die Felder, die sich unterscheiden.
fields:
type: object
description: >-
Ein Eintrag pro verglichenem Feld für den Entitätstyp der Partei
(`name`, `date_of_birth`, `address`, `account`; ein Unternehmen hat
kein `date_of_birth`).
additionalProperties:
type: object
properties:
result:
type: string
enum:
- matched
- mismatched
- not_compared
description: >-
`not_compared`, wenn die Regel `NONE` ist oder eine der beiden
Seiten keinen Wert für das Feld aufweist.
strictness:
type: string
enum:
- NONE
- STRICT
- CONTAINS
- DEFAULT
- FUZZY
TravelRuleDataUnmasked:
type: object
nullable: true
description: >-
Audit-Eintrag des Zeitpunkts, zu dem die Daten der Gegenpartei
demaskiert wurden. Null, solange die Daten noch maskiert sind, sowie bei
ausgehenden Überweisungen.
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: >-
Was die Inhaberschaft bestätigt hat: ownership_confirmed (Ihre
Bestätigung über die Konsole oder die API), wallet_proof (ein
Wallet-Nachweis im Widget oder ein eingehender INTERNAL-Transfer,
festgelegt bei der Erstellung), address_book_match (eine
verifizierte Adressbuch-Wallet), own_verified_wallet (die eigene
verifizierte Wallet Ihres Benutzers), inquiry_approved (Ihre
Genehmigung einer eingehenden TRP-Anfrage oder einer GTR- oder
Sygna-Nachricht), known_payment_method (eine Wallet, mit der Ihr
Benutzer bereits bezahlt hat) oder travel_address (die pro Wallet
angegebene Travel Address).
actor:
type: string
description: >-
Wer die Bestätigung vorgenommen hat: die E-Mail-Adresse des
Konsolenbenutzers oder die Bezeichnung des API-Schlüssels. Leer bei
einer automatischen Entscheidung.
TravelRuleDelivery:
type: object
description: >-
Status der neuesten Nachricht, die der Transfer der anderen Seite
schuldet. Didit kontaktiert die Gegenpartei, nachdem die Anfrage
zurückgegeben wurde, die den Transfer erstellt oder geändert hat. Dieses
Objekt gibt daher an, ob diese Nachricht durchgegangen ist: in der
Warteschlange, wird gesendet, wartet auf Wiederholungsversuch nach einem
Fehler, zugestellt oder fehlgeschlagen. Bei einem Fehler, von dem sich
das Netzwerk noch erholen kann (keine rechtzeitige Antwort,
fehlgeschlagene Verbindung, HTTP `408`, `429` oder `5xx`), wird der
Versuch nach 30 Sekunden, 2 Minuten, 10 Minuten, 30 Minuten und 1 Stunde
wiederholt. Wenn eine erste Nachricht (`kind: SEND`) endgültig
fehlschlägt, weil das Netzwerk sie abgelehnt hat oder auch der sechste
Versuch fehlgeschlagen ist, wechselt der Transfer zu
`COUNTERPARTY_VASP_NOT_REACHABLE` mit `last_error` in seiner `timeline`;
jede andere Nachricht, die endgültig fehlschlägt, wird in der `timeline`
vermerkt. Der `status` des Transfers bleibt die maßgebliche Quelle für
den Austausch selbst.
required:
- kind
- status
- rail
- attempts
- last_error
- next_attempt_at
- delivered_at
properties:
kind:
type: string
enum:
- SEND
- ANSWER
- TXID
- CANCEL
- POLL
description: >-
Was die Nachricht übermittelt. `SEND`: die erste Nachricht des
Transfers an die Gegenpartei (ausgehend; das Übertragungsnetzwerk
wird beim Senden ausgewählt). `ANSWER`: Ihre Annahme oder Ablehnung
gegenüber dem anfragenden Netzwerk (eingehend). `TXID`: der
On-Chain-Transaktions-Hash, nachdem Sie den Transfer abgeschlossen
haben. `CANCEL`: die Stornierung, nachdem Sie ihn abgebrochen haben.
`POLL`: eine Statusabfrage an ein Netzwerk, das dies anbietet, die
alle 5 Minuten wiederholt wird, während der Transfer auf die
Gegenpartei wartet.
status:
type: string
enum:
- QUEUED
- SENDING
- RETRYING
- DELIVERED
- FAILED
description: >-
`QUEUED`: Wartet auf den Versand. `SENDING`: Ein Versuch läuft.
`RETRYING`: Ein Versuch ist fehlgeschlagen und der nächste erfolgt
um `next_attempt_at`. `DELIVERED`: Die Gegenseite hat die Nachricht
entgegengenommen. `FAILED`: Die Gegenseite hat sie abgelehnt oder
der letzte Versuch ist fehlgeschlagen.
rail:
type: string
enum:
- INTERNAL
- TRP
- GTR
- TRUST
- VERIFYVASP
- SYGNA
- EMAIL
- ''
description: >-
Die Schiene (Rail), die die Nachricht übermittelt. Leer, bis Didit
eine für eine erste Nachricht ausgewählt hat.
attempts:
type: integer
minimum: 0
description: >-
Bisher durchgeführte Versuche für diese Nachricht. Für eine
Nachricht, die keine Statusabfrage ist, werden maximal 6 Versuche
unternommen.
last_error:
type: string
description: >-
Die Art des Fehlers, der beim letzten Versuch aufgetreten ist, `""`,
wenn keiner aufgetreten ist: beispielsweise `email undeliverable`,
`trp identity endpoint unreachable` oder `trp transfer inquiry
delivery failed`. Sie enthält niemals die eigene Antwort der
Gegenpartei, die in der `timeline` des Transfers verbleibt.
Wenn GTR mit einem Fehler antwortet, sind dessen eigener Statuscode
und dessen Nachricht enthalten. Antwortinhalte sind niemals
enthalten.
example: email undeliverable
next_attempt_at:
type: string
format: date-time
nullable: true
description: >-
Wann der nächste Versuch ausgeführt wird, während die Nachricht
`QUEUED` oder `RETRYING` ist.
delivered_at:
type: string
format: date-time
nullable: true
description: Wann die Gegenseite die Nachricht entgegengenommen hat.
TravelRuleDiscoveryStep:
type: object
description: >-
Ein Schritt der Gegenpartei-Ermittlung, die Didit für einen ausgehenden
Transfer durchgeführt hat, in der Reihenfolge der Ausführung. Der erste
Schritt, der einen VASP mit einer Route benennt, beendet die Kette.
properties:
step:
type: string
enum:
- internal_address_book
- wallet_attribution
- network_lookup
- customer_hint
- end_user
description: >-
`internal_address_book`: ein anderer Didit-Kunde, der die Kontrolle
über die Ziel-Wallet nachgewiesen hat. `wallet_attribution`: die
Blockchain-Analyse-Zuordnung der Wallet. `network_lookup`: ein
Netzwerk, das angeben kann, welcher VASP die Adresse hält.
`customer_hint`: der VASP-Name, der LEI oder die Jurisdiktion, die
Sie in `beneficiary_data` übermittelt haben. `end_user`: die
Gegenpartei, die der Endbenutzer (oder Sie) ausgewählt hat, oder die
Aufforderung, eine auszuwählen.
outcome:
type: string
enum:
- match
- miss
- skipped
description: >-
`match`: Der Schritt hat eine Gegenpartei benannt. `miss`: Er wurde
ausgeführt und hat keine gefunden. `skipped`: Er konnte nicht
ausgeführt werden, und `reason` gibt den Grund an.
reason:
type: string
description: >-
Maschinenlesbarer Grund, `""` bei einer Übereinstimmung:
`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` oder `picked_member_without_proven_wallet`.
vasp:
type: string
format: uuid
nullable: true
description: >-
Der Verzeichnis-VASP, den der Schritt benannt hat, sofern einer
benannt wurde.
rail:
type: string
nullable: true
description: >-
Die Schiene (Rail), die diese Gegenpartei erreicht, sofern der
Schritt eine gefunden hat.
at:
type: string
format: date-time
TravelRuleNextAction:
type: object
description: >-
Eine Maßnahme, die einen Transfer mit dem Status
`COUNTERPARTY_VASP_NOT_FOUND` oder `COUNTERPARTY_VASP_NOT_REACHABLE`
voranbringt. Siehe [Warum ein Transfer
festhängt](/de/transaction-monitoring/travel-rule#warum-ein-transfer-blockiert-ist).
properties:
action:
type: string
enum:
- select_counterparty_vasp
- declare_self_hosted
- add_vasp_hint
- update_compliance_email
- resend
description: >-
`select_counterparty_vasp`: Der Endbenutzer wählt die Ziel-VASP im
Widget zum Wallet-Eigentumsnachweis aus, oder Sie senden einen PATCH
mit `action=beneficiary_vasp`. `declare_self_hosted`: Der
Endbenutzer deklariert die Wallet im Widget als selbstverwahrt.
`add_vasp_hint`: Teilen Sie Didit über einen VASP-Namen, LEI oder
eine Travel Address (beispielsweise eine `travel_address` im
Adressbucheintrag der Ziel-Wallet) mit, wer die Gegenpartei ist, und
senden Sie die Anfrage erneut. `update_compliance_email` und
`resend` sind `action`-Werte von `PATCH
/v3/transactions/{transaction_id}/travel-rule/`: Geben Sie die
Compliance-E-Mail der Gegenpartei erneut an und führen Sie das
Routing noch einmal durch.
url:
type: string
format: uri
description: >-
Der Link zum Wallet-Ownership-Widget, bei `select_counterparty_vasp`
und `declare_self_hosted`, solange der Transfer eine offene
Widget-Sitzung hat.
required:
- action
TravelRuleChainDetails:
type: object
description: >-
Wie die Blockchain des Transfers ihre beiden Wallets benennt, wenn mehr
als eine Adresse eine andere bezahlt. Leer (`{}`) bei einem
Account-Chain-Transfer (EVM, Solana, Tron), bei dem die beiden Adressen
die Wallets sind. Abgleich, Weiterleitung und das Adressbuch lesen die
Wallets zuerst von hier aus.
properties:
chain:
type: string
description: >-
Kanonische Chain, z. B. `BTC`, `XRP` oder `LIGHTNING` für einen
Lightning-Transfer.
shape:
type: string
enum:
- utxo
- memo
- lightning
originator:
$ref: '#/components/schemas/TravelRuleChainSide'
beneficiary:
$ref: '#/components/schemas/TravelRuleChainSide'
utxo:
type: object
description: >-
Bei einem UTXO-Transfer: die Inputs und Outputs wie gespeichert
(Beträge als Dezimal-Strings) und welche Outputs Didit als was
interpretiert hat.
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: Ausgaben, die an eine Eingabeadresse zurückzahlen.
beneficiary_output_index:
type: integer
nullable: true
description: >-
Der Output, der den Begünstigten bezahlt; null, wenn keine
unterschieden werden konnten.
lightning:
type: object
description: >-
Bei einem Lightning-Transfer: Inhalt der Zahlungsanforderung. Immer
`kind` (`bolt11`, `bolt12_offer`, `bolt12_invoice`,
`bolt12_invoice_request`, `lnurl`, `lightning_address`, `node_id`
oder `unknown`); eine BOLT11-Rechnung ergänzt `network`,
`payee_node_id`, `payment_hash`, `amount_msat`, `created_at` und
`expires_at`; ein BOLT12-String ergänzt `blinded_paths` und
`payee_node_id`; eine LNURL oder Lightning Address ihre `domain`. Es
wird nichts über das Netzwerk aufgelöst: Die Anforderung wird
lediglich decodiert.
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: >-
UTXO-Inkonsistenzen, die eine Überprüfung wert sind: Der angegebene
Auftraggeber ist kein Input, der angegebene Begünstigte ist kein
Output, es konnte kein einzelner Output des Begünstigten
unterschieden werden oder der Begünstigten-Output zahlt einen
anderen Betrag aus, als in der Transaktion angegeben ist.
not_applicable_reason:
type: string
enum:
- LIGHTNING_NO_PAYEE_IDENTIFIER
- LIGHTNING_BOLT12_BLINDED_PAYEE
- LIGHTNING_LNURL_NAMES_NO_PAYEE
description: >-
Bei einem ausgehenden Lightning-Transfer, dessen Zahlungsanforderung
keinen Begünstigten nennt: der Grund, warum der Transfer
`NOT_APPLICABLE` ist. `LIGHTNING_NO_PAYEE_IDENTIFIER` (die
Anforderung nennt keinen Knoten des Begünstigten oder konnte nicht
decodiert werden), `LIGHTNING_BOLT12_BLINDED_PAYEE` (das Angebot
verbirgt seinen Begünstigten hinter blinden Pfaden),
`LIGHTNING_LNURL_NAMES_NO_PAYEE` (eine LNURL nennt einen Dienst,
keinen Begünstigten). Derselbe Code leitet den letzten
`timeline`-Eintrag des Transfers ein.
TravelRuleChainSide:
type: object
description: Die Wallet einer Seite, wie von Didit aus den Chain-Daten aufgelöst.
properties:
address:
type: string
description: >-
Die Wallet. Auf einem Memo-Netzwerk die klassische Adresse (eine
XRP-X-Adresse wird in ihre klassische Adresse und ihr Tag
aufgeteilt); auf Lightning die Knoten-ID des Zahlungsempfängers oder
die Lightning-Adresse.
memo:
type: string
description: >-
Das Destination-Tag oder Memo, das Teil der Wallet ist; `""` für
keines.
source:
type: string
enum:
- declared
- x_address
- largest_input
- only_non_change_output
- amount_match
- invoice_payee
- updated
description: >-
Woher die Wallet stammt: `declared` (Ihre Anfrage), `x_address` (aus
einer XRP-X-Adresse aufgeteilt), `largest_input` (die
UTXO-Input-Adresse mit dem größten Beitrag),
`only_non_change_output` (der einzige UTXO-Output, der kein
Wechselgeld ist), `amount_match` (der eine UTXO-Output, der den
Überweisungsbetrag zahlt), `invoice_payee` (der Zahlungsempfänger,
den eine Lightning-Zahlungsanforderung benennt), `updated`
(nachträglich mit `action: update_originator_wallet` festgelegt).
TravelRuleUtxoEntry:
type: object
description: >-
Eine Eingabe oder Ausgabe einer UTXO-Transaktion, wie sie von der
Blockchain erfasst wurde.
required:
- address
properties:
address:
type: string
maxLength: 128
amount:
type: string
nullable: true
description: >-
Dezimal-Zeichenkette in der Einheit des Coins selbst (BTC, nicht
Satoshis). Optional.
example: '0.0125'
txid:
type: string
maxLength: 128
description: Optional. Die Transaktion, deren Output ein Input ausgibt.
vout:
type: integer
nullable: true
minimum: 0
description: Optional. Der Index des Outputs, den ein Input ausgibt.
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: x-api-key
description: >-
Der API-Schlüssel Ihrer Anwendung, aus Entwickler -> API-Schlüssel in
der Business Console. Der Primärschlüssel hat Vollzugriff. Ein benannter
Schlüssel kann im Geltungsbereich eingeschränkt werden: keine, Lese-
oder Schreibberechtigung pro Ressource, beschränkt auf bestimmte
Workflows oder genehmigte Sitzungen, auf eine Liste von IP-Adressen und
auf ein Ablaufdatum. 401 bedeutet, dass der Schlüssel falsch, widerrufen
oder abgelaufen ist; 403 bedeutet, dass kein Schlüssel gesendet wurde,
der Schlüssel keinen Zugriff auf diese Ressource oder Aktion hat oder
die Anfrage von einer Adresse außerhalb seiner IP-Liste stammte; 404 bei
einer Sitzungsroute bedeutet, dass die Sitzung außerhalb der Workflows
oder Status des Schlüssels liegt. Ein Schlüssel ohne Medienzugriff
erhält Bild-, Video- und PDF-URLs als null, und ein Schlüssel ohne
Schreibberechtigung für Sitzungen erhält Sitzungslinks und Token als
null. Siehe https://docs.didit.me/console/api-keys.
````
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.