Skip to content

Search and audit transactions

Filter Travel Rule transactions and retrieve the immutable event history for a transaction.

Use the Transactions API to reconcile records in bulk and to inspect the immutable history of an individual Travel Rule transaction. Webhooks remain the preferred real-time notification mechanism; list and event endpoints are useful for recovery, investigations, audit evidence, and operational tooling.

Search transactions

curl --get 'https://api-dev.cryptoswift.eu/transactions' \
  --header "X-Api-Key: $API_KEY" \
  --data-urlencode '_direction=INCOMING' \
  --data-urlencode '_status=DELIVERED' \
  --data-urlencode '_from=2026-09-01T00:00:00.000Z' \
  --data-urlencode '_to=2026-10-01T00:00:00.000Z' \
  --data-urlencode '_start=0' \
  --data-urlencode '_end=100' \
  --data-urlencode '_sort=createdAt' \
  --data-urlencode '_order=DESC'

Supported list controls include:

ParameterPurpose
qFree-text search; the search term must contain at least three characters.
_from, _toLimit results to a date-time range.
_statusFilter by transaction status.
_directionFilter by INCOMING or OUTGOING.
_start, _endSelect an offset range; each page can contain at most 100 records.
_sort, _orderSelect sorting and ASC or DESC order.

Read X-Total-Count from the response headers to determine how many records match. Continue requesting pages until the requested range reaches that count.

Retrieve a transaction's event history

curl --location 'https://api-dev.cryptoswift.eu/transactions/{transactionId}/events' \
  --header "X-Api-Key: $API_KEY"

Events are returned in reverse chronological order and form an immutable audit history. An event can contain:

  • id, transactionId, eventType, actorType, and createdAt
  • the user responsible for a change, when applicable
  • the resulting status and statusReasoning
  • changedFields, which identifies updated transaction fields
  • piiChanged, which indicates that protected participant data changed without exposing that PII in the event record
  • a Rule Engine snapshot when the event includes a policy result

Event types include transaction creation, data changes, user or system status changes, and mirrored counterparty updates. Actor types distinguish system, user, API key, and counterparty activity.

The endpoint returns 404 if the transaction is not available to the authenticated tenant.

Reconciliation pattern

  1. Process transaction webhooks idempotently using transaction id.
  2. Run a scheduled query with an overlapping _from and _to window to recover missed notifications.
  3. Upsert the latest transaction representation in your internal system.
  4. Fetch /events only when you need a change timeline or audit evidence.

Do not infer every intermediate change from the latest transaction response. Use the event history when the sequence, actor, or changed fields matter.

Next steps