A critical guide to what is actually broken, inconsistent, or quietly wrong in the Modern Places API ecosystem in 2026, with supporting data tables per section and the practical workarounds developers are being forced to adopt.
Commercial Places APIs remain among the most heavily consumed data services on the public internet. They are also, in 2026, among the single largest sources of production discrepancies for developers who build anything location-aware. The problems are no longer limited to the fake-and-phantom category that dominated the 2019 to 2023 conversation. They now extend into geocoding drift, operating-hour staleness, inconsistent place-ID behaviour, inconsistent category tagging, legacy-versus-new API field mismatches, outage-induced data gaps, and the ongoing cost pressure of deprecation cycles that have pushed many teams into forced migrations that break their caches, their filters, and their integration tests.
This is a different kind of criticism than the phantom-listing problem. Phantoms are entries that should not exist. Discrepancies are entries that do exist, but describe reality incorrectly. Both are failure modes. The second one is quieter, more widespread, and more structurally baked into the architecture most large POI providers have chosen.
The Four Faces of Incorrectness
A single Place record returned by a typical commercial Places API carries anywhere from twenty to forty fields across its standard, contact, and atmosphere tiers. Any of those fields can be wrong in a way that still produces a syntactically valid API response. In 2026 the mistakes cluster into four broad families.
| Family | What Breaks | Who Notices First |
|---|---|---|
| Spatial incorrectness | Latitude-longitude coordinates, viewport, and spatial codes point to the wrong physical spot | Delivery drivers, ride-hail passengers, field service techs |
| Temporal incorrectness | Opening hours, current-hours, and operational-status fields lag reality | Last-minute customers, same-day delivery apps |
| Attribute incorrectness | Name, categories, phone, and website fields reflect stale or wrong metadata | Marketplaces, aggregators, voice assistants |
| Identity incorrectness | The persistent place identifier for the same physical place changes, duplicates, or does not resolve | Caching layers, analytics, long-lived integrations |
Table 1. Four families of incorrectness that developers encounter in commercial Places APIs in 2026.
Sources: public developer documentation of major POI providers; community issue trackers; independent operator reports.
Each family has its own detection difficulty, its own blast radius, and its own set of workarounds. A fifth category, availability incorrectness, covers the periods when the API itself is degraded. More on that below.
Spatial Incorrectness: When the Pin Is in the Wrong Place
The field that developers trust most is the one most likely to quietly betray them. Coordinate pairs are returned with six decimal places of precision, implying centimetre-level accuracy. The actual accuracy varies by country, by urban density, and by how the record was ingested. For a storefront in central London, the pin is typically correct within ten metres. For a residential address in a tier-three Indian city, a rural compound in Southeast Asia, or a strip mall in suburban Texas, the pin may be off by anywhere from fifty metres to half a kilometre, and in rare cases it may land on the wrong side of a highway, river, or international border.
| Pin Error Pattern | Typical Cause | Observed Impact |
|---|---|---|
| Pin on the street in front of the building | Default geocoder behaviour for parcels without rooftop match | Rider drops the parcel at the wrong gate |
| Pin on the nearest named road | Interpolation between address ranges | Driver circles the block |
| Pin on the building rooftop but wrong unit | No sub-building granularity in the API | High-rise package goes to the wrong lobby |
| Pin in a different country or state | Toponym collision with another same-named place | Order marked lost or re-routed internationally |
| Pin shifted by cadastral update | Local land-registry change not yet reflected | API says “address not found” |
Table 2. Spatial incorrectness patterns in commercial Places APIs and the operational outcomes.
Sources: OpenStreetMap community help thread on wrong-location routing; last-mile operator case studies.
A particular 2026 edge case is worth flagging. Many geocoding responses carry a confidence or precision tag with values like ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER, and APPROXIMATE. The companion Places surface does not always expose the same confidence signal consistently. A geometric-centre response for a large shopping centre may put the pin at the dead middle of the complex, hundreds of metres from any actual storefront. The developer cannot easily tell from the response whether the pin is high confidence or low confidence.
Temporal Incorrectness: Hours That Are Not Really the Hours
Every developer who has built a food-delivery or restaurant-discovery app has had the same bug report: “The app said they were open and they were not.” The opening-hours fields in a Places API are only as fresh as the latest signal from the business owner, a crowdsourced contributor, or the provider’s own crawlers. In practice, they lag reality.
| Hours Discrepancy Type | How It Appears in the API | Typical Lag |
|---|---|---|
| Closed-but-API-says-open | open_now = true while the storefront is dark | Days to weeks after a change |
| Open-but-API-says-closed | open_now = false because of a one-time holiday never cleared | Weeks to months |
| Wrong day-of-week | Weekend hours applied on weekdays | Variable; often from owner error |
| Seasonal hours not switched | Summer hours still showing in December | Up to a full season |
| Public holiday variance | Special-day features miss local observances | Country and city specific |
| Timezone-boundary edge cases | DST transitions or cross-border locations | Twice a year, episodic |
Table 3. Temporal incorrectness patterns in commercial Places API opening-hours surfaces.
Sources: PinMeto on updating business hours across major map providers; OpenStreetMap community thread on persistent incorrect business hours.
The developer-facing problem is that even when the API returns a derived current-hours field, it is a view based on the same base data. If the owner updated opening hours three days ago, those changes may still be propagating through the provider’s internal pipelines. The last-updated timestamp usually exists in the provider’s business-profile system but is rarely exposed through the Places API response itself.
Attribute Incorrectness: Wrong Names, Wrong Types, Wrong Categories
Beyond coordinates and hours, every other attribute on a Place record is subject to drift. In 2026, developer forums record a steady stream of complaints about four specific patterns.
The first is name drift. A restaurant renames itself after a rebrand or ownership change, and the new name does not propagate to the API for weeks. The second is phone-number drift, where VoIP forwarding changes behind a stable public number cause the API’s phone field to point to a different operator than the business the user is trying to reach. The third is website drift: a business migrates from a social-media page to a dedicated domain, and the API’s website field continues to point to the old URL for months. The fourth, and most operationally damaging, is category drift. Place-type taxonomies have grown to over a hundred values and are updated periodically. A business that was tagged “restaurant” in 2022 may now be returning “restaurant, meal_takeaway, meal_delivery”, with the new types silently expanding search surface area in ways that break downstream filtering.
| Attribute | Observed Drift Behaviour | Downstream Breakage |
|---|---|---|
| Name | Stale after rebranding, M&A, franchise changeover | Search mismatch, voice-assistant confusion |
| Types / categories | Taxonomy updates re-categorize existing records | Over-broad or under-broad category filters |
| Phone number | VoIP forwarding changes invisibly | Calls routed to wrong operator |
| Website | Lingers after domain migration | Dead links in discovery UI |
| Editorial summary | Can be absent, stale, or AI-generated and generic | Weak quality signal for ranking |
| Price level | Rarely updated after initial tagging | Wrong tier in budget-filtered searches |
Table 4. Attribute drift patterns in commercial Places APIs and their downstream effects. Sources: Drupal Geolocation issue tracker on API data population; independent developer-community observations.
Identity Incorrectness: The Persistent-ID Problem
The field developers rely on the most for durable integration is the persistent place identifier. Provider documentation typically says it uniquely identifies a place and should be stored for long-term reference. In 2026, three failure modes break that promise in practice.
First, a single physical business may have multiple persistent-ID values at different points in time, especially after the provider merges duplicate listings, splits an incorrectly merged pair, or re-ingests a record from a fresh data feed. The old ID may still resolve, may be redirected, or may return a not-found error.
Second, the same ID may silently point to a different physical place after a provider-side correction. The developer’s cached record is now wrong, but the API gives no signal that the underlying referent has shifted.
Third, the behaviour differs between legacy and current API versions, creating subtle breakage during migration windows.
| ID Failure | How It Manifests | Caching Impact |
|---|---|---|
| Duplicate IDs for one place | Two live IDs resolving to the same business | Analytics double-counts; dedup pipeline required |
| ID retired after merge or split | Not-found on previously stable ID | Broken bookmarks, dead integration links |
| ID silently repointed | Cached fields no longer match live record | Data pipelines serve stale enrichments |
| ID differs between legacy and new API | Same business returns different IDs on each endpoint | Cross-endpoint joins fail silently |
| ID format change over time | Old format IDs may still work but are not documented | Hard-to-debug intermittent failures |
Table 5. Persistent-ID failure modes in commercial Places APIs.
Sources: provider documentation; community issue trackers; status-dashboard incident reports.
Most providers document that a persistent ID can occasionally change, and recommend refreshing stored IDs periodically. In practice, no production system refreshes every stored ID on every read. The result is a long tail of silently-stale integration references that only surface during audits or user complaints.
The Deprecation Treadmill: Legacy vs New API Versions
A separate class of discrepancy in 2026 comes not from the data but from the API itself. Most major Places providers have moved to a next-generation API in the last eighteen months and designated the previous surface as legacy. The two surfaces are not functionally identical. Field names differ, pagination differs, pricing differs, authentication differs, and some response fields have been quietly dropped or renamed.
| Dimension | Legacy Places API | Current / New Places API |
|---|---|---|
| Status (as of 2026) | Frozen, in use by many existing apps | Current recommended API |
| Field naming | snake_case (e.g., formatted_address) | mixedCase (e.g., formattedAddress) |
| Pagination | next_page_token with short-lived server state | Explicit pageToken and pageSize |
| Pricing | Per-call, long-standing SKUs | New per-SKU pricing with field masking required |
| EU terms (as of mid-2025) | Separate EEA Terms of Service often apply | Same EEA Terms, re-stated |
| Field availability | Some legacy fields removed in new API | Some new-API fields never existed in legacy |
Table 6. Common differences between legacy and current-generation Places APIs across major providers.
Sources: Mapatlas blog on legacy API freeze for EU developers; Drupal Geolocation issue tracker on deprecated services still in use; Outscraper Places API Complete Guide (2026).
Migration-driven discrepancies are now common. A field that was reliably populated in legacy may be empty under field-masking rules in the new version if the developer forgets to request it. A persistent ID returned from the legacy endpoint may not resolve identically on the new endpoint. Community forums have active threads from 2026 chronicling production breakage caused by migration mismatches.
Availability Incorrectness: When the API Itself Degrades
Sometimes the discrepancy is not in the data but in whether the data is available at all. Provider status dashboards record a steady cadence of Places API incidents, ranging from elevated error rates to partial outages that affect specific regions or specific endpoints. During these windows, the API may return incomplete fields, empty result sets, or 500-class errors that developers have to catch and route around.
| Incident Type | What Happens | Developer Defence |
|---|---|---|
| Elevated error rate | Random 5xx responses on otherwise valid requests | Exponential backoff and retry |
| Regional degradation | Specific geographies return partial data | Multi-region fallback or secondary source |
| Field truncation | Expected fields missing from otherwise-200 responses | Explicit null-checking on every field |
| Autocomplete lag | Suggestions arrive after user keystroke latency budget | Local prefix cache for common queries |
| Quota and billing anomalies | Charges or quotas appear misreported during incidents | Daily reconciliation against cloud billing |
Table 7. Availability-side discrepancies tracked on commercial Places API status dashboards.
Sources: public provider status pages; developer-community incident reports.
The practical implication is that any production system reading from a Places API needs to treat it as eventually-available rather than always-available, and to design its retry and fallback paths accordingly.
The Cost of Incorrectness
Discrepancies carry real costs. A food delivery dispatched to the wrong pin may cost the operator USD 3 to USD 8 depending on local labour rates. A ride-hail trip routed through a stale geocode may cost minutes and fuel. A B2B courier run to a closed receiver may burn a full driver stop with no revenue to offset it. At scale, the compounded cost of location-data discrepancies is one of the quiet variables that separates logistics operators who hit their margin targets from those who do not.
| Discrepancy Type | Typical Per-Incident Cost | Scaling Factor |
|---|---|---|
| Wrong pin, consumer food delivery | USD 3 to 8 | Multiplied by failure rate across all orders |
| Wrong pin, B2B courier | USD 10 to 30 | High-value shipments, re-attempt required |
| Closed restaurant served as open | USD 1 to 3 | Lost conversion, no revenue |
| Closed receiver, B2B logistics | USD 20 to 100 | Entire stop wasted |
| Phone-number drift, voice assistant | Variable | Erosion of trust in assistant |
| Category drift, aggregator search | Variable | Loss of search relevance, user churn |
| Migration-induced regression | High fixed cost | Engineering time to detect and patch |
Table 8. Estimated per-incident cost of common commercial Places API discrepancies.
Sources: industry consolidation of operator case studies and public last-mile cost benchmarks.
Developer Workarounds That Actually Reduce Discrepancies
Providers typically give developers a handful of levers. Developers who treat them seriously are able to reduce the operational cost of discrepancy by a meaningful margin. The list below is ordered from easiest to hardest.
| Workaround | Problem Addressed | Implementation Effort |
|---|---|---|
| Request a business-status field and treat absent as suspect | Closed-business false positives | Trivial |
| Use current-day opening hours instead of static weekly hours where available | Day-specific hour corrections | Low |
| Request a secondary spatial key such as a plus-code alongside the lat-lng | Pin drift and timezone edge cases | Low |
| Refresh stored persistent IDs on a rolling cadence | Identity drift | Medium |
| Explicitly set field masks under the new API and audit which fields come back populated | Attribute drift and migration gaps | Medium |
| Instrument retry logic with jittered backoff and per-region fallback | Availability degradation | Medium |
| Add a confidence filter on review count and recency | Low-signal, high-drift records | Medium |
| Cross-validate critical addresses against a second POI or geocoding source | Spatial, attribute, and identity drift together | High |
| Build an in-house correction layer with user-reported fixes | All of the above | High |
Table 9. Practical developer workarounds for commercial Places API discrepancies.
Sources: consolidated from provider documentation, support resources, and developer community practice.
For most consumer applications, workarounds one through five remove the majority of the pain. For enterprise logistics, dispatch, and anything where a bad address becomes a billable incident, the full stack is non-negotiable.
The Structural Problem
The fairest critique of large commercial Places APIs is that most of their discrepancies are not failures of execution but consequences of their ingestion models. An index built from self-service claims, user contributions, third-party feeds, and algorithmic inference will always carry a background rate of staleness, drift, and incorrectness proportional to how open each of those pipelines is. Providers have invested heavily in machine learning to catch bad data at ingestion, in reporting flows to catch it after the fact, and in versioned APIs to improve the surface over time. None of those investments eliminate the underlying tradeoff. A corpus that is cheap to enter is a corpus that will contain errors.
Developers who treat a commercial Places API as a definitive source of truth for anything high-stakes will keep paying for that assumption. Developers who treat it as a high-coverage, medium-confidence feed that needs filtering, cross-checking, and reconciliation will get much more value from it. The 2026 state of the art is not to abandon the major providers. It is to use them honestly, acknowledging where the index is strong and where it is not, and to layer the right defences on top.
| Issue | 2026 Status | Developer Posture |
|---|---|---|
| Spatial incorrectness (wrong pin) | Common, especially outside dense Western metros | Treat as approximate; use secondary spatial key; cross-check |
| Temporal incorrectness (hours stale) | Common; often weeks behind reality | Fall back to open-now plus owner-provided feed |
| Attribute drift (name, phone, website) | Steady background rate | Refresh periodically; verify at checkout |
| Identity drift (persistent-ID instability) | Documented, under-communicated | Refresh IDs; store multiple keys |
| Legacy vs new API gaps | Active migration cycle | Field-mask explicitly; audit regressions |
| Availability degradation | Regular minor incidents | Retry, backoff, fallback source |
| Overall accuracy trajectory | Improving on fakes, mixed on drift | Monitor, measure, and complain when wrong |
Table 10. The commercial Places API discrepancy landscape in 2026 at a glance.
Sources as cited in each table above.
Sources and Credits
- Mapatlas. The legacy Places API freeze: what EU developers should know. mapatlas.eu
- Outscraper. Places API: Complete Guide (2026). outscraper.com
- PinMeto. How to update business hours across major map providers. pinmeto.com
- Sterling Sky. Why is my business profile temporarily closed? sterlingsky.ca
- Drupal community. Places API filled inaccurately. drupal.org
- Drupal community. Deprecated PlacesService and AutocompleteService APIs still in use. drupal.org
- OpenStreetMap community. Business hours keep displaying incorrect information. community.openstreetmap.org
- OpenStreetMap community help. The address is correct but the map takes you to the wrong location. help.openstreetmap.org
- Popular Science. How to report errors in major digital maps. popsci.com
- Independent operator and developer community case studies, consolidated from last-mile logistics forums, provider status dashboards, and public issue trackers.
Disclaimer:
Data compiled from independent industry reporting, developer-community forums, operator case studies, and public status-dashboard archives. Where estimates differ across sources, the most recently published figure has been used. Terminology such as “legacy” and “new” Places API reflects the current industry naming conventions used by multiple major providers.