Skip to content
YieldSeeker Docs

Rate limits

A standard-read tier has per-minute and per-hour limits; over-limit responses include a 429 status and Retry-After header. Standard read30 / min300 / hourWHEN EXCEEDED429Retry-After

Rate limits are declared per route and count calls within configured time windows. Public-read and public-account tiers are keyed by IP. Standard signed user operations are keyed by the authenticated user; API-key requests to integrator analytics use the integrator as the key. The public-account tier remains IP-keyed for wallet login and account creation, including loginWithWallet, which also requires SIWE.

A request over the limit receives a 429 response with a Retry-After header giving the number of seconds to wait before retrying. Treat that header as authoritative — read it and back off accordingly rather than hard-coding a client-side assumption about the limit.

The table summarizes current route metadata. Check each operation in the generated API reference for its configured tier; some routes have no explicit limit.

Tier Typical limit Used for
Public read 30/minute, 300/hour Public lookups (health, supported assets, onchain status, vault opportunities)
Public account 5/minute, 20/hour, 100/day Wallet login and account creation (IP-keyed)
Standard read 30/minute, 300/hour Authenticated reads (agent snapshots, positions, activity, memories)
Standard write 15/minute, 120/hour Authenticated writes (creating/updating an agent, saving a memory)
Expensive mutate 5/minute, 30/hour Expensive mutations, including deposit and withdrawal operations
Chat 6/minute, 20/5 minutes Sending a message to an agent conversation
Simulate 3/minute, 10/hour Preview-only allocation simulations
OAuth 5/minute, 20/hour OAuth login requests (Twitter, Discord, Telegram)

GET /v1/platform-stats currently has no explicit route limit; the platform stats detail and activity-feed routes do.

  1. Read the Retry-After header on the response.
  2. Wait at least that many seconds before retrying the same operation.
  3. Avoid tight retry loops. Retry only after the indicated delay, and honor any later Retry-After values.