Migration

Migrating from Bing Maps REST Services

Bing Maps REST Services has a recognizable response shape: a top-level object with a resourceSets array, each containing resources, and each resource carrying a point object with coordinates nested inside a coordinates array rather than separate latitude and longitude fields. Developers who built against it, often in .NET shops where Bing Maps was the natural fit, know this structure by heart, and rewriting around a different one is exactly the kind of quiet, tedious work that keeps a migration off the calendar for months.

A key generated through the Bing Maps Dev Center gets sent as a query parameter, which is a pattern shared with most consumer mapping APIs. That part of the integration is usually the least of anyone's worries; the response parsing is where the real coupling lives.

My Geocode runs a Bing Maps compatibility host that reproduces this exact resourceSets structure, so the parsing code that reads resourceSets[0].resources[0].point.coordinates keeps working after the swap. The only content in the response that isn't Bing's original shape is the copyright, terms, and privacy text, which is ours by necessity. Full details are at /compatibility/bing-maps/.

A few things worth checking before cutting over:

  • Confirm whether your code reads confidence or match-code fields, since these are worth a quick side-by-side comparison
  • Confirm which authentication style your client library uses; a key can be sent as X-API-Key, Authorization: Bearer, HTTP Basic auth, or a query parameter, so whichever one your library already does should keep working
  • Decide whether you want the optional extra fields (elevation, IP threat, network detail) turned on via mg_extras=1, since they sit alongside the standard shape rather than replacing it

The commercial side is straightforward by comparison. There is no billing account setup step: 2,500 requests a day are free with no key at all, and every key gets its own 2,500 free requests a day counted per network. Beyond that allowance, it is prepaid credit at €0.0001 per request or an Unlimited key at €50 a month, and the compatibility host costs the same as every other endpoint on the platform.

For teams running geocoding as part of a larger .NET or enterprise application, the migration is usually smaller in scope than it looks from the outside, because the resourceSets wrapper is normally read through a handful of well contained accessor methods rather than scattered inline across the codebase. Finding those access points first, then pointing them at the new host in a staging environment, is a reasonable way to validate the switch before touching production traffic.

If your integration also calls a Bing time zone or elevation endpoint alongside geocoding, those are handled separately, since My Geocode's own timezone and elevation lookups work independently of the geocoding compatibility host and are worth wiring up on their own terms rather than forcing them through the same code path. Full quota details, including the X-Quota-Limit and related response headers every request carries, are documented at /docs/rate-limits/.