Fallback URLs
This page covers Oracle API fallback URLs. The GMX API uses a different redundancy model — see GMX API peer deployments below.
Oracle API Fallbacks
The Oracle API uses chain-specific primary endpoints such as https://arbitrum-api.gmxinfra.io. When the primary Oracle API endpoint is unavailable for a chain, use the corresponding fallback endpoint below.
| Network | Fallback 1 | Fallback 2 |
|---|---|---|
| Arbitrum | https://arbitrum-api-fallback.gmxinfra.io | https://arbitrum-api-fallback.gmxinfra2.io |
| Avalanche | https://avalanche-api-fallback.gmxinfra.io | https://avalanche-api-fallback.gmxinfra2.io |
| Botanix | https://botanix-api-fallback.gmxinfra.io | https://botanix-api-fallback.gmxinfra2.io |
GMX API peer deployments
The GMX API does not use a primary-plus-fallback pattern. It is deployed per chain across two independent peer base URLs, both user-facing:
| Network | Peer A (.io) | Peer B (.ai) |
|---|---|---|
| Arbitrum | https://arbitrum.gmxapi.io/v1 | https://arbitrum.gmxapi.ai/v1 |
| Avalanche | https://avalanche.gmxapi.io/v1 | https://avalanche.gmxapi.ai/v1 |
| MegaETH | https://megaeth.gmxapi.io/v1 | https://megaeth.gmxapi.ai/v1 |
Both peers receive the same data and accept the same requests. Either base URL can be used on its own, and direct integrators are encouraged to rotate across both rather than hard-coding a single peer.
These URLs describe direct HTTP deployments. SDK clients use the fallback hosts configured by the installed package or supplied by the application. In @gmx-io/sdk 1.6.4, getApiFallbackUrls() returns an empty array for every chain, so an SDK integration that needs peer rotation must supply the second host itself.
Botanix is no longer an active GMX API deployment. This does not affect the separate Botanix Oracle API primary and fallback endpoints above, which remain available for legacy market reads.