News | My Geocode blog

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

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

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

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

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

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

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

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

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

A data processing agreement now available on request

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

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

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

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

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

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

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

A grace period before an unverified key pauses

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

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

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

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

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

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

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

A new bulk endpoint for address lists

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

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

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

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

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

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

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

IP threat and network detail available on request

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

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

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

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

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

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

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

Faster response times after an infrastructure upgrade

2026-09-19T07:53:00+00:00

Every request to My Geocode travels through the same serving infrastructure before an answer comes back, regardless of which endpoint it hits or which compatibility host it is shaped for. We recently completed an upgrade to that shared infrastructure, and the result is faster response times across the board.

This is a platform-wide change rather than something specific to one endpoint. /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete and /v1/postcode all sit on the same upgraded stack, as do all seventeen compatibility hosts. Nothing about request parameters, response fields, authentication methods, or pricing has changed as part of this. The upgrade is entirely behind the scenes, visible only in how quickly a response comes back.

For most integrations, this kind of improvement is felt rather than measured precisely, a general sense that calls come back a little quicker than before. For integrations doing meaningful volume, particularly batch jobs processing many items in sequence, or anything with autocomplete-style traffic firing repeatedly as a user types, the effect compounds across many requests and becomes easier to notice directly. An autocomplete field that sends a request on every keystroke of an eight character search term makes eight calls in the time it takes to type it, and shaving even a small amount off each one changes how the whole interaction feels, in a way a single standalone lookup would not show at all.

We treat infrastructure work like this as a continuous responsibility rather than a one-time project. A geocoding API that people build real products on top of needs to keep performing well as usage grows, not just on the day it launches, and that means revisiting the serving stack periodically rather than leaving it untouched indefinitely. This upgrade is one step in that ongoing process, not a final destination.

Because every endpoint and every compatibility host runs through the same shared stack, an upgrade like this only has to happen once to benefit all of them, rather than being repeated endpoint by endpoint or host by host. That shared design is also why a change here never touches request formats, response fields or the quota engine: those live at a different layer entirely.

None of the quota or billing mechanics change as a result. Every response still carries the same full set of quota headers, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit and X-Quota-Reset, and the free allowances, prepaid credit rate, and Unlimited package price are all unchanged.

The same shared stack is what every compatibility host runs on as well, so a TomTom-shaped call and a native call to /v1/forward see identical gains, and the improvement is not something that needs to be requested per host or negotiated separately for a specific integration.

If your integration is sensitive to response time, whether because it is user-facing or because it processes high volumes of batch requests, you should notice a difference without needing to change anything on your end. Full documentation for every endpoint remains exactly as it was, available at /docs/.

A dedicated postal code lookup endpoint

2026-09-18T20:50:00+00:00

Not every location question is really a geocoding question. Sometimes the only thing an application actually needs is the postal code for a given area, or the area covered by a given postal code, without the broader address resolution that forward or reverse geocoding provides. /v1/postcode exists specifically for that narrower question, as its own dedicated endpoint rather than a side effect of a more general lookup.

Keeping it separate from /v1/forward and /v1/reverse matters for a few practical reasons. It means the request shape can be built specifically around postal code parameters rather than adapted from a broader address structure. It means the response can focus on exactly what a postal-code-only integration needs, without extra address fields to filter out. And it means documentation, available in full at /docs/postal-code-lookup/, can explain postal code behavior on its own terms rather than as a subsection of a longer geocoding guide.

Authentication follows the same rules as every other endpoint: an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth with the key as the username, or a query parameter, all accepted identically. Pricing is the same as well, drawing on the same free daily allowance, whether from the calling network or from the key, and the same €0.0001 a request in prepaid credit or Unlimited package coverage beyond that.

Batch requests work here exactly as they do everywhere else on the platform: each postal code or address submitted in a single call counts as one request, not the call as a whole. A team validating postal codes across a large customer list can send that list as a batch and expect the same per-item counting that applies to any other bulk operation on My Geocode.

Having a dedicated endpoint also makes the postal code compatibility work across our seventeen compatibility hosts more precise, since providers that offer their own dedicated postal lookup can be matched exactly rather than approximated through a broader geocoding shape.

If your application only needs postal code information and has previously been sending broader geocoding requests just to extract that one field, /v1/postcode is worth switching to directly. It is documented fully at /docs/postal-code-lookup/, alongside the rest of our endpoint reference at /docs/.

Improved coverage for rural and low-density postal codes

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

Dense cities are the easy case for postal code data. Boundaries are well documented, addresses are numerous, and data providers tend to prioritize them naturally because that is where the volume of queries lives. Rural and low-density areas have always been the harder case, with fewer addresses spread across larger boundaries that are easier to get slightly wrong. We put specific effort into improving /v1/postcode coverage exactly there.

The endpoint's request and response shape is unchanged, documented in full at /docs/postal-code-lookup/. What improved is accuracy in the areas that tend to be weakest across postal code data generally: sparsely populated regions where a postal boundary might cover a wide area with relatively few actual addresses inside it, and where small errors in the underlying data are historically more common because there is less traffic to surface them.

This matters for a specific, often underserved set of use cases: logistics and delivery services covering rural routes, agricultural and land-based businesses operating outside dense population centers, and any address form that needs to work correctly regardless of whether a user lives in a city center or somewhere far more sparsely populated. An address lookup that works reliably only in cities is a gap that shows up exactly when a rural customer tries to use it, often without anyone noticing until a specific complaint arrives.

Pricing and quota behavior are unaffected. A postal code lookup in a dense city and one in a sparsely populated rural area cost exactly the same, counted the same way against the free allowance, prepaid credit, or an Unlimited package, and a batch of postal codes still counts each one individually.

We think coverage quality in lower-density areas is worth investing in specifically, rather than treating it as naturally solved once city coverage is strong, since the two do not actually correlate. A provider can have excellent coverage in major cities and noticeably weaker coverage everywhere else, and that gap is invisible until it directly affects a real address lookup for a real customer somewhere outside a city center.

If your application serves customers outside major population centers, whether for delivery, field service, or general address validation, this improvement should be visible as more reliable postal code matches in exactly the areas that used to be hardest to get right. Full documentation for the endpoint remains at /docs/postal-code-lookup/.

Autocomplete suggestions added across compatible hosts

2026-09-17T16:47:00+00:00

Address autocomplete is a different kind of request from a straight geocoding lookup: it needs to respond to partial, changing input rather than a single finished address, usually as someone types into a form. We have extended our compatibility hosts to support this pattern as well, matching the autocomplete request shape of the providers that offer it.

This sits alongside our native /v1/autocomplete endpoint, documented at /docs/address-autocomplete/, which handles the same kind of partial-address request directly. Wherever a compatibility host's original provider also offers autocomplete, that same request shape is now supported on our equivalent host, aside from copyright, terms and privacy text, which is ours.

Authentication and pricing for autocomplete requests follow exactly the same rules as every other request type on the platform. A key authenticates as an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter, and usage counts against the same free daily allowance, whether that allowance comes from the calling network or from the key itself. Beyond the free allowance, autocomplete requests draw on prepaid credit at €0.0001 a request or are covered by an Unlimited package, exactly like any other endpoint.

Autocomplete traffic tends to run at a different pace than a typical geocoding lookup, often firing on every keystroke as someone types an address into a form rather than once per finished submission. That makes quota visibility especially useful here: the same quota headers attached to every response, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining and the rest, let an integration watch consumption in real time and adjust behavior, such as debouncing requests more aggressively, if usage is running higher than expected.

For teams that already use a compatibility host for geocoding and separately handle autocomplete through another provider or a second integration, this update means autocomplete can now potentially move onto the same host and the same key, consolidating both request types under one account rather than splitting them across two.

Which compatibility hosts support autocomplete depends on whether their original provider does, and the details for each are documented on that host's own page, reachable from the full list at /compatibility/. Testing autocomplete against a compatible host costs nothing to try, given the free allowance available to any new key.

A faster elevation endpoint for long routes

2026-09-17T06:12:00+00:00

An elevation profile for a hiking trail or a driving route is rarely a single coordinate. It is dozens, sometimes hundreds, of points along a path, each needing an elevation figure to build a climb chart or estimate effort along the way. That pattern of use, many coordinates in service of one continuous route, is what we specifically optimized for in a recent pass over /v1/elevation.

The endpoint's request and response shape has not changed, and everything documented at /docs/elevation-lookup/ still applies exactly as written. What changed is how efficiently a large batch of coordinates along a route gets processed internally, aimed at reducing the time it takes to get an elevation profile back for a long path rather than a single isolated point.

Since a batch request counts each coordinate as one item, exactly as it always has, this improvement affects speed, not pricing or quota behavior. A route with two hundred coordinate points still counts as two hundred requests against whatever allowance applies, whether that is the free daily allowance, prepaid credit at €0.0001 a request, or coverage under an Unlimited package. What changes is how long the response takes to come back, which matters directly for anything building a route profile interactively rather than as a background job.

This same improvement carries through to our Open-Elevation compatibility host at /compatibility/open-elevation/, since it draws on the same underlying elevation endpoint. Anything already sending route-length batches through that host benefits from the faster processing without any change needed on the integration side.

Routing and hiking applications tend to be exactly where this kind of improvement is felt most directly, since an elevation profile that takes noticeably longer to load than the route itself creates a visible lag for a user waiting on a map. A faster response for these longer, route-shaped batches closes that gap.

If your application requests elevation for routes made up of many coordinates, whether for hiking, cycling, or driving directions, you should notice this as a quiet improvement in how quickly a full profile comes back, with nothing else about the integration needing to change. Full endpoint documentation remains at /docs/elevation-lookup/.

Batch limits: matching what the big providers already allow

2026-09-16T20:55:00+00:00

A batch integration built against a large, established provider was usually built around whatever batch size that provider already supported, since there was rarely a reason to test smaller. When that same integration gets pointed at a new provider, one of the first questions is whether the batch size it already sends will actually be accepted, or whether it needs to be split down into smaller pieces first.

We built our batch handling with exactly that concern in mind. Rather than picking an arbitrary limit and asking every integration to adjust around it, we sized batch support to match what the large providers our compatibility hosts stand in for already allow. An integration sending a batch shaped for Geocodio, or for Google Maps Platform, should not need to resize that batch just because the destination changed.

Pricing for batch requests stays exactly the same regardless of size: every item inside a batch counts as one request, not the call as a whole. A batch of a hundred addresses counts as a hundred requests against whatever allowance applies, whether that is the free daily allowance, prepaid credit at €0.0001 a request, or coverage under an Unlimited package. There is no separate, different rate that kicks in at a particular batch size, and no incentive to break work into smaller calls purely to manage cost.

This applies the same way across native endpoints and compatibility hosts alike. A batch sent to /v1/forward directly and a batch sent to a compatibility host shaped for a large provider are both handled by the same underlying batch logic, sized the same way, priced the same way, and reflected the same way in the quota headers attached to the response.

For teams migrating an existing batch integration over, this means the migration itself should be uneventful on the batch-sizing front specifically. The migration guides at /docs/compatibility/ cover the details worth checking for each provider, but batch size limits should not be one of the things that requires extra engineering work during a switch.

If you run batch jobs today against a provider you are considering leaving, testing the same batch size against the equivalent My Geocode compatibility host is a quick way to confirm this in practice, and it costs nothing to try given the free allowance covers meaningful testing before any commitment is needed.

Updated terms of service and privacy policy

2026-09-16T07:37:00+00:00

Legal documents are easy to write once and forget, even as the product underneath them keeps changing. Ours needed a proper update, and both our terms of service and our privacy policy have now been revised to reflect the platform as it actually works today, rather than an earlier version of it.

The most significant addition covers our seventeen compatibility hosts directly. Each one reproduces another provider's request and response shape exactly, and our updated terms are explicit about what that does and does not mean: the shape is matched precisely, while copyright, terms and privacy text on those hosts is ours, not the original provider's. Anyone relying on a compatibility host as part of their own product should read this section specifically, since it clarifies exactly where our responsibility as the operator of that host begins and ends.

The privacy policy update reflects how account data, usage data and payment information move through the platform, covering the dashboard's usage stats, invoices, API keys, referral program, and the three payment methods we support: PayPal, cryptocurrency, and bank transfer. It also addresses IP address handling directly, since IP geolocation is one of our core endpoints and a meaningful part of how quota is calculated per network in the first place.

We wrote both documents in plain language wherever the underlying legal requirement allowed it, on the theory that a policy nobody reads carefully is not doing its job. Where technical precision was required, particularly around data handling and account security, we kept that precision rather than smoothing it over for readability alone.

For teams that need a formal record of how personal data is processed on our end, a data processing agreement is available on request, separate from the general privacy policy, and covered in more detail elsewhere. That option exists specifically for organizations with their own compliance requirements around vendor data handling, on top of the general policy that applies to every account.

Neither update changes pricing, quota behavior, or how any endpoint or compatibility host functions. They exist to describe the platform accurately as it stands today, not to introduce new restrictions or new obligations beyond what was already true in practice. Both documents are linked from the footer of every page on the site, and we would encourage anyone building on the compatibility hosts specifically to give that section a read.

Coupon codes for teams moving from a competitor

2026-09-15T19:46:00+00:00

Switching providers is rarely just a technical decision. There is often a cost question sitting alongside the engineering one, especially for a team that has already invested time integrating against a provider it is now considering leaving. Coupon codes, now supported directly in the dashboard, are aimed at that part of the decision.

A coupon code can be applied to an account from inside the dashboard at /dashboard, where it is tracked alongside the account's usage, invoices, and prepaid credit or Unlimited package status, the same as every other billing detail already handled there. It sits next to the other account tools already available: API keys, the referral program, two-factor authentication, and language and dark-mode settings.

This works especially well alongside the migration guides and compatibility hosts we have published, since the combination addresses both sides of a switch at once. The compatibility hosts at /compatibility/ mean the technical side of a migration is close to free, a changed host name and a new key rather than a rewrite. A coupon code addresses the cost side directly, giving a team an added reason to make that switch now rather than putting it off indefinitely because the current setup, however imperfect, still technically works.

We built coupon codes generally rather than tying them to any single promotion, since the situations that call for one vary. A team migrating a large integration away from a competitor is different from an individual developer trying the platform for the first time, and both are worth supporting with the same underlying mechanism. However a code is issued, applying it is the same simple step inside the dashboard, and its effect shows up directly against prepaid credit or an Unlimited package.

None of this changes the underlying pricing model. Every endpoint and every compatibility host still costs the same: €0.0001 a request in prepaid credit, or €50 a month for an Unlimited package, on top of the free 2,500 requests a day from any address and a further 2,500 per key. A coupon code is applied against that same structure rather than replacing it with something separate or harder to reason about.

If you have a coupon code from us, applying it takes a minute inside the dashboard. If you are considering a migration and think a code might be available, our support team is worth asking before you commit to the switch.

Migration guides: a new home for switching providers

2026-09-15T06:21:00+00:00

Knowing a compatibility host exists is one thing. Knowing exactly how to move an existing integration onto it, without breaking anything along the way, is another. We built a dedicated set of migration guides to close that gap, gathered together at /docs/compatibility/.

The guides walk through the practical steps of switching: what changes in a request, what stays the same, which authentication method to use, and what to watch for in the response, provider by provider, endpoint by endpoint. Since each of our seventeen compatibility hosts reproduces its original provider's request and response shape exactly, aside from copyright, terms and privacy text, the guides focus mostly on the parts that genuinely differ: the host name to point at, the key to generate, and the quota headers that now ride along with every response.

We wrote these with a specific reader in mind: someone who already has working code against another provider and wants confidence, not just a promise, that pointing it at us will keep working. That means being explicit about pricing during the transition too. Every endpoint and every compatibility host costs the same, with 2,500 free requests a day from any address and a further 2,500 free requests a day per key, so testing a migration costs nothing before you commit to it.

Each guide also covers the small details that tend to trip up a migration if left unaddressed: how batch requests are counted, since a bulk call counts each item individually rather than the call as a whole, and what the extra quota headers on each response mean if you have not seen them before. None of that requires guesswork once the relevant guide is open next to your code.

For a team weighing whether to move, the recommended path is straightforward: read the guide for whichever provider you currently use, generate a key, and test a handful of real requests against the compatible host before touching any production code. Because the free allowance covers that testing entirely, there is no cost to comparing the two side by side before deciding.

The full list of compatibility hosts covered by these guides sits at /compatibility/, and general authentication and rate limit documentation that applies across all of them is at /docs/authentication/ and /docs/rate-limits/. We plan to keep expanding this guide collection as compatibility coverage grows.

A public compatibility matrix: seventeen hosts, one key

2026-09-14T20:49:00+00:00

Seventeen compatibility hosts is a lot to keep track of one announcement at a time, so we put all of them in a single place: a compatibility matrix at /compatibility/ listing every drop-in host we support, side by side, with a direct link to each one's own documentation.

The list covers Google Maps Platform, Bing Maps REST Services, HERE Geocoding and Search, Mapbox Geocoding, Geocode.Farm, OpenStreetMap Nominatim, OpenCage, LocationIQ, Geoapify, TomTom Search, MapQuest Geocoding, Geocodio, PositionStack, ip-api.com, ipinfo.io, ipstack and Open-Elevation. Between them, that covers geocoding, IP geolocation and elevation lookups, reproducing each original provider's request and response shape exactly, aside from copyright, terms and privacy text, which is ours.

The point of putting them on one page is not just tidiness. It means a team weighing which provider to move away from can see the full field at once, rather than discovering compatibility hosts one at a time through separate announcements. If your stack touches more than one of these providers, whether that is Mapbox for geocoding and ipinfo.io for IP lookups, or any other combination, the matrix makes it clear that all of them can be consolidated behind one My Geocode account and one key.

That consolidation is the real advantage of the compatibility approach generally. A single key authenticates against every host on the list, using whichever of our four standard methods your integration already prefers: an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter. Usage across all of them counts toward the same free allowance, the same prepaid credit balance, or the same Unlimited package, and every response, regardless of which host produced it, carries the same quota headers. One account, one key, one bill, covering however many separate providers your integration used to depend on.

For teams considering a broader migration rather than swapping a single provider, this matrix is the natural starting point, and general migration guidance sits alongside it at /docs/compatibility/. Each host's own documentation page covers the specific request parameters and any details worth knowing before switching.

We plan to keep this page current as compatibility coverage evolves, so it remains the single reference for what is available rather than something that goes stale between individual announcements.

The dashboard now speaks more than one language

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

My Geocode serves customers worldwide, priced in EUR with no regional restriction, and the dashboard managing those accounts should not assume everyone using it is most comfortable reading English. Language settings are now available in the dashboard, letting the interface itself adapt to whichever language a customer prefers.

This sits alongside dark mode as one of the personalization options available from account settings, both aimed at the same underlying idea: the tools surrounding an API should fit how someone actually prefers to work, rather than asking every customer, everywhere, to adapt to one default. Switching a language preference takes effect immediately and can be changed again at any time without affecting anything else tied to the account.

Language settings apply to the dashboard interface itself, the pages covering usage stats, invoices, API keys, the referral program, two-factor authentication and coupon codes. They do not change how the API itself communicates. Request parameters, response field names, error formats, and the seventeen compatibility hosts all remain exactly as documented regardless of which language a given account's dashboard is set to, since consistency there matters more for integration code than convenience does.

We think of this as a natural extension of building for worldwide use rather than a separate feature bolted on for its own sake. An API priced only in EUR and built to work from any address already assumes an international customer base. A dashboard that only spoke one language back to that same base was always a mismatch worth closing.

For teams with members working in different languages day to day, each person's dashboard preference is their own, tied to how they individually prefer to work rather than fixed at the account level for everyone. That means a shared account can have team members each viewing the dashboard in whichever language suits them, without one person's preference overriding another's.

Language settings are available now to every account, alongside dark mode and the rest of the personalization options, reachable at /dashboard. Nothing about existing usage, keys, or billing changes as a result of this update. It only changes the language the dashboard uses to present that same information back to you.

Dark mode for the dashboard

2026-09-13T18:17:00+00:00

Some preferences are small and still worth getting right. Dark mode is now available across the client dashboard, a setting anyone can switch on from their account preferences whenever they prefer working against a darker interface, whether that is a matter of taste, lighting conditions, or simply what feels easier on the eyes during a long session.

Turning it on changes the appearance of the dashboard itself, the interface where usage stats, invoices, API keys, referrals, two-factor authentication and coupon codes all live. It does not touch anything about the API. Requests, responses, quota headers and pricing behave exactly the same regardless of which theme the dashboard happens to be set to, since dark mode is purely a matter of how the account management interface looks, not how the API behaves.

The setting lives alongside language preferences in the same part of the dashboard, both aimed at the same idea: the tools around an API should adapt to how someone prefers to work, rather than asking everyone to work the same way. Switching between light and dark is immediate and can be changed back at any time without losing any other setting or preference tied to the account.

The clearest case is also the most common one: checking a quota counter or a key's status at night, often on a phone, while debugging something that broke outside business hours. A bright white dashboard in a dark room is a small but real friction in that moment, and it is exactly the kind of friction dark mode removes without requiring anyone to explain why it matters.

We treat interface details like this as worth doing properly rather than as an afterthought, even for a company whose core product is an API rather than a visual application. A dashboard is still the place most people interact with My Geocode directly, checking a key, reviewing an invoice, or watching a quota counter during a busy day, and small comforts there add up over repeated use in a way that is easy to underestimate.

None of this required touching how the API itself is built or served, which is part of why it shipped as a straightforward account preference rather than a larger project. The dashboard and the API are separate layers by design, so a visual setting on one side never has any bearing on request handling, quota accounting or pricing on the other.

If you spend meaningful time in the dashboard, whether managing keys for a team or just checking in on usage periodically, dark mode is available now with no separate signup or feature request needed. It is a setting, not a plan tier or an add-on, available to every account exactly the same way.

Account settings, including dark mode and language preferences, are reachable from /dashboard at any time.

Canned replies for faster support answers

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

Most support tickets are not unique. A question about how quota is counted, how to authenticate a key, or how a compatibility host handles a specific parameter tends to come up again and again, phrased slightly differently each time but asking essentially the same thing. We built a set of canned replies for our support team to draw on, aimed squarely at getting those routine questions answered faster.

This is not a chatbot and not an automated response system. A person on our team still reads every ticket and decides what to send back. What canned replies change is how quickly that person can put together a clear, accurate answer to a question we have already answered well before, rather than writing a fresh explanation from scratch each time or, worse, giving a shorter answer than the question deserves because time is tight.

The questions that benefit most tend to be the practical, structural ones: how the four authentication methods work, how the free allowance is shared across a network, how a compatibility host handles a particular edge case, or what happens to a key during the grace period before an unverified account is confirmed. These are questions with clear, stable answers, exactly the kind that a canned reply can capture accurately and reuse without losing any precision.

Genuinely unique problems, the kind that need someone to actually look at a specific account or a specific integration, are not something a canned reply is meant to solve, and our team still treats those individually. The goal here is narrower: clear the routine questions out of the way quickly, so the time that would have gone into re-explaining something well documented instead goes into the tickets that actually need a person thinking carefully about them.

This sits alongside the broader dashboard and account tooling we have built out, all aimed at the same underlying goal: reducing the amount of friction between a question and a clear answer, whether that answer comes from a quota header, a documentation page, or a support reply. Documentation for common questions is also available directly at /faq/ and /docs/, which is often the fastest path to an answer for anything that does not require a person to look at your specific account.

If you have a support ticket open with us now, or open one going forward, you should notice replies to common questions arriving a little more quickly and consistently as a result of this change.

Network allowance: why a shared office shares one quota

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

A twelve-person office sharing one internet connection looks, from the outside, like a single IP address making a lot of requests. That is exactly the situation our per-network free allowance is designed around, and it is worth explaining why we count it that way instead of counting every request as if it came from an unrelated stranger.

The free tier gives 2,500 requests a day from any address, with no key needed. That allowance is counted per network: all IPv4 addresses in the same /24 and all IPv6 addresses in the same /48 share one allowance together, whether or not any of them are using a key. A /24 covers 256 addresses, roughly the range a small to mid-sized office or building might sit within depending on how its network is configured. Treating that whole block as one allowance reflects the reality that it is very likely one organization, not 256 separate, unrelated users each entitled to their own free 2,500 requests a day.

This also closes an obvious gap that a purely per-address free tier would leave open. Without network-level counting, an organization could spread requests across many addresses, or generate many keys from within the same building, and effectively multiply a free tier meant for individual, modest use into something far larger. Counting per network keeps the free allowance meaningful and fair without requiring us to police individual accounts by hand.

It is worth being precise about what is shared and what is not. The free network allowance is shared across addresses and unkeyed traffic on that network. A key's own separate 2,500 free requests a day is not diminished by other unkeyed traffic on the same network, and it travels with the key rather than staying tied to wherever the key happens to be used from. X-Key-IPs-Used and X-Key-IPs-Limit on every response reflect how many distinct addresses a given key has been used from, giving visibility into that side of things as well.

For a business operating from a single, well-defined network, this usually means the free tier behaves exactly as expected: one shared 2,500 requests a day across the building, on top of whatever any individual key adds separately. X-Quota-Network-Used on every response shows exactly how much of that shared pool has been used at any given moment, so nobody on a shared connection has to guess how close the team is to needing prepaid credit or an Unlimited package.

Full detail on how quota is counted, including the header names involved, is documented at /docs/rate-limits/.

Rate limits, explained in plain language

2026-09-12T06:31:00+00:00

Rate limits have a reputation for being confusing, full of exceptions and fine print that only become clear after something breaks. Ours are simpler than that, and worth laying out plainly in one place.

Every address gets 2,500 free requests a day with no key at all. That allowance is not per address individually, it is shared across a network: all IPv4 addresses in the same /24 and all IPv6 addresses in the same /48 draw from one pool together. That matters if you are behind a shared office connection or a large network address translation setup, since your free allowance is shared with everyone else on that same network segment, whether or not they are using a key.

Every key also gets its own free daily allowance of 2,500 requests, separate from whatever the network already provides. A key's allowance is not diminished by other traffic on the same network, and a network's allowance is not diminished by traffic that already used up a key's separate quota. The two allowances sit side by side rather than competing with each other.

Past both allowances on a given day, a request either draws on prepaid credit at €0.0001 a request or is covered by an Unlimited package at €50 a month, whichever the account has set up. There is no throttling that silently slows requests down and no surprise block with no explanation. Every response carries quota headers, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining, X-Quota-Network-Used, X-Credits-Remaining, X-Key-IPs-Used, X-Key-IPs-Limit and X-Quota-Reset, so exactly where a request stands is visible before it ever fails.

A bulk or batch call follows the same rules at the item level, not the call level. A hundred addresses sent in one call counts as a hundred requests against whatever allowance applies, exactly the same as if they had been sent as a hundred separate calls.

All of this applies identically across every endpoint and every one of the seventeen compatibility hosts. A request shaped for OpenCage or ipstack is rate limited by the exact same rules as a request to /v1/forward or /v1/ip directly, with no separate, stricter limit hiding behind a familiar-looking response shape.

Full details, including how the daily reset works and what each header means, are documented at /docs/rate-limits/. If a rate limit question ever comes up in your integration, the answer is almost always visible directly in the headers of the response that triggered it.

A cleaner error format across every endpoint

2026-09-11T19:46:00+00:00

An error response is not a footnote to an API, it is part of the contract every integration relies on just as much as a successful one. We have standardized the error format across every native endpoint on My Geocode, so a failure looks the same regardless of which part of the API produced it.

Whether a request fails because of a missing parameter, an invalid key, exhausted quota, or a malformed coordinate, the response follows a single, predictable structure. That consistency means error-handling code written once, against one endpoint, works the same way against every other native endpoint without needing separate handling logic for each one.

Quota-related failures deserve particular mention, since they are the most common kind an active integration will encounter. When a request would exceed a key's or a network's allowance, the response makes that clear, and the quota headers already present on every response, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining and the rest, tell you exactly how much room was available before the request that failed. That combination means a client can distinguish a quota problem from an authentication problem or a bad request from the response alone, without guessing.

Compatibility hosts are a deliberate exception to this standardization, and for good reason. Their entire purpose is to reproduce another provider's request and response shape exactly, and that includes how errors look. A request shaped for Bing Maps REST Services that fails still gets an error in Bing's own error format, because matching that shape precisely, success or failure, is the whole point of a drop-in host. Standardizing errors there would break the very compatibility the host exists to provide.

For anything built against our native endpoints, this cleaner format should make error handling noticeably simpler to write and maintain. A single parsing routine, a single set of expected fields, and consistent behavior across /v1/forward, /v1/reverse, /v1/ip, /v1/timezone, /v1/elevation, /v1/autocomplete and /v1/postcode alike.

Full documentation of the error format, including field names and common causes, is available at /docs/errors/. If your integration currently has separate error-handling branches for different native endpoints, this is a good moment to simplify that down to one.

New ways to pay: PayPal, cryptocurrency and bank transfer

2026-09-11T07:41:00+00:00

Paying for an API should not be harder than using one. My Geocode now accepts three payment methods for prepaid credit and Unlimited packages: PayPal, cryptocurrency, and bank transfer, so an account can pick whichever fits its own setup rather than being locked into a single option.

PayPal suits accounts that want the fastest path from decision to active credit, using an account most people and businesses already have set up. Cryptocurrency suits accounts that prefer to pay that way for their own reasons, whether that is speed, privacy, or simply preference, and it is treated as a first-class option here rather than an afterthought bolted on separately. Bank transfer suits accounts, often larger organizations, that need a traditional paper trail or that operate under procurement rules requiring it.

Supporting three rails rather than one is mostly a question of settlement speed and paperwork, not a difference in what a payment buys. PayPal and cryptocurrency both settle quickly enough that credit or an Unlimited package can go active within the same session. Bank transfer settles on banking timescales instead, sometimes a business day or more, which is the tradeoff an organization accepts in exchange for the transfer record its own procurement process requires.

All three methods lead to the same place: either topped-up prepaid credit at €0.0001 a request beyond the free allowance, or an active Unlimited package at €50 a month. There is no difference in what you get based on how you paid for it, and no method carries a different rate or a hidden surcharge attached.

This flexibility matters because the accounts using My Geocode range widely, from an individual developer testing an idea on a personal card through PayPal, to a company settling invoices by bank transfer as a matter of internal policy, to a team that simply prefers paying in cryptocurrency. Building for EUR-based, worldwide usage means building for that same range of payment preference, not assuming one method fits everyone.

In practice this plays out as three very different account holders reaching the same result by different paths: a developer funding a small prepaid balance with a personal PayPal account before a weekend project, a company routing a larger Unlimited package through a bank transfer tied to a purchase order, and a team that simply prefers settling in cryptocurrency for its own operational reasons. All three see the identical €0.0001 per request rate and the same €50 monthly figure once the payment clears.

Every key gets a free daily allowance. Past it, requests draw on prepaid credit or are covered by an Unlimited package. Every response tells you where you stand in its headers, and now, funding that credit or that package is a matter of picking whichever of the three payment methods is easiest on your end.

Coupon codes sit next to payment methods in the dashboard for accounts that receive a promotional or referral credit rather than paying directly, applying the same way to a prepaid balance regardless of which of the three payment methods eventually tops it up further.

Managing payments, whichever method you choose, happens directly inside the client dashboard at /dashboard, alongside invoices, usage stats and API keys. Pricing details for prepaid credit and Unlimited packages are at /pricing/.

Postal code coverage extended to more countries

2026-09-10T19:39:00+00:00

A postal code lookup is only as useful as the map of countries it actually understands. We have extended the coverage behind /v1/postcode to include more countries than it did before, widening what the endpoint can answer for teams operating outside a single home market.

My Geocode is priced and built for worldwide use, in EUR only, and postal code coverage growing over time is part of what that promise means in practice. The request shape and response fields for /v1/postcode are unchanged, documented in full at /docs/postal-code-lookup/, so nothing about an existing integration needs to change to benefit from the wider coverage now available underneath it.

This matters most for applications that were built with one country in mind and later found themselves serving customers elsewhere. Address forms, shipping calculators, and location-based signup flows all tend to hit a wall the moment a user outside the original target market shows up. Wider postal code coverage means fewer of those moments, without needing to bolt on a second, country-specific data source just to fill a gap.

Coverage growth of this kind is naturally an ongoing effort rather than a single finished task. Postal systems vary a great deal between countries, some highly structured and consistent, others far less so, and closing that gap country by country takes real, continuing work. We plan to keep extending coverage over time, and updates like this one will keep landing as that work continues.

Pricing and quota behavior around the postal code endpoint are unaffected by this expansion. It still counts as a standard request within the free allowance, prepaid credit, or Unlimited package, exactly like every other endpoint on the platform, and a batch of postal codes still counts each one individually rather than the call as a whole.

If your application serves users outside the region it was originally built for, this is a good moment to check whether a country you previously had to handle separately, or skip entirely, is now covered. Full details on the endpoint, including its request parameters, are documented at /docs/postal-code-lookup/, and general pricing across all endpoints is at /pricing/.

Elevation data refreshed for better accuracy in mountainous regions

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

Flat terrain is forgiving. Elevation data that is slightly out of date barely shows in a response when the ground barely changes over a wide area. Steep terrain is a different story, where a small horizontal shift in a coordinate can mean a real difference in height. We refreshed the elevation data behind /v1/elevation with that specifically in mind.

The endpoint itself has not changed shape. Send a set of coordinates and you get back an elevation figure in meters, the same request and response structure documented at /docs/elevation-lookup/. What changed is the source data underneath, updated to reduce the kind of error that shows up most in mountainous and high-altitude terrain, where older or coarser data tends to smooth over real variation in the landscape.

This matters most for anything that treats elevation as more than a background detail. Route planning that accounts for climb, outdoor and hiking applications that report altitude along a trail, and engineering or agricultural tools that rely on precise ground height all depend on data that reflects terrain closely rather than approximately. A refreshed dataset behind the same endpoint means those use cases get a better answer without touching a single line of integration code.

Batch behavior is unchanged as well. A request carrying many coordinates still counts each one individually, exactly as it always has, and pricing follows the same €0.0001 a request beyond the free allowance, or coverage under an Unlimited package, regardless of how flat or steep the terrain in question happens to be.

This same refreshed data also sits behind our Open-Elevation compatibility host at /compatibility/open-elevation/, so anything already pointed there benefits from the same improvement without any action needed on your end.

We think of elevation accuracy as an ongoing responsibility rather than a one-time task, since terrain data sources themselves improve over time and it is worth passing that improvement along as it becomes available. This refresh is one step in that direction, focused specifically on the regions where accuracy tends to matter most and where older data has historically been weakest.

If elevation figures feed into anything user-facing in your application, from a hiking app's altitude readout to a route planner's climb estimate, this update should be visible as a quiet improvement in accuracy, particularly anywhere the ground is not flat. Full endpoint details remain at /docs/elevation-lookup/.

Faster time zone lookups after rebuilding our lookup table

2026-09-09T18:24:00+00:00

Every call to /v1/timezone runs against a lookup table mapping coordinates to time zone boundaries, and how that table is structured has a direct effect on how quickly an answer comes back. We rebuilt that table from the ground up, and the endpoint now answers faster as a result.

None of this changes what a request looks like or what a response contains. Send coordinates to /v1/timezone and you still get back the same fields you always did: the time zone identifier, offset information, and the rest of the response shape documented at /docs/timezone-lookup/. The only difference is how quickly that answer arrives, which matters most for anything calling the endpoint repeatedly, such as a batch of coordinates processed one after another or a real-time feature that cannot afford to feel sluggish.

Time zone lookups tend to sit in places where speed compounds. A single call feeling slightly faster barely registers, but a batch job resolving time zones for thousands of coordinates, or a live map showing local time as a user moves a pin around, both benefit directly from a leaner lookup underneath. Since a batch request counts each coordinate as one item, exactly as it always has, none of the pricing or quota behavior around batch calls changes here either.

This work sits alongside the rest of our approach to the timezone endpoint: consistent quota headers on every response, the same authentication options as every other endpoint, and the same pricing, whether it is called directly or reached through one of the seventeen compatibility hosts that touch location data. A faster lookup table does not change any of that, it just means the answer shows up sooner.

We treat this kind of underlying rebuild as ordinary maintenance rather than a headline feature, but it is worth mentioning because the effect is real for anyone leaning on the endpoint heavily. If your integration processes coordinates in bulk, or if timezone lookups sit on a path where response time matters to a user directly, you should notice the difference without changing a single line of code.

Full documentation for the endpoint, including request parameters and response fields, is available at /docs/timezone-lookup/. Nothing there has changed except how quickly it responds.

The client dashboard: usage, invoices and keys in one place

2026-09-09T07:27:00+00:00

Managing an API account usually means bouncing between several places: one page for keys, another for billing, a support inbox for everything else. We built the My Geocode dashboard to put all of that in one spot instead, reachable at /dashboard for any account.

Usage stats sit front and center, showing how a key or a network is tracking against its free allowance, prepaid credit, or Unlimited package, in the same terms as the quota headers attached to every API response. Invoices live in the same place, giving a clear paper trail for anything billed through prepaid credit or an Unlimited package, without needing to email support for a copy.

API keys are managed at /dashboard/keys, where new keys can be generated, old ones reviewed, and anything no longer in use retired. Since a key can authenticate as an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter, the dashboard shows the key value plainly enough to drop into whichever of those four methods a given integration uses.

Beyond usage and keys, the dashboard covers a growing set of account tools. A referral program at /dashboard/referrals rewards anyone who sends a paying customer our way. Two-factor authentication adds a second login step for accounts that want it. Coupon codes can be applied directly against an account. Canned support replies help our team answer common questions faster when a ticket does come in. Language and dark-mode settings let the interface itself adapt to how someone prefers to work.

None of these features are scattered across separate tools or separate logins. They live together because an account's usage, its billing, its keys and its security are all part of the same relationship with the API, not separate products bolted together. We build and run a geocoding API. That is the whole company, and the dashboard is meant to reflect that same focus rather than sprawl into something unrelated.

If you have not looked at your dashboard recently, it is worth a visit even if nothing about your usage has changed. Reviewing active keys, checking invoices, and confirming two-factor authentication is enabled are all small habits that are easy to keep once the dashboard makes them quick.

Everything described here is available now, to every account, with no separate request or upgrade needed to access it.

Two-factor authentication for your account

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

An API key sitting in a dashboard is worth protecting, and the account that manages it deserves more than a password alone. Two-factor authentication is now available on every My Geocode account, ready to turn on from the dashboard settings.

Once enabled, logging into the client dashboard requires a second step beyond your password, tying account access to a device you control rather than to a password alone. This is entirely separate from how API keys authenticate against the API itself: a key still works as an X-API-Key header, an Authorization: Bearer header, HTTP Basic auth, or a query parameter, exactly as it always has. Two-factor authentication protects the account that manages those keys, not the request traffic those keys send.

We built this as an opt-in feature rather than a requirement, because accounts vary in what they need. A personal project with a single low-volume key has different risk than an account managing Unlimited packages and a team's worth of production keys. Either way, turning it on takes a few minutes inside the dashboard, and turning it off again is just as straightforward if your workflow changes.

This sits alongside the rest of the account and security surface already in the dashboard: usage stats, invoices, API keys, a referral program, and language and dark-mode settings, all reachable from /dashboard. Two-factor authentication is one more setting in that same place, not a separate system to learn.

For anyone managing an Unlimited package or meaningful prepaid credit, we would recommend turning this on sooner rather than later. Account access effectively controls billing and key management both, so a second factor there is a small step that closes a real gap. It is also a good moment to review the API keys listed at /dashboard/keys and remove any that are no longer in active use, since fewer live keys means less that needs protecting in the first place.

Two-factor authentication does not change anything about how the API responds to requests, how quota headers work, or how billing is calculated. It changes exactly one thing: who can get into the account that manages all of that. For most accounts, that is worth the extra step at login.

A referral program for anyone who sends us a customer

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

Word of mouth has always mattered for a small, focused API company like ours, so we built a formal way to recognize it. A referral program is now live inside the client dashboard, available to any account that wants to take part.

The idea is simple. If you tell a colleague, a client, or another developer about My Geocode, and they sign up and become a paying customer, that referral is worth something back to you. The mechanics live entirely inside the dashboard at /dashboard/referrals, where a referral link and any activity tied to it are tracked automatically, with nothing to configure by hand and nothing to request manually.

This fits naturally with how we think about the product overall. We build and run a geocoding API. That is the whole company, and a lot of our growth has always come from developers mentioning us to other developers rather than from any large marketing effort. A referral program is a direct way to make that existing behavior worth something concrete, rather than leaving it as an unrewarded favor.

Anyone with a My Geocode account can find their referral details in the dashboard without needing to contact support first or apply for access. It sits alongside the other account tools already there: usage stats, invoices, API keys, two-factor authentication, and language and appearance settings, all reachable from the same place.

We designed it to be genuinely simple rather than clever. There is no tiered structure to memorize, no expiring window to track, and no fine print buried in a separate agreement. Send someone our way, they become a customer, and it shows up in your referral activity. That is the whole shape of it.

If you already recommend My Geocode informally, whether in a team chat, a blog post, or a conversation with another developer evaluating providers, generating a referral link takes a minute inside the dashboard and turns that recommendation into something tracked. And if you have not tried the API yourself yet, the free tier is still the easiest way to start: 2,500 requests a day from any address, no signup required, before you ever think about referring anyone else.

The referral program is available now to every account, existing and new, with no separate signup step required beyond visiting the dashboard.

Prepaid credit and Unlimited packages, explained

2026-09-07T20:36:00+00:00

There are exactly two ways to pay for My Geocode usage beyond the free allowances, and both are simple enough to explain in a sentence each. Prepaid credit costs €0.0001 a request. An Unlimited package costs €50 a month and removes the per-request cost entirely.

We build and run a geocoding API. That is the whole company, and our pricing reflects it: no tiered plans that bundle a handful of endpoints together at different rates, no separate pricing sheet for compatibility hosts, and no negotiation required to find out what something costs. Every endpoint and every drop-in host costs the same, whether it is /v1/forward, /v1/timezone, or a call shaped for Google Maps Platform.

Prepaid credit suits usage that is real but modest, or usage that varies a lot from day to day. You buy credit ahead of time, and each request beyond your free allowance draws it down at €0.0001 a request. Since a bulk or batch call counts each item individually, the same rate applies whether a request is a single lookup or one item inside a call carrying a thousand of them. X-Credits-Remaining on every response shows exactly what is left, so running low is never a surprise discovered mid-month.

An Unlimited package suits usage that is heavy enough that per-request billing would be harder to reason about. For €50 a month, every request past the free allowance is simply covered, on every endpoint and every compatibility host, with no per-request meter to watch. It is a flat number that is easy to budget against regardless of how traffic moves week to week.

Both options sit on top of the free tier, not instead of it. Every address still gets 2,500 free requests a day with no key at all, counted per network, and every key adds its own separate 2,500 free requests a day. Prepaid credit or an Unlimited package only comes into play once those allowances are used up on a given day.

Payment for either option can be made by PayPal, cryptocurrency, or bank transfer, whichever is easiest on your end. There is no requirement to commit to one payment method permanently. An account can switch from prepaid credit to an Unlimited package, or the other way around, as usage patterns change.

Every key gets a free daily allowance. Past it, requests draw on prepaid credit or are covered by an Unlimited package. Every response tells you where you stand in its headers, so choosing between the two is less about guessing and more about looking at a few days of X-Credits-Remaining and deciding which shape fits. Full pricing details are at /pricing/.

Quota headers on every response: know your limit before you call

2026-09-07T07:37:00+00:00

Most APIs make you guess where you stand on usage until something breaks. My Geocode takes a different approach: every single response, on every endpoint and every compatibility host, carries a full set of quota headers telling you exactly where you are.

X-Quota-Limit and X-Quota-Used give the basic picture for the calling key or network. X-Quota-Free-Remaining shows how much of the free daily allowance is left, and X-Quota-Network-Used reflects how much of that shared, per-network free allowance has already been consumed by any address or key on the same connection. X-Credits-Remaining shows prepaid credit balance for anyone past the free tier and not on an Unlimited package. X-Key-IPs-Used and X-Key-IPs-Limit track how many distinct addresses a given key has been used from, and X-Quota-Reset tells you when the daily counters roll over.

The reason this matters is simple: a script that can see its own quota can behave intelligently around it. It can slow down before it gets blocked, alert a developer when credit is running low, or switch from a free key to a paid one automatically rather than failing first and reacting afterward. None of that requires calling a separate usage endpoint or checking a dashboard by hand. The information rides along with the answer you already asked for.

This is true whether you are using our native endpoints or one of the seventeen compatibility hosts. A request shaped like a call to Google Maps Platform, Bing Maps REST Services, or ipstack still comes back with our quota headers attached, on top of whatever response body matches that provider's format. Switching providers does not mean losing this visibility, it means gaining it in places that never had it in the first place.

Every key gets a free daily allowance. Past it, requests draw on prepaid credit or are covered by an Unlimited package. Every response tells you where you stand in its headers, which is a small thing on any single call and a genuinely useful thing across a busy day of traffic.

For teams building anything more than a one-off script, we would suggest logging these headers alongside your own request logs from the start. A quiet trend in X-Quota-Free-Remaining running down faster than expected is a much cheaper thing to notice on a graph than in a support ticket. Full details on each header and what triggers it are documented at /docs/rate-limits/, alongside general authentication guidance at /docs/authentication/.