Responses

All Shufti Travel Rule API responses follow a consistent JSON structure. This section describes response formats, transaction statuses, and verification statuses.

Standard Response Format

Field	Type	Description
error	boolean	false when successful, true on error.
status	string	Overall result: SUCCESS or ERROR.
message	string	Human-readable result description.
data	object	Response payload. Structure varies by endpoint.

Success Response

success-response

{
  "error": false,
  "status": "SUCCESS",
  "message": "Operation completed successfully",
  "data": { }
}

Error Response

error-response

{
  "error": true,
  "status": "ERROR",
  "message": "Descriptive error message",
  "data": {}
}

note

The { error, status, message, data } envelope above applies to the management endpoints (/travel-rule/* read / detail / update / delete / wallets / VASP). The create flow (POST /) instead returns the standard Shufti envelope (reference, event, …) and delivers the result via Callbacks.

Callbacks

Travel Rule screening is asynchronous. POST / returns request.pending immediately; the result is pushed to your callback_url as a signed callback. Every callback includes an sp_signature header — verify it as sha256(raw_json_body + secret_key), exactly as for other Shufti services.

Event	When	Verification result
request.pending	Synchronous response on create (not a callback)	Pending
verification.accepted	Transaction reaches CONFIRMED, an OUTGOING transaction reaches DELIVERED, or a wallet is verified	Accepted
verification.declined	Transaction reaches DECLINED / FAILED / CANCELLED	Declined

The verification stays pending until the transaction reaches a final status — CONFIRMED → accepted; DECLINED / FAILED / CANCELLED → declined. DELIVERED depends on direction: an OUTGOING transaction is accepted at DELIVERED (the message was delivered; under the post-transaction model the counterparty's confirmation is not required), while an INCOMING transaction stays pending until you confirm or decline it. Use the Read / Detail endpoints to check the current status at any time.

Final callback

verification.accepted-callback

{
  "reference": "sp-tr-txn-001",
  "event": "verification.accepted"
}

For a declined outcome the event is verification.declined (with declined_reason / declined_codes as for other services — see Declined Reasons).

Transaction Statuses

Travel Rule transactions progress through these statuses during their lifecycle:

Status	Description	Set By
PENDING	Created and waiting for further processing. Initial status of INCOMING transactions.	System
DELIVERED	Delivered to the counterparty VASP. Initial status of OUTGOING transactions.	System / beneficiary VASP
CONFIRMED	Beneficiary VASP reviewed and approved the transaction.	Beneficiary VASP
DECLINED	Beneficiary VASP reviewed and rejected the transaction. status_reasoning required.	Beneficiary VASP
FAILED	Could not be processed because of a system or API error.	System
CANCELLED	Transaction cancelled.	System / counterparty

info

DELIVERED, CONFIRMED, and DECLINED can be set via the Update Transaction endpoint for INCOMING transactions. See Status Lifecycle for how each status is reached per direction.

Wallet Verification Statuses

Status	Description
pending	Verification is pending review.
verified	Wallet ownership has been successfully verified.
failed	Verification failed.

Risk Severity Levels

Severity	Description
low	Low risk entities.
medium	Moderate risk entities.
high	High risk entities requiring extra caution.