Axelar · Rate Limits

Axelar Rate Limits

Axelar does not publish explicit numeric rate limits for the Axelarscan API suite (api.axelarscan.io). The APIs are publicly accessible with no API key requirement and rely on OpenSearch-backed cached data for efficient serving. Sustained high-frequency polling beyond normal application usage may result in server-side throttling with HTTP 429 responses. On-chain GMP and token transfer operations are bounded by underlying blockchain transaction throughput and the Axelar network's validator consensus latency, not by HTTP-level rate limits. This artifact remains reconciled:false until Axelar publishes explicit per-minute or per-second limits in their developer docs.

Axelar Rate Limits is the machine-readable rate-limit profile for Axelar on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 5 rate-limit definitions, measuring requests and cross_chain_transactions.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled, unauthorized, and serverError.

Tagged areas include Blockchain, Cross-Chain, Interoperability, Web3, and Rate Limiting.

5 Limits Throttle: 429
BlockchainCross-ChainInteroperabilityWeb3Rate Limiting

Limits

Axelarscan API Public Throughput global
requests · minute
unspecified
No published numeric ceiling. Responses are served from OpenSearch cache with sub-second latency. High-frequency polling (e.g., per-second scraping) may trigger server-side throttling. Use caching locally to minimize repeat calls.
Validator API Public Throughput global
requests · minute
unspecified
No published numeric ceiling. Validator metrics update periodically; polling more frequently than every 60 seconds provides minimal benefit.
Token Transfer API Public Throughput global
requests · minute
unspecified
No published numeric ceiling. Transfer status is updated as cross-chain confirmations arrive; polling more than once per block is unnecessary.
GMP API Public Throughput global
requests · minute
unspecified
No published numeric ceiling. GMP status progresses through discrete states (source-confirmed, axelar-confirmed, destination-executed); polling intervals of 10-30 seconds are sufficient for most monitoring use cases.
On-Chain GMP Transaction Throughput network
cross_chain_transactions · block
network-bound
Limited by source and destination chain block times and Axelar validator consensus rounds. No HTTP-level rate limit; throughput scales with validator set capacity and network congestion.

Policies

Exponential Backoff on 429
If the Axelarscan API returns HTTP 429, implement exponential backoff with jitter before retrying. Avoid tight polling loops.
Local Response Caching
Cache TVL, supply, and network-stats responses locally for at least 60 seconds. These values are pre-computed server-side and do not change faster than the underlying chain's block time.
Event-Driven Status Polling
For GMP and token transfer status tracking, poll only after the expected confirmation window has elapsed (typically 2-15 minutes depending on source/destination chains). Consider switching to Axelar's testnet for development to avoid congesting mainnet APIs.
SDK-Mediated Calls
Prefer the AxelarJS SDK (AxelarGMPRecoveryAPI, AxelarQueryAPI) over direct HTTP polling. The SDK incorporates appropriate retry and backoff logic and abstracts endpoint details that may change.

Sources