Monitor your key's usage before you hit a limit
Watching your quota headers as you go tells you when a limit is approaching, well before a request actually gets rejected.
Send your API key three different ways (and why it matters)
Not every tool that talks to an API handles authentication the same way, which is why the API accepts a key through more than one mechanism rather than forcing everything through a single header name.
The X-API-Key header
This is the most direct option, a dedicated header carrying nothing but the key.
GET /v1/forward?q=Baker+Street
X-API-Key: mg_live_examplekey123Authorization: Bearer
Some HTTP clients and API gateways are already set up to attach a bearer token to every outgoing request, and using that mechanism means you do not need to add a second, API-specific header alongside it.
GET /v1/forward?q=Baker+Street
Authorization: Bearer mg_live_examplekey123HTTP Basic auth
Older tools, and some server-to-server integrations built against other providers, expect credentials as HTTP Basic auth. The key goes in as the username, with the password left blank.
GET /v1/forward?q=Baker+Street
Authorization: Basic bWdfbGl2ZV9leGFtcGxla2V5MTIzOg==A query parameter, for everything else
When a tool gives you no control over headers at all, such as a quick test in a browser address bar or a client that only supports URL-based configuration, the key can also be passed as a query parameter directly on the request.
GET /v1/forward?q=Baker+Street&key=mg_live_examplekey123Why the choice matters in practice
A key sent as a query parameter ends up in server logs, browser history, and referrer headers more easily than one sent in a request header, so prefer a header-based method whenever the calling code has any control over it. All four methods work identically against every endpoint and every compatibility host, so switching between them later, say when migrating a script from a browser test to a proper backend integration, does not change anything about how quota or credit is tracked against the key.
Using this across compatibility hosts
Every one of the 17 compatibility hosts accepts credentials in the same style the original provider used, so a script written against another provider's authentication convention generally keeps working after you point it at the matching My Geocode compatibility host, without rewriting how the key is sent. See the compatibility page for the list of hosts and which credential style each one expects.
A mistake worth avoiding
Testing a script with the key as a query parameter and leaving it that way in production is an easy habit to pick up, since the query parameter is often the fastest way to get a first request working. Move to a header-based method, X-API-Key or Authorization, before the script goes anywhere near production traffic or gets checked into a shared repository, since a key visible in a URL is far more likely to end up somewhere you did not intend, such as a proxy log or a browser history file on a shared machine.
No cost difference
None of these methods change how a request is billed. Every request against the key still counts the same way toward its 2,500 free requests a day, and past that, against prepaid credit or an Unlimited package.
Picking the right authentication method is mostly about matching what the calling tool already supports, not about performance or cost. Full details are on the authentication docs.