Get upstream status

GET /v1/order/{orderId}/status The aggregator-backed projection of an openFor order.

Item	Value
Route key	`infinityOrderUpstreamStatus`
Credential	API key or project id; your organization’s orders only
`X-Infinity-Subject`	required: only the orders placed under that subject are answered (Authentication — your users)

One of the hub’s three status views — the advisory one. Which view answers which question: Order lifecycle.

Request

Path parameters

Param	Rules	Meaning
`orderId`	the aggregator `orderId` or the `hubOrderId`, `^[A-Za-z0-9_-]{1,256}$`	anything else, an unknown id, and an order that is not yours (another organization’s, or one placed under another subject) all answer the same `EIN0009`. Open-flow (`POST /order`) orders are not served here; use `GET /status/{orderId}`

Response

data (UpstreamOrderStatus):

Field	Type	Meaning
`orderId`	string	the upstream order id
`state`	string	`created`, `pending`, `executing`, `executed`, `settling`, `settled`, `finalized`, `refunded`, `failed`
`failedAt`	string	`Prepare`, `Fill`, `PostFill`, `PreClaim` or `Claim` — failures only
`failureReason`	string	the upstream’s message — failures only
`history[]`	array	`{state, at}` — the distinct states the hub has read, in order, each stamped when the hub first read it: `history[0].at` is the hub’s first read, not `submittedAt`, and a state the upstream passed through between two reads is absent. It lives in the hub’s memory: a restart, or 10 minutes without a read, can start it over
`fillTransaction`	object	the upstream’s fill reference — unverified; resolve it with `GET /onchain/tx/…`
`upstreamFillReported`	boolean	the upstream supplied a fill reference (sticky); not chain proof
`filled`	boolean	legacy alias of `upstreamFillReported`
`stateSource`	string	always `upstream-advisory`
`finalityVerified`	boolean	always `false`
`latestUpstreamState`	string	the latest reported state, including one that was rejected
`rejectedUpstreamTransition`	boolean	the latest report could not replace the accepted state
`lastUpstreamSyncAt`	timestamp	the last successful upstream read
`upstreamStale`	boolean	the accepted state could not be refreshed

Behavior

This is advisory. Neither finalized, settled nor filled proves settlement; use the on-chain views for observed facts.
States only move forward: created < pending < executing < executed < settling < settled < finalized, with failed and refunded reachable from any non-terminal state. The terminal states are finalized, failed and refunded: settled can still become any of them. A backwards, unknown or contradictory report is not applied: it sets rejectedUpstreamTransition and upstreamStale and keeps the previous state.
Served from a 2-second cache; when a refresh fails the last good state is served with upstreamStale: true.
Stop polling at finalized, failed or refunded, and do not present any of them as verified finality.
Give the loop a stall rule. An EVM gasless order can stay executed long after it filled and settled on chain, with fresh syncs, upstreamStale: false and no fillTransaction; settled may never be reported (known issue). Once the order reaches executed, read GET /onchain/{orderId}/fill with its onchainOrderId (from GET /orders): its filled and settled facts are the chain’s answer. Hand off to it after a few minutes without progress. The chain facts are open to your project id too; a page, which cannot list orders, takes the on-chain id from the order it submitted: on the escrow lanes the openFor ack’s orderId is the on-chain id, and the SDK’s executeQuote finds it for you.
Open to a project id, like every route but GET /orders. Anyone who holds your project id and one of your order ids can read that order’s status. Nothing lists the ids to a page.

Errors

Code	When
`EIN0007`	an upstream answer the hub refused and no earlier state to fall back to
`EIN0009`	unknown, not yours, malformed, or unknown upstream
`EIN0050` / `EIN0051`	availability, with no earlier state — `EIN0050` with `error_params` `["upstreamAuth"]` when the aggregator refused the hub’s own credential, which only an operator can clear
`EIN0081`	the projection table is full

The gateway’s own refusals — a refused credential, a route not open to it, a rate limit, the hub unreachable or too slow — can come back from every route, with an EPX code and a real HTTP status (Errors — gateway codes); EIN0049 (internal, scrubbed) can come back from any route.

Example

curl -sS https://proxy-api.infinimesh.net/v1/order/0x8c7f293ae9851d2919e1543d0268483a0636bef9417240b0aa15258c508e32b9/status \
  -H "x-api-key: $HUB_API_KEY" \
  -H "X-Infinity-Subject: user-42"

Response

Illustrative values; formats follow the Response table.

{
  "success": true,
  "request_id": "30415263-7485-46b0-8b1c-2d3e4f506172",
  "data": {
    "stateSource": "upstream-advisory",
    "finalityVerified": false,
    "latestUpstreamState": "executed",
    "rejectedUpstreamTransition": false,
    "upstreamFillReported": true,
    "orderId": "0x8c7f293ae9851d2919e1543d0268483a0636bef9417240b0aa15258c508e32b9",
    "state": "executed",
    "history": [
      { "state": "created", "at": "2026-09-22T12:00:23Z" },
      { "state": "executed", "at": "2026-09-22T12:00:52Z" }
    ],
    "fillTransaction": { "hash": "0x4b8d2f6a1e9c3b7d5f0a8e2c6b4d9f1a3e7c5b0d8f2a6e4c1b9d3f7a5e0c8b2d" },
    "filled": true,
    "lastUpstreamSyncAt": "2026-09-22T12:01:00Z",
    "upstreamStale": false
  }
}

failedAt/failureReason are absent: this order is not on the failure arm. The first at is the hub’s first read, three seconds after the ack’s submittedAt.

// client: your InteropClient (see /infinity-interop/sdk/installation)
const st = await client.api.getOrderStatus(ack.orderId);

Get started

Core concepts

Resources

API reference

SDK

SDK reference

Request

Path parameters

Response

Behavior

Errors

Example

Response

See also

​Request

​Path parameters

​Response

​Behavior

​Errors

​Example

​Response

​See also

Request

Path parameters

Response

Behavior

Errors

Example

Response

See also