Tradeics applies fair-use rate limits so one integration cannot starve others. Limits are shared across REST V2, MCP tools that call the same resources, and (separately) the LLM proxy.
How limits are measured
- Counters are typically per API key (and sometimes per workspace).
- Burst capacity absorbs short spikes; sustained traffic should stay under the published steady rate for your tier.
- MCP tool calls count against the same resource quotas as equivalent REST requests.
Exact numbers depend on your early-access agreement. When self-serve Platform rolls out, limits will appear on the developer dashboard.
Response signals
When you exceed a limit, expect HTTP 429 (or an LLM-style rate error from https://llm.tradeics.example).
Honor these response headers when present:
| Header | Meaning |
|---|---|
Retry-After |
Seconds (or HTTP date) to wait before retrying |
X-RateLimit-Limit |
Ceiling for the current window |
X-RateLimit-Remaining |
Calls left in the window |
X-RateLimit-Reset |
Unix timestamp when the window resets |
Treat missing headers as “retry with backoff” — do not tight-loop
429s.Client best practices
- Cache read-mostly master data (categories, dictionaries) instead of polling every second.
- Use exponential backoff with jitter on
429and5xx(see Errors & retries). - Batch work: prefer list endpoints with pagination over N× single-id GETs.
- Separate LLM traffic (
llm.tradeics.example) from platform REST — different capacity pools. - For agents via MCP, throttle autonomous loops; prefer human-confirmed writes.