Anthropic API Tester

Read this before you paste a live API key

Stated plainly, without softening, because it is the thing you most deserve to know before typing a secret into somebody else's web page:

If a particular credential is too sensitive for any of that, keep it off this page entirely: build the request here with the key field blank, press Copy as cURL, and fill the key in on your own machine. You still get the exact request shape and the correct headers, and the secret never leaves your laptop.

The two headers people get wrong

More failed first requests against this API come down to headers than to bad keys. Two are worth committing to memory.

x-api-key, not Authorization: Bearer

The Anthropic API takes the key in a dedicated x-api-key request header. If you have been working with providers that use the bearer-token convention, muscle memory will put the key in an Authorization header and the request will fail authentication despite the key being perfectly good. This is the single most common cause of a puzzled first 401. The Auth tab above is already set to API key header with the correct name filled in, so you only need to paste the value. If you want to understand why different APIs pick different conventions, our guide to HTTP headers covers how the Authorization header and vendor-specific headers are treated differently by proxies, caches and logs.

anthropic-version is mandatory

This API is versioned by header rather than by a segment of the URL path. Every request must carry an anthropic-version header with a dated version string; the long-standing value is 2023-06-01, and it is pre-filled in the Headers tab above. Omit it and the request is rejected even with a valid key — which is confusing precisely because the error has nothing to do with the key you were testing.

A third header, content-type: application/json, is needed for any request that carries a JSON body. It does nothing on the GET used above, which is one reason a models listing makes such a clean first test: fewer moving parts, fewer things to get wrong.

How to test a Claude API key

1. Create a key

Keys are issued from the Anthropic developer console after you sign in, and are conventionally prefixed with sk-ant-. Copy the key when it is created; consoles typically show a credential in full exactly once. If your organisation uses separate workspaces, note which workspace the key belongs to — that detail matters later when a request authenticates fine but is refused permission.

2. Send the models request

The pre-filled request is a GET to https://api.anthropic.com/v1/models. It requires authentication, generates no output, and returns the list of models your account can address. That last part is genuinely useful beyond the key check: it tells you the exact model identifiers to use in later calls, which is more reliable than copying one from a blog post that may predate a model being retired.

3. Read the status code first

A 200 with a JSON object containing a data array of model entries means the key is valid, both headers were accepted, and the account is in order. Everything else is diagnostic, and this API is unusually good about telling you which of those three things went wrong.

Valid key vs invalid key: what comes back

Success returns a JSON object whose data field is an array, each entry describing a model your key may use. Errors return a consistent envelope: a top-level type of error, an error object carrying a machine-readable type and a human-readable message, and a request_id.

That request_id deserves a moment of attention. It uniquely identifies the request on the provider's side, which makes it the single most useful thing to capture in your own logs when something goes wrong — far more useful than the error text alone, and the thing support will ask for first. Log it on every failed call.

GET https://api.anthropic.com/v1/models
x-api-key: sk-ant-…
anthropic-version: 2023-06-01

200 OK → { "data": [ { "id": "…", … }, … ] }
error  → { "type": "error",
           "error": { "type": "…", "message": "…" },
           "request_id": "req_…" }

Reading 401, 403 and 429 from the Anthropic API

The error.type field names the failure category directly, which removes most of the guesswork that other APIs leave you with. The three you will meet most often:

401 — authentication error

The credential was not accepted. In practice this is mechanical: the key is in the wrong header (see above), it was truncated on paste, it carries stray whitespace or quotation marks, an environment variable resolved to an empty string, or the key has been revoked. If you are debugging from code rather than from this page, log the length of the key your process is sending — never the key itself — and compare it with the real one. A length mismatch identifies the bug in seconds. See 401 Unauthorized for the general semantics of authentication failure in HTTP.

403 — permission error

Authentication succeeded, authorisation did not. The key is real and was recognised; it simply is not allowed to do this particular thing. Typical causes are a key scoped to a workspace that lacks access to the resource, an organisation-level restriction, or a model your account is not enabled for. The instinct to re-check the key for typos is wrong here — the key already proved itself. Our 403 Forbidden page explains why HTTP separates these two concepts and why conflating them wastes debugging time.

429 — rate limit error

You have exceeded a limit. On this API the limits are multi-dimensional — requests per minute, input tokens per minute and output tokens per minute are tracked separately — so hitting one while comfortably under another is normal rather than contradictory. The response carries a retry-after header giving the number of seconds to wait, and honouring it is strictly better than guessing. Official client libraries retry 429 responses automatically with backoff, which is worth knowing because it means a failure that reaches your code has usually already been retried. Read 429 Too Many Requests for backoff strategy and the response headers worth paying attention to.

Other categories you will encounter

A 400 is an invalid request: a malformed body, a missing required field, or a parameter the endpoint does not accept. A 404 usually means a typo in the path or a model identifier that does not exist for your account. A 413 means the request payload was too large. And responses in the 5xx range, including the provider-specific overloaded response, mean the service is having a moment rather than that your request was wrong — retry those with exponential backoff.

Sending an actual message request

Once the key checks out, the natural next step is a real completion. That is a POST to https://api.anthropic.com/v1/messages with the same two authentication headers plus content-type: application/json, and a body naming a model, a token cap and a list of messages.

POST https://api.anthropic.com/v1/messages
x-api-key: sk-ant-…
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "PUT-A-MODEL-ID-FROM-/v1/models-HERE",
  "max_tokens": 64,
  "messages": [ { "role": "user", "content": "Say hello." } ]
}

The model placeholder is deliberate. Model identifiers on this platform are introduced and retired on their own schedule, and a page that hard-codes one is guaranteed to mislead someone eventually — so take the value from your own /v1/models response, which is authoritative for your account right now. To run this above: switch the method to POST, change the URL, add the content-type header in the Headers tab, paste the body into the Body tab, and press Format JSON to confirm it parses before spending a request on it. Unlike the models listing, this call does real work and consumes tokens.

Streaming responses are not useful in this console: they arrive as a sequence of server-sent events over a long-lived connection, while the tool renders one completed response body. Leave streaming off for tests here.

What this tool isolates for you

The value of a standalone request console is that it takes your application out of the equation. When a call fails inside your own code the fault could be the key, the headers, the endpoint, the payload, your HTTP client, a framework that quietly rewrites headers, a corporate proxy, or your own logic. Reproducing the same request here answers one question cleanly: does it work outside my app?

• Works here, fails in your app. The key and endpoint are fine — look at how your code assembles headers, and at which environment the failing process is actually reading its configuration from.
• Fails here too. Then it is the key, the headers, the URL or the body, all of which are visible on one screen.
• Works in staging, fails in production. Different key, different workspace, different egress address, or a restriction that applies to only one of the two. Compare the environments field by field rather than assuming.
• Fails intermittently. Look specifically for 429s and capture the request_id from each failure. Concurrency that is harmless at low volume starts tripping limits under load, and without logging the status code the symptom reads as randomness.

If your own application wraps the provider behind a token your backend issues to your frontend, the JWT decoder will show that token's claims and expiry — the usual explanation when authentication works for a while and then abruptly stops. For general request-building practice beyond this one API, the REST API tester and the comparison of browser and desktop API clients are both worth a look.

Provider APIs change — check the official docs

api-tester.com is an independent tool with no affiliation to, partnership with or endorsement from Anthropic. Nothing on this page is official documentation. Endpoints, header requirements, version strings, model identifiers, error categories and limits are all the provider's to change, and this page can fall behind them. For current and authoritative detail, consult the official Anthropic API documentation.

We have deliberately avoided quoting prices, specific rate limits or particular model names here. Those are the details that go stale fastest, and a confidently stated wrong number does more harm than no number at all. What this page describes is the durable shape of the API: how it authenticates, which headers it requires, how its errors are structured, and how to interpret them.

Test other providers and related tools

Frequently asked questions