Get Started
Integrate / SDKs
User Verification
Business Verification
Transaction Monitoring
ChangelogSubmit Transaction (SDK Token)
Device-facing endpoint the Didit SDKs call to submit a transaction directly from the end-user’s device. Authentication is a scoped token from POST /v3/transactions/sdk-token/ sent in the X-Transaction-Token header instead of an API key, and the endpoint is CORS-enabled so browsers can call it cross-origin. The payload uses the camelCase wire aliases shown below (the SDK submitTransaction methods build it for you). Three server-side guarantees: the application is always taken from the token; the subject identity (externalUserId) is always enforced from the token’s vendor_data, so spoofed payload values are ignored; and device intelligence (the SDK device fingerprint plus server-derived IP and user agent) is attached to the subject automatically.
Authorizations
Short-lived scoped token minted by your backend via POST /v3/transactions/sdk-token/. Used by the Didit SDKs on the device-facing /v1/transactions/ endpoints.
Body
Your unique identifier for this transaction (maps to transaction_id, max 128 characters).
"wd-2026-07-07-0042"
Transaction category (maps to transaction_category), e.g. finance, kyc, travelRule, userPlatformEvent, gamblingBet.
"travelRule"
Core financial details of the transaction (maps to transaction_details).
The subject (applicant) of the transaction. externalUserId is ignored here: the subject identity is always enforced from the token's vendor_data.
When the transaction occurred (maps to transaction_at). Defaults to now if omitted.
IANA time zone identifier (maps to time_zone), e.g. Europe/Madrid.
The counterparty of the transaction (optional). Same shape as subject; externalUserId is meaningful here.
Custom key-value pairs (maps to custom_properties). Each key can be referenced in rule conditions as custom_values.<key>.
Travel Rule details (maps to travel_rule_details). When Travel Rule is enabled for the application, Didit ignores any status you send and drives the exchange itself.
Per-transaction override for crypto blockchain analytics screening (maps to include_crypto_screening).
The didit-fp-v2 device fingerprint payload. Injected automatically by the SDKs; only relevant when calling the wire API directly.
Response
Transaction submitted and monitored. Same detail shape as GET /v3/transactions/{transaction_id}/, including the action_required block when the end user must complete a follow-up action (the SDKs auto-launch it by default).
Full monitoring record for one transaction, as returned by GET /v3/transactions/{transaction_id}/ and POST /v3/transactions/.
Didit-stable transaction identifier. Use as {transaction_id} for follow-up calls.
Application-scoped sequential transaction number shown in Console (e.g. 4123).
The transaction_id you supplied at create time (max 128 chars). Unique per application.
When the transaction occurred (from transaction_at; defaults to submission time).
IANA time zone identifier provided at create time.
Top-level category as stored: finance, kyc, travelRule, userPlatformEvent, gamblingBet, gamblingLimitChange, gamblingBonusChange, auditTrailEvent. Note multi-word values are echoed back in camelCase even when submitted in snake_case.
Sub-type within the category (e.g. deposit, withdrawal, transfer). Defaults to the category when not supplied.
Direction relative to the subject. Stored uppercase regardless of the casing submitted (in/out/inbound/outbound are accepted on input).
INBOUND, OUTBOUND Current monitoring verdict. Transactions are created APPROVED; rules may flip them to IN_REVIEW/DECLINED synchronously.
APPROVED, IN_REVIEW, DECLINED, AWAITING_USER Transaction amount as a decimal string with trailing zeros stripped (e.g. "1500", "0.5", "0.123456789012345678"). Up to 18 decimal places.
Currency code of amount (e.g. EUR, USD, BTC).
fiat or crypto, as submitted in currency_kind.
Pre-converted amount you supplied, as a decimal string with trailing zeros stripped.
amount converted to the application's preferred currency, when available.
Free-text payment reference or memo from the submission.
External payment system reference (e.g. blockchain transaction hash) from payment_reference_id.
Risk score accumulated by rules (typically 0–100). Higher = riskier.
Categorical risk severity set by rules/providers (UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL). null until something sets it.
UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL Machine-readable reason for the current status.
Human-readable label for decision_reason_code.
Convenience copy of the applicant's vendor_data.
Snapshot of the subject and counterparty payloads as submitted at create time.
The custom_properties you supplied at create time. Each key is addressable in rule conditions as custom_values.<key>.
Tags attached to the transaction (manually or by rules).
Transaction parties (applicant, counterparty).
Payment methods linked to the transaction.
Activity log entries (creation, notes, manual reviews, status changes).
Alerts raised by rules and providers.
Per-rule execution results — which rule fired, with what score impact.
Raw provider payloads (AML screening, blockchain analytics, etc.).
Travel Rule compliance check, present when travel_rule_details was submitted.
Graph snapshot of related transactions/parties used by the rules engine, present when submitted.
Remediation session offered to the user when re-verification is required. Superseded by action_required, which is the canonical block; kept for backward compatibility.
Pending end-user action required to complete this transaction, or null when there is none. The Didit SDKs auto-launch the action by default and refresh the transaction when it finishes. Two variants, discriminated by type: verification_session (a hosted verification session created by a rule action) and wallet_ownership (a wallet-ownership widget session auto-minted for a Travel Rule transfer that needs proof of wallet control, gated by the auto_wallet_verification Travel Rule setting). When both could apply, wallet_ownership takes precedence because it blocks the Travel Rule exchange.
- Verification session
- Wallet ownership
Per-feature credit cost breakdown for this transaction.