429 response. Use this guide to optimize your request workflow or replace status polling with webhooks or websockets. If you have already tried both, contact support to request an elevated rate limit.
Optimize your request workflow
Most integrations that reach a limit are sending requests they don’t need. This is the fastest change to ship, and it usually resolves the problem without any change to your architecture. Configuration data is the most common source of unnecessary traffic. Chains, currencies, and similar responses change infrequently, so fetch them once at startup and cache them rather than calling on every user interaction. Quote traffic is the next place to look./quote carries the tightest default limit at 50 requests per minute. Debounce amount and token inputs so a user typing an amount produces one call rather than one per keystroke, and collapse identical in-flight requests into a single call whose result is shared across callers.
Validation belongs on the client too. Amounts below Relay’s minimum come back as AMOUNT_TOO_LOW, so a sub-cent value a user types should fail your own check before it turns into a quote call. Where your interface already knows the user’s balance, apply the same treatment to amounts they can’t cover.
If you poll for status, widen the interval and stop polling once a request reaches a terminal status (success, failure, or refund). When you need many records at once, GET /requests/v3 retrieves them in a single filtered call instead of one call per request ID.
Replace polling with webhooks or websockets
Polling for status is a major source of avoidable request volume. Relay can push status updates to you instead, which removes those calls from your budget entirely and delivers updates faster than any polling interval. Webhooks POSTrequest.status.updated events to an HTTPS endpoint on your backend as each request changes status. Configure one endpoint per API key in the Relay Dashboard. Use webhooks when you have a server that can receive traffic.
Websockets deliver the same events over an open connection to wss://ws.relay.link, authenticated with your API key. Use websockets when the consumer is a client or a process that can hold a connection open.
Either option eliminates polling for status. Keep a low-frequency reconciliation poll if you want a safety net against missed events, but drive your primary flow from the pushed updates.