How to Use Maps, Geocoding and Routing APIs in a GDPR-Compliant Application

A GDPR-compliant location application is built from compliant data flows, not from one API setting. Map, geocoding, and routing requests may contain an IP address, an address, coordinates, or other information connected to a person. Application builders therefore need to understand what data they send, why they process it, how long they keep it, and which providers receive it. EU-only processing can satisfy an additional technical or procurement requirement, but GDPR does not require every compliant application to process data only in the EU.

This article provides technical guidance for application design. It is not legal advice, and the correct assessment depends on your organization, users, purposes, data, and jurisdiction.

Why GDPR Matters for Location Applications

The basic idea behind GDPR is simple: organizations should use personal data for a clear and legitimate reason, treat it responsibly, and remain accountable for what happens to it. The regulation does not prohibit applications from using personal data or providing location-based features. It sets rules intended to protect people when organizations collect, combine, share, store, or make decisions with data connected to them.

In practical terms, an application should be able to explain:

• Why it needs the data: Each use of an address, coordinate, route, or identifier should have a specific purpose and lawful basis.
• What happens to it: People should receive clear information about collection, use, recipients, retention, and their rights.
• Why the amount is proportionate: The application should use only the data and precision required for the feature.
• How it is protected: Access, transmission, storage, providers, and deletion should be controlled according to the risk.
• How people can exercise their rights: The organization should be able to handle applicable requests to access, correct, restrict, export, or delete personal data.

This matters especially for location applications because location data can become revealing when connected to a person or collected over time. A single request might show a delivery destination; repeated requests might reveal a home, workplace, daily routine, or sensitive visit. Even a request for public map content can include an IP address and technical metadata.

GDPR therefore asks teams to look beyond the visible map. The important subject is the complete data flow: what the application collects, what it sends to an API, which organizations process it, what is stored afterward, and how long each part remains available. The European Commission summarizes this approach through the principles of lawfulness and transparency, purpose limitation, data minimization, storage limitation, security, and accountability.

What GDPR Compliance Means for a Location-Based Application

GDPR compliance starts by mapping the complete processing activity. For a location feature, that can include the user's device, browser or mobile application, your backend, a location API, network providers, application logs, analytics, customer-support tools, and stored results.

The GDPR's definition of personal data explicitly includes location data and online identifiers when they relate to an identified or identifiable person. The important questions are therefore not only “Do we store a name?” or “Are the coordinates in Europe?” They are also “Can this data identify or single out someone?” and “What other data can it be combined with?”

When Location Data Becomes Personal Data

Coordinates are not automatically personal data in every context. The coordinates of a public monument describe a place, while a live coordinate associated with a customer account, device identifier, delivery order, or employee can describe a person.

The same value can change character when its context changes. A pair of coordinates in a public geographic dataset may be non-personal, but the same pair stored beside a user ID and timestamp may reveal where that person lives, works, or travels.

Data Controller, Processor, and Subprocessor Roles

GDPR responsibilities depend partly on who decides the purpose and means of processing. These roles describe responsibilities in a specific processing activity; they are not permanent labels for an entire company.

For example, an online retailer can use a delivery platform built and operated by another company. The retailer decides why customer addresses are processed and acts as controller. The delivery-platform provider processes those addresses for the retailer and acts as processor. If the platform sends an address or coordinates to an external location API, that API provider is a subprocessor in this data flow.

The processor may also use subprocessors for hosting, infrastructure, transactional email, customer communications, storage, security, monitoring, or—in some arrangements—payment processing. A subprocessor can use its own providers, creating another level in the processing chain.

This is the role model used in the rest of this article. If a company operates an application for its own purposes, it may instead be the controller and its location API provider the processor. A vendor's role depends on the actual service, instructions, contract, and purposes; the European Data Protection Board provides detailed controller and processor guidance.

GDPR Compliance Does Not Require EU-Only Processing

GDPR and EU-only processing answer different questions:

• GDPR compliance concerns whether personal data is processed lawfully, fairly, transparently, securely, and with the rights and safeguards required by the regulation.
• EU-only processing is a data-location constraint whose exact scope should be documented. For an API service, it can require the provider's service processing and storage to use EU infrastructure without claiming that the provider controls the complete public Internet route.

The GDPR allows personal data to be transferred outside the EU or EEA when the requirements in Chapter V are met. Depending on the destination and relationship, this can involve an adequacy decision, Standard Contractual Clauses, another approved safeguard, or a limited derogation. The European Commission summarizes these rules for transfers outside the EU.

Several US-headquartered technology providers publish GDPR compliance commitments and explain how customers can use their services as part of a compliant data flow:

These are provider statements, not a general GDPR certification or a guarantee that every customer implementation is compliant. Customers must still evaluate the selected services, contracts, transfer mechanisms, configuration, purposes, and complete data flow.

An organization may still require EU-only processing because of a contract, tender, sector policy, customer commitment, or internal architecture standard. That requirement can be stricter than the GDPR itself. It should be recorded separately in the technical and vendor assessment.

Location API Data-Processing Examples

The application team must evaluate the complete flow rather than treating an API provider's compliance statement as a substitute for its own work. A useful starting point is to document each feature as a sequence:

User action
  -> data collected by the app
  -> data sent to the location API
  -> response returned to the app
  -> data displayed, logged, stored, or forwarded
  -> deletion or anonymization

For every step, record the data, purpose, lawful basis, recipient, location, retention period, security controls, and access rules. This turns “Is our maps API GDPR compliant?” into a set of questions the engineering, privacy, security, and procurement teams can actually answer.

Example: Displaying Public Map Tiles

A map can show public geographic data without sending a user's precise device coordinates. However, a browser that requests map tiles directly from a provider still sends network information such as its IP address and HTTP headers.

The application should disclose the provider where required, avoid adding user identifiers to tile URLs, secure the API key appropriately, and determine whether consent or another lawful basis applies to any separate analytics or tracking. A public map is not automatically outside GDPR simply because the visualized roads and places are public.

Example: Sending an Address to a Geocoding API

A store-locator search for “Berlin Hauptbahnhof” is different from geocoding a customer's full home address. In the second case, the address can be personal data, especially when it is connected to an order or account.

Send only the fields the geocoder needs. Do not append a customer name, email address, internal account ID, or order number to a query merely for application convenience. If the result must be associated with an order, make that association inside the application under defined access and retention rules.

Example: Calculating a Route from User Coordinates

A one-time route between two points may be needed to provide navigation or estimate a delivery. A continuous history of routes can reveal habits, work locations, health visits, religious attendance, or other sensitive inferences.

Define whether the feature needs current coordinates, approximate coordinates, a one-time route, or a stored history. Processing less precise data for less time can materially reduce privacy risk without removing the location feature.

What Application Builders Need to Address

Building a GDPR-compliant location application starts with the application's own data practices. The application provider and controller should briefly review whether they:

• define the purpose and lawful basis for each location feature;
• collect and send only the addresses, coordinates, identifiers, and precision the feature needs;
• explain the processing and recipients clearly to users;
• protect API requests, credentials, stored results, and access;
• set justified logging and retention rules and support applicable data-subject requests; and
• assess whether higher-risk processing, such as systematic location tracking, requires a DPIA.

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 European Commission's guidance covers the core GDPR processing principles, data protection by design and by default, and DPIA requirements.

What Managing Subprocessors Means

When an application provider acts as processor for its customer, an external service that processes personal data for the application is a subprocessor. Managing subprocessors means more than adding vendor names to a privacy policy.

The application provider generally needs to:

1. Identify the data flow: Record which data is sent to each subprocessor, for which purpose, and from which application feature.
2. Obtain authorization: Article 28 GDPR requires the controller's prior specific or general written authorization before the processor engages another processor.
3. Put contractual terms in place: The subprocessor must receive appropriate data-protection obligations through the contractual chain.
4. Review the service: Assess security measures, processing locations, retention, subprocessors used by the provider, and international-transfer safeguards.
5. Keep information current: Maintain the subprocessor list and follow the agreed notification or objection process when providers change.
6. Match configuration to documentation: Ensure that production hostnames, regions, logging, and storage correspond to what the controller approved.

The processor remains responsible to the controller for the subprocessor's performance of its data-protection obligations. It should therefore be able to explain where data goes, which agreements apply, and how it will support requests, deletion, incidents, and audits across the provider chain.

Using Geoapify as a GDPR-Compliant Subprocessor

An application provider can use Geoapify as a GDPR-compliant subprocessor for Map Tiles, Static Maps, Address Autocomplete, Geocoding, place discovery, Routing, and other location APIs. Geoapify provides contractual and service information that the application provider can use in its vendor review and its own documentation for the controller.

The application provider should list Geoapify as a subprocessor and describe the relevant purpose and data categories in the form agreed with its controller. It should also document the selected endpoint configuration. If Geoapify's EU-focused service-processing configuration is approved, production must use api-eu.geoapify.com; listing the EU option in a contract does not change requests sent through a default hostname.

Privacy-Aware Maps, Geocoding, and Routing Integration

API syntax does not determine compliance, but implementation choices affect how much personal data is exposed. The following examples show how to keep request construction explicit and avoid mixing business identifiers into location queries.

Maps: Separate Public Map Delivery from User Tracking

For default Geoapify map delivery, a raster tile URL follows this pattern:

https://maps.geoapify.com/v1/tile/osm-bright/{z}/{x}/{y}.png?apiKey=YOUR_API_KEY

The tile coordinates identify a map area, not necessarily the user's precise position. Still, the browser makes a network request and supplies technical metadata. Do not add account IDs, email addresses, or other user identifiers to the tile URL. Assess analytics and location tracking separately from the map-rendering request.

Geocoding: Keep the Query Focused on the Address

This backend JavaScript example sends the address needed for geocoding and limits the response to one result. It does not add an order number or customer identifier to the provider request.

const apiHost = process.env.GEOAPIFY_API_HOST ?? "api.geoapify.com";

const params = new URLSearchParams({
  text: userSuppliedAddress,
  format: "json",
  limit: "1",
  apiKey: process.env.GEOAPIFY_API_KEY
});

const response = await fetch(
  `https://${apiHost}/v1/geocode/search?${params}`
);

if (!response.ok) {
  throw new Error(`Geocoding failed: ${response.status}`);
}

const result = await response.json();

If the application needs to connect the selected result to an order, it can do so inside its own controlled data model. Avoid logging the complete request URL, because it contains both the address and API key.

Routing: Send Only the Waypoints Required for the Route

The Geoapify Routing API accepts coordinate pairs in latitude-longitude order. Here the API hostname is configurable, so the same integration can use the reviewed default or EU-focused endpoint configuration.

const apiHost = process.env.GEOAPIFY_API_HOST ?? "api.geoapify.com";

const params = new URLSearchParams({
  waypoints: "48.8584,2.2945|48.8606,2.3376",
  mode: "drive",
  apiKey: process.env.GEOAPIFY_API_KEY
});

const response = await fetch(
  `https://${apiHost}/v1/routing?${params}`
);

if (!response.ok) {
  throw new Error(`Routing failed: ${response.status}`);
}

const route = await response.json();

Whether these waypoints are personal data depends on their context. If they represent a user's live position and home address, document and protect them accordingly. If they represent two public landmarks in a general travel tool, the privacy risk is different.

Geoapify Default and EU-Focused Endpoints

Geoapify gives application teams two documented endpoint configurations. The default configuration uses Cloudflare's globally distributed network. The EU-focused configuration uses BunnyCDN, operated by BUNNYWAY in Slovenia, together with Geoapify's EU infrastructure for service-side processing.

For a broader evaluation of API coverage as well as default and EU-focused delivery options, see Geoapify as a European alternative to Google Maps.

Default Endpoints: api.geoapify.com and maps.geoapify.com

Use api.geoapify.com for default Geocoding, Places, Routing, Route Matrix, and other location API requests. Use maps.geoapify.com for default Map Tiles and Static Maps.

Cloudflare provides the CDN, load-balancing, performance, and security layer for these hostnames. Because Cloudflare operates a global network, Geoapify does not describe this configuration as EU-only.

The default configuration is nevertheless operated as GDPR compliant. GDPR permits international processing and transfers when the required legal mechanisms and safeguards are in place. Geoapify uses Cloudflare under its Data Processing Addendum. Cloudflare documents mechanisms including the EU Standard Contractual Clauses, supplementary safeguards, and the EU-US Data Privacy Framework where applicable; see Cloudflare's GDPR information and Cloudflare Data Processing Addendum.

For maps, maps.geoapify.com also provides extensive Cloudflare caching. Tiles and static map images served from that cache do not count as Geoapify API usage. This performance and usage characteristic may matter for map-heavy applications, but it is separate from the application's GDPR assessment.

EU-Focused Endpoint: api-eu.geoapify.com

Use api-eu.geoapify.com when the application requires Geoapify's EU-focused service-processing configuration. It serves Geoapify location APIs as well as Map Tiles and Static Maps through BunnyCDN, operated by BUNNYWAY in Slovenia, together with Geoapify's EU infrastructure.

This scope covers service processing performed by Geoapify and the subprocessors designated for the endpoint. It does not guarantee the geographical route traffic takes across the public Internet before reaching or after leaving the service infrastructure. Public Internet routing operates across independently administered networks. The same Geoapify API key, path, parameters, request body, and response handling generally continue to apply; the main integration change is the hostname.

For example, the geocoding requests differ only by host:

# Default Cloudflare-backed endpoint
curl "https://api.geoapify.com/v1/geocode/search?text=Berlin%2C%20Germany&limit=1&format=json&apiKey=YOUR_API_KEY"

# EU-focused endpoint
curl "https://api-eu.geoapify.com/v1/geocode/search?text=Berlin%2C%20Germany&limit=1&format=json&apiKey=YOUR_API_KEY"

For Map Tiles and Static Maps, change maps.geoapify.com to api-eu.geoapify.com. BunnyCDN provides caching for EU-focused map delivery, although it is less extensive than the Cloudflare cache used by the default maps hostname.

How to Choose a Geoapify Endpoint

Choose the endpoint from the documented processing requirement, not from the assumption that only EU-hosted services can comply with GDPR.

Treat the hostname as an application configuration value. When changing it:

1. Identify whether the default request currently uses api.geoapify.com or maps.geoapify.com.
2. Change the configured hostname to api-eu.geoapify.com.
3. Keep the existing API path, parameters, request body, API key, and response handling.
4. Update allowlists, Content Security Policy rules, monitoring, and deployment documentation.
5. Test representative requests and failure handling.
6. For map-heavy workloads, compare observed usage because the EU endpoint has less extensive caching.

The endpoint choice covers processing within Geoapify's service boundary; it does not control the geographical route selected by the public Internet. Your application can also send data to logs, analytics, monitoring, support tools, databases, or other providers. Those systems remain part of the compliance assessment.

GDPR Checklist for Location Applications

Use this checklist as an engineering and review aid. It does not replace a legal assessment.

Repeat the review when adding continuous tracking, precise background location, route history, advertising, employee monitoring, location sharing, or a new provider. These changes can materially alter the purpose and risk even if the visible map remains the same.

Conclusion

Using maps, geocoding, and routing APIs in a GDPR-compliant application requires more than selecting a European provider or EU server. Application builders need to identify personal data, define purposes and lawful bases, minimize requests, inform users, secure processing, control retention, review providers, and support data-subject rights.

Geoapify supports this work with documented GDPR-compliant location services, a Data Processing Agreement, and two endpoint configurations. Use api.geoapify.com and maps.geoapify.com when the default Cloudflare-backed configuration meets the application's requirements. Use api-eu.geoapify.com when Geoapify service processing in EU infrastructure is an explicit requirement.

The endpoint is an important architecture decision, but it remains one part of the complete application data flow.

FAQ