Use cases | 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/.

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/.

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/.

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/.

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/.

Building a route elevation chart for a running app

2026-09-19T08:12:00+00:00

Runners planning a route care about hills in a way that is hard to judge from a flat map alone, since two routes of the same distance can feel completely different depending on how much climbing is packed into them, and a running app's feature request board had one item near the top for months: show the elevation profile of a planned route before someone commits to running it.

The app's routing feature already produced a sequence of coordinates describing a planned run, generated from a start point, an end point, and the app's own path-finding logic along real streets and trails. What was missing was elevation data for each point along that path. /v1/elevation filled that gap directly: a list of coordinates sent in a single request came back as a matching list of elevation values, in the same order, ready to plot against the runner's cumulative distance along the route.

The resulting chart, elevation against distance, gave runners exactly what the feature request had been asking for: a clear view of where the climbs sat along a planned run, how steep each one looked relative to the rest of the route, and a total elevation gain figure that became, alongside distance and estimated pace, one of the headline numbers shown for every saved route in the app.

Sampling density mattered for cost control here, similar to how a cycling app would approach the same problem. A short neighborhood run needed elevation sampled fairly frequently to produce a smooth, accurate-looking chart, while a longer route could use a coarser sampling interval without the resulting chart looking noticeably different to a runner glancing at it, since a bulk elevation request counts each point as one billed item and the app's engineering team tuned sampling interval by route length specifically to avoid requesting far more points than the resulting chart's visual resolution actually needed.

The app added one more small feature on top of the same data: a "climb difficulty" badge on saved routes, calculated from total elevation gain relative to distance, giving runners a quick way to compare two routes of similar length without reading a full chart for each one, similar in spirit to how a hiking app might use the same underlying calculation for trail difficulty, just tuned for the shorter distances and different pace expectations of a typical run rather than a hike.

User engagement with saved routes increased after the feature launched, which the app's team attributed specifically to runners feeling more confident committing to an unfamiliar route once they could see what they were actually signing up for in terms of climbing, rather than discovering a route's difficulty only partway through running it for the first time.

Elevation lookups ran once per saved route rather than per run, since a route's elevation profile does not change between runs of it, keeping total request volume proportional to how many distinct routes users created rather than to total app usage, comfortably inside the free daily allowance for an app of moderate active user size.

Documentation for the endpoint, including point limits per request, is at /docs/elevation-lookup/.

Adding location context to a customer support chat

2026-09-18T19:57:00+00:00

A phone support agent gets a caller's area code before the conversation even starts, a small but genuinely useful piece of context. A live chat agent, by comparison, often starts with nothing but a name and whatever the customer types first, and a software company running live chat support wanted to close that gap by surfacing the same kind of basic location context automatically, without asking the customer anything extra.

The fix ran entirely server-side, at the moment a chat session started. /v1/ip resolved the visitor's IP address into country, region, city and a time zone field, all displayed in a small panel next to the chat window for the agent's own reference, never shown to the customer, since this was context for the agent's benefit rather than a feature the customer needed to see or interact with.

The immediate benefit was straightforward: an agent could see a customer's local time before responding, useful for judging whether "sorry for the delay" made sense or whether the customer had, in fact, been chatting at a completely reasonable hour for their own time zone. An agent could also see the customer's country and region without needing to ask, useful context for a support team handling a product with region-specific policies, shipping rules, or regulatory differences that changed what advice was actually correct to give.

The company was careful about what this location context was and was not used for. It informed how an agent framed a response and occasionally which knowledge base article was most relevant, given region-specific product differences, but it never automatically changed what the agent told a customer without the agent's own judgment involved, and it was never presented to the customer as a claim about exactly where they were, avoiding the discomfort some customers understandably feel when a company appears to know more about their location than they explicitly shared.

For customers on a VPN or a corporate network, the displayed location sometimes did not match where the customer actually was, and agents were trained to treat it as a helpful hint rather than a confirmed fact, particularly for anything where getting it wrong mattered, like assuming a specific regional policy applied to a customer whose account actually showed a different, more reliable location on file. Where the two disagreed, the account's own location data always took precedence over the IP-based hint.

This was a small addition to an existing support tool rather than a new product feature, added by the company's own engineering team to the internal agent dashboard the support software already provided, and it required nothing from the customer's side, no permission prompt, no location sharing dialog, since it worked entirely from the IP address already present in the chat connection.

Volume matched chat session volume directly, one lookup per new session, a workload well within the free daily allowance for the company's support chat traffic. Small context like this rarely gets noticed by name, but it changes, in a lot of small ways, how prepared an agent feels answering the very first message in a conversation.

Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/.

Building a broadband coverage checker for a service address

2026-09-18T06:30:00+00:00

A postal code level coverage answer is a good first filter, quick to check and useful for ruling areas in or out immediately, but it is not precise enough for a sales team about to schedule an installation, since coverage within even a single postal code area can vary meaningfully depending on exactly how far a specific property sits from the nearest network cabinet or fiber junction, a detail that matters enormously to whether an installation can actually happen on the timeline a salesperson wants to promise.

An internet provider building a more precise coverage checker for its sales team layered address-level detail on top of the postal code check it already offered on its public website. Once a visitor's postal code check came back positive, indicating the general area was served, the sales-facing version of the tool asked for the full street address and geocoded it through /v1/forward to get an exact coordinate. That coordinate got compared against the provider's own network infrastructure map, built and maintained internally from its buildout records, to give a much more specific answer: not just "this area is served" but an estimate of exactly which network segment would serve that property and what that implied for expected installation timeline and service tier.

This two-stage approach mirrored how a customer's own decision process actually worked. A visitor browsing casually wanted the fast, low-commitment postal code check, happy with a general yes or no before investing more effort. A sales conversation already underway, where a customer was seriously considering signing up, warranted the more detailed address-level check, since by that point both sides benefited from a precise answer rather than a general estimate that might turn out to be wrong for the specific property once an installation crew actually looked at it.

The provider used match confidence from the forward geocoding step as a practical signal for its own sales team too, not just as an internal data quality check. An address that resolved cleanly gave the sales team confidence to quote a specific installation timeline. An address that resolved with lower confidence, common for very new construction not yet fully reflected in mapping data, prompted the sales team to caveat the timeline more carefully or flag the address for a quick manual check against the provider's own most recent buildout records before making any specific promise to the customer.

None of this replaced the provider's own network data, which remained the actual source of truth for what could be installed where. The location lookups solved a narrower, specific problem: turning a customer's typed address reliably into the exact coordinate the provider's own infrastructure map needed to answer the coverage question precisely, rather than relying on a customer's postal code alone or a possibly inconsistent free-text address a sales rep had to interpret by hand.

Volume was concentrated among active sales conversations rather than casual browsing traffic, a smaller and more predictable number than the postal code checker's public traffic, comfortably inside the free daily allowance for the provider's sales team usage.

Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/postal-code-lookup/.

Verifying a rental property's address for a listing site

2026-09-17T19:19:00+00:00

A guest arriving at a vacation rental to find the pin on the map pointing at an empty lot, a different building entirely, or a location a few streets away from the actual property is a bad experience that reflects on the platform as much as on the host, and a vacation rental platform allowing self-service listing creation found this happening often enough that it warranted a real fix rather than relying on guest complaints to catch bad addresses after the fact.

Most cases were not deliberate fraud. Hosts entering an address by hand made ordinary typos, dropped a pin slightly off from the actual property while setting up a new listing, or entered a postal code that did not match the city and street they had typed elsewhere on the same form. A smaller number of cases did look more deliberate, addresses that resolved somewhere entirely different from what was claimed, sometimes tied to other signals suggesting a listing was not what it claimed to be at all.

The platform added a verification step to the listing creation flow. The address a host entered went to /v1/forward, which reported a match along with an indication of how confidently it resolved, and the platform compared that resolved location against the pin the host had separately dropped on a map during setup, flagging listings where the two disagreed by more than a small tolerance, a strong signal that either the typed address or the dropped pin was wrong, since a genuinely accurate listing should have both agree closely. The postal code entered was separately checked against /v1/postcode to catch cases where it did not correspond to the city also entered on the form.

Listings that passed both checks published normally. Listings with a mismatch between the typed address and the dropped pin, or a postal code inconsistent with the rest of the entered address, were held for a quick manual review, or in some cases sent back to the host with a specific prompt to double check and correct the flagged field before the listing could go live, catching the error at the moment it was easiest and cheapest to fix, before a guest had booked and traveled based on it.

The platform was clear internally that this verification confirmed an address was well-formed and consistent with the pin location, not that the property itself matched its photos or description in any other respect, a separate part of its trust and safety process that the address check did not attempt to solve. Treating the address check as one narrow, well-defined piece of a broader trust system, rather than asking it to do more than it reasonably could, kept expectations realistic both internally and in how the feature was described to hosts.

Volume tracked new listing creation and edits to existing listing addresses, a modest and predictable workload relative to the platform's total booking volume, comfortably inside the free daily allowance for a platform of moderate size.

Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/postal-code-lookup/.

Building a field service dispatch tool by distance

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

Assigning the nearest available technician sounds obvious until you look at how most small dispatch systems actually work, which is often by simple availability, next job to whichever technician finishes their current job first, regardless of whether that technician happens to be on the far side of the service area from where the new job is located. A home appliance repair company running a fleet of technicians found this was quietly costing it drive time across the board, technicians crossing the service area to reach jobs that a nearby colleague could have reached in a fraction of the time.

Fixing this required knowing, in coordinates, where every technician currently was and where every new job was located, rather than treating both as text descriptions a dispatcher had to reason about by memory of the local area. New job addresses were geocoded through /v1/forward as they came in, converting each service request into a coordinate the moment it was scheduled. Technician locations, tracked through their own mobile app as they moved between jobs, arrived as coordinates directly from device location, needing no geocoding themselves, but the reverse lookup, /v1/reverse, gave dispatchers a readable street-level description of where a technician currently was, useful for a human dispatcher glancing at a screen who needed to understand a technician's position quickly rather than parsing raw coordinates.

With both sides expressed as coordinates, the dispatch system could calculate actual distance between every available technician and a new job, and assign based on a combination of distance and availability rather than availability alone, weighted so that a technician who was slightly less immediately available but much closer often came out as the better assignment than one who was free right now but far away, a tradeoff the company tuned over a few weeks of watching real assignment outcomes.

The measurable effect was a reduction in average drive time per job across the fleet, which translated directly into more completed jobs per technician per day, since less time spent driving between jobs meant more time available for the jobs themselves. Fuel cost per job also dropped, a smaller but real additional benefit the company had not specifically been trying to solve for when it started the project.

The company kept a dispatcher in the loop rather than fully automating assignment, since distance is an important factor but not the only one, a technician's specific certification for a particular appliance brand or a customer's preference for a technician they had seen before sometimes outweighed a purely distance-optimal assignment, and the tool surfaced the distance-ranked suggestion as a strong default a dispatcher could override rather than an automatic assignment with no human check at all.

Volume scaled with job volume, one geocoding call per new job plus a smaller number of reverse lookups for dispatcher-facing technician location display, comfortably inside the free daily allowance for a company running a fleet of this size, with headroom into prepaid credit available if the company expanded into additional service areas.

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

Adding local currency display to a pricing calculator

2026-09-16T19:40:00+00:00

A price shown in a currency a visitor does not use is a price that requires an extra mental step before it means anything, and a software vendor selling a usage-based product with a calculator on its pricing page found that visitors from outside its home market spent noticeably longer on the calculator page and converted at a lower rate, a pattern that traced back, once the team dug into it, to exactly that extra friction.

The fix was showing the calculated price in a currency the visitor actually used day to day, alongside the vendor's base currency for anyone who preferred it. Detecting which currency to show first started with country, resolved server-side from the visitor's IP address through /v1/ip, before the pricing calculator page rendered. The vendor maintained its own small mapping from country to display currency and an approximate conversion rate, refreshed periodically, and used the country field from the lookup to decide which currency to show as the default.

It is worth being precise about what this changed and what it did not. My Geocode itself prices and bills in EUR, worldwide, regardless of where a customer using the API is located, a detail unrelated to what currency a business built on top of the API chooses to display to its own customers. The vendor's decision to show prices in a visitor's local currency was entirely its own pricing and localization choice, using the country signal from the lookup as an input, not something the location API decided or was involved in beyond resolving the country.

The vendor was careful to label the converted price clearly as an approximate conversion for reference, since actual billing still happened in the vendor's own base currency and exchange rates fluctuate, meaning the number shown on the pricing page was a helpful estimate rather than a locked-in guarantee of what a specific charge would be once currency conversion happened at the actual payment processor. This distinction mattered enough to call out directly on the page itself, in a small note near the calculator, to avoid any customer confusion about what they would actually be charged.

A visitor could switch back to the base currency with a single click if they preferred it, useful for finance teams evaluating the product who wanted to see the actual billing currency directly rather than a converted estimate, and the vendor kept that switch prominent rather than burying the option, since removing a visitor's ability to see the real billing currency in favor of a forced localized view would have created its own kind of friction for exactly the buyers most likely to be doing careful budget comparisons.

Pricing page traffic was a modest fraction of the vendor's total site visits, keeping this comfortably inside the free daily allowance for most months, with occasional overflow into prepaid credit during a product launch or a marketing campaign that drove unusually high pricing page traffic.

Documentation for the underlying lookup is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, and My Geocode's own pricing is detailed at /pricing/.

Building a franchise territory planner

2026-09-16T08:28:00+00:00

Selling a new franchise territory that overlaps too closely with an existing one is the kind of mistake that generates lawsuits, not just awkward conversations, and a franchisor expanding into a new region needed to be certain, with actual data rather than a rough sense from a paper map, exactly where its existing locations sat relative to any new territory it was about to offer.

The franchisor's location records existed as text addresses in its franchise management system, useful for mailing invoices and useless for measuring distance or drawing a boundary. Turning that list into something a territory planning process could actually use started with geocoding the entire existing network in a single batch through /v1/forward, since a bulk request counts each address as one billed item, giving every location a fixed coordinate rather than a name and street that could not be directly compared to a proposed new boundary.

With coordinates for the full existing network, drawing a new territory became a measurable exercise: a proposed boundary for a new franchisee could be checked directly against the coordinates of every nearby existing location, confirming a minimum distance was respected or that a proposed boundary did not accidentally include a competing existing territory within it, a check the franchisor's legal and development team could run before ever presenting a territory map to a prospective franchisee, catching a conflict on paper rather than after a contract was signed.

The franchisor also used the geocoded network for straightforward expansion analysis, looking at which regions had no existing locations within a reasonable distance of any population center worth serving, a gap analysis that had previously relied on development staff's general familiarity with the map rather than an actual measured distance from real coordinates. That analysis surfaced a couple of genuinely underserved regions the development team had not prioritized before, simply because nobody had looked at the existing network's coverage gaps with real distance data rather than an impression of the map.

This was largely a one-time project rather than an ongoing integration, similar in shape to a sales territory mapping exercise: the existing network got geocoded once, in a batch that fit comfortably inside the free daily allowance for a franchise system of moderate size, and new locations were geocoded individually as they came online after that, a small and predictable ongoing volume that never approached needing prepaid credit for a franchisor adding a modest number of new locations per year.

The value of the project showed up specifically in the confidence it gave the legal and development team before finalizing a new territory, since a proposed boundary that had been checked against real distances to real existing locations was a much stronger position to stand behind than one drawn by hand and reviewed by eye, particularly if a territory dispute with an existing franchisee ever needed to be resolved and the company wanted to point to a documented, measured process rather than a subjective judgment call.

Documentation for the endpoint, including batch request formatting, is at /docs/forward-geocoding/.

Detecting mismatched billing and shipping countries

2026-09-15T18:16:00+00:00

Not every order with a billing address in one country and a shipping address in another is fraud, plenty of people buy gifts for family abroad or ship to a vacation address, but a retailer reviewing a year of chargeback data found that orders where three separate location signals, billing country, shipping country, and the country resolved from the order's connecting IP address, all disagreed with each other were dramatically more likely to end in a dispute than orders where even two of the three lined up.

The retailer already collected billing and shipping country as standard checkout fields. What it added was the third, independent signal: /v1/ip resolved the country of the IP address placing the order, checked automatically against the two fields the customer had entered. A gift order, where billing and shipping countries commonly differ but the IP address usually still matches the billing country, since the actual buyer is placing the order from their own home, looked meaningfully different from an order where all three disagreed, since that pattern is much harder to explain with an innocent, common scenario.

The retailer built a simple scoring rule rather than an outright block: an order with all three signals in agreement proceeded normally with no extra friction. An order with a plausible two-way match, like a gift order with matching billing and IP country but a different shipping address, also proceeded normally, since that pattern matched an extremely common and entirely legitimate shopping behavior. An order where all three disagreed got flagged for a manual review step or an additional verification request before shipping, a small amount of added friction applied only to the pattern the retailer's own data showed was disproportionately risky.

This mattered because the alternative, treating any billing and shipping mismatch as suspicious on its own, would have added friction to a huge number of entirely legitimate gift orders, exactly the kind of false positive that costs a retailer real sales without meaningfully reducing fraud. Adding the third, independent IP-based signal let the retailer target the review step much more narrowly, at the pattern its own data actually connected to chargebacks, rather than at a broad and mostly harmless behavior that happened to share one surface-level similarity with it.

The retailer measured the change directly against its chargeback rate over the following months and saw a real reduction, though it was careful to note this single check was one part of a broader fraud prevention stack that included other signals too, payment verification, order value thresholds, and account history among them, rather than treating the IP comparison as solely responsible for the improvement.

Cost was trivial relative to the value protected: one additional lookup per order, comfortably inside the free daily allowance for a retailer of moderate size, moving into prepaid credit during a peak shopping season, a cost that was not close to a serious consideration next to the average cost of a single chargeback, which carries fees and reputational cost well beyond the value of the disputed order itself.

Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, with authentication methods covered at /docs/authentication/.

Building a solar panel siting tool using elevation

2026-09-15T07:31:00+00:00

A full solar site assessment involves an engineer visiting the property, checking roof orientation, shading from nearby structures and trees, and the specific slope of the roof itself, a process that takes real time and cost per visit, and a residential solar installer was scheduling a meaningful number of these visits for properties that turned out, once an engineer actually looked, to be poor candidates for solar for reasons that a much simpler check could have flagged in advance.

Elevation and terrain context, while not a complete replacement for an in-person shading and roof survey, gave the installer a useful early filter. /v1/elevation returned ground elevation for a property's coordinates and for points around it, which the installer's team used to get a rough sense of the surrounding terrain, whether a property sat in a valley likely to face more shading from nearby higher ground, or on relatively flat or elevated terrain with fewer obvious obstructions from the landscape itself, separate from the question of trees or nearby buildings that only an actual site photo or visit could assess.

The installer built this into its initial online quote request form as a lightweight pre-screening step: a homeowner entered their address, which the system geocoded to get coordinates, and elevation data for that point along with a small grid of surrounding points gave a rough terrain profile that fed into an early estimate of solar viability, clearly labeled as preliminary and explicitly not a substitute for the full site assessment that would still happen before any installation was scheduled.

This did not eliminate site visits, since terrain is only one factor among several, and plenty of properties with fine terrain still turn out to be poor candidates because of tree cover or roof condition, details elevation data cannot see. What it did was help the installer prioritize which quote requests to schedule a site visit for first, and occasionally set more realistic expectations with a homeowner upfront when the terrain profile suggested real difficulty, like a property tucked into a steep, shaded valley, that would likely limit solar viability regardless of roof condition.

The installer also used ground elevation as an optional extra field on some of its other location lookups, since My Geocode's optional extras, available with mg_extras=1 or the X-MG-Extras header, include ground elevation alongside the coordinates it was already resolving for other parts of its quoting workflow, letting the installer pull elevation context without a fully separate call for cases where it only needed a quick additional data point rather than a full terrain grid.

The installer was careful in its marketing and quote materials not to overstate what this early check could promise, framing it consistently as a preliminary screening tool rather than a final assessment, which mattered both for setting realistic homeowner expectations and for avoiding any claim that could be read as a firm energy production estimate before an actual engineer had looked at the property.

Volume was low, tied to quote request volume rather than to anything more frequent, comfortably inside the free daily allowance for an installer of regional size. Documentation for the endpoint and the extras fields is at /docs/elevation-lookup/.

Personalizing a newsletter send time by time zone

2026-09-14T18:26:00+00:00

A newsletter sent at 7 AM headquarters time lands in some subscribers' inboxes at a reasonable early morning hour and in others' inboxes well after midnight, buried by the time they wake up and check email, and a publisher running a daily newsletter to an international subscriber base had exactly this problem without realizing how much it was costing in open rates, since the difference showed up as a vague regional pattern in the data rather than an obvious, single explainable cause.

The publisher had approximate location data for most subscribers already, gathered at signup either from a location field or inferred from the signup IP address through /v1/ip, resolved into country and city. What it lacked was a way to turn that location into an actual send time decision, since knowing a subscriber was in a particular country is not the same as knowing the correct time zone to schedule around, especially for larger countries spanning multiple zones.

For each subscriber's resolved location, the publisher's sending system looked up the IANA time zone name through /v1/timezone, storing it against the subscriber's record rather than looking it up fresh on every send. With a real time zone attached to each subscriber, the sending platform could stagger delivery so that the newsletter arrived at roughly the same local hour for everyone, regardless of how many time zones the total subscriber base spanned, rather than firing every copy at once from a single scheduled time.

Open rates improved measurably in the regions that had previously been receiving the newsletter at an inconvenient local hour, the clearest evidence that the original single-send-time approach had been quietly costing engagement in exactly the markets furthest from headquarters time, the ones probably least likely to have been noticed as a problem without directly measuring for it.

The publisher used the stored IANA name rather than a fixed offset specifically so the send time calculation stayed correct through daylight saving changes without needing manual updates, an easy detail to overlook that would have caused the carefully tuned send times to drift out of alignment twice a year in every affected region if a raw offset had been stored instead.

This was a one-time lookup per subscriber rather than a per-send cost, since a subscriber's time zone rarely changes and there was no reason to re-resolve it for every single newsletter issue. That kept the total request volume low relative to the publisher's subscriber base, well within the free daily allowance even accounting for a steady trickle of new signups needing their own first-time lookup.

Send time is one of the more overlooked levers in email marketing precisely because a single average open rate number hides how differently it performs by region, and the fix, once the underlying cause is visible, is a straightforward technical change rather than a content or subject line problem the team might otherwise have spent time chasing instead.

Documentation for both endpoints is at /docs/ipv4-lookup/ and /docs/timezone-lookup/.

Building a school catchment area checker

2026-09-14T06:59:00+00:00

Every spring, a school district's enrollment office fielded the same question over and over from families who had just moved, were considering moving, or simply were not sure: which school does my address belong to. Answering it by hand meant a staff member looking up a street address against a set of catchment area boundaries maintained as maps and lists, a process that took a few minutes per family and did not scale well during the weeks leading up to enrollment deadlines when the volume of questions spiked hardest.

The district built a self-service checker to handle the common case directly. A family typed in their address, which the tool sent to /v1/forward to get back a location match with coordinates, since the district's catchment boundaries were maintained as geographic areas that needed a coordinate to test against, not a text address that could not be directly compared to a boundary shape. Once an address resolved to a coordinate, checking which catchment area contained that point was a straightforward geometry test run by the district's own system, comparing the point against each boundary polygon on file.

For addresses that resolved with high confidence and landed clearly inside one boundary, the tool gave an immediate answer, naming the assigned school directly. For addresses that resolved with lower confidence or fell very close to a boundary line, common for newer developments or addresses near the edge of two zones, the tool flagged the result as needing confirmation from the enrollment office rather than stating a school name with more certainty than the underlying match actually supported, since a wrong answer on something as consequential as school assignment was a much bigger problem than an occasional "please contact us to confirm" message.

This distinction mattered enough that the district built it in deliberately rather than as an afterthought. A geocoding match reflects how confidently an address resolved, and treating every match as equally certain would have produced confidently wrong answers for exactly the addresses most likely to be genuinely ambiguous, the ones sitting right at a boundary edge where getting it wrong caused the most disruption for a family relying on the answer.

The tool cut enrollment office call volume substantially during the weeks it mattered most, freeing staff to spend time on the harder cases, boundary-edge addresses, families with unusual circumstances, rather than repeating the same basic lookup hundreds of times over. The district also used the same underlying geocoding to occasionally audit its own catchment maps, checking whether addresses near a boundary that families had disputed were, in fact, correctly assigned according to the district's own official boundary data, catching a small number of genuine mapping errors in the process.

Usage was seasonal and concentrated, spiking hard in the weeks before enrollment deadlines and quiet the rest of the year, a pattern the free daily allowance handled well during quiet periods, with prepaid credit covering the enrollment season spike without the district needing to commit to a plan sized for its busiest weeks year round.

Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/postal-code-lookup/.

Adding a "closest pickup point" map to an e-commerce site

2026-09-13T17:08:00+00:00

Offering pickup locker delivery as a cheaper shipping alternative only works if shoppers can quickly find a locker that is actually convenient for them, and an online retailer's first version of this feature, a plain list of locker addresses sorted by city, mostly failed at that, since a shopper had no easy way to tell which of thirty lockers listed under their city was actually near them without opening a separate map for each one.

The retailer rebuilt the feature around distance, the same underlying approach as a store finder but embedded directly inside the checkout flow rather than as a separate page. Every pickup locker location, sourced from the retailer's logistics partner, was geocoded once through /v1/forward, a batch job that counted each locker address as one billed item, giving the full network of lockers a fixed set of coordinates to work from.

At checkout, a shopper who allowed location detection got a starting point from /v1/ip, resolved from their IP address into approximate coordinates, letting the checkout page immediately show the nearest few lockers without asking the shopper to type anything. A shopper who preferred to search by their own address instead had that address geocoded through the same endpoint used for the locker network, then ranked against it the same way.

The result embedded directly into the shipping method selection step: instead of a generic "pickup locker" option that led to a separate search page, the checkout flow showed the single closest locker by name and distance right in the shipping options, with an easy way to see the next few closest if the top choice was not convenient for some reason, a schedule conflict or a locker that looked too small for a large order.

This kept the pickup option genuinely competitive with home delivery in the moment a shopper was deciding between them, rather than losing shoppers to a plain home delivery default simply because finding a locker required extra effort that a shopper was not willing to spend in the middle of checking out. The retailer's data showed pickup locker adoption increased meaningfully once the nearest option was surfaced directly in the checkout flow rather than requiring a separate search step, a change the retailer attributed specifically to removing that friction rather than to any change in what the locker service itself offered.

The retailer treated the detected starting location the same way any responsible use of IP geolocation should: as a convenient default, not a certainty, with a visible option to search by a different address for a shopper whose actual pickup preference did not match their current browsing location, someone ordering a gift to be picked up near a family member's address in another town, for example.

Volume ran with checkout sessions specifically, a smaller number than total site traffic, which kept the feature comfortably inside the free daily allowance for most of the year, with the usual prepaid option covering peak shopping periods without requiring any special planning ahead of time.

Documentation for the relevant endpoints is at /docs/forward-geocoding/ and /docs/ipv4-lookup/.

Building an insurance quote tool that uses postal code risk

2026-09-13T06:37:00+00:00

An instant online insurance quote has to balance two things in tension: it needs to happen fast, ideally after just a few fields, and it needs enough real information to price the policy reasonably rather than guessing. A regional home insurer building an instant quote tool found that asking for a full address up front, before showing any price at all, cost it a lot of visitors who left before ever seeing a number, exactly the visitors the fast quote tool was supposed to keep engaged.

Postal code turned out to be the input that satisfied both constraints reasonably well. A single short field, quick enough that most visitors did not think twice about entering it, and specific enough to place a property within an area that correlated meaningfully with the risk factors the insurer's own actuarial models already used to price policies, factors like regional weather patterns, local claim history, and proximity to known flood or wildfire risk zones that the insurer's own risk team maintained independently.

The quote tool sent the entered postal code to /v1/postcode, which resolves the area that code corresponds to, and the insurer's own pricing engine used that resolved area to look up its internal risk rating for the region, entirely the insurer's own proprietary data and methodology, with the postal code lookup serving only as the bridge between what a visitor typed and which row of the insurer's own risk table applied. My Geocode had no role in and no visibility into how the insurer weighted risk, only in resolving what location a given postal code actually described.

An instant quote produced this way was clearly labeled as preliminary, since a full underwriting process still required a complete address, details about the specific property, and other information a postal code alone cannot provide, like the age of a roof or the presence of specific fire mitigation features. The instant quote's job was to give a visitor a realistic ballpark figure fast enough to keep them engaged with the process, not to be the final, bindable price, and the insurer's own site was explicit about that distinction at every step.

This staged approach, fast estimate now with a full address collected only once someone was ready to proceed toward an actual policy, matched how visitors were already behaving: most people requesting an instant quote were comparison shopping and wanted a rough number before committing to the longer application, and asking for a full address before giving them that rough number had been costing the insurer exactly those comparison shoppers.

Quote tool traffic, like most insurance shopping traffic, spiked around renewal seasons and after major weather events in a region, which pushed the insurer's usage past the free daily allowance during those periods and into prepaid credit, a cost trivial against the value of a completed policy application driven by a fast, low-friction quote experience.

Documentation for the endpoint is at /docs/postal-code-lookup/, and details on API pricing are at /pricing/.

Detecting country of origin for compliance reporting

2026-09-12T19:05:00+00:00

Selling digital goods across borders comes with a reporting obligation that a lot of smaller sellers underestimate until it becomes a problem: knowing, with reasonable confidence, which country each transaction actually took place in, since tax treatment and reporting requirements for digital sales often depend specifically on the buyer's location rather than the seller's own. A self-declared country on a checkout form is a start, but it is also trivially easy for a buyer to get wrong or misrepresent, intentionally or not, and a compliance-minded seller needed a second, independent signal to check that declaration against.

The seller added a server-side check at the point of purchase. /v1/ip resolved the buyer's IP address into a country field, checked automatically against whatever country the buyer had entered or selected during checkout. Where the two agreed, which was the overwhelming majority of transactions, nothing further happened, the declared country stood as the transaction's country of record. Where they disagreed, the transaction was flagged for a closer look before being finalized, since a mismatch could mean anything from a buyer traveling abroad and using their home billing details, to someone routing through a VPN, to a genuine attempt to misrepresent their location for a pricing or tax advantage.

The seller was careful not to treat every mismatch as evidence of wrongdoing, since plenty of legitimate transactions involve someone temporarily outside their home country making a purchase using their normal payment details. The flag triggered a review step rather than an automatic block, and the review looked at the transaction as a whole, payment method country, billing address, and IP-detected country together, rather than rejecting anything based on IP mismatch alone.

For its own compliance recordkeeping, the seller retained both the declared country and the IP-detected country against each transaction, along with a note on how any disagreement had been resolved. That record gave the company something concrete to point to if a tax authority or payment processor ever asked how it determined the country of a given sale, a documented, consistent process rather than an unverifiable claim based on checkout form data alone.

None of this is a substitute for proper tax and legal advice specific to the jurisdictions a seller operates in, and the company treated the IP check as one input into a broader compliance process built with guidance from its own accountants, not a complete solution on its own. What IP geolocation contributed specifically was a cheap, consistent, server-side signal that did not depend on a buyer filling out a form honestly, which meaningfully strengthened a compliance process that had previously relied on self-reported data alone.

Volume matched transaction volume directly, one lookup per purchase, which for a digital goods seller of moderate size fits comfortably inside the free daily allowance most months, moving into prepaid credit during a strong sales period without requiring any advance planning, since the per-request cost scales in the same direction as revenue does.

Getting country detection right matters more the moment a business starts taking tax and reporting obligations seriously, and a reliable, independent signal that does not depend on what a buyer chooses to type is worth having in place before it is needed rather than after. Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/.

Building a call center routing system by region

2026-09-12T07:40:00+00:00

An agent who knows the local regulatory quirks and typical claim patterns of one region handles a call from that region faster and better than an equally skilled agent who has never worked a claim from there before, and an insurance company running a national call center realized its "route to next available agent" system was ignoring that entirely, treating every agent as interchangeable regardless of which region a caller was in.

For calls coming through the company's web-based contact form and callback request system, rather than a traditional phone line, the caller's IP address was already part of every request. /v1/ip resolved that address into region and city, which the routing system used to match a caller against agents who had been assigned specialization in that particular region, rather than routing purely by who happened to be free first.

This did not replace availability as a factor entirely, since a perfectly matched agent who is unavailable for another twenty minutes is often a worse outcome than an available agent with general knowledge, so the routing logic weighed both together: a strong regional match with a short wait beat a mismatch with no wait at all only up to a point, tuned based on actual wait time data the company gathered once the new system was live.

The company also used the same regional data to route certain calls to agents fluent in a relevant local language variant, not just a broad language category, since a general "Spanish-speaking agent" pool served callers less well than one that accounted for regional differences in terminology that come up specifically in insurance and claims conversations, a detail that mattered more to caller satisfaction scores than the company had initially expected going in.

None of this required a phone system overhaul. The location resolution happened at the point where a caller's contact request first reached the company's servers, before it was ever handed off to the call routing logic itself, which only needed a region field to make its decision, a small integration point rather than a rebuild of the routing system as a whole.

The company treated the detected region as a strong signal rather than an absolute fact, aware that a caller on a corporate VPN or traveling could resolve to a region other than where they actually held their policy. For cases where policy region and detected region disagreed, the system fell back to matching against the caller's policy record instead, treating the IP-based detection as useful primarily for the more common case where policy holders are also physically in the region their policy covers, calling from a normal home or mobile connection.

Volume tracked inbound contact form submissions, a workload well inside the free daily allowance for a company of this size, since the lookup ran once per contact request rather than continuously during a call. The change did not require new headcount or new agent training beyond formalizing which agents already had strength in which regions, an inventory the company had informally but had never systematically used for routing before.

Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/.

Scheduling webinars that show the right time per attendee

2026-09-11T21:06:00+00:00

"Join us Thursday at 2 PM Eastern" is precise for exactly the attendees who already think in Eastern time and a guessing game for everyone else, and a B2B software company running regular webinars for an international audience found that a noticeable share of no-shows and late joins traced back to attendees simply doing the time zone math wrong, or not doing it at all and assuming the invite meant their own local 2 PM.

The company's registration form already collected an email address and, for scheduling purposes, an approximate location, either entered directly or inferred from the registrant's IP address at the moment they signed up, resolved through /v1/ip into coordinates along with country and city. Those coordinates fed into /v1/timezone, which returned the IANA time zone name for the registrant's location, giving the company a reliable way to calculate that specific attendee's correct local time for the webinar, rather than relying on the attendee to convert it themselves.

Every confirmation email after that showed the webinar time twice: once in the presenter's own time zone for consistency, and once calculated specifically for that attendee's resolved time zone, spelled out in plain language rather than as an offset a reader had to do further math on. The same dual display carried through to the calendar invite attached to the confirmation, so an attendee adding the event to their own calendar saw it land at the correct local hour automatically rather than needing to trust a manual conversion.

Because webinars were often scheduled weeks ahead, sometimes crossing a daylight saving transition in one region but not another, the company relied on the timezone lookup's ability to calculate the correct offset for the specific future date of the webinar rather than the offset in effect on the day the invitation was sent. Storing the IANA name rather than a fixed offset meant this stayed correct without anyone at the company needing to track which regions were about to change their clocks and adjust invitations by hand.

The measurable result was a meaningful drop in the number of support and sales emails asking to confirm the actual local time of an upcoming session, a small but recurring cost in staff time that had been treated as an unavoidable part of running international webinars before this. Attendance also improved modestly, though the company was careful to note that better attendance likely came from a mix of factors, clearer time zone display being one contributor among several rather than a single explanation.

Volume was light and predictable, one lookup per registrant at signup time, a workload that never came close to the free daily allowance even for a company running frequent webinars, since registration volume for any single event rarely reaches a scale where request cost becomes a meaningful consideration.

Getting a meeting time right for every attendee, individually, rather than asking each person to do their own conversion, removes a small but real source of friction from something as simple as showing up to a scheduled call. Documentation for both endpoints is at /docs/ipv4-lookup/ and /docs/timezone-lookup/.

Building a hiking trail difficulty rating from elevation data

2026-09-11T08:13:00+00:00

Distance alone is a poor way to rate how hard a hike actually is. A flat six-mile trail along a riverbank and a six-mile trail that climbs a mountain both showed up under the same "moderate, six miles" label in a trail guide app's directory, a categorization that had generated a steady stream of complaints from hikers who trusted the moderate rating and found themselves on a much harder climb than they had prepared for.

The app already stored each trail as a sequence of coordinates tracing its path, gathered from GPS recordings submitted by contributors. What it was missing was elevation along that path, the piece of data that actually distinguishes a flat walk from a serious climb at the same distance. /v1/elevation took the full list of coordinates for a trail, since a bulk request accepts a list of points and returns elevation for each one, and the app got back an elevation value for every point along the recorded path, still in the same order they were submitted.

From that list, computing total elevation gain, the sum of every upward change along the route, was straightforward arithmetic the app's own backend handled. Total gain, combined with distance, produced a genuinely more useful difficulty signal than distance alone: a trail with high gain over a short distance rated as steep and difficult regardless of how short it looked on paper, while a long, flat trail rated easier despite its length, matching what hikers actually experience on the ground far more closely than the old distance-only system had.

The app rebuilt its difficulty rating around this combined figure and retroactively recalculated every trail already in its directory, a one-time batch job across the full trail library. That batch was the single largest request the app ever sent, and because a bulk elevation request counts each point as one billed item rather than each trail, the exact size of the job scaled with how many coordinate points existed across the whole library rather than with the number of trails, something the team accounted for when estimating cost ahead of time rather than being surprised by it afterward.

Beyond the headline difficulty rating, the same elevation data let the app show a climbing profile chart on every trail page, similar to what a cycling app might show, letting a hiker see exactly where the steep sections fell along the route rather than only knowing an aggregate difficulty label. Hikers who wanted to prepare for a specific tough stretch, rather than just knowing a trail was hard overall, found the chart more useful than the label by itself.

Ongoing elevation lookups after the initial batch were driven by new trail submissions, a much smaller and steadier volume than the one-time recalculation project, comfortably inside the free daily allowance for the app's typical rate of new contributor submissions.

A rating system is only as good as the data underneath it, and elevation turned out to be the missing input the app's difficulty rating needed all along. Documentation for the endpoint, including limits on points per request, is at /docs/elevation-lookup/.

Verifying identity address details for a fintech signup

2026-09-10T18:58:00+00:00

Opening an account at a digital bank involves a stack of identity checks, document verification, sanctions screening, proof of address, run in sequence because each one is a genuine cost in time and sometimes money, and it makes sense to run the cheapest, fastest checks first to filter out obviously broken applications before spending effort on the expensive ones.

Address plausibility turned out to be one of the cheapest and earliest checks a digital bank could run. Before an application moved on to document upload and identity verification, the address a new customer had typed into the signup form went through two quick checks. /v1/forward attempted to match the address and reported how confidently it resolved, catching cases where the street name did not exist, the address was incomplete, or the format did not correspond to any real location. /v1/postcode checked the entered postal code against the city and region also entered, catching the specific and common mistake of a postal code copied from a different location or simply mistyped.

Neither check on its own determines whether someone is who they claim to be, and the bank was explicit internally that this step did not replace the identity verification and know your customer process that followed. What it did was cheaply catch a category of application that would otherwise waste the time of the more expensive downstream steps: an address that could not possibly be real does not need to proceed to document review, and flagging it at the address step, in seconds, saved the cost of running a fuller verification against an application that was going to fail anyway.

Applications with a clean, well-formed address moved straight into the standard identity verification queue. Applications with an address that failed to resolve, or where the postal code and city clearly disagreed, were flagged either for a quick correction prompt back to the applicant or, if the pattern looked more deliberate than accidental, straight to manual fraud review rather than the standard queue.

The bank kept a clear internal boundary around what this step was for. Address plausibility is a data quality and early fraud signal, not a compliance control on its own, and it did not substitute for the actual proof of address documentation or the sanctions and identity checks a regulated financial institution has to run regardless of how clean an applicant's typed address looks. The value here was entirely in filtering and triage, moving the obviously broken applications out of the expensive part of the pipeline earlier, not in replacing any part of the actual compliance process.

Volume matched signup volume, one pair of checks per new application, a workload that stayed inside the free daily allowance for a digital bank at moderate signup volume, with prepaid credit as the natural next step during a growth period or a marketing push that drove a surge of new applications.

For a regulated business, the appeal of a check like this is less about catching fraud outright and more about not wasting expensive verification steps on applications that were never going anywhere. Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/postal-code-lookup/.

Building a telecom coverage checker by postal code

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

"Is service available at my address" is the first question anyone visiting an internet provider's website actually wants answered, and a regional provider's old coverage checker made that question harder to answer than it needed to be, requiring a full street address, city, and state before showing anything, a form long enough that a fair number of visitors abandoned it before finding out whether the provider even served their area.

The provider rebuilt the checker around a postal code as the first and often only input needed. A visitor typed their postal code, and the site sent it to /v1/postcode, which resolves what area that code corresponds to. The provider matched the resolved area against its own coverage database, built from its network buildout records, to give an immediate answer: served, not yet served, or served with a note about which service tier was available in that area, since coverage quality can vary within a single postal code area depending on how far a property sits from existing network infrastructure.

For postal code areas where coverage was mixed, the checker asked for a street address as a second step only when necessary, rather than requiring it up front for every visitor. Someone in a fully served area got their answer immediately from the postal code alone. Someone in a postal code area with partial coverage got a quick follow-up question, still far shorter than the original form, since only the smaller number of ambiguous cases needed the extra detail at all.

This staged approach cut the average number of fields a visitor filled in before getting an answer by a significant margin, since most postal code areas in the provider's territory were either fully served or fully unserved, with only a minority genuinely needing the more detailed check. The visitors most likely to convert into a signup, the ones with clear, available service, got the fastest possible path to that answer, while the smaller group needing more detail got exactly the extra step required and no more.

The provider also used the same postal code data for its sales team's territory planning, cross-referencing postal code areas against buildout plans to see where marketing spend aimed at driving coverage checker traffic would land in areas that could actually convert into signups, rather than driving traffic toward postal codes that were not yet served.

Coverage checker traffic scaled with marketing activity, spiking noticeably during ad campaigns aimed at driving signups in newly served areas. During ordinary periods this sat inside the free daily allowance, and during a campaign push it moved into prepaid credit at €0.0001 a request, a cost easily justified against the value of a completed signup for an internet service subscription.

Reducing a form from several required fields to often just one, with a fast and confident answer at the end of it, is a small change that shows up directly in how many visitors actually complete the check rather than leaving partway through. Documentation for the endpoint is at /docs/postal-code-lookup/.

Personalizing ad copy by country

2026-09-09T20:11:00+00:00

Writing a separate version of an ad for every market it might run in is more work than most advertisers using a self-service ad platform are willing to do, and the result, when they do not, is an ad that mentions "free shipping" to a viewer in a country the advertiser does not actually ship to, or a price quoted in a currency the viewer does not use, both of which look sloppy and cost clicks.

An ad platform serving small and mid-size advertisers built a lighter-weight fix: rather than asking advertisers to write country-specific versions, the platform let a single ad template include a few variable fields, country name, a shipping promise, a price, that got filled in per viewer based on where the ad was being served. Resolving where a viewer was came from /v1/ip, run server-side at the moment an ad was selected to serve, returning the viewer's country among other fields.

An advertiser configured what each variable field should say for each country they wanted to target, a short setup step done once, and the platform handled substituting the right version in at serve time. A viewer in one country saw an ad copy that named their own country and quoted a price consistent with what they'd actually be charged, while a viewer in another country serving from the same underlying campaign saw a version tailored to their own market, all from a single ad the advertiser had built once.

This mattered more for smaller advertisers than large ones, since a bigger advertiser typically already has the resources to build fully separate creative per market. The platform's audience, smaller businesses running their own ad campaigns without a dedicated marketing team, benefited from getting a reasonable version of localized ad copy without needing to produce that many separate assets themselves.

The platform was careful about targeting decisions versus copy personalization, treating them as separate concerns. Whether an ad was eligible to be shown to a viewer in a given country at all was still controlled by the advertiser's own targeting settings, set deliberately rather than inferred. The IP-based country detection only decided which version of an already-eligible ad's copy to display, never whether to show the ad in the first place, keeping the advertiser fully in control of where their spend actually went.

Accuracy expectations here were realistic rather than absolute. IP-based country detection is reliable for the great majority of traffic but not infallible, particularly for viewers on certain mobile networks or corporate connections that can occasionally resolve to a different country than the viewer is physically in. For ad copy personalization, an occasional mismatch was a minor cosmetic issue rather than a serious problem, a different risk tolerance than something like fraud screening or legal compliance would allow.

Given how much ad serving volume can be, the platform ran comfortably on an Unlimited key rather than prepaid credit, since a flat €50 monthly cost was easier to reason about against unpredictable and often very high ad serving volume than a per-request bill that could swing widely week to week.

Documentation for the endpoint is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, with pricing options detailed at /pricing/.

Building a disaster-response resource map

2026-09-09T07:32:00+00:00

During an active weather emergency, information about where help is needed and where help is available arrives fast and in no consistent format at all. A regional relief coordination group found itself collecting shelter locations, supply drop points, and reports of people needing assistance from volunteers texting in whatever description came to mind, a cross street, a landmark, a partial address, a set of coordinates copied from a phone's map app.

None of that is directly usable on a shared map without a common format underneath it. The coordination group needed every incoming report converted into the same thing, a coordinate pair, regardless of how it arrived. Reports that came in as text, an address or a description close enough to one, went through /v1/forward to get a location match. Reports that came in as coordinates, copied from a phone's location share, went through /v1/reverse to get back a readable address and administrative area, useful for showing volunteers a plain description of the location rather than a raw pair of numbers on the map.

With every report normalized to a coordinate, plotting them together on one shared map became straightforward, and more importantly, comparable: a supply point and a reported need could be measured against each other by actual distance, which mattered enormously for routing volunteers efficiently rather than guessing at proximity from written descriptions that did not obviously relate to each other.

The group ran this through a lightweight intake form rather than anything more elaborate, since the priority during an active response was speed and simplicity over polish. A volunteer submitting a report did not need to know or care which endpoint handled their particular input format, the intake form decided that based on whether the submission looked like text or like coordinates, and either path ended in the same normalized point on the shared map.

Match quality mattered more here than in most other uses of geocoding, since a report during an emergency that resolves to the wrong location, even by a small distance, can send help to the wrong place at exactly the moment that matters most. The group's intake form surfaced the match confidence returned by the forward geocoding call directly to whoever was reviewing incoming reports, so a low-confidence match got a quick human check before it was trusted and acted on, rather than being plotted with the same apparent certainty as a clean match.

None of this required specialized emergency management software. The coordination group ran its intake form on infrastructure it already had, adding geocoding as the one missing piece that let unstructured, volunteer-submitted location descriptions become something a shared map could actually display and compare.

Request volume during an active response spiked sharply and briefly, the kind of pattern that is hard to plan a fixed budget around in advance. The free daily allowance covered ordinary planning and preparation use between events, and prepaid credit absorbed the spike during an actual response without requiring the group to commit to a larger ongoing plan it would not need most of the year.

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

Adding local business hours to a franchise website

2026-09-08T19:38:00+00:00

A franchise with locations across several time zones had a website problem nobody had thought to fix: the central "hours" section on every location page showed the same schedule, written once by someone at headquarters and copied to every store, regardless of which time zone that particular store actually operated in. A location on the west side of the franchise's territory closing at what its own clock read as 9 PM looked, on the website, like it closed three hours earlier than it actually did, because the hours had been written against headquarters time and never adjusted per location.

Fixing it required attaching a real time zone to each location rather than treating "hours" as one shared piece of content. For every franchise location's address, the company resolved coordinates through /v1/forward and passed those coordinates to /v1/timezone, which returns the IANA time zone name for that exact point. Storing the name rather than a fixed offset meant the hours display stayed correct automatically through daylight saving changes, without anyone at headquarters needing to remember to update anything twice a year.

With each location's own time zone on file, the website could finally do the thing it should have been doing from the start: show a visitor whether a specific location was open right now, calculated correctly against that location's own clock, not the visitor's clock and not headquarters' clock. A visitor browsing from across the country looking at a location page for a store on the opposite coast saw an accurate "open now" or "closed, opens at 8 AM" reflecting that store's actual local time, which is the only version of that information that is actually useful to someone about to drive there.

The company layered the visitor's own location on top of this for the location finder specifically. /v1/ip resolved a visiting customer's approximate coordinates, which fed into the same distance ranking used by other locator tools, so a customer searching for the nearest open location got results that accounted for both distance and whether that particular location was actually open at the moment of searching, rather than a distance-sorted list that included several currently closed stores mixed in with open ones.

This was a small, mostly invisible fix in the sense that a website visitor would never think to credit "correct time zone handling" for anything, they would simply notice, or more likely not notice, that the hours shown matched reality. That is generally the sign of a fix worth making: nobody praises it, but everybody who would have been confused by the old version simply is not confused anymore.

Geocoding ran once per location as part of a one-time setup, a small batch given how many locations most franchises operate, well within the free daily allowance. Time zone lookups for the visitor-facing "open now" feature added a light ongoing volume tied to location finder traffic, also comfortably inside the free tier for a franchise of moderate size, with prepaid credit available if a national marketing campaign drove an unusual spike in location searches.

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

Building a farm equipment dealer locator

2026-09-08T06:33:00+00:00

Rural coverage breaks a lot of assumptions that store locators built for cities carry with them by default. A farm equipment manufacturer with a network of independent dealers spread across large agricultural regions found that a locator tuned for city-scale distances, showing dealers within a ten or twenty mile radius, returned an empty result for a meaningful share of its customers, who might reasonably expect to drive an hour or more to reach the nearest dealer for a major purchase.

Building a locator suited to that reality started the same way any distance-based locator does, with coordinates. Every dealer address in the manufacturer's network was geocoded once, in a single batch through /v1/forward, since a bulk request counts each address as one billed item regardless of how many dealers were in the list. That gave every dealer a fixed coordinate to measure distance from, rather than relying on the loose regional descriptions, "serves the tri-county area," that dealer listings had used before.

The distance defaults were the real change. Instead of a fixed search radius tuned for a city, the locator scaled its default radius up substantially for rural search areas, and let a customer widen it further with a single control rather than hitting a wall of "no dealers found" that suggested, wrongly, that the manufacturer simply had no presence nearby. A customer who allowed location detection got a starting point from /v1/ip, resolved from their IP address into approximate coordinates, and a customer who preferred to type in a town name or postal code had that entry geocoded the same way as the dealer list.

The manufacturer also used the geocoded dealer network for something beyond the customer-facing locator: internal coverage analysis, looking at where genuine gaps existed between dealers relative to where its equipment was actually being used, based on service and warranty registration addresses. That analysis, run once the whole dealer network had coordinates attached, informed where the company prioritized recruiting new dealers, a decision that had previously relied on regional sales reps' informal sense of where coverage felt thin.

None of this required treating rural and urban customers differently in the code itself. The same geocoding and distance calculation ran for every search. What changed was tuning, the default search radius and how the "no results" state was worded and handled, decisions that came from understanding the actual geography being served rather than from the underlying location technology, which worked identically regardless of how dense or sparse the area was.

Geocoding volume was almost entirely front-loaded into the initial dealer network batch, with a slow trickle after that as new dealers signed on, a workload that fit easily inside the free daily allowance included with the manufacturer's key. Customer-facing locator searches added a modest ongoing volume on top, also comfortably within the free tier for a company of this size, since dealer locator searches happen at a much lower frequency than, say, an everyday retail store finder would see.

Distance-based tools built with city assumptions baked in quietly fail rural users, and the fix is rarely a different technology, usually just different defaults applied to the same underlying calculation. Documentation for the endpoint is at /docs/forward-geocoding/.

Detecting fraud rings by shared IP ranges

2026-09-07T19:44:00+00:00

A single fake account is a nuisance. A dozen fake accounts that all appear unrelated, until you notice they log in from network addresses that sit right next to each other, is a coordinated operation, and a marketplace's trust and safety team started finding exactly this pattern once it began looking at IP addresses in terms of the network they belonged to rather than as isolated data points.

Individually, none of the flagged accounts looked obviously suspicious. Different email addresses, different names, different listing categories. What connected them only became visible when the team started resolving each account's login IP addresses through /v1/ip and looking at the ASN and organization fields alongside the address itself, then grouping accounts by which network range those addresses fell into.

This is also the reasoning behind how My Geocode's own free allowance works: usage is counted per /24 network for IPv4 addresses and per /48 for IPv6, shared across every account or key using addresses from that same network, rather than treated as entirely separate per individual address. Addresses close together on a network genuinely tend to belong together, whether that's a household, an office, or in less benign cases, a single operator running many accounts from a narrow range of addresses they control. The same logic that groups legitimate free-tier usage together works just as well for spotting a fraud ring hiding behind superficially different account details.

The marketplace's team built a simple report: for any set of accounts flagged for suspicious activity for unrelated reasons, check whether their login IP addresses clustered unusually tightly on the same network ranges, using the ASN and organization data as a cross-check against addresses that merely happened to be geographically close but belonged to different, unrelated providers. A cluster of accounts sharing a narrow slice of address space on the same hosting provider's ASN was a very different and much stronger signal than a cluster that happened to share a country, which millions of unrelated legitimate accounts would too.

Confirmed clusters led to a coordinated suspension across the whole ring at once, rather than the previous pattern of banning one account and watching a nearly identical one appear a week later from an adjacent address, since removing accounts one at a time from a ring operating across a shared range had let operators simply spin up a replacement, register from the address next door, and continue.

The team was careful not to over-rely on network proximity alone, since plenty of legitimate activity genuinely shares network ranges, a large office, a university, or a mobile carrier's shared address pool can put many unrelated legitimate users behind addresses that look clustered by this same measure. Network clustering was used as one signal that raised a case's priority for human review, not as an automatic ban trigger on its own.

Investigation volume was small relative to total marketplace traffic, since it only ran against accounts already flagged for other reasons rather than every login, which kept it well inside the free daily allowance included with the marketplace's key. Documentation for the fields involved is at /docs/ipv4-lookup/ and /docs/ipv6-lookup/, with rate limit behavior at /docs/rate-limits/.

Building a ride-share pickup radius check

2026-09-07T08:02:00+00:00

A small ride-share service operating under a campus and surrounding neighborhood agreement had one hard rule it could not break: pickups and drop-offs had to stay inside a defined operating area, agreed with the local authority that had approved the service in the first place. Drivers dropping outside that boundary, even by a short distance, put the whole operating agreement at risk, and relying on drivers to eyeball a boundary on a paper map was never going to be reliable.

The service built the check around coordinates rather than addresses, since a rider's pickup pin was already a coordinate dropped on a map inside the app, not typed text. For that raw coordinate, the service used /v1/reverse to get back a readable address and its administrative area, useful for showing the rider a confirmed pickup location and for staff reviewing any flagged trip after the fact, since a coordinate alone is hard for a human to sanity check quickly, while a resolved address is not.

The actual boundary check itself was a straightforward geometry comparison, run by the app's own backend, between the rider's coordinate and the polygon describing the approved operating area, a calculation that does not require an external service once you have a coordinate to test. Where the location endpoints came in was making sure that test always had a real coordinate to work with, converting whatever a rider had typed into their side of the app, if they typed an address rather than dropping a pin, into a coordinate through /v1/forward first.

A pickup request that fell inside the boundary proceeded normally. One that fell outside it, even slightly, was declined before a driver was ever dispatched, with a message explaining the service could not legally operate outside its approved zone, rather than a driver arriving and then discovering they were not allowed to make the pickup. Declining early saved both the driver's time and the rider's, and it kept a clean record showing the service was actively enforcing its own boundary rather than only discovering violations after the fact.

The service also used the reverse geocoded address on flagged or disputed trips, since a small number of pickups landed right at the boundary edge and needed a human to confirm whether a request had, in fact, fallen inside or outside the approved area, something much easier to judge from a resolved street address and neighborhood name than from a raw pair of coordinates on an internal dashboard.

This kind of boundary enforcement is not a complicated technical problem once the location pieces are in place. The hard part was making sure every pickup and drop-off, however it was entered into the app, always ended up as a coordinate the backend's geometry check could actually use, and that fell to /v1/forward and /v1/reverse working together depending on which direction the data came from.

Volume was tied directly to ride volume, one or two lookups per trip, a workload that stayed inside the free daily allowance for a service of this size operating in a single limited area. Documentation for both endpoints is at /docs/forward-geocoding/ and /docs/reverse-geocoding/.