Plaza Docs | Blog

Plaza: The Geospatial Layer for AI

Mon, 30 Mar 2026 00:00:00 GMT

Every AI agent that interacts with the physical world needs geospatial data. Most of them are calling Google Maps or Mapbox — APIs built for rendering web maps, not for tool use by language models. Those APIs are expensive, require stitching multiple providers together, and return inconsistent response formats across endpoints.

Plaza is a single geospatial data API with billions of features — the full OpenStreetMap planet, curated open datasets, and custom user data. Geocoding, routing, search, isochrones, distance matrices, elevation, map matching, route optimization, and — critically — arbitrary spatial queries via PlazaQL. One base URL, one auth mechanism, GeoJSON everywhere.

PlazaQL as a graph query language

Think about what people actually ask AI assistants:

“I need to get to the office, but I need to stop by the pharmacy on the way”
“Find me a coffee shop with wifi near a subway station in Manhattan”
“Where can I charge my EV between here and Portland?”
“What parks are within a 15-minute walk?”

These sound simple, but with traditional APIs they’re multi-step nightmares. “Stop by the pharmacy on the way” means: geocode the origin, geocode the destination, find pharmacies, figure out which ones are near the route, re-route through the best one. That’s 4-5 API calls across potentially different providers.

With Plaza, each of these is a single query.

PlazaQL: a query language over the planet

The real power is PlazaQL. It lets an agent query billions of features like a graph database. Things that would take multiple API calls with any other provider become a single query:

“I need to stop by a pharmacy on the way to work”:

$r = route(origin: point(40.748, -73.993), destination: point(40.755, -73.970));
search(node, amenity: "pharmacy").around(200, $r).sort(distance($r));

One query: compute the route, find pharmacies within 200m of it, sort by distance. With Google Maps this is 3 separate API calls across 2 different services.

“Find coffee shops with wifi near subway stations in Manhattan”:

$manhattan = boundary(name: "Manhattan", admin_level: "7");
$subway = search(node, railway: "subway_entrance").within(geometry: $manhattan);
search(node, amenity: "cafe", internet_access: "wlan").around(200, $subway);

Resolve Manhattan’s boundary, find subway entrances inside it, then find cafes with wifi within 200m of those entrances. A multi-hop spatial query in a single POST.

“Where can I charge my EV between Portland and Seattle?”:

$r = route(origin: point(45.52, -122.68), destination: point(47.61, -122.33));
search(node, amenity: "charging_station").around(5000, $r).sort(distance($r));

“What parks are within a 15-minute walk?”:

search(way, leisure: "park")
  .within(isochrone(center: point(40.748, -73.993), time: 900, mode: "foot"));

Each query goes in the data field of one POST to https://plaza.fyi/api/v1/query, and GeoJSON comes back. LLMs are good at generating PlazaQL from natural language — give the agent one tool that accepts a query string and it can answer almost any spatial question.

Isochrones: “what’s within reach?”

When a user asks “What’s within a 15-minute walk?”, an isochrone gives you the exact reachable area as a polygon:

curl -X POST https://plaza.fyi/api/v1/isochrone \
  -H "x-api-key: pk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"geometry": {"type": "Point", "coordinates": [-73.993, 40.748]}, "time": 900, "mode": "foot"}'

time is in seconds and mode is auto, foot or bicycle. The agent gets back a GeoJSON polygon it can use to filter results, display on a map, or feed into the next query. Combine it with PlazaQL to find specific things within that reachable area.

Why this matters

The difference between a fixed list of endpoints and a query language over a planet-scale graph is the difference between an agent that can answer pre-defined questions and one that can reason about physical space.

An agent with Plaza can:

Compose multi-hop spatial queries — “Find cafes near subway stations in Manhattan” becomes a single query using variables and area resolution
Search along routes — route() computes a route, then .around(200, $r) finds things near it — no separate API calls
Filter by arbitrary attributes — OSM has millions of tags: cuisine=sushi, wheelchair=yes, opening_hours, height, building:levels
Use named areas as boundaries — Query by city, country, neighborhood, or any administrative boundary without knowing coordinates
Transform results inline — .buffer(), .sort(distance($r)), .limit() process geometry server-side before returning

MCP server

Plaza doesn’t have a published MCP server today. We’re rebuilding it, and there’s no date yet. Once it’s out, MCP-compatible agents will be able to geocode, route, search, and run PlazaQL queries without glue code.

You don’t need it to start. Give your agent plaza.fyi/llms.txt or the OpenAPI spec and it can call the REST API directly. The Use with AI guide shows how.

What Plaza doesn’t do

Plaza covers the spatial data layer — geometry, topology, routing, search. It doesn’t have real-time traffic, Street View imagery, or business reviews. If your agent needs to know whether a restaurant is currently busy, you’ll need another provider for that.

Get started

Grab an API key from plaza.fyi/dashboard (free tier, no credit card) and point your agent at llms.txt.

More: API reference · Use with AI

Plaza vs Mapbox

Sat, 28 Mar 2026 00:00:00 GMT

Mapbox makes good maps. If you need custom map rendering, their GL JS and Studio tools are best-in-class. The vector tile rendering, 3D terrain, and mobile SDKs are impressive engineering.

But if what you need is geospatial data — geocoding, routing, spatial queries, feeding location context to an AI agent — the comparison looks different. Here’s a direct breakdown.

Feature comparison

Feature	Plaza	Mapbox
Forward geocoding	Yes	Yes
Reverse geocoding	Yes	Yes
Autocomplete	Yes	Yes (part of geocoding)
Batch geocoding	Yes	No
Routing	Yes	Yes
Turn-by-turn data (steps, voice and banner instructions, lanes, exits)	Yes (Mapbox Directions response shape)	Yes
Live traffic	No (time-of-day profiles)	Yes
Isochrones	Yes	Yes
Distance matrix	Yes	Yes
Map matching	Yes	Yes
Route optimization	Yes (50 stops)	Yes (25 waypoints)
Full-text search	Yes	Limited (geocoding-based)
Elevation	Yes	Yes (Tilequery)
PlazaQL	Yes	No
Vector tiles	Yes	Yes (core product)
Custom datasets	Yes	Yes (Tilesets/Datasets API)
MCP server for AI	Not yet	No
Custom map styling	No (data API only)	Yes (Studio, GL JS)
Mobile map SDKs	No	Yes (iOS, Android, Flutter)
Static map images	No	Yes
3D terrain/buildings	No	Yes
Navigation SDK (on-device guidance)	No	Yes

Plaza covers more data and query capabilities. Mapbox covers more rendering, plus the client side of navigation. These are different products that overlap in the middle.

One thing worth noting: Plaza serves billions of geospatial features, the full OpenStreetMap planet plus curated open datasets, from a single API. That is how it offers PlazaQL and complex spatial queries alongside geocoding and routing. Most providers need multiple specialized services to cover the same feature set.

Pricing

Mapbox prices each API separately and offers generous free tiers per SKU. Plaza uses flat monthly plans with a single request pool.

Mapbox pricing (published rates)

Geocoding (v6): 100K free/mo, then ~$5/1K
Directions: 100K free/mo, then ~$5/1K
Matrix: 100K free elements/mo, then varies by volume
Isochrone: 100K free/mo, then ~$5/1K
Optimization: 100K free/mo, 25-waypoint limit
Map loads (GL JS): 50K free/mo, then $5/1K

Plaza pricing

Plan	Included requests	Price
Free	500 std/day + 50 premium/day	$0
Pro 100K	100,000/mo	$50/mo
Pro 300K	300,000/mo	$150/mo
Pro 1M	1,000,000/mo	$500/mo

Overage: $0.50/1K standard, $1.50/1K premium. Premium endpoints (routing, isochrone, distance matrix) carry a 4x multiplier against your included allocation.

Running the numbers

Scenario 1: 100K geocoding + 50K routing requests per month

Mapbox: Both within free tiers. $0/mo.
Plaza: 100K standard + 50K x 4 premium multiplier = 300K effective requests. Pro 300K plan. $150/mo.

At this volume, Mapbox’s per-SKU free tiers are hard to beat on price alone.

Scenario 2: 500K geocoding + 200K routing + 100K matrix per month

Mapbox: Past free tiers on all three SKUs. Geocoding: ~$2,000. Routing: ~$500. Matrix: varies, estimate ~$500-1,000. Roughly $2,500-3,500/mo.
Plaza: 500K + (200K x 4) + (100K x 4) = 1.7M effective requests. Pro 1M plan ($500) + 700K overage at blended rate. Roughly $850/mo.

The crossover happens around 200-300K total requests. Below that, Mapbox’s free tiers win. Above that, Plaza’s flat pricing pulls ahead, and the gap widens with volume.

Data rights

Plaza serves open data — OpenStreetMap (ODbL-licensed) plus curated open datasets — so you can cache results, display them on any map, and use them in AI pipelines. Mapbox uses proprietary data with restrictions: results must be displayed on Mapbox maps, caching is temporary only, and reuse in AI training or vector databases is not permitted.

	Plaza	Mapbox
Cache results permanently	Yes	Temporary only
Display on non-Mapbox maps	Yes	No (per ToS section 3)
Use in AI training data	Yes	No
Store in vector DB for RAG	Yes	No
Map renderer lock-in	None	GL JS required for map display

The display restriction catches people off guard. If you’re building with Leaflet, MapLibre, or no map at all, Mapbox’s terms create a contractual problem. Plaza has no renderer dependency.

AI readiness

There’s no MCP server right now. It’s being rebuilt, with no release date. Today, agents can read llms.txt or the OpenAPI spec and call the REST API to geocode addresses, find nearby points of interest, calculate routes, and run PlazaQL queries. Agents can cache and reuse results across sessions, which is how most RAG and agent architectures need to work.

Mapbox has no MCP server and no published AI agent tooling. If geospatial data is part of your AI stack, tooling and caching freedom matter as much as per-request pricing.

Where Mapbox wins

Mapbox is a map rendering company that also does data APIs. Plaza is a data API company that doesn’t do map rendering. That distinction matters.

Mapbox is the better choice when you need:

Custom map styling. Mapbox Studio is the best visual map design tool available. If your product’s value depends on how the map looks, this is a real advantage.
Mobile map SDKs. Native iOS, Android, and Flutter SDKs with offline support, gesture handling, and annotation systems. Plaza doesn’t ship mobile rendering SDKs.
GL JS for web maps. Despite the proprietary license change in v2, Mapbox GL JS remains a capable web map renderer with a large ecosystem.
3D terrain and building extrusion. If your app renders 3D cityscapes or terrain visualization, Mapbox has production-ready support.
Turn-by-turn navigation. The Mapbox Navigation SDK runs on the phone: it follows the GPS, speaks the instructions, re-routes and adjusts for live traffic. Plaza’s Directions API returns the navigation data (steps, instructions in 22 languages, voice and banner text, lanes, exit numbers, congestion) in the shape of a Mapbox Directions response, with snake_case names and unit suffixes (distance_m), so a Mapbox-style client ports over with little mapping. But you write the client yourself; Build a Turn-by-Turn Nav App shows how. Plaza’s congestion comes from time-of-day profiles, not live traffic, and there are no shield images or junction views.
Static map images. Server-generated map images for emails, PDFs, or social sharing.

If you’re building a consumer map application where the visual design of the map is central to the product, Mapbox is still the right tool.

Using both

Some teams use Mapbox for map rendering and Plaza for data queries. This works well when you want Mapbox’s visual layer but need flexible spatial queries, batch geocoding, or AI-ready data access that Mapbox doesn’t offer. Plaza returns standard GeoJSON, so results drop directly onto any map renderer, including Mapbox GL JS.

They’re not mutually exclusive.

Summary

Mapbox is a rendering-first platform with strong data APIs attached. Plaza is a data-first platform with no rendering layer. If you need custom map styling, a ready-made mobile navigation SDK, live traffic, or 3D terrain, go with Mapbox. If you need flexible geospatial queries, AI tooling, or lower costs at scale, go with Plaza.

Try it at plaza.fyi/dashboard. The free tier includes 500 standard requests/day + 50 premium requests/day for $0, no credit card required. The API reference covers every endpoint.

Plaza vs Google Maps

Thu, 26 Mar 2026 00:00:00 GMT

This isn’t an opinion piece. Here’s what each API does, what it costs, and where it’s better.

We put Plaza and Google Maps Platform side by side across every endpoint category and ran the pricing math at three different volumes. The results are below.

Feature comparison

Feature	Plaza	Google Maps
Forward geocoding	`/geocode`	Geocoding API
Reverse geocoding	`/geocode/reverse`	Geocoding API
Autocomplete	`/geocode/autocomplete`	Places Autocomplete
Batch geocoding	`/geocode/batch`	No (must loop single requests)
Routing / directions	`/route`	Directions API
Turn-by-turn instructions	`/route` with `steps`: 22 languages, voice and banner text, lanes, exits	Directions API steps
Isochrones	`/isochrone`	No
Distance matrix	`/matrix`	Distance Matrix API
Map matching	`/map-match`	Roads API
Route optimization	`/optimize` (up to 50 stops)	Routes API (waypoint optimization, 25 stops max)
Full-text search	`/search`	Places Text Search
Elevation	`/elevation`	Elevation API
PlazaQL	`/query`	No
Vector tiles	`/tiles/{z}/{x}/{y}`	Map Tiles API
Custom datasets	`/datasets`	No
MCP server for AI	Not yet	No
Street View	No	Yes
Real-time traffic	No (time-of-day profiles)	Yes
Business reviews/photos	No	Yes (Places API)
Transit directions	Scheduled, where a GTFS feed is loaded	Yes, with live delays

Plaza covers 15 of the 20 rows, plus scheduled transit where a feed is loaded. Google covers 15. The overlap is large, but each platform has exclusive capabilities the other lacks entirely.

Plaza’s exclusive features lean toward developer infrastructure: PlazaQL for arbitrary spatial queries, custom datasets, and tooling for AI agents. Everything runs behind one API, without the fleet of specialized services other providers require. Google’s exclusive features lean toward consumer-facing applications: Street View imagery, real-time traffic from billions of Android phones, business reviews and photos, and transit directions with live schedules.

Pricing comparison

Google Maps Platform bills per SKU. Each API call type has a separate price, and the costs add up across endpoints. Plaza uses flat monthly plans with included request allocations. Premium endpoints (routing, isochrone, distance matrix) count as 4x against your allocation.

Here’s the published pricing for the most common endpoints:

Endpoint type	Google Maps (per 1K)	Plaza standard (per 1K overage)	Plaza premium (per 1K overage)
Geocoding	$5.00	$0.50	—
Directions (basic)	$5.00–$10.00	—	$1.50
Directions (advanced)	$20.00	—	$1.50
Distance Matrix	$5.00–$10.00	—	$1.50
Places Nearby Search	$32.00	—	—
Places Text Search	$32.00	$0.50	—
Places Details	$17.00	$0.50	—
Elevation	$5.00	$0.50	—

Google offers a $200/month free credit. Plaza’s free tier gives you 500 standard requests/day + 50 premium requests/day for $0, no credit card required. Paid plans start at $50/month.

Scenario 1: 100K geocoding requests/month

Google: 100,000 x $5.00/1K = $500. Minus $200 credit = $300/mo.

Plaza: Pro 100K plan = $50/mo.

Scenario 2: 100K mixed requests (50K geocoding + 30K routing + 20K search)

Google: (50K x $5) + (30K x $10) + (20K x $32) = $250 + $300 + $640 = $1,190. Minus $200 credit = $990/mo.

Plaza: 50K standard + 30K premium (x4 = 120K effective) + 20K standard = 190K effective requests. Pro 300K plan = $150/mo.

Scenario 3: 1M geocoding requests/month

Google: 1,000,000 x $5.00/1K = $5,000. Minus $200 credit = $4,800/mo.

Plaza: Pro 1M plan = $500/mo.

At every volume we tested, Plaza costs between 6x and 10x less than Google Maps Platform for equivalent API calls. The gap widens with mixed workloads because Google’s most expensive SKUs (Places Search at $32/1K) have no equivalent premium multiplier on Plaza.

Data rights

Google’s Terms of Service prohibit caching API responses, storing results in your database, displaying data on non-Google maps, and using results in ML pipelines. Plaza is built on open data — OpenStreetMap (ODbL-licensed) plus curated open datasets — with none of these restrictions. Cache freely, store permanently, display anywhere.

	Plaza	Google Maps
Cache results	Yes	No (session-length only)
Store in your database	Yes	No
Display on non-Google maps	Yes	No
Use in AI training data	Yes	No
Store in vector DB for RAG	Yes	No
Bulk export	Yes	No

Developer experience

Plaza serves every endpoint from a single base URL (https://plaza.fyi/api/v1/) and returns GeoJSON for all responses. Google Maps Platform has separate base URLs, authentication schemes, and response formats for each API family. Geocoding returns one JSON structure, Places returns another, Directions returns a third.

Plaza publishes an OpenAPI spec for the whole API. The TypeScript, Python, and Go SDKs are being regenerated from that spec after the Stainless shutdown, so for now you call the REST API directly. The API reference has a request example for every endpoint. Google provides official client libraries for JavaScript, Android, and iOS, plus raw REST access for everything else.

Rate limits on Plaza scale with your plan: 10 req/min on Free, 300 on Pro 100K, 1,000 on Pro 300K, 2,000 on Pro 1M, and 10,000 on Enterprise. One number, applied uniformly. Google enforces per-API quotas with different limits per SKU, and the defaults vary by billing account age and history.

AI readiness

The MCP server is being rebuilt and has no release date. In the meantime, an agent given llms.txt can call geocoding, routing, search, and PlazaQL over REST. An LLM can write a PlazaQL query, run it against Plaza’s full dataset, and work with the results. Agents can cache and reuse results across sessions.

Google Maps Platform has no MCP server and no function-calling tooling. Every agent invocation is a fresh billable call with no ability to persist the result.

Where Google Maps wins

Google Maps Platform has real advantages that Plaza does not replicate.

Real-time traffic. Google collects live traffic data from billions of Android devices. Their ETAs in congested urban corridors are more accurate than any routing engine that relies on historical or static speed data. Plaza’s Directions API returns full navigation data (steps, instructions in 22 languages, voice and banner text, lanes, exit numbers, per-segment congestion), but its speeds and congestion come from time-of-day profiles for each road type, not from live traffic. If your product is a consumer navigation app where ETA accuracy in rush-hour traffic is the core feature, Google’s data moat is real.

Business listings. Google’s Places database includes business hours, user reviews, photos, price levels, and structured metadata for hundreds of millions of businesses worldwide. Plaza has extensive POI data from OpenStreetMap and other open sources, but it doesn’t have Yelp-style reviews or user-submitted photos. If your application needs “show me the 4-star Italian restaurants open right now with photos,” Google is the better data source.

Street View. Panoramic street-level imagery covering most of the world’s road network. Plaza has no imagery product.

Transit directions. Google aggregates real-time transit schedules from thousands of agencies globally. Their transit routing includes live delay information, transfers, and fare estimates. Plaza’s transit routing works from published GTFS timetables, and only where a feed for that agency is loaded. It handles transfers, arrive_by and wheelchair-accessible trips, but it has no live delays and no fares.

Mobile SDKs. Google’s Android and iOS SDKs are deeply integrated with native map rendering, gesture handling, and platform-specific optimizations built over more than a decade. Plaza has no mobile or navigation SDK. Its route responses carry what a nav screen needs, but following the GPS and re-routing is your code (here’s a walkthrough). If you’re building a mobile-first consumer maps experience, Google’s client-side SDK ecosystem is more mature.

If your product depends on any of these capabilities, Google Maps is still the right choice for those specific features. Many teams use both: Google for consumer-facing traffic and business data, Plaza for backend geocoding, spatial queries, and data pipelines where cost and flexibility matter most.

Get started

Plaza’s free tier includes 500 standard requests/day + 50 premium requests/day for $0, covers every endpoint in the table above, and requires no credit card.

Get your API key in 30 seconds.

PlazaQL: Query Geospatial Data Without the Overhead

Tue, 24 Mar 2026 00:00:00 GMT

If you’ve ever tried to pull specific geographic data from OpenStreetMap, you’ve probably hit infrastructure walls. The public overpass-api.de has aggressive rate limits, and self-hosting an Overpass instance means downloading 70GB+ and managing your own server. Neither option is fun when you just want location data in your app.

PlazaQL is Plaza’s query language for geospatial data. It lets you query billions of features — every pharmacy within 500 meters, all parks in a city, every bike shop with a repair stand — through a single HTTP endpoint that returns GeoJSON.

This article covers PlazaQL itself and how Plaza removes the infrastructure headache so you can query geospatial data with one POST request.

What PlazaQL is

PlazaQL is a read-only query language designed for geospatial data. It reads a bit like SQL for geographic places. You can query OpenStreetMap nodes, ways, and relations, Plaza-curated datasets, and your own custom data — all with the same syntax.

Features have tags and properties. An OpenStreetMap pharmacy is tagged amenity=pharmacy. A park is leisure=park. A vegan restaurant has amenity=restaurant plus diet:vegan=yes. PlazaQL lets you filter by any combination of tags or properties, apply geographic constraints like bounding boxes or radius searches, and return the results — whether the data comes from OSM, a curated dataset, or your own uploads.

The syntax is clean and readable. Once you see a few examples, you can pull almost any real-world geographic dataset you can think of.

What you can ask it

Plaza gives you direct access to billions of features — the full OpenStreetMap planet, curated open datasets, and any custom data you upload.

Google Maps and Mapbox expose curated POI data through their own APIs. You get what they decide to surface, in the format they choose, under their licensing terms. With PlazaQL, you query the raw data yourself. You can filter by obscure tags, combine conditions, mix data sources, and retrieve data that simply does not exist in commercial APIs.

A few examples of what you can do that you can’t easily do with a standard geocoding API:

Find every public drinking fountain in Berlin
List all ATMs that are wheelchair accessible within a city
Pull every road with a specific surface type for a cycling app
Get all buildings taller than 10 floors in a bounding box
Filter roads by computed length (length() > 1000)
Aggregate data — average building height by type, total restaurant capacity by neighborhood
Use expression filters with arithmetic on tag values (number(t["capacity"]) > 50)

PlazaQL is useful for data-heavy applications, urban planning tools, accessibility apps, and anything beyond “find a coffee shop near me.”

Running your own OSM query server is a chore

To query OSM data in production, you historically had two realistic options.

You can use the public Overpass API at overpass-api.de. It’s free, but it’s shared infrastructure. Rate limits kick in fast. Heavy queries get rejected. You can’t rely on it for anything user-facing because you have no SLA and no control over availability.

Or you run your own Overpass instance. This means downloading a full OSM planet file (over 70GB compressed), setting up the server, keeping the data synced, and managing the infrastructure yourself. It works, but it’s a lot of ops work before you’ve written a single line of application code.

Neither option is a good fit if you’re a developer who just wants to query geographic data and ship something.

One endpoint for PlazaQL

Plaza is a geospatial data API that handles all of this for you. It supports geocoding, reverse geocoding, routing, and POI search. But PlazaQL support is probably the most relevant part if you want raw query power.

You send your PlazaQL query to POST /api/v1/query in the data field of a JSON body. Plaza runs it against its full dataset — OpenStreetMap, curated sources, and any custom data you’ve uploaded — and returns a GeoJSON FeatureCollection. No infrastructure to manage, no caching restrictions.

For large result sets, add format=geojson or format=ndjson and Plaza streams the response, so your client can process features as they arrive.

How it works

You make a standard HTTP request to the Plaza API with your PlazaQL query in the data field of a JSON body. Plaza handles the query execution and returns the response. No special client library required — if you can make an HTTP request, you can use Plaza.

Examples

Some real examples using cURL. All of these work against the Plaza endpoint and return GeoJSON.

Pharmacies near a coordinate

This query finds every pharmacy within 500 meters of a point in central Paris.

curl -X POST "https://plaza.fyi/api/v1/query" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": "search(node, amenity: \"pharmacy\").around(500, point(48.8566, 2.3522));"
  }'

You get back a GeoJSON FeatureCollection with each pharmacy as a feature, including its name, address tags, and coordinates.

Parks in London

This query finds every park in the City of London by looking up the area by name — no coordinates needed.

curl -X POST "https://plaza.fyi/api/v1/query" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": "search(way, leisure: \"park\").within(boundary(name: \"City of London\"));"
  }'

PlazaQL returns the full geometry of each way, so you get polygon outlines for the parks, not just centroid points. Useful if you’re rendering them on a map or doing area calculations.

Cafes with outdoor seating

This one combines two tag conditions to find cafes with outdoor seating across all of Paris.

curl -X POST "https://plaza.fyi/api/v1/query" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": "search(node, amenity: \"cafe\", outdoor_seating: \"yes\").within(boundary(name: \"Paris\"));"
  }'

You can’t do this through the Mapbox geocoding API or Google Places. You’re querying raw tags, which means you can filter on any attribute in the dataset.

PlazaQL and AI agents

If you build LLM-powered tools, PlazaQL has a useful property: it is structured enough for a model to generate and expressive enough to handle queries that no pre-built API category system covers.

When you give a Google Places API to an LLM agent, the agent picks from predefined categories — “restaurant,” “hospital,” “gas_station.” That works for common searches. But what happens when the query is “find all buildings with solar panels within 1km of this school” or “show me every road segment with a speed limit under 30km/h in this neighborhood”? Google’s category system has no answer.

An LLM can generate PlazaQL for those queries directly:

User prompt: “Find all wheelchair-accessible ATMs in Berlin”

LLM-generated PlazaQL:

search(node, amenity: "atm", wheelchair: "yes")
  .within(boundary(name: "Berlin"));

User prompt: “Show me every building taller than 10 floors near Times Square”

LLM-generated PlazaQL:

$ts = search(node, name: "Times Square", place: "square");
search(way, building: *)
  .around(500, $ts)
  .filter(is_number(t["building:levels"]) && number(t["building:levels"]) >= 10);

Expression filters let the LLM do numeric comparisons on tag values — something regex hacks can’t handle cleanly.

User prompt: “Find a pharmacy on my way to work”

LLM-generated PlazaQL:

$r = route(origin: point(40.748, -73.993), destination: point(40.755, -73.970));
search(node, amenity: "pharmacy").around(200, $r).sort(distance($r));

That last one computes a route, finds pharmacies within 200m of it, and sorts by distance — all in a single query. With traditional APIs, that’s 3 separate calls across 2 different services.

User prompt: “What’s the average restaurant capacity by cuisine in Manhattan?”

LLM-generated PlazaQL:

search(node, amenity: "restaurant")
  .within(boundary(name: "Manhattan"))
  .filter(is_number(t["capacity"]))
  .group_by(t["cuisine"])
  .avg(number(t["capacity"]));

Aggregation queries skip GeoJSON and return a small JSON object. This one comes back as {"groups": {"italian": 62.5, "japanese": 41.0, ...}, "total": 2}, with one average per cuisine. Without .group_by(), a .sum(), .avg(), .min() or .max() returns {"value": n}. The LLM gets the answer in one call.

Send any of these in the data field of a POST /api/v1/query request and you get back GeoJSON (or the aggregate object above). The LLM doesn’t need to know what categories exist ahead of time. It writes the query based on the tag system, which covers millions of attribute combinations.

If you’re building an AI agent that needs flexible geospatial queries, point it at this endpoint. We’re rebuilding the MCP server, with no release date. Until it ships, an agent can call the query endpoint directly.

Plaza vs Mapbox

Mapbox is a solid product. The map rendering and geocoding work well. But pricing scales quickly, you can’t freely cache and store results, and you’re limited to the POI data Mapbox chooses to expose.

If you’re building something that needs flexible geographic queries, open data access, or lower per-request cost at scale, Plaza is worth evaluating. PlazaQL alone covers use cases that Mapbox simply does not offer. Plaza has no caching restrictions — store query results in your own database, build offline-capable features, whatever you need.

Try it free — no credit card needed.

FAQs

What is PlazaQL used for? PlazaQL is a query language for geospatial data. Developers use it to retrieve geographic features filtered by tags and properties — finding all hospitals in a city, all bike lanes in a bounding box, or all restaurants with a specific cuisine type. It works across OpenStreetMap data, Plaza-curated datasets, and custom uploads.

Do I need to run my own server to query geospatial data? Not if you use Plaza. Plaza exposes a hosted PlazaQL endpoint so you can send queries directly via HTTP and get GeoJSON back without managing any infrastructure.

How is Plaza different from the public Overpass API? The public Overpass API at overpass-api.de is shared infrastructure with rate limits and no SLA. Plaza is a managed API with consistent availability, a cleaner query language, and no caching restrictions on the data you retrieve.

Is Plaza a good Mapbox alternative for geocoding? Yes. Plaza supports geocoding, reverse geocoding, routing, and POI search alongside PlazaQL queries, all through one unified API at https://plaza.fyi/api/v1/. It’s designed as a drop-in replacement for Mapbox or Google Maps at a lower cost.

Can I use PlazaQL with LLM agents? Yes. LLMs can generate PlazaQL from natural language prompts, which makes it a good fit for AI tool use and function calling. There’s no MCP server yet, so agents call the query endpoint over REST for now.

Can I cache Plaza results for RAG or training data? Yes. You can cache, store, and reuse query results in vector databases, training pipelines, or any other system. OpenStreetMap data is open (ODbL), and other datasets carry their own license terms.

Can I use Plaza for commercial projects? Yes. Plaza is built for production use. Check plaza.fyi/pricing for current pricing tiers.

What response formats does Plaza support? Endpoints that return feature lists take a format parameter: json (default), geojson, csv, and ndjson. The PlazaQL endpoint returns a GeoJSON FeatureCollection for feature results, and a small JSON object for counts and aggregates. See Streaming & Response Formats for details.

Is the data accurate enough for production apps? OpenStreetMap data quality varies by region but is generally strong in urban areas and improving globally. Plaza also curates additional open datasets to fill gaps. For many use cases — especially those requiring tag-level specificity — open data covers things that commercial datasets do not.

Introducing Plaza

Fri, 20 Mar 2026 00:00:00 GMT

The geospatial API market has a problem. If you’ve built anything that touches maps, geocoding, or routing, you already know what I’m talking about.

Google Maps charges obscene prices and increases them without warning. A startup with moderate geocoding traffic can easily face a five-figure monthly bill. Their pricing model punishes growth — the more successful your product, the more they take. And they know you’re locked in.

Mapbox offers better pricing but wraps everything in restrictive licensing. Want to cache results? Want to use the data in ways they didn’t anticipate? Their licensing terms add friction for common use cases. Licensing shouldn’t slow down a simple integration.

Geocode.earth is a step in the right direction with its open-data philosophy, but the feature set is limited. Need routing? Isochrones? Batch geocoding? You’ll be stitching together multiple providers and maintaining glue code forever.

None of these meet developers where they are.

What is Plaza?

Plaza is a full-featured geospatial data API. The full OpenStreetMap planet, curated open datasets, and your own custom data — all behind a single API with consistent conventions and honest pricing. Geocoding, reverse geocoding, routing, isochrones, distance matrices, map matching, route optimization, search, and more.

We’re not just wrapping existing open-source tools and calling it a day. We built the query engine ourselves so billions of geographic features come back with sub-50ms response times. It’s the reason Plaza can serve all its data sources through a single API without the fleet of specialized services that other providers need.

There’s no MCP server yet. We’re rebuilding it and have no date, so agents call the REST API directly for now. You can cache results, store them in vector databases, and use them in AI pipelines without restrictions.

Why now?

A few things lined up to make this the right time:

Open data has matured. OpenStreetMap’s coverage and quality have improved enormously over the past decade, and governments and organizations are publishing more geospatial data than ever. The data foundation is there.

Infrastructure costs have dropped. What would have required a warehouse of servers ten years ago now runs on modern cloud infrastructure. We can offer performance that competes with Google at a fraction of the cost because the economics are different now.

Developer expectations have changed. Developers expect APIs that are well-documented, predictable, and fair. SDKs that work, error messages that help, and pricing that doesn’t require a spreadsheet to understand.

AI needs a geospatial layer. Every LLM-powered agent that interacts with the physical world needs to geocode, route, search, and answer spatial questions. But the APIs they’re calling weren’t built for this. Self-hosting OSM is operationally complex, and most commercial APIs restrict caching. We built a geospatial API that’s fast, cacheable, and designed for AI workflows from day one.

The backstory

I’ve been working with geospatial and civic data for over a decade. I previously founded Stae, where we built open data platforms for local governments — helping cities like Atlanta and Jersey City standardize, share, and actually use their infrastructure data. Before that, I started the Code for Phoenix civic tech brigade, where 30+ engineers volunteered to make municipal data accessible.

At Stae, I saw firsthand how fragmented the geospatial data ecosystem is. Cities were paying steep licensing fees for basic geocoding. Developers building civic tools were priced out by Google’s API costs. Open-source alternatives existed but were fragmented and hard to operate at scale.

After Stae, I spent time at Apple working on AI and security. Building systems at that scale changed how I think about infrastructure, performance, and what’s possible when you invest in doing things right.

Plaza is the product of all of these experiences. It’s what I wished existed every time I saw a city, a startup, or an independent developer get locked into a mapping API they couldn’t afford to leave.

What we believe

Geospatial data should be accessible. No lock-in, no surprises.
Pricing should be honest. Predictable, designed so that your success doesn’t become your biggest expense.
Developer experience matters. Clear docs, a published OpenAPI spec, TypeScript, Python, and Go SDKs being regenerated after the Stainless shutdown, and an API that behaves the way you’d expect.
Performance is not optional. Fast by default, not “fast for an open-source alternative.”
AI should understand the real world. Geospatial data for agents should be fast, cacheable, and affordable — not priced to make AI applications unviable.

Try it

Plaza is live today. Create an account, grab an API key, and start building. Check out our getting started guide or jump straight into the API reference.

We’re just getting started. If you have questions, ideas, or just want to say hi — reach out.