Monitor your key's usage before you hit a limit
Watching your quota headers as you go tells you when a limit is approaching, well before a request actually gets rejected.
Set up polling for a large batch job without a webhook
Some APIs hand back a job ID for a large batch and expect you to poll or wait for a webhook while it processes in the background. This one does not work that way. Every bulk request, large or small, is answered synchronously in the same call, which changes how you should think about running a very large job.
Chunking instead of queuing
Rather than submitting one enormous array and waiting, split a large job into fixed-size chunks, a few hundred to a few thousand items each, and send them as a sequence of ordinary bulk POST requests. Since each call returns its results immediately, there is no job status to poll for, only the next chunk to send.
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]What "polling" actually means here
The closest thing to polling in this setup is checking your own quota headers between chunks rather than checking a job status. Read X-Quota-Free-Remaining and X-Credits-Remaining after each chunk completes, and pause the job, or stop it, if you are about to run past your daily free allowance without enough prepaid credit to continue.
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50Building a simple runner
A small script that loops over chunks, sends each one, checks the headers on the response, and either continues or pauses based on what it sees is all a large batch job needs here. There is no separate job status endpoint to call, since the chunk you just sent already contains everything you asked for.
Resuming after a pause
Track which chunk index you have successfully processed so far, so a pause for a quota reset or a credit top-up can resume exactly where it left off rather than reprocessing earlier chunks and spending requests twice.
What it costs
Cost is the same either way, one request per item across the whole job. The chunking approach only changes how you manage the job, not how many requests it uses in total.
Treating a large job as a sequence of ordinary synchronous chunks, rather than looking for an async job system that does not exist here, keeps the whole thing simple. The rate limits docs cover the quota headers that drive this pattern.