GET /status

GET https://api.trustware.io/api/v1/route-intent/:intentId/status Poll this endpoint to track routing and settlement progress through to completion. The response doesn’t include the metadata you passed to POST /route. To attribute a transaction to a user or an internal record, store the intentId from the route response against that record, and look it up when you read the status. You can start polling as soon as the intent exists. Until you commit the transaction there is no transaction record yet, so the endpoint returns 200 with "status": "pending" and the intent’s expiresAt instead of an error. Poll until status reaches success or failed.

Path parameters

Parameter	Description
`intentId`	The `intentId` returned by `POST /route`.

Response

{
  "data": {
    "id": "bc5a5e82-1ecb-453b-bf78-c7c3ccdc3223",
    "intent_id": "d9a10f42-7243-498d-914a-269a18b93660",
    "project_id": "6f1d2c3b-4a5e-4f60-8172-93a4b5c6d7e8",
    "sdk_request": false,
    "from_address": "0xeb212fe20f26243ec4d4df2dd49c8aa9fa75a201",
    "to_address": "0xeb212fe20f26243ec4d4df2dd49c8aa9fa75a201",
    "from_chain_id": "43114",
    "to_chain_id": "137",
    "source_tx_hash": "0x4c8f91363c5f5e3ac2154f94995f5beac2993cc595af552c2681538af627e05d",
    "dest_tx_hash": "0x9b7e3f0a...",
    "request_id": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
    "provider_request_id": "eeaa53a4f2e254896ae690edac309e68",
    "transaction_request": {
      "to": "0xce16f69375520ab01377ce7b88f5ba8c48f8d666",
      "data": "0x846a1bc6...",
      "value": "215124226346059100"
    },
    "status": "bridging",
    "routing_provider": "squid",
    "quote_to_amount_usd": "0.19000000",
    "to_amount_wei": "198584",
    "landed_amount_verified": false,
    "poll_attempt": 1,
    "next_poll_at": "2026-04-15T03:13:54.289994Z",
    "create_date": "2026-04-15T03:13:22.592483Z",
    "update_date": "2026-04-15T03:13:24.290292Z",
    "gas_sponsored": false
  }
}

Optional fields may be omitted. The fields always present on a transaction payload are id, intent_id, sdk_request, from_address, to_address, from_chain_id, to_chain_id, transaction_request, status, landed_amount_verified, routing_provider, poll_attempt, create_date, update_date, and gas_sponsored.

Status values

The status field on the response is one of these values:

`status`	Meaning
`pending`	The intent exists but no transaction has been committed yet, so there is no transaction to describe. Continue polling.
`expired`	Nobody committed a transaction within 24 hours of the intent’s `expiresAt`. A late commit still works. See expiry.
`submitted`	The receipt has been submitted; tracking has started. Continue polling.
`bridging`	Assets are in transit to the destination chain. Continue polling.
`success`	Route completed successfully. Final amounts and destination hash are available.
`failed`	The route failed. This alone doesn’t confirm a refund; see polling guidance.

HTTP 404 Not Found means the intent ID is unknown. It is terminal, so stop polling.

expired is a new value. Before it, an intent with no commit reported pending indefinitely.

Expiry

The pending and expired payloads carry expiresAt, the intent’s broadcast deadline as an RFC 3339 timestamp. It is the same value the route response returns. Judge it on Trustware’s clock, not the device’s. An intent stays pending for at least 24 hours after expiresAt. After that, a periodic background sweep marks it expired, so the change doesn’t happen at an exact time. A commit still works in both states. Once the intent is expired, Trustware accepts it only when it can see the transaction on-chain from the payer. See committing late.

The pending response

A pending payload is a stub. The intent row exists, so the response reports the intent’s own status and expiry, but none of the transaction fields exist yet. An expired payload has the same shape, with status and intent_status both "expired".

{
  "data": {
    "intent_id": "d9a10f42-7243-498d-914a-269a18b93660",
    "status": "pending",
    "intent_status": "created",
    "create_date": "2026-04-15T03:13:22.592483Z",
    "expiresAt": "2026-04-15T03:43:22.592483Z",
    "steps": [
      {
        "step_index": 0,
        "step_kind": "approve",
        "chain_id": "43114",
        "status": "confirmed",
        "tx_hash": "0x1f0c...",
        "detail": {
          "token": "0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e",
          "spender": "0xce16f69375520ab01377ce7b88f5ba8c48f8d666",
          "amount": "1000000"
        },
        "create_date": "2026-04-15T03:13:22.592483Z",
        "update_date": "2026-04-15T03:13:40.101223Z"
      }
    ]
  }
}

Check status before reading any other field. steps appears only once the intent has an execution plan, so a resuming client can see that an approval already landed while the route transaction has not been submitted.

Field	Meaning
`intent_status`	The intent’s own lifecycle state: `created`, `submitted`, `bridging`, `success`, `failed`, or `expired`. Present on the pending payload so you can see how far the intent itself got.
`expiresAt`	The intent’s broadcast deadline, RFC 3339. The only camelCase field on this payload; the rest of the `/status` payload is snake_case.
`steps[].step_index`	Position of the step in the execution plan. Steps are ordered: one `approve` entry per required allowance, then the route’s own transaction.
`steps[].step_kind`	`approve` or `main`.
`steps[].chain_id`	The chain the step belongs on.
`steps[].status`	`planned`, `submitted`, `confirmed`, `failed`, or `skipped`. A step stays `planned` until its transaction hash is reported.
`steps[].tx_hash`	Hash reported for that step. Absent while the step is `planned`.
`steps[].detail`	Plan snapshot. For an `approve` step: `token`, `spender`, and `amount`.

Auxiliary status fields

A few separate fields surface conditions that are not part of the main status enum:

Field	Meaning
`gas_status`	Set to `"needs_gas"` when the destination chain step stalled due to insufficient gas. Present only when relevant.
`routing_provider`	The routing provider used for this route, as a runtime value such as `"squid"` or `"lifi"`. Useful when triaging a `failed` status.

Response fields

These are the fields of a transaction payload, which the endpoint returns from submitted onward. On a pending or expired payload only intent_id, status, intent_status, create_date, expiresAt, and sometimes steps are present.

Field	Description
`id`	Trustware internal transaction record ID.
`intent_id`	The `intentId` from the route response.
`project_id`	The Client Dashboard project the intent belongs to.
`sdk_api_key_id`	ID of the SDK key that built the route. This is the key’s ID, never the key itself.
`sdk_request`	Don’t rely on this field. It currently reads `false` on every transaction payload, including routes built with an SDK key.
`from_address`	Source wallet address.
`to_address`	Destination wallet address.
`origin_eoa`	The account behind `from_address`. On EVM chains Trustware reads it from the chain when it can: `from_address` itself for an externally owned account, or a smart account’s `owner()`. Otherwise it is the address reported with the commit, checked only for format.
`from_chain_id`	Source chain ID.
`to_chain_id`	Destination chain ID.
`source_tx_hash`	Transaction hash on the source chain. After an accepted replacement, this is the new hash. On a sponsored route it is the userOp hash until the bundler includes the userOp, then the bundle transaction’s hash.
`dest_tx_hash`	Transaction hash on the destination chain. Absent until the destination transaction is known, which can be before the route reaches `success`.
`from_chain_tx_url`	Block explorer link for `source_tx_hash`, when the routing provider reports one. Provider dependent.
`to_chain_tx_url`	Block explorer link for `dest_tx_hash`, when the routing provider reports one. Provider dependent.
`from_chain_block`	Source chain block number of the transaction. Provider dependent.
`to_chain_block`	Destination chain block number. Provider dependent.
`request_id`	Trustware’s own request ID for the call that created the intent, a UUID. This is the ID to quote in a support request.
`provider_request_id`	The routing provider’s own correlation ID, which its status API and its support recognize. Absent when the selected provider returned none.
`transaction_request`	The source chain transaction the route response asked the payer to sign, as the route returned it. Its shape depends on the chain and the provider, so don’t assume EVM fields such as `to` and `value`. Can be `{}`, and can be large.
`status`	Current status. One of `pending`, `expired`, `submitted`, `bridging`, `success`, `failed`. Treat any other value as not finished.
`intent_status`	The intent’s own lifecycle state. Only on the `pending` and `expired` payloads.
`steps`	Execution steps for the intent, when it has an execution plan. See The pending response.
`routing_provider`	Routing provider used for this route, as a runtime value such as `"squid"` or `"lifi"`.
`status_raw`	The routing provider’s latest raw status response. Its shape is provider dependent and can change without notice, so use it for support and debugging, not for logic. A refund, for example, appears only here: `status` reports it as `failed`.
`route_path`	Provider dependent summary of the route’s legs. Same caveat as `status_raw`.
`route_status`	Provider dependent per-leg status. Same caveat as `status_raw`.
`is_gmp_transaction`	`true` when the route uses a general message passing leg. Provider dependent.
`axelar_transaction_url`	Explorer link for the message passing leg, when there is one. Provider dependent.
`quote_to_amount_usd`	Expected destination USD value from the quote.
`to_amount_wei`	Destination token amount, in the token’s smallest unit. Starts as the pre-trade quote estimate, and is exact only once `landed_amount_verified` is `true`.
`landed_amount_verified`	`true` once Trustware has confirmed `to_amount_wei` by reading the destination chain. Check it before using the amount to drive anything automatic.
`time_spent_ms`	How long the route took, in milliseconds, as the routing provider reports it. Provider dependent.
`gas_status`	Optional. Surfaces conditions such as `"needs_gas"` when the destination step stalls.
`poll_attempt`	How many times Trustware has retried its status check after an error. It is not a count of every check.
`next_poll_at`	When Trustware’s next retry after an error is scheduled. Can be absent or in the past, so don’t schedule your own requests from it.
`create_date`	When the transaction record was created (ISO 8601).
`update_date`	When the record was last updated (ISO 8601).

Gas sponsorship fields

When the transaction is linked to a paymaster sponsorship record, the payload also carries the fields below. They describe that record at any sponsorship_status, so they don’t show that the gas was paid.

Field	Description
`gas_sponsored`	`true` when a sponsorship record is linked, whatever its `sponsorship_status`. Always present, `false` otherwise.
`sponsorship_request_id`	ID of the sponsorship record.
`sponsorship_status`	`requested`, `approved`, `rejected`, `submitted`, `settled`, `failed`, or `expired`.
`paymaster_rule_id`	The sponsorship rule that approved it.
`paymaster_address`	The paymaster address recorded on the sponsorship.
`approved_sponsored_gas_usd`	The maximum gas cost approved, in USD.
`gas_sponsored_usd`	Same value as `approved_sponsored_gas_usd`.
`actual_sponsored_gas_usd`	The gas cost actually paid, in USD, once known.
`approved_sponsored_gas_wei`	The maximum gas cost approved, in the chain’s smallest native unit.
`actual_sponsored_gas_wei`	The gas cost actually paid, in the chain’s smallest native unit, once known.
`sponsorship_user_operation_hash`	The sponsored userOp’s hash.

Polling guidance

Poll on an interval of your own. next_poll_at is Trustware’s internal retry schedule, not a hint for clients. Keep polling on pending, submitted, bridging, and any status you don’t recognize. Stop on success, on failed, and on a 404. Retrying a 404 cannot change the answer, and every attempt counts against your key’s rate limit. expired means nobody committed a payment for the intent. You can stop polling it unless you broadcast a transaction for it, in which case commit that transaction and keep polling. A failed status doesn’t confirm a refund: refund handling is provider dependent. Your application should not trigger any downstream payout until success is confirmed.

The status endpoint will become a WebSocket stream in a future release. The polling interface will remain supported.

Getting Started

Endpoints

Path parameters

Response

Status values

Expiry

The pending response

Auxiliary status fields

Response fields

Gas sponsorship fields

Polling guidance