A client should be able to slow down before it starts getting 429s. To do that, it needs to know how much room is left in the current rate-limit window.
The API includes that information on successful calls. For example, a normal response from /country/us can carry these headers:
x-ratelimit-limit: 120
x-ratelimit-remaining: 113
x-ratelimit-reset: 2
In this example, the limit is 120 requests per minute, 113 remain in the current window, and the window resets in two seconds. Your actual limit follows your team's settings. reset is a number of seconds, not a timestamp.
If the response also includes X-RateLimit-Burst, capacity replenishes continuously. That header describes the bucket capacity; Remaining is the current estimate and Reset is the time until full recovery with no further calls. On a 429, use Retry-After for the next attempt instead of waiting for the entire bucket to refill. Other callers on your team share the allowance.
A script processing a list can read those headers as it goes and pause when it gets close to the limit. It doesn't need an extra request just to check whether it can make the next one. If it does hit the limit, the 429 response also includes Retry-After with the wait in seconds.
These headers describe the short rate-limit window, not your monthly request allowance. They are added when a request reaches the rate-limit check, so an earlier failure, such as a missing API key, won't necessarily have them.