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 (or wallet verified)	Accepted
verification.declined	Transaction reaches DECLINED / FAILED / CANCELLED	Declined

The verification stays pending while the transaction moves through non-terminal statuses and only finalises on a terminal status — CONFIRMED → accepted; DECLINED / FAILED / CANCELLED → declined. DELIVERED is not terminal (the message reached the counterparty VASP but isn't yet confirmed), so it keeps the verification pending. 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	Transaction created, awaiting delivery to counterparty.	System
FAILED	Transaction delivery failed.	System
CANCELLED	Transaction cancelled.	System
DELIVERED	Successfully delivered to counterparty VASP.	User/System
CONFIRMED	Counterparty VASP confirmed receipt and acceptance.	User
DECLINED	Counterparty VASP declined the transaction.	User

info

Only DELIVERED, CONFIRMED, and DECLINED statuses can be set via the Update Transaction endpoint, and only for INCOMING transactions.

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_RISK	Low risk entities.
MEDIUM_RISK	Moderate risk entities.
HIGH_RISK	High risk entities requiring extra caution.