HTTP 429 means the server refused the next request. On trends.google.com that refusal is almost always a scrape or bot check. On POST https://api.trendsapi.ai/api it is a burst or plan signal for a Bearer key. Those are different stops. Back off. Do not refresh a NID cookie and fire again. Envelope body is a JSON string and must be parsed a second time after a 200. Limit text lives on pricing. The request shape lives on the API reference. Google property notes live on the Google Trends guide.
Read the status line before retrying
POST https://api.trendsapi.ai/api
Authorization: Bearer <api_key>
Content-Type: application/json
{"mode":"get_time_series","source":"google search","keyword":"bitcoin"}
If this POST returns 429, the key is in a burst or a monthly cap. If a scrape client returns 429 against Google's HTML, the session is the problem. Mixing those logs hides the fix. Log the host with the status.
Jitter, not a fixed sleep
A constant 60 second pause synchronizes workers. Full jitter picks a delay in [0, cap] and raises the cap after each miss. Honor Retry-After when the header exists. Stop after a small attempt budget. A worker that retries past that budget is a denial of service against its own quota.
Collapse N scrape calls into one growth window
Unofficial clients often request each timeframe as a separate explore page. That is how 429s start. Trends API accepts several presets on one get_growth call:
{"mode":"get_growth","source":"google search","keyword":"bitcoin","percent_growth":["3M","12M","YTD"]}
One 200, one parse of body, three windows. That is the backoff that matters: fewer requests.
A 429 on POST /api is not a cookie problem
hl, tz, proxies, and requests_args exist in scrape clients. They do not exist on this POST. If the envelope is 429, read pricing and slow the scheduler. If the envelope is 200 and the inner payload is empty, that is a data miss, not a 429.