> ## Documentation Index > Fetch the complete documentation index at: https://docs.delora.build/llms.txt > Use this file to discover all available pages before exploring further. # Transaction Tracking API > Read Delora transaction history and asynchronous bridge status for your integration. 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: | Data | Typical refresh behavior | | --------------------------------------- | ------------------------------- | | Analytics transaction ingestion | Approximately every minute | | Eligible bridge-status checks | Approximately every two minutes | | Receipt, sender, and gas-fee enrichment | Retried about every 30 minutes | 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](/api-reference/endpoint/get-transaction-status) with sensible backoff and respect `429` responses. ## Status lifecycle | Status | Meaning | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | `success` | A swap completed in analytics, a terminal bridge event was observed, or a bridge provider reported success when no destination Delora call is required. | | `recovered` | Delora recorded a recovery event. | | `bridge_pending` | The bridge is still pending, or the provider succeeded but Delora is waiting for a required destination event. | | `refund_pending` | A refund is pending. | | `refunded` | The provider reported a completed refund. | | `bridge_failed` | The bridge provider reported failure. | | `unknown` | Delora cannot yet classify the route reliably, including when a source receipt failed after an analytics event. | `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: | Value | Meaning | | ------------ | ----------------------------------------------- | | `analytics` | Derived from Delora analytics events. | | `receipt` | Derived from a source-chain receipt. | | `bridge_api` | Derived from a bridge provider. | | `mixed` | Derived from more than one source. | | `unknown` | No authoritative source is currently available. | `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 * [Track a submitted transaction](/examples/transaction-flow/track-a-submitted-transaction) * [List tracked transactions](/api-reference/endpoint/get-transactions) * [Get a tracked transaction](/api-reference/endpoint/get-transaction) * [Get a transaction's status](/api-reference/endpoint/get-transaction-status) * [API errors](/api-reference/errors)