TooManyRequestsError is the pytrends name for Google's HTTP 429. It is raised inside _get_data when the explore request is rejected. Catching it and sleeping is not a quota. The GeneralMills/pytrends repository is archived, so the wrapper will not grow a new session handshake. Trends API does not use that stack. POST https://api.trendsapi.ai/api with source google search returns an envelope whose body is a JSON string and must be parsed a second time. Docs: the API reference. Caps: pricing.
Where the exception is raised
A typical crash looks like this:
from pytrends.request import TrendReq
pt = TrendReq(hl="en-US", tz=360)
pt.build_payload(["Blockchain"], timeframe="today 5-y")
pt.interest_over_time()
interest_over_time calls _get_data. On status 429 that helper raises TooManyRequestsError.from_response. The line of business code that catches Exception then retries interest_over_time is retrying a scrape.
Cookie and proxy knobs on TrendReq
The constructor accepts proxies, retries, backoff_factor, timeout, and requests_args. Those exist because the transport is Google's website. They do not appear on Trends API. Passing verify=False or a list of HTTPS proxies is a scrape workaround. It is not an API key.
The exception is not a daily budget
A budget has a remaining count and a reset time. TooManyRequestsError has a status code. Some days the first call works. Some days it does not. That variance is the client, not a published Google Trends quota. Encoding the exception as "wait until midnight" invents a policy Google never wrote.
Drop the session object
POST https://api.trendsapi.ai/api
Authorization: Bearer <api_key>
Content-Type: application/json
{"mode":"get_time_series","source":"google search","keyword":"Blockchain"}
No TrendReq. No build_payload. If this POST returns 429, the product is applying a burst or plan limit. That is a different error and a different fix. Google property notes: the Google Trends guide.