Short answer: GMX has no single centralized REST API. A bot needs to combine three sources: a Chainlink oracle feed for price, on-chain contract reads for live position and pool state, and GMX’s public subgraph for historical and aggregated data via GraphQL. This is structurally different from polling one CEX API endpoint and needs to be architected accordingly.
No single endpoint, three different sources
A bot built for a CEX typically polls one REST or WebSocket API for prices, order book, and account state. GMX doesn’t offer that single surface — because it’s a decentralized protocol, the relevant data is split across an oracle feed for pricing, on-chain smart contracts for live position and pool state, and a public subgraph for historical and aggregated queries.
None of these is optional if the bot needs a complete picture: oracle price alone doesn’t tell you pool utilization, and the subgraph alone won’t give you real-time state at the moment of execution.
Pricing: reading the oracle feed directly
GMX’s execution price is sourced from Chainlink oracle feeds rather than an internally matched order book. For a bot, this means price discovery is a contract read (or an oracle-provided price API, depending on the specific integration) rather than a WebSocket price ticker — the data is deterministic and on-chain, but the polling pattern is different from what a CEX integration expects.
Price impact for a specific trade size is a separate calculation layered on top of the oracle price, derived from current GM pool state — this has to be computed per trade, not cached from a previous read.
Positions and pool state: on-chain contract reads
Live position data — size, collateral, entry price, accrued borrow fee — lives in GMX’s on-chain position manager contracts on Arbitrum, queryable via a standard RPC call once you have the relevant contract addresses and ABI. This is the source of truth for anything that needs to be current to the last block.
For historical data — past trades, referral volume, pool composition over time — GMX’s public subgraph indexes on-chain events into a GraphQL API, which is generally faster and easier to query in bulk than replaying raw contract events, though it can lag the chain tip by a block or two depending on indexer load.
Designing around three sources instead of one
The practical implication for architecture: a GMX bot needs to combine a fast, low-latency read path (oracle price + live contract state, for execution decisions) with a separate, higher-latency path (subgraph queries, for historical analysis and backtesting) rather than assuming one API call can serve both purposes the way it might on a centralized venue.