Turn coordinates into locality in n8n

BigDataCloud·September 14, 2026

n8n is open-source workflow automation: connect apps and HTTP APIs on a canvas without shipping a full application.

GPS and device APIs give you numbers. This how-to wires BigDataCloud’s reverse-geocode API into n8n so a workflow can turn latitude and longitude into country, state, city, suburb, and postcode — useful when an agent or form already has coordinates and needs a place name.

There is no official BigDataCloud n8n node yet. Import the sample workflow below, or build the same call with a standard HTTP Request node.

What you need

Import the workflow

  1. In n8n, open Workflows → Import from File (or Import from URL and paste the download link above).
  2. Open the canvas. The sticky note on the left repeats the setup steps.

Set your API key

On the Reverse geocode HTTP Request node:

  1. Find the header x-bdc-key.
  2. Replace YOUR_BDC_API_KEY with your real key.
  3. Keep the key in that header only. Do not put it in the URL.

Sample request

The workflow uses Adelaide coordinates (same values as the public docs sample):

GET https://api-bdc.net/data/reverse-geocode?latitude=-34.93129&longitude=138.59669&localityLanguage=en
Header: x-bdc-key: YOUR_BDC_API_KEY
  • latitude — sample value -34.93129 (WGS 84, expected range [-90, 90])
  • longitude — sample value 138.59669 (WGS 84, expected range [-180, 180])
  • localityLanguage — sample value en. Optional; ISO 639-1 language for locality names.

Endpoint docs: Reverse Geocoding to City API.

Run the sample

  1. Click Test workflow.
  2. Open the Reverse geocode node output.

Useful fields (names as published in the docs):

  • countryName / countryCode
  • principalSubdivision / principalSubdivisionCode
  • city
  • locality — suburb, village, or town when available
  • postcode
  • plusCode

Replace the sample latitude and longitude with values from your upstream node (mobile client, map picker, IoT payload) when you wire this into a real flow.

Where this fits in agent workflows

Typical pattern: receive lat/lng → reverse-geocode → use city, locality, or countryCode in the next step (routing, personalisation, logging). This API resolves administrative and locality boundaries rather than nearest street address, which stays useful outside dense urban areas.

Docs