Open Places API A narrow public contract
The launch API is one documented endpoint, GET /v1/places, with a public OpenAPI 3.1
contract, stable error envelopes, and server-side bearer authentication.
About
Built for teams that need places, not maps-platform gravity.
Open Places API exists because a lot of products only need one thing: search for places near a coordinate and get structured JSON back. They do not need a full map platform, a surprise usage bill, or a data pipeline to keep open POI data searchable.
The working thesis.
Place search should not force every small team into the same broad maps-platform contract. If your app already has a latitude and longitude, a nearby search endpoint should be boring: authenticate from your backend, send the query, enforce quota, return JSON, and stop cleanly at the cap.
That is the shape Open Places API is built around. It uses open Overture Places data as the base layer, serves a selected production index, and leaves out the features that make broader platforms broader: tiles, routing, address autocomplete, mobile SDKs, reviews, photos, and open-ended usage billing.
What the service is accountable for.
Open-data foundations
The base index is built from Overture Places data, then processed into production search coverage with validation before a release is promoted.
Hard-capped pricing
Self-serve plans stop at their monthly quota instead of rolling into overages. Quota exhaustion is an API response, not an invoice surprise.
Clear limits
The API is proximity search only. It is not geocoding, address autocomplete, routing, map tiles, a browser SDK, or a full replacement for Google Maps Platform.
How trust should work.
For a developer API, trust should be practical. The service publishes docs, examples, an OpenAPI contract, coverage pages, price tables, release notes, terms, privacy policy, and support channels so teams can inspect the product before depending on it.
The origin is straightforward: Open Places API came from repeatedly running into the same pattern while building maps and places features. The data was useful, the APIs were broad, and the billing model was often more stressful than the feature deserved.
Contact.
For product or support questions, email support@openplacesapi.com. For privacy requests, email privacy@openplacesapi.com.