Geoapify published a walkthrough of building GDPR-compliant applications on maps, geocoding and routing APIs that spends most of its length arguing against the easy sale. “A GDPR-compliant location application is built from compliant data flows, not from one API setting.” They offer an EU-focused endpoint at api-eu.geoapify.com alongside the default api.geoapify.com, and rather than positioning it as a compliance switch they scope it precisely: it covers service-side processing, and “it does not guarantee the geographical route traffic takes across the public Internet.” The recommendation is to stay on the default and move only when EU service-side processing is contractually required.
Vendor content that shrinks its own differentiator is worth reading closely, and the substance holds up. The subprocessor chain is named rather than gestured at — Cloudflare on the global default, BunnyCDN/BUNNYWAY in Slovenia and Hetzner in Germany and Finland behind the EU option — which is what Article 28 accountability actually looks like in practice, and the post is direct that “the processor remains responsible to the controller for the subprocessor’s performance of its data-protection obligations.” The sharpest line closes two of the most common developer escape hatches at once: “Browser permission to access device location does not replace this assessment, and routing a request through a backend does not make the location data anonymous.” The advice that follows is concrete — send only the required fields, never append a customer ID to a query, treat the hostname as configuration, run a DPIA for continuous tracking, and do not log complete request URLs, because they contain your API key.
The catalog holds ten Geoapify API pages, and the post walks most of them: the Geoapify Geocode API and Reverse Geocoding API that turn an address into a coordinate and back, the Address Autocomplete API that sees a user’s keystrokes before they finish typing, the Places API and Routing API, and the Map Tiles API and Static Maps API the post insists you assess separately from any tracking. The IP Geolocation API sits in the catalog too, and it is the surface where the post’s data-minimisation argument bites hardest.
Geoapify scores 25.4, emerging on the Kin Score, and the facets are an awkward fit for the post’s subject. Governance and contract governance are both 0.0. Developer ergonomics is 2.4. Discoverability at 57.4 and contract quality at 48.3 carry what score there is. Agent Readiness is 24.0, agent-aware — spec_presence, mcp_server and rate_limit_signal lit, and auth_clarity unlit, which lands oddly against a post whose own advice is that your logs must never capture the API key in a URL. consent_identity is unlit as well. Geoapify has written the clearest thing on their site about documenting data flows, retention and subprocessors. None of it is yet in a place the catalog, or an agent, can read.