My Geocode blog

Verifying an address matches its stated postal code before checkout

2026-09-21T18:34:00+00:00

A shopper who autofills a checkout form from a saved browser entry, or copies an address from an old email, sometimes ends up with a postal code from one location paired with a city name from another, an easy mistake to make and an easy one to miss when reading over a filled-in form quickly before clicking submit. An online store shipping physical goods found this exact mismatch behind a steady, low-level trickle of misdirected or delayed deliveries, each one small on its own and collectively a real cost in reshipping and customer frustration.

The fix was a cross-check run automatically at checkout, before an order was confirmed. The postal code entered on the form went to /v1/postcode, which resolves what location that code actually corresponds to. The store compared the resolved location against the city and region the shopper had also entered on the same form, and where they clearly disagreed, rather than letting the order through and discovering the mismatch only once a delivery went to the wrong place, the checkout flow paused with a plain prompt asking the shopper to double check the postal code and city before continuing.

The store also ran the full entered address through /v1/forward as a second layer, since an address can pass the postal code and city cross-check while still having a genuine problem elsewhere, a street that does not exist under that name or a number outside the plausible range for that street, and the match confidence returned by the forward geocoding call gave the checkout flow a second signal to weigh alongside the postal code comparison, flagging clearly poor matches for the same quick confirmation prompt.

The store was deliberate about how much friction this added. Most orders passed both checks instantly and moved through checkout with no visible change at all, since the overwhelming majority of shoppers enter their own address correctly the first time. Only the smaller number of orders with a genuine mismatch saw the confirmation prompt, and even then it took a shopper only a few seconds to review and correct, or confirm the address was in fact correct as entered, since an occasional legitimately unusual address could still trigger the check without actually being wrong.

This kind of check pays for itself specifically because the cost of catching a mismatch before shipping is so much smaller than the cost of an order that has already shipped to the wrong place, a reshipment plus a delayed or lost original delivery plus, often, a frustrated customer who is now less likely to order again. Fixing it in the few seconds before an order is placed, rather than the days it takes to discover and correct a shipping problem after the fact, moved that cost from significant to close to nothing.

Every order triggered one postal code check and one address check, a workload that scaled directly with sales volume and stayed inside the free daily allowance for a store of moderate size most of the year, with prepaid credit covering busier periods without requiring any special planning ahead of time.

Documentation for both endpoints is at /docs/postal-code-lookup/ and /docs/forward-geocoding/, and general error handling behavior for both is covered at /docs/errors/.

Monitor your key's usage before you hit a limit

2026-09-21T18:22:00+00:00

Finding out you are near your daily limit because a request just got rejected is the least useful way to find out. Every response already carries the numbers needed to see it coming.

The headers to watch

X-Quota-Limit: 2500
X-Quota-Used: 2210
X-Quota-Free-Remaining: 290
X-Quota-Network-Used: 2210
X-Credits-Remaining: 5.75
X-Key-IPs-Used: 2
X-Key-IPs-Limit: 3
X-Quota-Reset: 2026-09-22T00:00:00Z

X-Quota-Free-Remaining shrinking toward zero is your clearest early signal for the free daily allowance. X-Credits-Remaining tells you how much runway is left once you have moved past the free allowance and are drawing on prepaid credit at €0.0001 a request.

Setting your own alert threshold

Rather than waiting for a 429, log or alert once X-Quota-Free-Remaining drops below a threshold you choose, such as 10 percent of X-Quota-Limit, so there is time to react, whether that means slowing down a batch job, topping up credit, or simply expecting a quiet period until X-Quota-Reset.

Watching key IP slots too

X-Key-IPs-Used and X-Key-IPs-Limit track how many different source addresses have used a given key under its rolling IP slot allowance. A key suddenly used from more addresses than expected, climbing toward its limit, is worth investigating on its own, separate from request volume, since it can point to a key being shared more widely than intended.

Building a simple dashboard

A small script that logs these headers on a sample of requests, or on every request if volume is low enough, gives you a usage trend over time without needing a separate monitoring call, since the numbers arrive on responses you were already making. Plotting X-Quota-Used against time across a day or a week shows usage patterns that a single snapshot never would.

Acting before you hit the wall

Once you see a consistent pattern of running close to your limit, the two paths forward are the same two options available at any point: add prepaid credit for occasional overflow, or move to an Unlimited key at €50 a month if you are consistently past the free allowance. Either decision is easier to make calmly, ahead of time, than in response to a live 429 blocking real traffic.

Reading quota headers as routine telemetry, not just as something to check when a request fails, turns a hard limit into a manageable trend. Current allowance and credit options are on the pricing page, and full header definitions are on the rate limits docs.

What we shipped this month: geocoding, IP, time zone and more

2026-09-21T17:55:00+00:00

It has been a busy stretch across the whole platform, touching compatibility, performance, and the dashboard alike, so it is worth stepping back and looking at the shape of it together rather than one change at a time.

On compatibility, our lineup now covers seventeen hosts in total, reproducing the request and response shape of Google Maps Platform, Bing Maps REST Services, HERE Geocoding and Search, Mapbox Geocoding, Geocode.Farm, OpenStreetMap Nominatim, OpenCage, LocationIQ, Geoapify, TomTom Search, MapQuest Geocoding, Geocodio, PositionStack, ip-api.com, ipinfo.io, ipstack and Open-Elevation, each one switchable with just a host name and a key. The full list, kept current, lives at /compatibility/, alongside migration guides for anyone moving an existing integration over at /docs/compatibility/.

On performance, we rebuilt the lookup table behind /v1/timezone for faster responses, refreshed the elevation data behind /v1/elevation for better accuracy in mountainous terrain, and completed an infrastructure upgrade that reduced response times across every endpoint and every compatibility host. None of that required any changes on the integration side. IP, time zone and elevation lookups all remain fully working endpoints you can rely on for real, populated responses today.

On the dashboard, accounts can now enable two-factor authentication, switch to dark mode, and set a preferred language, all from account settings. A referral program rewards anyone who sends us a paying customer, coupon codes can be applied directly against an account, and our support team now works from canned replies to answer common questions faster.

On data and endpoints, postal code coverage has grown to include more countries, with specific attention paid to accuracy in rural and low-density areas that are historically harder to map well. IPv6 is now handled consistently across every endpoint and every compatibility host, sharing the same free allowance and quota structure as IPv4. IP lookups can also return optional threat and network detail by adding mg_extras=1 or an X-MG-Extras header.

Through all of it, the fundamentals have not moved. Any address gets 2,500 free requests a day with no key required, counted per network. Every key adds its own 2,500 free requests a day. Beyond that, prepaid credit is €0.0001 a request, or an Unlimited package covers everything for €50 a month, paid by PayPal, cryptocurrency, or bank transfer, with every endpoint and every compatibility host costing exactly the same.

We build and run a geocoding API. That is the whole company, and updates like this reflect the same focus applied consistently across compatibility, performance, and the tools around the API itself. Full documentation for everything mentioned here is at /docs/, and current pricing is at /pricing/.

The trouble with API keys that never expire

2026-09-21T10:29:00+00:00

A key that never expires is convenient in exactly the way that makes it easy to forget it exists. It gets generated once, embedded in a configuration file or an environment variable, and then it simply keeps working, indefinitely, with nobody revisiting whether it should. Years later, the person who generated it may have left the company, the project it was created for may have been decommissioned, and the key itself may be sitting in a forgotten server, a leaked repository, or an old backup, still fully valid, because nothing about the system ever asked it to prove it was still needed.

This is a real, underappreciated security problem, not a hypothetical one. Keys leak through committed configuration files, through logs that captured a request header by accident, through old backups that outlive the project they belonged to. A key that never expires means every one of those leak vectors stays dangerous indefinitely, with no natural point at which the exposure closes on its own. A key that gets rotated or reviewed periodically at least bounds how long a given leak stays exploitable, even if the leak itself was never detected.

We do not think the answer is forcing expiration dates that break integrations without warning, which trades one problem for a different, equally frustrating one: a key that stops working mid-production because of a rotation policy nobody communicated clearly. The answer is visibility and control that make rotation a deliberate, informed choice rather than something that either never happens or happens as an unplanned surprise. Quota headers on every response, including a count of how many of a key's IP slots are in use, give an ongoing signal about whether a key's usage pattern still matches what it was originally issued for, which is exactly the kind of information that should prompt a periodic "does this key still need to exist" review.

The broader industry habit of treating a key as a permanent, install-it-once credential comes from prioritizing initial integration convenience over the entire lifetime of that credential's existence. It is genuinely easier, on day one, to generate a key that never needs touching again. That convenience is front loaded, and the cost, an old, unmonitored, unrotated key sitting somewhere as a permanent liability, is back loaded onto a future incident nobody is thinking about on day one.

We think the healthier default is treating a key less like a fixed installation and more like a credential with an ongoing relationship to the account: visible in real time through the requests it makes, reviewable periodically, and revocable without drama when a project it belonged to has actually ended. None of that requires forcing expiration on anyone. It requires making it easy enough to see what a key is actually doing that letting an old one linger forever stops being the path of least resistance.

Migrating a Zapier or Make automation to a new geocoding host

2026-09-21T10:05:00+00:00

Automations built in Zapier or Make often include a geocoding step tucked into a larger workflow: a new lead comes in through a form, its address gets geocoded to check territory assignment, and the result triggers a routing decision further down the chain. These workflows are frequently built by someone without a software engineering background, using whichever pre-built app connector or generic HTTP module the platform offered at the time, which changes what a migration actually looks like compared to a custom codebase.

If your current geocoding step uses a dedicated app connector, a first-party integration built by Zapier or Make specifically for the provider in question, migrating to a provider without an equivalent dedicated connector means switching that step to a generic HTTP or webhook module instead, configured to call the new provider's API directly. This is a real change in how the automation is built, not just a credential swap, and it is worth testing the replacement step thoroughly in an isolated test scenario before touching a live, production automation that other parts of a business depend on.

Specific steps for making this switch:

Duplicate the existing automation in the platform's builder rather than editing it in place, so the working version keeps running until the replacement version is fully tested
Replace the geocoding step with a generic HTTP module, configured with the new provider's endpoint and authentication, since a query parameter key or an Authorization: Bearer header (both supported here) is straightforward to configure in a generic HTTP module without needing a dedicated connector
Map the response fields manually in the automation's data mapping step, since a generic HTTP module returns raw response data that needs to be explicitly mapped to whatever fields later steps in the automation expect, unlike a dedicated connector which often does this mapping automatically
Test with a range of real inputs, including edge cases like partial addresses or unusual formatting, since this is exactly the kind of testing that is easy to skip in a no-code tool where the "code" itself is not visible for review the way a script would be
Switch the trigger from the test version to the duplicated, verified automation, and only then deactivate the original once you have confirmed the new one is running correctly on live data for a short period

Because a compatibility host reproduces a familiar provider's exact response shape, if your original automation's geocoding step happened to call a provider with a matching compatibility host here, the field mapping in step 3 above may closely resemble the mapping your original connector already used internally, which can meaningfully shorten this migration. The full list of compatibility hosts is at /compatibility/, worth checking before assuming a from-scratch field mapping is necessary.

For a business-critical automation, the extra caution of testing in a duplicate rather than editing live is worth the small amount of extra setup time, since a broken lead-routing automation tends to be noticed quickly and by people outside the technical team.

Testing location data with edge cases, not just happy paths

2026-09-21T08:32:00+00:00

It is easy to build and test location-aware software entirely against convenient, well-behaved examples: a clean address in a major city, a residential broadband IP address, a location comfortably far from any border or time zone boundary. Every one of those tests will reliably pass, and every one of them will tell you almost nothing about how your system behaves in the situations most likely to actually cause a problem once it meets real, messier data in production.

A genuinely useful test suite for location software needs to deliberately include the harder cases this whole series has covered individually: an address in a country without conventional house numbering, a query for a location extremely close to an international border, a timestamp that falls exactly within a daylight saving transition, an IP address known to belong to a mobile carrier's CGNAT pool or a satellite internet provider, a coordinate near the poles where longitude-based assumptions start to break down, and a postal code from a country whose postal data is comparatively coarse rather than one from a country with unusually detailed reference data.

None of these are exotic, unlikely scenarios invented purely for the sake of thoroughness. Each one represents a real, recurring category of input that any sufficiently large, genuinely global user base will eventually and predictably send your way, often sooner than you would expect. A system that has never been tested against them will not fail loudly and obviously in an easy to diagnose way. It will most often fail quietly, returning a plausible-looking but subtly wrong result that passes every superficial check and only surfaces as a real problem much later, usually as a confusing support ticket or an unexplained business metric that does not add up, by which point it is considerably harder to trace back to its actual root cause.

Building this kind of test set is itself the same discipline described earlier for measuring both accuracy and coverage: a fixed, deliberately varied, reusable collection of test inputs, checked not just for whether a plausible response comes back at all, but specifically for whether the precision and confidence fields on that response behave sensibly and consistently given the genuine difficulty of the specific input. A low-confidence, coarse-precision result for a genuinely hard case is a correct, honest outcome and should be treated as a pass. A confidently wrong result, or an unhandled error, is the actual failure worth catching before your users find it for you.

Our documentation covers the exact fields and behavior to expect across each endpoint, which is the right starting reference for building this kind of deliberately adversarial test set for whatever specific edge cases matter most to your own application and its users.

Cross-check an address against its postal code

2026-09-21T07:33:00+00:00

A customer can type a real street address and a real postal code that do not actually belong together, most often by transposing digits or copying an old postal code into a new address. Neither field alone reveals the problem, since both are individually valid.

Resolving each field independently

Geocode the full address with /v1/forward to see what postal code it actually resolves to, and separately look up the postal code the customer typed with /v1/postcode to see what area it covers.

GET /v1/forward?q=10 Downing Street, London&limit=1

{
  "status": "ok",
  "results": [
    {"formatted": "10 Downing Street, London, UK", "lat": 51.5033, "lon": -0.1276, "type": "address", "precision": "house", "confidence": 0.96, "place_id": "op678", "components": {"postcode": "SW1A 2AA", "city": "London"}}
  ]
}

GET /v1/postcode?code=SW1A 1AA&country=GB

{
  "status": "ok",
  "postcode": "SW1A 1AA",
  "country_code": "GB",
  "results": [{"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London"}}]
}

Comparing the two results

If the postcode component from the address lookup does not match the postal code the customer typed, as in this example, that is a mismatch worth flagging, even though both the address and the postal code independently checked out as real. Comparing the two components directly is more reliable than comparing distance between the two sets of coordinates, since a postal code area can be small enough that even a genuine match will not sit exactly on the address's coordinates.

A second example: a bigger mismatch worth catching earlier

The same check also catches a far more obvious error, a postal code entered for an entirely different country or region than the street address itself, such as a UK-format code paired with an address that actually resolves inside another country. Comparing the country component from the address result against the country parameter used for the postcode lookup, before even reaching the more detailed postcode comparison, is a cheap first check that filters out this kind of larger mistake early.

What to do with a mismatch

Show the customer both values side by side and ask them to confirm which one is correct, rather than silently picking one over the other or rejecting the order outright. A transposed digit is an easy fix once pointed out, and a genuine edge case where a postal code legitimately covers a boundary between two commonly used values is rare enough to handle with a quick manual confirmation.

A common mistake to avoid

Do not compare the two sets of coordinates directly with a distance threshold as a substitute for comparing the postcode components themselves. A postal code area can be geographically small enough that even a completely correct match will show some distance between the postcode's representative point and the address's specific building coordinates, and a small area code can also be geographically large enough that a genuinely mismatched pair still falls within a lenient distance threshold. Comparing the postcode text itself is a more direct and reliable check than trying to infer a match from distance.

An edge case worth allowing for

A postal code area that sits right on a boundary between two administrative regions can legitimately return a component set that looks slightly different depending on which endpoint resolved it, even when both are correct. Treat a close but not exact textual match, such as a difference only in how a region name is written, with a lighter touch than a fully different postal code entirely.

Checking many orders at once

For a batch of existing orders rather than a single new submission, both endpoints accept a bulk POST array, so a backlog of orders can be checked by sending the addresses as one bulk request to /v1/forward and the postal codes as another bulk request to /v1/postcode, then comparing the two result arrays by position.

Request cost

This check uses two requests per order, one for the address and one for the postal code, both counted against your daily allowance the same as any other lookup. That is a reasonable cost for catching an error that would otherwise show up as a failed delivery.

Catching a mismatched postal code before an order ships is worth the second request it takes to check. Details on both endpoints are in the forward geocoding docs and the postal code lookup docs.

A data processing agreement now available on request

2026-09-21T07:18:00+00:00

Some organizations cannot simply agree to a general privacy policy and move on. Internal compliance requirements, industry regulation, or a customer's own vendor requirements sometimes call for a specific, signed agreement covering exactly how a vendor handles personal data. A data processing agreement covering My Geocode is now available on request for exactly that situation.

The agreement sits alongside our general privacy policy rather than replacing it, addressing the same underlying data handling in the more formal, specific terms that a compliance process often requires. It covers how account data, usage data, and IP address information, which is central to how quota is calculated per network, are processed as part of running the API.

Requesting one is straightforward: contact our team through /contact/ and ask for a data processing agreement for your account. This is handled directly by a person on our team rather than through an automated form, since the details of a given organization's requirements sometimes call for a conversation rather than a generic document.

This is particularly relevant for organizations processing personal data on behalf of their own customers, where a chain of data processing agreements down through every vendor involved is often a genuine legal requirement rather than a nice-to-have. If My Geocode's IP geolocation, geocoding, or other endpoints touch personal data as part of a larger system you operate, having this agreement in place closes that link in the chain properly.

We built this to be available to any account that needs it, rather than reserved for a particular size of customer or a particular pricing tier. Whether an account is running on the free tier, prepaid credit, or an Unlimited package, the same agreement is available on the same terms, since the underlying data handling it describes does not change based on how much an account happens to be paying.

None of this changes anything about how the API itself works, what data flows through a normal request, or what is documented in our general privacy policy. It is an additional, more formal document for organizations that specifically need one, sitting alongside the terms of service and privacy policy that already apply to every account by default. If your organization's compliance process requires this kind of agreement before deployment, reach out through /contact/ and we can get it arranged.

Building a simple geofencing alert for a logistics app

2026-09-21T07:10:00+00:00

A full fleet tracking platform was more than a small logistics company actually needed for the one specific thing its dispatch team kept asking for: a plain notification the moment a delivery truck arrived at or left a specific, important customer site, useful for customers who wanted advance notice of an arriving delivery and for the company's own record of when a delivery had actually reached its destination rather than relying on a driver's own end-of-day report.

The building blocks for this were simpler than a full tracking platform, and the company already had GPS coordinates streaming from its delivery vehicles through the mobile devices drivers carried. What it needed was a way to define a customer site as a boundary and check incoming coordinates against it, plus a way to make sense of a raw coordinate when something needed a human-readable description rather than a pair of numbers.

For each important customer site, the company geocoded the site's address through /v1/forward to get a fixed reference coordinate, then defined a small radius around that point representing the site's arrival boundary, a simple radius check rather than a complex custom-shaped boundary, since a radius was precise enough for the company's actual sites, mostly warehouses and loading docks without unusual or irregular boundaries to worry about. As a truck's incoming GPS coordinates streamed in, the company's own backend calculated distance from each tracked truck to each relevant site's reference point, triggering an arrival alert once a truck crossed inside the radius and a departure alert once it moved back outside it.

/v1/reverse played a supporting role for the human side of this system: when a dispatcher needed to review an alert or investigate an unexpected pattern, like a truck that seemed to leave a site and immediately return, having the raw coordinate resolved back into a readable address and location description made the dispatcher's review meaningfully faster than working from a pair of numbers on a map that needed manual investigation to interpret.

The company kept this deliberately simple rather than building toward a full route optimization or fleet management platform, since the specific problem it was solving, arrival and departure alerts for a defined list of important sites, did not need most of what a larger platform would offer, and building only what was needed kept the project small enough to ship quickly and maintain without a dedicated engineering team behind it.

Customers receiving arrival alerts reported real value from the advance notice, particularly ones with limited staff on-site who needed a few minutes' warning to have someone ready to receive a delivery rather than being caught off guard, a small operational improvement for the customer that cost the logistics company relatively little to build.

Site geocoding was a one-time setup cost, small given how few high-priority sites needed this specific treatment, and reverse geocoding usage tracked how often a dispatcher needed to investigate a specific alert, a light and occasional workload rather than a constant one. Both stayed comfortably inside the free daily allowance for a company of this size.

Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/reverse-geocoding/.

Why free support tiers should still get real answers

2026-09-20T22:42:00+00:00

It is common enough to be almost unremarkable: a support system with a fast, thoughtful response path for paying customers and a slow, templated, barely-read queue for everyone else. The logic is straightforward from a resourcing perspective, paying customers generate the revenue that funds support staff, so it makes sense to prioritize their tickets. The result, though, is that a free tier user with a genuine, well-formed technical question gets a canned response, or no response at all, purely because of which pricing tier they happen to be on, regardless of how legitimate or how easy to answer the question actually was.

We think this creates a bad first impression at exactly the point where a first impression matters most. A developer testing an API for the first time, on the free tier, encountering a genuine problem, and getting a dismissive or absent response is learning something real about what support looks like after they start paying, not something separate from it. Free tier support quality is not a cost center disconnected from paid customer experience. It is a preview of it, and treating it as disposable sends exactly the wrong signal to the customers a company most wants to eventually convert.

This does not mean every ticket, regardless of tier, needs the same response time or the same depth of hands-on engineering attention. A large paying customer with a production incident reasonably gets faster and more direct attention than a general question from someone testing on the free allowance. The distinction we care about is between prioritization, which is a reasonable operational reality, and dismissal, which is treating a question as not worth a real answer at all because of the account it came from.

Part of why this matters more for us specifically is that our free tier is meant to be a genuine evaluation path, not a token gesture: 2,500 requests a day, enough to build and test a real integration. If someone hits a real, confusing problem while doing exactly that evaluation, and the support response they get is a form letter, the free tier has failed at its actual purpose, which is to let someone find out honestly whether the product works for them. A support interaction that answers nothing is part of that evaluation too, whether or not it was meant to be.

We do not think this requires unlimited support staff time devoted equally to every account regardless of scale, which would not be sustainable. It requires deciding that a real question deserves a real answer, proportionate to its complexity, regardless of which tier asked it. A templated non-answer costs almost nothing to send and communicates almost exactly the wrong thing: that the question, and the person asking it, were not worth the time.

Add postal code auto-fill to a shipping form

2026-09-20T21:49:00+00:00

A shipping form with separate fields for postal code, city, and region asks a customer to type information that a single postal code often already implies.

Looking up the code

Once a customer finishes typing a postal code and selects a country, or if country is already known from their account, send both to /v1/postcode.

GET /v1/postcode?code=SW1A 1AA&country=GB

{
  "status": "ok",
  "postcode": "SW1A 1AA",
  "country_code": "GB",
  "results": [
    {"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London", "country": "GB"}}
  ]
}

Filling the form fields

Populate the city and region fields directly from the components object in the result, and let the customer confirm or correct them rather than locking the fields entirely, since a postal code occasionally spans a boundary or covers more than one commonly used place name.

A second example: prefilling a billing region for tax purposes

The same lookup fits a signup or billing form that needs a customer's region for tax calculation purposes, not just a shipping form. Triggering the same postcode lookup once a billing postal code is entered fills the region field consistently in both contexts using the identical request and response shape, so the same client-side and server-side handling code can serve both forms.

Triggering the lookup at the right moment

Run the lookup once the postal code field loses focus, or once it reaches the expected length for the selected country, rather than on every keystroke, since a postal code is only meaningful to look up once it is complete. This keeps the feature to one request per completed field entry rather than one per character typed.

A common mistake to avoid

Do not hard-code a fixed expected length for every country's postal code format. A five-digit assumption that works for one country will trigger the lookup too early or never at all for a country using a different length or an alphanumeric format like the example above. Either trigger on focus loss regardless of length, or maintain a small per-country length table if you want to trigger earlier for countries you support most often.

Handling an unrecognized code

An empty results array means the code was not recognized for that country, most often because of a typo. Leave the city and region fields blank and let the customer fill them in manually rather than blocking form submission, since rejecting the field outright over an auto-fill failure is a worse experience than simply asking for manual entry in that one case.

An edge case: a code covering more than one place name

Some postal codes legitimately cover an area known locally by more than one place name, or sit right at a boundary between two commonly used city names. When this happens, showing the returned value as an editable suggestion rather than a fixed label lets the customer correct it to whichever name they actually use, without treating either as more or less official than the other.

Getting exact coordinates once the address is complete

Auto-fill from a postal code gives an area-level location, which is enough for city and region fields, but once the customer has typed a full street address on top of that, running the complete address through /v1/forward gets you the precise coordinates a shipping label or delivery routing system actually needs.

What it costs

Each completed postal code field triggers one request. A shipping form processing many orders a day still uses this feature at a modest rate, one lookup per order rather than per keystroke, keeping it well within the 2,500 free requests a day included with every key for most stores.

Auto-filling city and region from a postal code cuts a shipping form down by two fields for the large majority of customers who type a valid code. Full field definitions are on the postal code lookup docs.

Data processing agreements: what changes when you switch vendors

2026-09-20T21:39:00+00:00

A vendor migration in geocoding or IP data is not purely a technical exercise, since the data flowing through these APIs, addresses, coordinates, and IP addresses, often qualifies as personal data under privacy regulations in a meaningful number of jurisdictions. Switching providers means switching who is processing that data on your behalf, and that change deserves the same review a new vendor relationship would get in any other part of a business, not less scrutiny just because the technical migration is small.

A few specific things worth reviewing when evaluating a new location data vendor from this angle, separate from the technical evaluation:

Where the data is processed and stored. Depending on your regulatory obligations, the geographic location of a vendor's infrastructure and any sub-processors involved can matter as much as the vendor's technical capability. This is worth confirming directly with any new vendor rather than assuming it matches your previous provider's setup.

What data is retained, and for how long. IP addresses and query addresses sent to a geocoding or IP lookup API are, by nature of the request, transmitted to that vendor. Understanding whether and how long a vendor retains that data, separate from whether it processes it to return a result, is a distinct question worth asking explicitly rather than assuming based on the vendor's general reputation.

Whether a data processing agreement is available and what it covers. Many jurisdictions' privacy frameworks expect a formal agreement covering how a processor handles data on a controller's behalf. Confirming this exists, and reading what it actually says rather than just confirming its existence, is worth doing before committing to a new vendor relationship, exactly as it would be for any other data processor a business relies on.

How the change affects your own privacy notices and internal documentation. If your organization's privacy policy or internal data flow documentation names a specific vendor, or a category of vendor with specific characteristics, a migration means updating that documentation to reflect the new relationship accurately, which is easy to overlook amid the technical work of the migration itself.

My Geocode is a company built specifically to run a geocoding API, described plainly as: we build and run a geocoding API, that is the whole company. For any specific compliance question relevant to your own regulatory obligations, whether that involves data processing terms, retention practices, or infrastructure location, the direct path is to review the relevant terms and privacy documentation for the specifics that apply to your situation, since these are the kind of details that deserve a direct, current answer rather than a general summary in a blog post. See /pricing/ and /about/ for more on how the company operates, and reach out through /contact/ with specific compliance questions relevant to your migration.

Treating this review as a normal part of vendor onboarding, not a special extra step required only for large enterprises, keeps a technical migration from accidentally creating a compliance gap that surfaces much later, usually at the worst possible time, during an audit or a customer's own vendor review.

Data licensing and why some sources can't be used commercially

2026-09-20T21:17:00+00:00

It is a common and understandable mistake to assume that if a dataset is publicly accessible, it is automatically fine to use inside a commercial product. In practice, public accessibility and commercial usability are two entirely separate questions, and a meaningful amount of location data that is genuinely free to view, download, or reference for personal or research purposes carries licensing terms that specifically prohibit or restrict its use inside a product you charge money for, or even inside a free product that is part of a broader commercial business.

This distinction matters because location datasets are compiled through real, often substantial ongoing effort: surveying, aggregation, verification, and continuous maintenance to keep the data current as the real world changes underneath it. The organizations and governments that produce this data reasonably attach licensing terms that reflect how they want that effort used and, in many cases, compensated, and those terms vary enormously from one source to the next. Some data is released under genuinely open terms with generous or no commercial restrictions. Some is free for personal or non-commercial use only. Some requires a specific paid commercial license before any business use is permitted, regardless of how the underlying data is technically accessed or how small the intended use might seem.

Building a product on any external location data source without checking this specifically, and without keeping track of it over time, since terms can and do change when they are updated or reissued, is a genuine business and legal risk, not merely a technical or data quality concern in the sense most of this series has otherwise focused on. It is worth treating licensing due diligence as its own explicit step in evaluating any data source, separate from and in addition to evaluating that source's actual accuracy and coverage, since a dataset can be excellent on every technical measure and still be the wrong choice if its licensing terms do not actually permit the specific commercial use you have in mind.

This is also, practically speaking, part of why commercial geocoding and location APIs exist at all as a category of product, rather than every company simply compiling and using open data directly on their own. A significant part of what you are paying for with a commercial provider is the licensing clarity itself: a clear, contractual right to use the resulting data commercially, with the underlying licensing complexity, and its ongoing maintenance as terms shift over time, handled on your behalf rather than left for you to track and manage yourself across every individual source involved.

If you are evaluating any provider for a commercial product, ask directly and explicitly about licensing terms for commercial use, not just about accuracy or coverage figures, since a technically excellent dataset with the wrong license is not actually usable for your purpose regardless of how good the data itself looks in isolation. Our pricing page covers usage terms for both the free daily allowance and paid usage beyond it.

Adding a country flag and local time to user profiles

2026-09-20T19:33:00+00:00

A remote team collaboration tool had a profile field for time zone that almost nobody filled in correctly, since it required a person to manually select their own time zone from a long dropdown list during onboarding, a step easy to skip or get wrong, especially for someone who had just moved or was traveling when they set up their account. The result was a team directory full of stale or missing time zone data that nobody trusted enough to actually use when deciding whether to message a colleague.

The company replaced the manual field with an automatic one. Rather than asking a user to select their time zone, the app resolved it directly from the connection making the request. /v1/ip took the user's IP address at login and returned country and coordinates, and those coordinates fed into /v1/timezone, which returned the IANA time zone name for that location, kept fresh by re-resolving periodically rather than locking in whatever a user's location happened to be the one time they filled out a form.

The visible result in the product was a small addition to every teammate's profile: a country indicator and a live local time, updating automatically, next to their name in the team directory and in any direct message conversation. A colleague deciding whether to send a message or wait until morning could see, at a glance, whether it was a reasonable hour where the other person was, without needing to remember which country they were based in or do any time zone math themselves.

The company kept this adjustable rather than fully automatic and unchangeable, since a user occasionally did want to override the detected location, someone working temporarily from a different country than they normally would, for example, and preferring their profile to reflect their usual time zone rather than wherever they currently happened to be connecting from. The automatic detection set a sensible default that updated on its own for the common case, while a manual override remained available for the exception.

This was a genuinely small feature in terms of engineering effort, essentially two lookups chained together at login and a small display change in the team directory, but it removed a piece of friction that had been quietly costing the team small amounts of coordination overhead for years, the low-grade cost of not knowing whether now was a good time to reach out to someone without asking first or just guessing.

Volume tracked login sessions rather than every single message or page view, since the location and time zone data was refreshed periodically rather than on every request, keeping the workload well within the free daily allowance even for a team collaboration tool with a meaningfully large user base logging in throughout the day.

Small, quiet defaults like this tend to matter more cumulatively than any single flashy feature, since they remove a tiny bit of friction from something that happens constantly rather than solving a problem that only comes up occasionally. Documentation for both endpoints is at /docs/ipv4-lookup/ and /docs/timezone-lookup/.

A grace period before an unverified key pauses

2026-09-20T18:29:00+00:00

Signing up and generating a key should not mean sitting around waiting for an email to arrive before you can actually test anything. New accounts on My Geocode get a grace period during which keys work fully, immediately after signup, whether or not the email address behind the account has been confirmed yet.

This exists for a straightforward reason: the moment right after signing up is exactly when someone wants to try their key and see the API actually respond, not read an inbox first. During the grace period, a new key authenticates and works exactly like any other, drawing on its own 2,500 free requests a day the same as a fully verified account, with the same quota headers on every response.

The grace period is not indefinite, though. If the email address tied to the account is never confirmed, keys on that account pause once the grace period ends, until verification is completed. This protects against accounts created with an email address that was never real to begin with, while still giving a genuine new user room to try the API before committing to the verification step.

Confirming an email address is a quick step available from the dashboard at any time, and doing it early removes any question of a key pausing later. For anyone planning to rely on My Geocode for something more than a quick test, verifying the account promptly is the simple way to make sure nothing interrupts a key partway through a project.

None of this affects pricing or quota behavior otherwise. A key inside its grace period, and a key on a fully verified account, both draw on the same free daily allowance, the same prepaid credit rate of €0.0001 a request beyond that, and the same Unlimited package option at €50 a month. The grace period only affects whether the key is currently active, not how much it costs to use or how it is metered.

If you signed up recently and have not yet confirmed your email, it is worth doing before the grace period ends, particularly if a key is already wired into something running unattended. Verification takes a minute inside the dashboard at /dashboard and removes the question entirely.

What "real-time" location data actually requires

2026-09-20T10:13:00+00:00

"Real-time" gets attached to a lot of location data products as shorthand for fast response times, and speed is a real and worthwhile thing to optimize for. It is also a different claim entirely from what "real time" should actually mean for data that describes something about the current state of the world: that the answer reflects what is true right now, not a fast, low-latency lookup against a dataset that itself was compiled some time ago and has not been meaningfully updated since.

This distinction matters most for IP geolocation specifically, because the mapping between IP address ranges and their physical location changes over time as address blocks get reassigned, reallocated, or repurposed by the regional internet registries that manage them. A lookup that responds in a few milliseconds against a stale mapping is fast and wrong at the same time, and speed does nothing to fix the wrongness. Genuine real time IP geolocation requires the underlying mapping itself to be kept current, with a live lookup process and a cache that gets refreshed rather than treated as a fixed, one-time snapshot.

We built our IP geolocation specifically around this distinction: it runs live, with caching used to keep response times low, not as a substitute for freshness, and a background retry process that keeps working through data that needs rechecking rather than a periodic cron job standing in as the only mechanism for keeping the mapping current. The goal is that the cache makes it fast without making it stale, which is a different design goal than a cache that exists purely to avoid ever recomputing anything, current or not.

The same distinction applies, in a different form, to time zone data. A fast response describing an offset that has not accounted for a recent daylight saving transition or a recent government rule change is not real time in any meaningful sense, even if it returned in ten milliseconds. Real time here means the underlying reference, the IANA time zone database in this case, is being tracked and applied as it changes, not that the response arrived quickly against a table nobody has touched recently.

We think "real time" deserves to be treated as a claim about data currency first and response latency second, even though latency is the part that is easiest to measure and demonstrate. A provider can genuinely optimize response time to a fraction of a second while quietly letting the underlying data go stale for months, and from the outside, a fast wrong answer and a fast right answer look identical until something downstream depends on the difference. The harder, less visible work is keeping the data itself current. That is the part that actually earns the label, and it is also the part a customer cannot verify just by timing a request.

Retiring old API keys safely after a migration

2026-09-20T10:12:00+00:00

Retiring an old provider's API key feels like a small, almost administrative step at the end of a migration, but getting the timing wrong in either direction carries real cost. Retire too early, before every dependent system has actually moved, and something still calling the old key breaks unexpectedly. Retire too late, or never, and an unused but still-valid credential sits around as a security liability nobody is actively watching.

The safest process treats key retirement as its own small project with a defined sequence, not an afterthought tacked onto the end of the main migration work:

Confirm zero traffic on the old key first, not just belief that migration is complete. Most providers offer some usage visibility for a given key; check it directly rather than assuming the migration checklist being marked done means the old key has actually gone quiet in practice.

Leave the old key valid but unused for a defined observation window after you believe migration is complete, rather than deactivating it the moment the new provider goes live. This window, typically a few weeks depending on your traffic patterns and release cycles, catches any forgotten call site, delayed mobile app update, or infrequently run batch job that still references the old credential.

Deactivate rather than delete the old key first, if your provider supports that distinction. A deactivated key that still exists as a record is easier to briefly reactivate if something unexpected turns up than a fully deleted one, giving you a safety margin during the observation window without extending it indefinitely.

Delete or fully revoke the old key on a specific decided date, and document that it happened. An indefinitely deactivated key is still a security surface someone could potentially reactivate if the account itself is ever compromised; a genuinely retired credential should eventually be removed for good, not left in a permanent limbo state.

Audit where the old key was stored, including configuration management systems, secrets managers, environment variable files, and any documentation or onboarding materials that might reference it, since a retired key that is still written down somewhere as "the API key" creates confusion for whoever reads that documentation next, long after the key itself has stopped working.

For a migration onto My Geocode, the new key can be scoped and monitored from day one using the quota headers present on every response, X-Quota-Used, X-Key-IPs-Used, and others documented at /docs/rate-limits/, which makes it straightforward to confirm the new key is actually carrying the traffic you expect before starting the clock on retiring the old one. Treating credential retirement with this level of deliberateness is a small amount of extra process for a meaningful reduction in both operational risk and lingering security exposure.

Build a heatmap from raw IP address logs

2026-09-20T09:25:00+00:00

An access log full of IP addresses has real geographic information buried in it, but only once each address has been resolved to coordinates that a mapping tool can actually plot.

Extracting addresses from the log

Pull the unique IP addresses out of your log file first, rather than looking up every single log line individually, since the same visitor address commonly appears many times across a session and there is no reason to pay for the same lookup repeatedly.

sort logfile.txt | awk '{print $1}' | sort -u > unique_ips.txt

Resolving in bulk

Send the list of unique addresses as a bulk POST array to /v1/ip.

POST /v1/ip
Content-Type: application/json

["203.0.113.10", "198.51.100.25", "192.0.2.44"]

{
  "status": "ok",
  "results": [
    {"ip": "203.0.113.10", "version": 4, "found": true, "country": "Germany", "country_code": "DE", "region": "Berlin", "city": "Berlin", "postcode": "10115", "lat": 52.5300, "lon": 13.3800, "timezone": "Europe/Berlin", "asn": 1111, "org": "Example ISP"},
    {"ip": "198.51.100.25", "version": 4, "found": true, "country": "Spain", "country_code": "ES", "region": "Madrid", "city": "Madrid", "postcode": "28001", "lat": 40.4168, "lon": -3.7038, "timezone": "Europe/Madrid", "asn": 2222, "org": "Example Networks"},
    {"ip": "192.0.2.44", "version": 4, "found": false}
  ]
}

Building the heatmap dataset

Pair each returned lat and lon with the frequency count of that original address in your log, so a visitor who appears a hundred times in the log contributes proportionally more weight than one who appears once. Feed the resulting list of weighted coordinate points into whichever mapping or charting tool you use to render the heatmap.

A second example: a country-level breakdown instead

If a precise point-by-point heatmap is more detail than you need, aggregating by country_code instead of raw coordinates produces a simpler choropleth-style view, one figure per country rather than a scattered cloud of points. This uses exactly the same bulk lookup, just grouped differently once the results come back, so it costs nothing extra to build both views from the same resolved data.

Handling addresses that do not resolve

An entry with found: false, as in the third result above, should simply be excluded from the heatmap rather than plotted at a default location, since including it would misleadingly cluster unresolved traffic somewhere on the map that has nothing to do with where it actually came from.

A common mistake to avoid

Do not skip filtering out obvious non-visitor traffic, such as internal health checks or monitoring services that hit your server constantly from a fixed address, before building the unique address list. A monitoring service polling every minute can rack up a disproportionate log line count that has nothing to do with real visitor geography, and while deduplication already limits it to one resolved point, that one point can still visually dominate a heatmap out of proportion to any real traffic pattern it represents.

An edge case: hosting and data center traffic

The org field on a resolved address often reveals when traffic is coming from a data center or cloud hosting range rather than a residential or mobile connection, which is a reasonable signal for filtering out bot or scraper traffic before it skews a heatmap meant to represent real visitor locations.

What it costs

Resolving unique addresses rather than every log line is what keeps this affordable, since request cost is one per unique address, not one per log line. A log with a million lines but only a few thousand unique visitor addresses costs a few thousand requests, not a million, comfortably manageable against prepaid credit or an Unlimited package for a large site, and often within the free allowance for a smaller one. Watching the X-Quota-Used header during a large batch job is a simple way to confirm usage is tracking as expected before the job finishes.

Deduplicating before you resolve is the single biggest lever for keeping a log-based heatmap affordable. The IPv4 lookup docs cover the bulk request format in full.

How we treat null and low-confidence results

2026-09-20T09:06:00+00:00

There is a real temptation, in any system that answers questions, to always return something rather than admit a question cannot be answered reliably. For location data specifically, giving in to that temptation is actively harmful, because a plausible-looking but wrong answer is generally far more damaging to whatever decision it feeds into than an honest admission that the data does not support a confident answer.

The reasoning is straightforward once stated directly. A null result, or a result explicitly marked with low confidence, is something a well designed application can detect and handle deliberately, falling back to asking the user for clarification, applying a wider default, or flagging the record for manual review. A manufactured guess that looks like every other confident result, with no visible signal that it was actually a weak or ambiguous match, cannot be detected or handled specially at all, because from the outside it is indistinguishable from a genuinely solid answer, right up until it causes a real, visible problem somewhere downstream that is often difficult to trace back to its actual source.

This is why an ambiguous or unresolvable query should return either no result at all, or a result whose confidence score honestly and clearly reflects the genuine uncertainty involved, rather than the geocoder silently picking one plausible candidate among several and presenting it with the same apparent certainty as an unambiguous match. The same principle applies to precision: a result should never claim a finer precision level than the data actually supports, even under pressure to always return something more specific looking. Reporting city honestly is a better outcome than reporting house on a guess.

For anyone building on top of this kind of data, the practical implication is to design your own application to genuinely expect and gracefully handle null and low-confidence results as a normal, routine part of the response space, not as a rare exceptional case requiring special separate handling bolted on as an afterthought. A form that only has a happy path for high-confidence, fully resolved results, with no considered behavior for anything else, will eventually break in a confusing way when it inevitably encounters a query the data genuinely cannot resolve confidently, which happens more often than most initial designs anticipate.

Checking both precision and confidence on every result, and having a deliberate, considered fallback behavior for when either one falls below whatever threshold your specific use case actually requires, is the difference between an application that degrades gracefully on hard cases and one that quietly propagates bad data because it was never actually designed to expect anything but a clean, unambiguous answer.

Building a nonprofit volunteer matching tool by distance

2026-09-20T06:47:00+00:00

A volunteer willing to help but unwilling to drive forty minutes each way is a volunteer who quietly stops responding to requests, and a community nonprofit coordinating several hundred volunteers across a metro area found that its old matching process, a coordinator manually recalling who lived roughly near a given need and reaching out individually, was both slow and increasingly unreliable as the volunteer list grew past what any one person could keep in their head.

Both sides of the matching problem, volunteer home addresses and the addresses of ongoing needs, whether a food pantry needing regular help, an elderly resident needing occasional assistance, or a community event needing setup volunteers, existed as text addresses collected through simple signup and request forms. Turning those into something that could be matched by actual proximity started with geocoding both lists through /v1/forward, run as a batch for the existing volunteer roster and needs list, then per new entry as fresh signups and requests came in.

With coordinates on both sides, matching became a distance calculation the nonprofit's own simple database could run directly: for any new need, rank registered volunteers by actual distance from their home address, then reach out starting with the closest ones rather than relying on whoever a coordinator happened to remember lived in the right part of town. This surfaced volunteers who had been sitting unused in the system for reasons that had nothing to do with willingness, simply because a coordinator did not personally know they lived near a particular recurring need.

The nonprofit kept a human coordinator in the loop for the actual outreach and matching decision, since distance was an important factor but not the only one, a volunteer's specific skills, availability, or existing relationship with a particular need sometimes mattered more than being the closest option, and the tool's job was to surface a ranked, distance-sorted list a coordinator could work through quickly rather than to fully automate an assignment a coordinator would rather review first.

Response rates from volunteers improved noticeably once outreach started consistently targeting genuinely nearby people first, an outcome that made intuitive sense once the organization saw it clearly in its own data: a request that was actually convenient for a volunteer to fulfill was simply more likely to get a yes than one further away that a coordinator had reached for out of familiarity rather than proximity.

Because it operated as a nonprofit with real budget constraints, cost mattered specifically here, and the project's usage, a modest batch geocoding run for the initial roster plus a small ongoing trickle for new signups and requests, fit comfortably inside the free daily allowance without ever needing to consider prepaid credit or an Unlimited key, meaning the entire location matching capability came at no cost to an organization for whom every dollar of a limited budget mattered.

If a community organization is considering something similar, the starting point is smaller than it sounds: geocode what addresses you already have, and see what distance-based matching actually looks like against your real volunteer and need lists before building anything more elaborate on top of it. Documentation for the endpoint is at /docs/forward-geocoding/.

A new bulk endpoint for address lists

2026-09-20T06:40:00+00:00

Processing a list of addresses one at a time, one HTTP call after another, works fine for small volumes and becomes tedious fast at any real scale. We now support sending an entire address list as a single bulk call, cutting down the round trips needed to process a large list without changing how anything is priced.

The counting rule here is exactly the one we apply everywhere else on the platform: each address inside a bulk call counts as one request, not the call as a whole. Send a list of five hundred addresses in one bulk call, and that consumes five hundred requests against whatever allowance applies, whether that is the free daily allowance, prepaid credit at €0.0001 a request, or coverage under an Unlimited package. There is no discount and no penalty for combining work into a single call versus sending it as many smaller ones.

Quota headers reflect the bulk call accurately as well. X-Quota-Used, X-Quota-Free-Remaining and X-Credits-Remaining all move by the number of addresses actually processed in the call, so a large bulk request updates your visible quota the same way five hundred individual calls would have, just in one round trip instead of five hundred.

This is aimed at exactly the kind of workload that used to mean writing a loop around single-address calls: importing a customer list that needs geocoding, cleaning up an address database, or preparing a large batch job that runs on a schedule rather than in response to a single user action. Sending that list in one bulk call reduces the overhead of managing many separate HTTP connections, particularly useful for jobs that run on infrastructure with its own connection or rate constraints beyond ours.

Authentication and general behavior are unchanged: the same four key methods work, the same quota rules apply, and the same free allowance covers meaningful testing before any real cost is involved. As with any address-based lookup, forward and reverse geocoding results are still part of our currently developing backend for populated real-world results, so this bulk capability is documented around its request shape and counting behavior specifically.

Full documentation for sending bulk requests, including request formatting, is available at /docs/forward-geocoding/ and /docs/reverse-geocoding/. If your workflow currently loops over single-address calls, this is worth a look for anything processing more than a handful of addresses at once.

Set sensible timeouts for high-volume batch jobs

2026-09-19T21:44:00+00:00

A timeout value that works fine for a single address lookup will cut off a bulk request carrying a few thousand items well before the server has finished processing all of them, which looks like a failure even though the request would have completed given enough time.

Why bulk requests need more time

Each item in a bulk array is a lookup in its own right, so a request with 2,000 items in it involves roughly 2,000 times the processing of a single lookup, even though it is one HTTP call from your side. A one or two second timeout, reasonable for a single address, is nowhere near enough for a request of that size.

Scaling the timeout to the batch

Set your client's timeout proportionally to the size of the array you are sending, with some margin for typical variation, rather than using a single fixed value across every request your code makes, small or large.

timeout_seconds = max(5, item_count * 0.05)

This is a starting point to tune against your own observed behavior, not a fixed number to treat as authoritative, since actual per-item processing time is not a published guarantee.

Preferring smaller chunks over one giant request

Rather than pushing timeout values higher and higher to accommodate an ever larger single request, split a very large job into chunks of a few hundred to a few thousand items each. Smaller chunks need shorter, more predictable timeouts, and a failure partway through only costs you the current chunk rather than the entire job.

Handling a timeout that does happen

If a request does time out on your end, you may not know whether the server actually finished processing it or not. Rather than blindly resubmitting the same chunk, which could double-count against your quota if the original request did complete, check your quota headers from your most recent successful call to estimate whether the timed-out chunk likely went through, and resubmit cautiously.

Cost is unaffected by timeout settings

A timeout is purely a client-side setting about how long you are willing to wait. It has no effect on what a request costs, still one request per item processed, whether your client waited the full duration or gave up early.

Matching your timeout to your batch size, and preferring several smaller chunks over one very large request, keeps large jobs both reliable and easy to resume if something goes wrong. Chunking and quota strategy for large jobs is covered further on the rate limits docs.

Why elevation data gets treated as an afterthought

2026-09-19T21:04:00+00:00

Elevation data has an image problem in this industry more than a technical one. It gets framed as a nice-to-have, a flourish added to a map view or a flight planning tool, rather than as data that genuine, practical applications actually depend on: flood risk assessment, drainage planning, agricultural work, aviation clearance calculations, construction site evaluation. None of these are niche uses. All of them need ground elevation to be treated with the same seriousness as a coordinate or an address, not as a decorative extra bolted onto a mapping product.

We built elevation as a real endpoint with its own place in the product, not as an obscure optional field buried in a geocoding response that most integrations never notice exists. It is priced the same as everything else, covered under the free daily allowance and billed at the same €0.0001 per request beyond it, or included under the same €50 Unlimited key, exactly like geocoding, IP, and time zone lookups. There is no separate, higher price attached to it that would signal it is considered a specialty feature rather than a standard one.

Part of why elevation gets underrated is that it is genuinely less visible in a typical consumer-facing product than an address or a pin on a map. Nobody notices elevation data directly the way they notice a wrong address on a delivery form. That invisibility to the end user does not make the underlying data less important to the systems that depend on it. A drainage calculation that is off because the elevation figure feeding it was wrong does not announce itself the way a bad address does. It shows up later, as a real-world consequence, in a decision that assumed the ground height was correct.

We treat elevation as one of the parts of our product that is fully working and safe to describe concretely, alongside IP and time zone data, specifically because we think it deserves the same confidence and the same investment as any other core endpoint, not a hedge or a footnote. It is also available as an opt-in addition layered onto a standard response for callers who want ground elevation alongside a location lookup they are already making, rather than requiring a separate specialty product or a separate contract just to access it.

The broader point is that elevation is exactly the kind of data category that suffers when a product treats visibility to the end user as a proxy for actual importance. Some of the most consequential uses of location data in agriculture, engineering, and risk assessment run entirely on data the end user of the resulting product will never directly see. Building that data well, and pricing it like a standard feature rather than a specialty add-on, is a bet that the invisible parts of a system deserve the same care as the visible ones, because the decisions built on top of them are just as real.

Business versus residential IP classification, and its limits

2026-09-19T20:32:00+00:00

Classifying an IP address as belonging to a business connection or a residential one is a genuinely useful signal for a range of applications, fraud scoring, B2B sales targeting, network security policy, but it is worth understanding that this classification is an inference drawn from network characteristics, not a directly verified fact about who is actually using that address at any given moment.

The classification typically draws on signals like how the address block is registered, whether it is associated with a residential ISP's typical customer allocation pattern versus a commercial or dedicated line allocation, and characteristics of how the organization behind the ASN is generally known to operate. A block registered to and consistently used by a residential broadband provider for typical home internet service gets classified as residential. A block registered to and used by a business connectivity provider, or associated with a specific known commercial entity, gets classified as business.

The limits on this inference are real and worth keeping in mind. A residential connection can be used for legitimate business purposes, someone working from home on their home internet connection looks, from a network classification standpoint, identical to any other residential user, even though the actual use in that moment is business activity. Conversely, a business-classified connection does not guarantee that traffic from it represents an actual business decision-maker or company activity, since plenty of individual, personal traffic passes through business networks for all kinds of ordinary reasons, a shared office connection, a coworking space, a mixed-use building. The classification describes the type of network connection, not the nature of the specific activity or user behind any individual request at any given moment.

This means business versus residential classification is best used as one input among several rather than as a definitive answer on its own. For fraud scoring, it works well combined with other signals like whether the address also matches known hosting or VPN infrastructure, and how consistent it is with other information you have about the request. For sales or marketing targeting, it is a reasonable filter to narrow a broad audience but should not be treated as a guarantee that every visitor from a business-classified address is currently acting in a business capacity, or that every residential-classified visitor is definitely not.

The organization field, combined with asn, gives you the underlying detail needed to make this kind of classification yourself, or to sanity-check a classification, with a level of transparency into what is actually known about the network rather than a black-box label alone. It is available through our IPv4 and IPv6 lookups, and treating it as one strong signal among several, rather than as a final answer by itself, is the more reliable way to build on top of it.

IP threat and network detail available on request

2026-09-19T20:26:00+00:00

A location is often only part of what matters about an IP address. Whether that address is associated with known threat activity, and what kind of network it actually belongs to, can matter just as much for fraud prevention, access control, or general risk assessment. /v1/ip now returns exactly that information as an optional extra, available whenever you ask for it.

Adding mg_extras=1 to a request, or sending an X-MG-Extras header, layers IP threat and network detail on top of the standard location response, without changing anything about the base fields already returned. Leave that flag off, and the response is exactly what it always was. Add it, and the same call returns additional detail alongside the location fields you already receive.

This same mechanism applies to ground elevation as well, so mg_extras=1 is a single, consistent way to request additional depth across different endpoints, rather than a separate flag per feature. It also applies across our compatibility hosts, so a request shaped for ip-api.com, ipinfo.io, or ipstack can add the same flag or header on top of its otherwise exactly matched request and response format, gaining threat and network detail without breaking compatibility with the original shape.

Pricing does not change based on whether extras are requested. A lookup with mg_extras=1 added counts as the same single request against your free allowance, prepaid credit, or Unlimited package as a lookup without it. There is no separate, more expensive tier for the additional detail, and no separate quota to track for extras specifically.

This is aimed squarely at use cases where location alone is not enough. An application screening signups for suspicious activity, a service deciding whether to apply extra verification to a given connection, or a security tool building a broader picture of network reputation can all pull that context directly from the same /v1/ip call they are already making, rather than maintaining a second integration with a separate threat intelligence provider just for that one piece.

Full documentation for the IP endpoints, including how to add extras, is available at /docs/ipv4-lookup/ and /docs/ipv6-lookup/. Since it is entirely opt in, testing it against an existing integration is as simple as adding one flag to a call you already make.

Your first week after migrating: what to watch

2026-09-19T20:05:00+00:00

The first week after a migration goes live is when the gap between what testing covered and what real production traffic actually looks like tends to show up. Testing, no matter how thorough, samples a finite set of scenarios; a full week of live traffic exposes the long tail of real usage that a test plan almost never fully anticipates.

A few specific things worth watching closely during that first week, beyond the general error rate dashboards most teams already check:

Request patterns you did not think to test. Real users type addresses with typos, unusual formatting, and regional conventions your test data may not have covered. Watching for an uptick in "no results found" responses, specifically, compared to your pre-migration baseline, can surface address formatting or matching differences between providers that clean test data missed.

Quota consumption against your actual estimate. If you estimated your quota needs before migrating, the first week is when that estimate meets reality. Checking the X-Quota-Used and X-Quota-Free-Remaining headers, documented at /docs/rate-limits/, against your projected daily volume tells you quickly whether your estimate was close or needs adjusting before you commit to a specific pricing tier for the longer term.

Response time distribution, not just averages. An average response time that looks fine can hide a smaller but meaningful tail of slow requests that only shows up under real concurrent load, something a limited test environment rarely reproduces accurately.

Any code path that still silently references the old provider. Migrations sometimes miss a call site, particularly one in a less frequently exercised feature or an infrequently run background job, and the first week is often when that gap surfaces on its own, usually through a support ticket or an unexpected log entry rather than through active searching.

Cached data drifting between old and new provider results. If your migration plan involved any of the cache handling approaches discussed elsewhere, tagging entries by source provider or letting old entries expire naturally, the first week is when it is worth actually checking that this is behaving as designed rather than assuming it.

Setting a specific, brief daily check-in during this first week, even just fifteen minutes reviewing the relevant dashboards and headers, catches most of what a migration might have missed far earlier than waiting for a problem to surface as a support ticket. After the first week without significant issues, most teams can reasonably step down to normal monitoring cadence, having used that window specifically to catch the differences that only real traffic, not testing, can reveal.

If something does turn up that testing missed, having a rollback plan ready from before the migration, rather than improvising one under pressure, is what keeps a rough first week from becoming a genuinely bad one.

Detecting data residency for GDPR compliance

2026-09-19T18:56:00+00:00

GDPR compliance touches more of a product's technical architecture than most teams expect going in, and one of the more concrete requirements a SaaS company ran into was needing to know, reliably and at the start of every session, whether a visitor was connecting from inside the European Union, since that answer decided which data storage region a new account's data should be routed to and which consent flow needed to be shown before any non-essential data collection started.

Self-reported location was not reliable enough for this. Asking a visitor to declare their own country during signup produces answers people sometimes skip, mistype, or simply get wrong when signing up quickly, and the company needed a signal that did not depend on a form field being filled in correctly to make a compliance-relevant decision.

/v1/ip gave the company an independent, server-side signal for this. Resolving a visitor's IP address into a country field, checked automatically at the start of a new session, told the company's application server whether to apply EU-specific consent and data handling rules before the visitor had interacted with anything on the page at all, rather than after the fact once some data collection had already happened.

The company treated the detected country as a strong operational signal for this purpose specifically because GDPR's own protections are generally understood to apply based on where a person is located when their data is processed, not based on their nationality or where a company is headquartered, which made an IP-based location check a genuinely relevant signal for this particular compliance question in a way it would not necessarily be for, say, determining which country's tax law applied to a transaction. The company's own legal counsel reviewed this approach specifically and treated it as one reasonable input into a broader compliance program, not a complete solution by itself.

Edge cases were handled conservatively rather than optimistically. A visitor whose IP resolved ambiguously, or where a VPN or proxy was detected using the extras field available with mg_extras=1 or the X-MG-Extras header, defaulted to the stricter EU-consistent handling rather than the lighter default, on the reasoning that applying stronger privacy protections to a visitor who did not need them was a far smaller problem than applying weaker protections to one who did. This conservative default was a deliberate policy decision made with legal guidance, not something the location lookup itself determined.

The company logged which country signal had driven each session's data handling decision, alongside a timestamp, as part of its own compliance documentation, giving it a concrete, auditable record of how these decisions were made if a regulator or auditor ever asked, rather than an unverifiable claim about how the system generally behaved.

None of this replaces broader GDPR compliance work around consent language, data subject rights, or a company's underlying data processing agreements, and the company was explicit internally that IP-based country detection solved one specific, narrow piece of a much larger compliance picture, the piece about routing a session to the right handling rules at the moment it started.

Volume matched session volume, comfortably inside the free daily allowance for moderate traffic and moving into prepaid credit predictably as the product grew. Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/.

The case against charging extra for basic authentication methods

2026-09-19T10:06:00+00:00

Authentication is one of the more mundane parts of using an API, and it is exactly the kind of mundane detail that ends up gated behind a pricing tier more often than it should be. Some providers reserve certain authentication methods, HTTP Basic auth, or a Bearer token pattern, for higher paid tiers, while a lower tier only supports a single, specific header format. The technical cost difference between validating one authentication style and another is close to nothing. What differs is how convenient each one is for a given customer's existing code, which has nothing to do with how much they should pay to use the API at all.

We accept a key as an X-API-Key header, an Authorization Bearer header, HTTP Basic auth with the key as the username, or a query parameter, on every host, at no extra cost for any of them. Whichever pattern already fits your existing code, whatever library or internal convention your team already uses for other APIs, is very likely already supported without needing to restructure anything just to match a specific format we happened to prefer.

The reasoning behind gating authentication methods by tier is not really about cost. It is about tier differentiation for its own sake: finding features to reserve for a higher-paying customer, even features that cost nothing extra to provide, simply because having more features locked behind a higher tier makes the higher tier look more valuable on a comparison table. Authentication methods are an easy target for this because supporting several of them is genuinely low effort for the provider and genuinely convenient for the customer, which makes gating it purely a monetization decision rather than one grounded in any real cost difference.

We think this kind of gating quietly punishes developers for a decision that has nothing to do with how much value they are getting from the actual data. A team whose existing tooling defaults to Bearer tokens should not pay more than a team whose tooling defaults to a custom header, when both teams are asking the exact same lookup and getting the exact same answer back. The value of the product is the response. The authentication method is plumbing, and plumbing should not carry a price tag based on which pipe happens to fit your existing wall.

There is a broader principle here that applies past authentication specifically: features that cost the provider nothing extra to offer should not become artificial tier boundaries just because they can be. A tier structure built around genuine cost differences, like request volume, is defensible. A tier structure padded out with low-cost conveniences reserved for higher payers exists mainly to make the pricing page look more differentiated than the underlying product actually is.

What changes when a country redraws its administrative borders

2026-09-19T09:47:00+00:00

Administrative boundaries within a country, regions, provinces, districts, are not permanent fixtures any more than time zone rules are. Governments periodically redraw them: merging smaller units into larger ones, splitting a large unit into smaller ones, adjusting a boundary line to reflect population growth, or renaming a region entirely as part of a broader administrative reorganization. Each of these changes ripples outward into every dataset that references the old boundary, and that ripple rarely completes everywhere at the same time.

The immediate effect is on any address or coordinate whose administrative label depends on the boundary that changed. An address that correctly listed one region name before a boundary adjustment may need to reflect a different region afterward, even though the physical building itself has not moved an inch, and the coordinate for that building remains exactly as accurate as it always was, since coordinates describe physical position while administrative labels describe a legal designation layered on top of that position.

This creates a real and specific challenge for keeping location data current, because different systems referencing the same underlying geography update on different schedules. A government's own official records update at the moment the change takes legal effect. Third-party datasets that reference administrative boundaries, and the internal systems built on top of them, generally lag by some amount, and how much they lag depends entirely on how frequently that data source is refreshed and how quickly it can identify and propagate a boundary change once it has occurred. Until that data source catches up, a query against it can return an administrative label that is technically outdated even though the coordinate itself was never wrong.

For anyone building on this kind of data, the practical implication is to treat administrative labels, region and district names in particular, as data with its own refresh cadence, separate from the more stable underlying coordinates, and to expect boundary changes to introduce a transition period where different systems may briefly disagree about which administrative label currently applies to a given area. This is a genuine, recurring category of data maintenance, not an occasional anomaly, and building systems that can tolerate a stale administrative label without catastrophic downstream effects is more realistic than assuming boundary data is permanently fixed once compiled.

Coordinates and administrative components returned through our reverse geocoding and postal code lookup endpoints reflect currently maintained boundary data, and like any location data source, benefit from being refreshed on a schedule aware that administrative geography, unlike physical geography, is something a government can and does periodically redraw.

Rate limit differences to expect when you switch providers

2026-09-19T09:08:00+00:00

Rate limits differ across providers in ways that go beyond the raw number of requests allowed, and a migration that only checks the headline limit can miss structural differences that matter more in practice than the number itself.

A few structural dimensions worth checking specifically, for any provider you are moving to or away from:

What the limit is counted against. Some providers limit by API key alone. Others limit by IP address, by account, or by some combination. My Geocode's structure counts the free allowance per network, meaning per /24 for IPv4 or per /48 for IPv6, and this is shared between keyless and keyed use originating from that same network. That is a meaningfully different model from a limit counted purely per key, and it matters specifically for applications running behind a shared IP range, such as a corporate network or a cloud environment where many instances share an address block.

How the limit resets. Daily, monthly, or a rolling window are all common approaches, and the difference affects how you should think about pacing a bulk job or handling a traffic spike. A limit that resets at a fixed daily boundary behaves differently under a burst of traffic than one on a rolling window basis.

Whether limit information is exposed on every response or requires a separate check. This affects whether your application can self-throttle proactively or has to discover it hit a limit only when a request fails. My Geocode exposes this directly: every response carries X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit, and X-Quota-Reset as headers, documented at /docs/rate-limits/, which means retry and pacing logic can read current status from the exact response it just received rather than polling a separate endpoint or dashboard.

What happens beyond the limit. Does the provider hard-stop requests, degrade to a slower response, or automatically bill overage. My Geocode's model beyond the free daily allowance is prepaid credit at €0.0001 per request or an Unlimited key at €50 a month, with every endpoint priced the same, which is worth comparing directly against whatever overage or throttling behavior your current provider uses, since these can differ meaningfully in how a traffic spike actually affects your application's behavior in the moment.

Before switching, it is worth explicitly rewriting any retry or backoff logic that references a specific header name, status code, or numeric threshold tied to your current provider, rather than assuming the same logic will simply work against a different provider's rate limit signals. This is a small piece of code in most applications, but it is exactly the kind of detail that silently breaks during a migration if it is not reviewed deliberately, since a rate limit error handled incorrectly tends to make a real traffic spike worse rather than better.