Skip to main content
GET
List bridge intents
Alpha Preview — Endpoints and response shape may change without notice.
Paginated history of bridge intents — every bridge attempt with its lifecycle status, amounts (raw + USD), token metadata, itemized fees, transaction hashes, and per-step timestamps. Newest-first by default; pass order=asc to walk it forward from a watermark (see Following the feed).

Scoping

At least one scoping dimension is required — the endpoint never runs an unbounded scan:
  • wallet — intents sent by that address (the depositor).
  • customerId — intents created with any API key owned by that customer.
  • apiKey — intents created with that specific API key.
  • intentId — a single intent; it scopes on its own, since the id is unique.
customerId and apiKey are mutually exclusive (at most one). wallet can be combined with either to narrow a customer/key scope to one address. Note that apiKey is both the auth credential and a scope: passing ?apiKey= filters results to intents created with that key. To list a wallet’s intents across all keys, authenticate with the Authorization: <key> header and pass only wallet. An unknown or revoked apiKey returns 404.

Query parameters

Unknown chains, malformed wallets, malformed cursors, and unparseable createdAfter / createdBefore values return 400.

Response

Two differences from /status/{id} worth flagging:
  • amountIn / amountOut are raw base units (not decimal-adjusted) — "7887660" above is 7.88766 USDC. Divide by originMeta.decimals / destinationMeta.decimals to display, or use amountInUsd / amountOutUsd.
  • Timestamps are epoch milliseconds, not ISO strings.
originMeta / destinationMeta / inputMeta carry token name/symbol/logo/decimals, with null fields when the token isn’t indexed. latencyMs is the deposit-detected → fill-confirmed delta (null when the intent never filled, e.g. a refund).

The token the user sold

Bridging from a token the bridge does not hold — anything but the native coin or USDC on that chain — swaps it first: the helper sells it for the origin chain’s native coin, and only then does the bridge see the funds. originToken is therefore the native coin, because that is what the bridge received and what a refund would return. inputToken / inputMeta / inputAmount describe the leg before that swap — what the user actually parted with:
Read as: sold 1.8189 GNS, which became 0.000411 ETH, which is what got bridged. When no swap was needed, inputToken equals originToken and inputAmount equals amountIn. Both are null on intents created before these fields existed — fall back to originToken / amountIn there; they are never backfilled.

Refunds

A bridge that cannot deliver returns the deposit on the origin chain. refundTxHash is that transaction, and status is refunded. Two things to know when rendering one:
  • The refunded amount is in amountOut, denominated in the origin token (originToken / originMeta) — not the destination token it normally holds. It is the deposit minus the refund’s gas.
  • A swapped deposit is refunded in what the bridge held, so a user who sold GNS is paid back in ETH. The swap already happened on chain and cannot be undone.
refundTxHash is null on every intent that was not refunded.

Fees

fees itemizes what was already deducted — the amounts in amountOut / amountOutUsd are net of all of it: integratorAddress / integratorUsd are null on intents quoted without an integrator fee. Destination gas is not itemized here — it is priced into the quote, not charged as a fee line.

Destination before the fill

Until the fill lands, destinationToken and recipient are chain-shaped placeholders, not the real values — the destination of an unfilled intent describes a trade the solver still has to execute. They become real on filled, settling, settled, settle_lost, refunded, and failed. Treat a non-terminal row’s destination as unknown rather than storing it.

Status lifecycle

Happy path: pending → deposited → filling (→ broadcasted → replaced) → filled → settling → settled. Failure path: filling → retrying → refunded or failed; settling → settle_lost when reconciliation could not confirm settlement. From the user’s perspective, filled (and later settled) means funds were received; refunded means the deposit was returned on the origin chain. See Bridge Status for the statuses the live polling endpoint emits.

Pagination

Cursor-based (keyset) on (createdAt, id), in whichever order you asked for. The cursor is opaque — pass it straight back, and keep order identical across the pages of one scan or it will walk the wrong way.
  • nextCursor is non-null only when the page came back full, meaning there is at least one more page. null means you’ve reached the end of the scan.
  • resumeCursor marks where the page stopped, and is set whenever the page returned a row — including a partial one. It is what a follower resumes from; deriving a position from createdAt instead loses sub-millisecond ordering and can re-serve or skip a row.

Following the feed

To keep an index in sync, page forward with order=asc and hold the last resumeCursor as your watermark. Every cycle resumes exactly where the last one stopped, so a cycle that returns nothing costs one request instead of re-paging the whole history from the newest row down.
createdAfter is inclusive of nothing — it is strictly greater-than — so a timestamp cold start never re-delivers the row it names. Once you hold a cursor, drop createdAfter: the cursor is the more precise position.

Query Parameters

wallet
string

Wallet address — returns intents this address sent (the depositor). Recipient-side lookups are not served here.

customerId
string

Scope to all intents created with API keys owned by this customer.

apiKey
string

Scope to intents created with this API key.

intentId
string

Return the single intent with this id.

status
enum<string>

Filter by lifecycle status.

Available options:
pending,
deposited,
filling,
broadcasted,
replaced,
filled,
settling,
settled,
settle_lost,
retrying,
refunded,
failed
originChainId
string

Filter by origin chain (id, name, or alias — e.g. "evm:8453", "base").

destinationChainId
string

Filter by destination chain (id, name, or alias).

createdAfter
string

Only intents created strictly after this time — epoch seconds, epoch milliseconds, or ISO-8601. Pair with order=asc to page forward from a watermark.

createdBefore
string

Only intents created at or before this time — epoch seconds, epoch milliseconds, or ISO-8601.

order
enum<string>

Sort on creation time: desc (newest-first, default) or asc (oldest-first).

Available options:
asc,
desc
limit
integer

Page size (1-100, default 50).

Required range: 1 <= x <= 100
cursor
string

Opaque cursor from the previous page's pagination.nextCursor. Keep order identical across pages of one scan.

Response

200 - application/json

Bridge intents in the requested order, with cursor pagination. pagination.resumeCursor marks where a page stopped even when it was partial, so a follower can tail the feed; token meta carries decimals for the raw amounts, and fees itemizes the bridge and integrator cuts already deducted from amountOut.

data
object[]
required
pagination
object
required