Two different things happen when you push an API hard, and both have clean fixes.
Timeouts on a heavy batch. Fetching deep financial data or long histories for many tickers can legitimately take over a minute, because good APIs pace requests to respect upstream limits. If your HTTP client has the usual 5-10 second default timeout, it aborts the connection mid-answer and you blame the API. Two fixes: raise the client timeout to a generous one or two minutes for heavy calls, and query in small groups rather than 15-20 items in a single call. (Relatedly, high-performance bulk formats like Parquet are offered on bulk download endpoints, not on live real-time query endpoints - do not append format=parquet to a live query.)
429 Too Many Requests. This is not a ban and nothing is broken - you simply sent more calls in that minute than the per-IP rate limit allows (a per-IP limit exists so one caller cannot crowd out everyone else). The response tells you how to recover: a Retry-After header says how many seconds to wait, and X-RateLimit-Remaining (on every response, not only the 429) shows how much budget is left before you hit the wall. So: read Retry-After, pause that long, then continue - and watch X-RateLimit-Remaining to pace yourself before you ever trip it.
The bigger lever: if you are pulling a lot of data, a bulk download file is almost always the right tool rather than firing hundreds of single calls - it is one request, no rate-limit dance. Each endpoint publishes its own per-IP limit on its docs page (https://www.tigzig.com/apis), so check the number for the endpoint you are using. The server side of this - why heavy files must stream from object storage, not a serverless function - is here. Worked examples: https://www.tigzig.com/post/tigzig-api-errors-practical-guide-jul2026.
← All Agents FAQ