Skip to main content
The Transaction Tracking API is a read-only view of Delora transactions associated with your integrator. Use it after a transaction has been submitted to retrieve source and destination hashes, status, token and fee data, and bridge-provider enrichment. It is not a transaction-execution API and it is not a complete blockchain archive.

​
Authentication and data access

All tracking endpoints require a valid x-api-key.
  • Delora derives the integrator from the API key.
  • A key can retrieve only that integrator’s tracking records.
  • Do not use the optional integrator list parameter to select another tenant. It is only a same-integrator assertion and a mismatch returns 403.
  • Keep API keys on your backend. If you display tracking data to end users, enforce your own user authorization before proxying the request to Delora.

​
What is tracked

The API tracks Delora transactions that are present in Delora’s analytics events, including supported bridge routes and generic swaps. It does not index every transaction on a wallet or chain.
Historical backfill is not yet available. The scanner is not a complete historical ledger; only transactions within the current ingestion lookback are guaranteed candidates for discovery. A transaction can return 404 even if it occurred on-chain.
Transactions that revert before producing the relevant Delora event may not appear.

​
Freshness and enrichment

The read model is updated asynchronously: These timings are operational targets, not an SLA or a settlement guarantee. Provider availability, chain finality, and destination calls can delay a final-looking record. There are no transaction webhooks. Poll the lightweight status endpoint with sensible backoff and respect 429 responses.

​
Status lifecycle

hasDestCall: true is important: a route can remain bridge_pending after the bridge provider reports success while the destination Delora call is awaited. statusSource indicates the data used for the current status: substatus is supplementary diagnostic text that may be generated by Delora or a provider. Do not treat it as a stable enum.

​
Chain IDs and data quality

Use canonicalSourceChainId and canonicalDestChainId as the normalized chain identifiers. List filters sourceChainId and destChainId use canonical IDs. protocolRawSourceChainId and protocolRawDestChainId preserve provider-specific values for diagnostics. Do not use them for filtering. Token amounts and fees are strings to preserve precision. Do not parse raw amounts with JavaScript floating-point numbers. A null token, fee, gas field, sender, destination hash, or explorer URL means the data is unavailable or has not been enriched; it does not mean zero. Receipt and gas-fee enrichment is best effort and currently depends on EVM RPC availability. lastReceiptCheckedAt and lastBridgeCheckedAt record scanner check attempts. lastBridgeSuccessCheckedAt records a non-unknown bridge-provider result; despite its name, none of these timestamps proves settlement or finality. rawBridgeStatus is an unstructured provider diagnostic payload. Its shape is not a stable public contract; do not build application logic around it.

​
Endpoints