Rate limits & backoff

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.

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.

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

The API doesn't publish exact limits, but the tastytrade MCP server self-imposes conservative client-side buckets that make a good default for any client:

Stay comfortably under these and you won't see 429s in normal use.