“All the restaurants in Miami” sounds like one query. It is not, and understanding why is most of what it takes to run this well.
It is a tiling problem, not a pagination problem
Google caps any single Maps query at about 200 results. That limit is on the query rather than on a page, so paging, offsetting or re-asking does not get past it. The only thing that returns more businesses is asking about a smaller area — why the cap works that way.
So the algorithm is: split the map into tiles, and split again wherever a tile comes back full, until every tile returns under the cap.
Step 1 — run the census first
censusOnly: true runs one request per 1-degree cell and extracts no businesses at all. It tells you which parts of the area are dense, which are empty, which are already exhausted and which belong to a neighbouring country.
Step 2 — choose search terms, carefully
Terms go in the country's language: English in the US and Canada, Spanish elsewhere. And they barely overlap — measured at 5.5% across 30 of them — so each term you add is close to a full extra pass in both time and cost rather than a marginal addition.
Two terms is roughly twice the run. That is the single biggest lever on what a job costs.
Step 3 — set the area and the brakes
country supplies a bounding box, the country bias and the language. bbox overrides the box so you can do one city or one batch of a large country. Two independent brakes stop a run: maxPlaces caps delivered businesses and requestBudget caps requests. Whichever is reached first ends the run, and the summary says which it was.
Step 4 — run the extraction
{
"country": "US",
"categories": ["restaurant"],
"bbox": { "lat_min": 25.70, "lng_min": -80.32, "lat_max": 25.85, "lng_max": -80.13 },
"maxPlaces": 1000
}A residential proxy is a requirement rather than a tuning option: Google returned HTTP 302 to Apify's own IP ranges when measured on 3 September 2026, so a direct run from the platform returns nothing at all.
Reading the output
One row per business, deduplicated by feature_id across runs as well as within one. Name, address, coordinates and place_id are at 100% in every market measured; phone, hours, rating and website vary enormously by market and vertical — 96.7% in Toronto, 41.4% in a remote region.
Then read RUN_SUMMARY, because the row count cannot tell you whether the area was actually covered — the four fields that can.
What a run costs
$0.001 per delivered business on the Free plan, $0.0008 on Bronze, $0.0006 on Silver and $0.0005 on Gold and above. Phone, opening hours, website, rating, categories and coordinates are included at that price — there are no add-on charges for applying a filter or pulling place details, and the tiling overhead is absorbed rather than billed. Failed tiles are never charged.
Four mistakes that waste a run
Skipping the census. It costs almost nothing and it is the only way to know what the real run costs before starting it.
Adding search terms casually. At 5.5% overlap, each one is close to a whole extra pass.
Trying a whole country in one run. It does not fit in the run time limit. Batch it with a bbox and a requestBudget each — batches are resumable and re-running a finished one spends almost nothing.
Reading the row count as coverage. A truncated census still returns rows. The run summary is what says whether they cover the area.
