API Key Tester

Read this before you paste a live API key

This page exists to be useful to people holding real credentials, so it owes them a straight explanation of what happens to those credentials:

For a credential where none of that is acceptable, use this page as a request builder rather than a request sender: fill in the endpoint and scheme, leave the key field empty, press Copy as cURL, and paste the key in on your own machine. You get a correct request; the secret never leaves your laptop.

Where the key goes: four schemes

A valid key sent the wrong way fails identically to an invalid key, which makes "wrong scheme" one of the most frustrating classes of bug in API integration. There are four patterns in common use, and the Auth tab above covers all of them.

Bearer token in the Authorization header

The most widespread convention: Authorization: Bearer <key>. The word Bearer, one space, then the key — no quotes, no trailing newline. Malformed spacing here is a leading cause of mysterious 401s. Anything that describes itself as a "token" almost certainly wants this form.

A vendor-specific header

Many providers define their own header instead: X-API-Key is the generic convention, and plenty of services use their own spelling. Header names are case-insensitive per the HTTP specification, but the value is not, and neither is the exact name spelling once you move past case. Our HTTP headers reference covers how custom headers travel through proxies and logs, which matters more than people expect when a request works in one network and not another.

A query string parameter

Some APIs accept the key as ?api_key= or ?key=. This is convenient and genuinely worse for security: query strings are routinely written into web server access logs, proxy logs, browser history and sometimes referrer headers, none of which are places you want a long-lived credential to accumulate. Where a provider supports both a header and a query parameter, use the header — in this tool and in your own code.

HTTP Basic authentication

A handful of APIs, particularly older payment and infrastructure services, want the key as the username of a Basic credential with an empty password. The Auth tab handles the Base64 encoding for you. If you ever need to decode such a value by hand — to check what a legacy config file is actually sending, for instance — the Base64 encoder and decoder will do it in the browser without the value leaving your machine.

Choosing a good endpoint to test against

The best key-validation request is one that requires authentication, changes nothing, and returns quickly. Look for these, roughly in order of preference:

• An account or identity endpoint — something like a "current user", "me", or "whoami" route. It authenticates, does no work, and its response usually confirms which account or scope the key belongs to, which is often the real thing you wanted to know.
• A listing endpoint — models, projects, resources. Cheap, read-only, and the response doubles as documentation for identifiers you will need in later calls.
• A dedicated health or ping route that still requires auth. Not every API has one, and some do not require credentials on it, which makes them useless for this purpose.

Avoid testing with anything that creates, updates or deletes a resource. A key check is not worth a stray record in production data, and a write endpoint conflates "the key works" with "the payload was right". Avoid billable generation endpoints too when a free listing route exists.

Checking your request shape without sending a real key

If you only want to confirm the request is formed correctly — header name, scheme prefix, no stray whitespace, no smart quotes from a word processor — send a placeholder value like test123 to an endpoint that echoes request headers back. The "Echo my headers back" button above does exactly that. You will see precisely what left the wire. This proves the shape of your request but says nothing about whether the key is valid, since only the issuing provider can answer that. Do not send a real credential to an echo service: its entire purpose is to reflect your data back, and that is not a property you want applied to a secret.

Reading the response: what each status code tells you

The status code is a better diagnostic than the error text, because it categorises the failure before you have to interpret anyone's prose.

The distinction that saves the most time is 401 versus 403. A 401 says the server does not know who you are; the fix lives in how the credential is being transmitted. A 403 says it knows exactly who you are and is declining anyway; the fix lives in permissions, scopes, plans or ownership, and re-checking the key for typos is wasted effort. And 429 is not a credential problem at all, though it is often misreported as one because the request "stopped working".

Provider-specific guides

Each of these pages carries the same tester pre-filled with the right endpoint, headers and authentication scheme for that provider, plus notes on how to create a key and how that provider's particular error responses are shaped.

Common causes of a key that "stopped working"

Keys rarely fail for interesting reasons. When one that used to work no longer does, the explanation is almost always in this list.

• It was rotated or revoked. Somebody cleaned up unused credentials, or an automated policy expired it. Check the provider's console before debugging anything else.
• The environment variable is empty. A rename, a missing secret in a deployment, a .env file that is not loaded in the environment that is failing. The request goes out with an empty credential and returns a 401 that looks exactly like an invalid key.
• Whitespace or quotes were copied along with it. A trailing newline from a here-document, curly quotes from a document, a space introduced by line wrapping in an email. Invisible, and fatal.
• It was truncated on paste. Long keys are easy to select incompletely. Compare the length of the key your code sends against the real one — log the length, never the key.
• Wrong environment. A sandbox key against production hosts, or the reverse. Most providers issue separate keys per environment and they are not interchangeable.
• A restriction it no longer satisfies. Keys limited by IP address, referrer, or allowed API list will fail from a new deployment, a new egress address, or a new endpoint even though the key itself is untouched. This is also why such a key will fail in this tool: our server is not an allowed caller.
• Quota rather than credential. A 429 or a billing-related error reads as "the key stopped working" but is neither an authentication nor an authorisation problem.
• The token expired. If what you are holding is a short-lived access token rather than a long-lived API key, expiry is expected behaviour. Paste it into the JWT decoder to read its expiry claim directly, if it is a JWT.

Once the key works

A validated key is the start of an integration rather than the end of one. From here, the REST API tester gives you the same console for exercising real endpoints with bodies and query parameters, the guide to REST API testing covers what is actually worth testing once requests succeed, and the comparison of browser and installed API clients explains when to graduate from a single-request tool to something with saved collections. For a quick reference on any response you do not recognise, the HTTP status code reference covers every code with its usual causes.

One limitation worth stating: because requests originate from our server rather than your machine, keys for APIs on localhost, private network ranges or internal hostnames cannot be tested here — those addresses are blocked by design to prevent server-side request forgery. For an internal API, use a client that runs on your own machine, or expose the service on a public URL with a tunnelling tool first.

Frequently asked questions