Radix Gateway API

Overview

The Radix Gateway API is the primary developer interface for building dApps on Radix. It indexes the ledger and provides REST endpoints for querying account states, token balances, transaction history, and resource metadata.

Decentralization

Currently operated by the Radix Foundation, the Gateway API is undergoing community transition via RFP (opened February 2026). The database is approximately 2TB with ~60GB monthly growth. Successful operators must guarantee 99.9% uptime and sub-second query latency for the Radix Wallet and Dashboard.

What the Gateway does when it falls behind

The Gateway answers from its own index rather than from a node’s live state, so it can fall behind the network. Rather than serve a stale answer it refuses to answer at all. LedgerStateQuerier compares the timestamp of its own head against the clock and throws NotSyncedUpException when the gap is too wide. The caller gets HTTP 500 with a NotSyncedUpError body naming current_sync_delay_seconds and max_allowed_sync_delay_seconds.

The guard has two halves, separately configurable, both on by default at 30 seconds (Gateway configuration reference). PreventReadRequestsIfDbLedgerIsBehind covers the state and stream endpoints. PreventConstructionRequestsIfDbLedgerIsBehind covers /transaction/construction, and the source gives its reason: a construction request built against a stale index would use historic stake records, which gets an unstake calculation wrong. The Radix Foundation’s public mainnet Gateway runs both thresholds at 720 seconds.

What that looks like from a dApp

The mainnet halt that began on 31 August 2026 holds the guard open long enough to read it. Every endpoint below was called once at 03:10 UTC on 5 September 2026:

Endpoint	Response
/status/gateway-status	200, returning the frozen head: state version 557,840,622, epoch 339,896, round 102
/status/network-configuration	200
/state/entity/details	500, request_type Read
/state/validators/list	500, request_type Read
/stream/transactions	500, request_type Read
/transaction/construction	500, request_type Construction

All four failures reported current_sync_delay_seconds 366,663 against max_allowed_sync_delay_seconds 720. A wallet or dApp on this Gateway therefore connects, resolves the network, and then fails on every balance, history and submission call, with nothing wrong with the account or the key: the index will not answer for a ledger whose top it cannot see. The two status endpoints stay up throughout, which is what makes /status/gateway-status the place to check whether the network is moving.

Reading around the guard

The refusal covers questions about the present, and only those. GetValidLedgerStateForReadRequest resolves the ledger state the caller asked for before it does anything else, and the lag comparison sits behind an early return: if (!ledgerStateReport.TopOfLedgerResolved) return ledgerState;. TopOfLedgerResolved is set true on one branch only, the one taken when the request named no ledger state and the Gateway had to read its own head. A request that pins a state version, an epoch, an epoch and round, or a timestamp never reaches the threshold and cannot throw NotSyncedUpException.

The halt makes that visible. Each endpoint below was called twice within two seconds at 07:07:56 UTC on 6 September 2026, at a reported current_sync_delay_seconds of 467,332 against 720 — once as an ordinary request, once with "at_ledger_state": {"state_version": 557,840,622}, the last state version the ledger reached:

Endpoint	Unpinned	Pinned
/state/entity/details	500	200
/state/validators/list	500	200, 287 validators with stake vaults
/stream/transactions	500	200
/transaction/construction	500	500

Construction is the exception and the source says why it is not an inconsistency: GetValidLedgerStateForConstructionRequest carries the identical early return, but the /transaction/construction request has no at_ledger_state field to fill, so the value is ignored, the Gateway resolves its own head, and the Construction guard fires as before. Nothing here lets a stopped network be transacted on; it lets a stopped network be read.

So the practical division during a halt is not between working and broken endpoints but between two questions. What is true now has no answer and the Gateway declines to invent one. What was true at state version 557,840,622 has an answer, it is the last one the ledger produced, and the same public Gateway will serve it — balances, resource holdings and transaction history included. A dApp fails during a halt because it asks the first question; a caller willing to name a ledger state gets the second.