Waze Places Search Scraper

What does Waze Places Search Scraper do?

Waze Places Search Scraper runs a batch of point queries — venue search, nearby POI discovery, and/or reverse geocoding — against Waze's internal live protocol, and pushes one dataset row per result. Pass an array of {operation, lat, lon, ...} objects in a single run instead of calling one endpoint per point.

It talks directly to the same internal protocol the official Waze Android app uses (rt.waze.com), reverse-engineered by live MITM capture against a real device and cross-referenced against the app's own decompiled protobuf schema (see proto/waze_rt.proto in the source repo — field names and numbers are the real app's, not guesses). No Waze account, no API key, no scraping setup. Each query opens its own short-lived anonymous session server-side; you never see or manage credentials. This is the places-search slice of Waze All-in-One API, split out as its own focused batch Actor.

Why use Waze Places Search Scraper?

• Batch, not one-call-at-a-time — mix search, nearby, and reverse-geocode queries for many different points in one Actor run
• Place search — the same location-biased venue lookup as the app's search bar
• Nearby POI discovery — what's around a point, with real category tags, no text query needed
• Reverse geocoding — turn any coordinate into a street address
• No account needed — every query authenticates itself
• Use cases: logistics/routing risk analysis, points-of-interest datasets, address enrichment, urban mobility research, travel/mapping apps

How this connects to the parent

Waze All-in-One API is an always-on Standby REST API exposing /search, /nearby, /reverse-geocode, plus /alerts, /route, /walking-distance, /eta-batch, and /sos-providers. This Actor derives from the same three place-query endpoints, but runs as a normal batch Actor: give it an array of point queries as input, get dataset rows out — no HTTP client, no Standby URL, no per-call pricing tab. Use the parent Actor instead if you need on-demand single calls or any of its other endpoints (live traffic alerts, route calculation, ETA, SOS contacts).

Input

queries — required, non-empty array. Each item:

Field	Type	Description
operation	string	search | nearby | reverse-geocode. Required.
lat	number	Latitude, decimal degrees. Required.
lon	number	Longitude, decimal degrees. Required.
query	string	Free-text venue query. Required for search.
maxResults	integer	Max results. Default 5 for search, 10 for nearby. Unused otherwise.
radius	integer	Search radius in meters. Default 50. Only used by reverse-geocode.

A malformed item (missing/invalid fields for its operation) is logged and skipped — it does not fail the whole run.

Example:

{
    "queries": [
        { "operation": "search", "query": "SPBU", "lat": -6.1754, "lon": 106.827, "maxResults": 3 },
        { "operation": "nearby", "lat": -6.175, "lon": 106.827, "maxResults": 3 },
        { "operation": "reverse-geocode", "lat": -6.1954, "lon": 106.8206 }
    ]
}

Output

One dataset row per result item, tagged with the query that produced it. search and nearby push one row per venue found; reverse-geocode pushes exactly one row per query (with venue: null if nothing was found).

search / nearby row (trimmed real example):

{
    "query": { "operation": "search", "query": "SPBU", "lat": -6.1754, "lon": 106.827, "maxResults": 3 },
    "name": "SPBU 34.10401",
    "location": { "x": 106.843635672, "y": -6.184980284 },
    "city": "Jakarta Pusat",
    "country": "ID",
    "address": "Kramat Raya 116 RT 002/09",
    "phone": "+62-21-3106507"
}

reverse-geocode row:

{
    "query": { "operation": "reverse-geocode", "lat": -6.1954, "lon": 106.8206 },
    "venue": { "street": "Jalan Teluk Betung", "city": "Jakarta Pusat" }
}

Venue fields (name / houseNumber / street / city / country / address / phone) are as reported — not every field is populated for every result. location.x / location.y are longitude/latitude in plain decimal degrees, present on search and nearby results only. categories (e.g. ["MUSEUM"], ["CAFE"]) is present on nearby results only.

Known limitations

• reverse-geocode returned empty in some regions during the parent Actor's testing (New York and Tel Aviv, both otherwise dense Waze markets) despite working reliably in Indonesia and the UK. Cause not yet isolated — logged as a regional caveat rather than assumed fixed everywhere.
• nearby doesn't support filtering by category. The protocol has a category filter field, and real category strings were pulled straight from the app (GAS_STATION, PARKING_LOT, CHARGING_STATION, EV_CHARGING_STATION, ...), but every one tried returned zero results in testing, while leaving the filter unset reliably returns real nearby venues with their category already attached. Filter client-side on the categories field in the response for now.
• This is an unofficial, reverse-engineered integration, not affiliated with or endorsed by Waze / Google. Behavior may change if Waze changes its protocol.

Pricing

Pay per event: $0.006 per place — charged once for each search/nearby/reverse-geocode result row pushed to the dataset (Free plan price; lower on paid Apify plans). See the Actor's Pricing tab for current tiered rates.

Found a bug or have a feature request? Use the Issues tab on this Actor's page.