Rate limits & backoff

On the REST side tastytrade throttles by reasonable thresholds rather than a published per-endpoint quota — the documented 429 responses carry no rate-limit headers, so treat the bare status as the only signal. The contract is simple: don't hammer the API, back off when told, and prefer streaming over polling.

Streaming is different: the market-data streamer has hard, published caps. Those are exact numbers, and exceeding them fails rather than throttles. See Streaming rate limits.

What you'll hit

• 429 Too Many Requests — you sent a high volume of requests in a short window, exceeding reasonable thresholds. See error reference → 429.
• IP block (~8 hours) — too many failed logins in a short period gets your IP blocked outright (a brute-force protection). Requests then time out. Contact api.support@tastytrade.com to be unblocked.

Backoff

On 429 (and on 5xx/network errors), retry with exponential backoff + jitter, and cap the number of attempts. Do not tight-loop retries — that's what triggers the threshold in the first place. For order placement, combine backoff with the status check in Idempotency & retries.

Streaming rate limits

Unlike the REST thresholds, the DXLink market-data streamer enforces explicit limits:

Two of these catch people out. The per-event cap of 100 applies to Candle, Order and Series specifically, so a client that happily holds thousands of Quote subscriptions will still fail at the 101st Candle. And the change rate is a rate, not a total: churning subscriptions symbol-by-symbol as a user scrolls a watchlist can exhaust 10,000/minute while the subscription count stays small. Batch subscription changes and unsubscribe in groups rather than per-symbol.

The 5-session limit is per set of credentials, so a client that opens a session per browser tab or per worker will hit it before it hits anything else. Share one streamer connection and fan out internally.

Reduce load (the real fix)

• Stream, don't poll. For live quotes and account updates use the DXLink market-data streamer and the account streamer instead of polling REST. (Get a quote token first; see the streaming docs.)
• Batch. Endpoints that accept many symbols at once — e.g. the market-data quote snapshot (GET /market-data/by-type, up to 100 symbols across all instrument-type parameters) — let you replace many calls with one.
• Cache slow-changing data (instrument definitions, option chains, session calendars) instead of re-fetching per request.

A sensible client-side guideline

If you want a client-side ceiling to code against, the tastytrade MCP server charges each call against tastytrade's own published per-second, per-endpoint ceilings plus a 50/sec global cap. Mirroring that — a per-endpoint ceiling with a global cap, counted once per call — is a reasonable default for any client, and it is stricter than the REST thresholds in normal use.

Combined with streaming for anything live, and caching for anything slow-changing, that is usually enough to never see a 429.