Can you store Places API results? Every caching policy, compared

Short answer: with most places APIs, no — you’re renting the answers, not buying them. The table below is what each provider’s current terms actually let you keep from a place-search response, verified against official policy pages in August 2026.

If you’re building anything with memory — a store locator, a directory, a lead list, an agent that remembers what it found — that column is the spec that decides your architecture. The rest of this post walks the receipts.

The fine print, provider by provider

Google Places API (New). The Places policies allow exactly one thing to be stored indefinitely: the place ID. Latitude/longitude may be cached for up to 30 days. Everything you’d actually show a user — display name, formatted address, rating, photos — has no caching exception in the service terms, which means every render is another billable call. This is why Google Places pricing compounds: you can’t amortize a result you’re not allowed to keep.

Mapbox Search Box. The API docs state results are available for temporary use only; storing search results requires a sales contract. Mapbox does sell a Permanent Geocoding product ($5.00 per 1,000 requests, no free tier), but it covers addresses, not POI search — it is not a path to keeping Search Box place results.

Foursquare. Under the current usage guidelines, pay-as-you-go accounts may cache fsq_place_id, photo IDs, and address IDs indefinitely — and nothing else. Names, categories, hours, and ratings stay on Foursquare’s side of the meter. (Their open dataset, FSQ OS Places, is the deliberate exception: Apache 2.0, yours to keep, but a flat file you host and query yourself, not an API.)

Radar. The terms of service prohibit caching or storing address and POI data from the geocoding, autocomplete, and search APIs for more than 30 days — and separately prohibit using the APIs to build a database of addresses or POIs at all. Radar’s 100,000 free monthly calls are genuinely generous; a directory or lead list built on them isn’t a permitted use, at any retention window.

HERE. Standard platform terms cap retention of search results at 30 days, and permanent geocoding rights are excluded from the self-serve Base plan.

LocationIQ. The pricing page splits the question in two: response data may be stored, but caching complete request–response pairs — keeping a stored response around to answer the same query again — is capped at 48 hours on the free tier and runs while a paid subscription stays active. Built on OpenStreetMap, it’s one of the friendlier postures on this list; the free tier requires a “Search by LocationIQ” attribution link.

Geoapify. Credit where due: Geoapify is the other provider built on open data, and their Places API page says plainly that you may cache, store, and redistribute results without additional limits. The constraints are attribution — OpenStreetMap credit always, plus “Powered by Geoapify” on the free plan — and a plan ladder that jumps from the free tier straight to €49/month.

AWS deserves a footnote because it prices the distinction explicitly: Amazon Location Service bills any request made with intendedUse=Stored in its most expensive pricing bucket — storage rights are the premium SKU, not a default.

Why the big free tiers aren’t what they look like

Ranked by free monthly volume, several providers beat anyone’s paid entry tier: LocationIQ offers about 150,000 requests a month, Radar 100,000, Geoapify around 90,000. But volume and retention are a trade. Where the terms allow no storage at all — Google, Mapbox, Foursquare — a café that hasn’t moved since your last deploy still costs a fresh API call every time a user opens the page. Where they allow 30 days, you re-buy your entire dataset every month, and Radar’s terms rule out building a place database in the first place. The tiers are big because the meter is designed to keep running.

Flip the model and the arithmetic inverts. When results are storable, a places API stops being a per-render tax and becomes a data acquisition pipeline: search once, write the result to your own database, serve it from there at zero marginal cost, and re-query only when you want fresher data. A modest quota of storable searches builds a permanent asset; an enormous quota of 30-day results builds a treadmill.

What this means if you’re building on places data

Three questions to ask before you pick a provider, in order:

1. Does my product remember places? Store locators, directories, market analyses, CRM enrichment, AI agents with memory — if yes, a no-storage ToS isn’t a pricing problem, it’s an architecture veto. Retrofitting compliance later means deleting your own tables.
2. What does steady state cost? Price the second year, not the first month. With storable results most of your traffic migrates to your own database; with rental terms your bill tracks your page views indefinitely. The cost calculator makes the rental math concrete.
3. Is the cap hard? Storage rights protect your data; a hard quota cap protects your bill. Google Maps Platform has no spending ceiling — budgets alert, they don’t stop.

Open Places API exists because of question one: it serves open Overture data, so the results are yours to cache, store, and ship — on every plan, including the free tier, with a hard cap and no card required. The full posture, with license details per source, is on the data rights page.

Not legal advice; vendor terms change. Every claim above links to the official page it came from — verify before you commit an architecture to it.