When to batch
Reach for batch when three things are true: (a) you have a large list of URLs, (b) you do not need the results in real time, and (c) you would rather the service handle retries and concurrency than write that code yourself. Building your own batch processor that does the job well is months of effort — controlling how many requests run at once, retrying failures, parking the URLs that never succeed, avoiding duplicate work, and tracking progress. A managed batch endpoint (a ready-made API that runs the job for you) spreads that work across all its customers, so you do not pay for it alone.
How to size batches
Most batch APIs let you submit up to about 1 million URLs in a single job, but the smart size is smaller: 1,000–10,000 URLs per batch. Smaller batches pay off in three ways. You get faster feedback — a broken configuration shows up in minutes instead of hours. You can run several batches at the same time under different job IDs to balance the load. And if one batch goes wrong, you only re-run that batch, not the whole crawl. So split a 1-million-URL crawl into 100–200 batches.
Synchronous fallback
Sometimes a job is batch-sized overall but a few results need to come back right away — for example, a content-monitoring pipeline that pulls 99% of its data from a nightly batch but needs to check a breaking-news URL the moment it appears. Most scraping APIs offer both endpoints: a batch one and a per-request (synchronous) one that replies immediately. Send the urgent work to the sync endpoint and everything else to batch. Just do not call the sync endpoint in a tight loop hoping to match batch throughput — you will get rate-limited (temporarily blocked for sending too many requests too fast).
