Reverse Geocoding API: Find Vietnam Province and District from GPS Coordinates

If you already have GPS coordinates, you do not need to parse a messy address string to know which Vietnam province or district the point belongs to. A reverse geocoding API can turn lat,lng into current administrative context.

This matters for delivery zones, driver location, branch coverage, CRM territories, and reports that must follow Vietnam's current province and district structure. Coordinates are stable even when names and boundaries change.

This post is intentionally different from the admin-boundary dataset overview. For the dataset itself, read Vietnam admin boundaries. For old-to-new address normalization after the 2025 merger, read Vietnam's 2025 Province Merger.

The problem

Many systems store an address string and later try to infer province, district, or service zone from that text. That approach breaks when:

• The user typed an old district or ward name.
• The address is missing accents or uses abbreviations.
• A province or district changed after an administrative update.
• The app needs to classify thousands of historical points consistently.

If you have coordinates, the better source of truth is geometry. Point-in-polygon lookup answers: "Which administrative boundary contains this point?"

When it matters

Reverse geocoding by coordinates is useful whenever location is captured from GPS, a map pin, or a previously geocoded address.

Common examples:

• Delivery zones: decide whether an order belongs to a branch, depot, or surcharge area.
• Driver tracking: attach a live GPS point to province and district for operations.
• Store coverage: show whether a customer is inside a supported area.
• CRM territories: group customers by current province or district.
• Reporting: keep dashboards stable after administrative name changes.

The key advantage is durability. If the address text changes, the coordinate still represents the same real-world point.

Implementation pattern

Call reverse geocoding after you collect a coordinate. That coordinate can come from browser geolocation, a mobile app, a selected map pin, or an address autocomplete result.

curl -H "X-API-Key: gdk_live_..." \
  "https://api.gogoduk.com/v1/reverse-geocode?lat=21.03&lng=105.85"

Example response:

{
  "lat": 21.03,
  "lng": 105.85,
  "city": "Hà Nội",
  "district": "Đống Đa"
}

In a backend service, persist the coordinate and the administrative result:

async function classifyPoint({ lat, lng }) {
  const res = await fetch(
    `https://api.gogoduk.com/v1/reverse-geocode?lat=${lat}&lng=${lng}`,
    { headers: { "X-API-Key": process.env.GOGODUK_API_KEY } },
  );
 
  if (!res.ok) throw new Error("reverse geocoding failed");
  return res.json();
}

Store both values. The coordinate lets you re-run classification later if boundaries or business rules change.

Data model

For operational systems, avoid storing only a formatted address.

A practical location record looks like this:

{
  "addressText": "226 Vạn Phúc, Ba Đình, Hà Nội",
  "lat": 21.0345,
  "lng": 105.8125,
  "province": "Hà Nội",
  "district": "Ba Đình",
  "source": "user_selected_suggestion",
  "classifiedAt": "2026-05-29T00:00:00.000Z"
}

The classifiedAt timestamp is useful when you later need to audit which boundary version produced the result.

Common mistakes

The first mistake is trusting text over coordinates. If an address says one district but the coordinate falls inside another, your delivery and reporting logic should usually trust the coordinate and flag the record for review.

The second mistake is using reverse geocoding only at display time. If province and district drive pricing, routing, or analytics, classify and store the result server-side.

The third mistake is ignoring failed or out-of-country points. Your app should handle null results, ocean points, bad GPS accuracy, and coordinates outside Vietnam.

Where GoGoDuk fits

GoGoDuk's /docs/endpoints/reverse-geocode endpoint is backed by Vietnam administrative boundary data and designed for province/district classification.

Use it together with:

• Address autocomplete for user-entered addresses.
• Stored GPS points from mobile apps.
• Admin-boundary polygons when you need visual service-area maps.

For a deeper look at the boundary dataset, read Vietnam admin boundaries. If your main problem is old address text after the 2025 merger, read the normalization guide.

FAQ

Is reverse geocoding the same as geocoding? No. Geocoding turns an address into coordinates. Reverse geocoding turns coordinates into an address or administrative area.

Why use coordinates instead of parsing address text? Coordinates are more stable. Names can be misspelled, abbreviated, or changed after administrative updates, but a point still falls inside a boundary.

Can this classify historical customer records? Yes, if the records have coordinates. Re-run reverse geocoding to attach current province and district fields.

What if the point is near a boundary? Store the coordinate and classification timestamp. For high-risk operations, add manual review for low-accuracy GPS points near service-zone edges.

Try it

Send one real point from your app:

curl -H "X-API-Key: gdk_live_..." \
  "https://api.gogoduk.com/v1/reverse-geocode?lat=10.7769&lng=106.7009"

Create a free API key, then test points from your delivery, driver, or customer dataset.