How to Test an API Online: Headers, Auth Tokens and Assertions

Testing an API endpoint means sending it one request and checking that the answer is what you expected. It sounds trivial, but most "the API is broken" moments are really a missing header, a token in the wrong format, or a 200 response that quietly contains an error.

This guide walks through testing any REST API from your browser, with custom headers, bearer tokens, Basic auth or API keys, and a request body. It also covers how to write checks that catch real failures instead of just confirming the server answered.

What do you need to test an API endpoint?

Six things, most of which you'll find in the API's documentation:

1. The URL, including the version path, e.g. https://api.example.com/v1/orders.
2. The method: GET to read, POST to create, PUT or PATCH to update, DELETE to remove.
3. Credentials: a bearer token, a username and password, or an API key.
4. Headers the API requires, such as Accept and Content-Type.
5. A body, for POST, PUT and PATCH.
6. What a correct answer looks like: the status code, and a field or two you can check.

The last one is the part people skip, and it's what turns "I got a response" into "it works".

How do I test an API online, step by step?

Using the free Wrklyst API Monitor. No signup is needed, and a one-off test stores nothing.

1. Enter the URL and pick the method. If the docs give you a curl command, click Import cURL and paste it instead; the rest gets filled in for you. See How to Run a cURL Command Online.
2. Add query parameters on the Params tab. The tool shows the final URL so you can see exactly what's sent.
3. Add credentials on the Auth tab. Choose Bearer token, Basic auth, or API key; secret fields are masked.
4. Add headers on the Headers tab. One click adds common ones such as Accept: application/json.
5. Add a body on the Body tab for POST, PUT or PATCH. Choose JSON, Form, XML or Text; JSON is checked as you type and can be auto-formatted.
6. Set assertions, then click Run check.

If you just want to see it work first, the Try row at the top loads ready-made examples. They cover a JSON GET, a POST with a body, a bearer-token request, Basic auth and custom headers, each against a public test API.

Which auth method does my API use?

The docs will name one of these. Here's how each looks on the wire:

Two common mistakes:

• Basic auth is not encryption. The Base64 step just packs user:password into a header and anyone can reverse it. It's only safe over HTTPS.
• A key in the query string leaks. URLs end up in server logs, proxy logs and browser history. If the API accepts the key as a header too, prefer the header.

On the Auth tab you choose the type and paste the secret, and the tool builds the header for you, including the Base64 encoding for Basic auth. For an API key you also choose whether it goes in a header or the query string.

Which headers actually matter?

• Content-Type tells the server what format the body is in. Send JSON labelled as form data and a strict API answers 415 Unsupported Media Type or 400. The tool sets it from the body type you pick, unless you type your own.
• Accept asks for a response format. Some APIs return HTML error pages unless you ask for application/json.
• API-specific headers, such as a version header (API-Version: 2024-06-01), a tenant or account ID, or an idempotency key. If the docs list one as required, a missing one usually produces a 400 with a message saying so.

How do I write checks that catch real failures?

A status code alone isn't enough. Plenty of APIs return 200 OK with {"success": false, "error": "quota exceeded"} in the body. Assertions let you state what "working" means. The tool supports five kinds:

• Status code: an exact code (201), a class (2xx), or a list (200, 204). A class is usually the right choice, because an endpoint moving from 200 to 201 hasn't broken.
• JSON path: a value inside the response, e.g. $.data.status equals active, $.items[0].id exists, or $.balance is greater than 0. Array indexes can be negative ($.items[-1] is the last item), and keys with dots can be quoted: $["user.name"].
• Body contains: plain text anywhere in the response. Useful when the response isn't JSON.
• Response header: e.g. Content-Type contains json, or Cache-Control exists. Header names match regardless of case.
• Response time: fails if the whole request takes longer than a limit you set, e.g. under 1000 ms.

Comparisons are done on the value as text, so $.active equals true matches a JSON true without you worrying about types. "Greater than" and "less than" compare numbers.

Every assertion shows as pass or fail with the reason spelled out, e.g. Expected $.status to equal active, got suspended.

How do I read the results?

• Total time vs time to first byte. If the first byte comes back fast and the total is slow, the response is large. A slow first byte means the server is slow to start answering, which is a database or upstream problem.
• Size and truncation. Responses are read up to 512 KB.
• Redirects. Every hop is listed. An API that redirects HTTP to HTTPS, or an old path to a new one, will show it here.
• SSL. HTTPS endpoints show how many days the certificate has left.
• Diff. Run the request again after changing something and the Diff tab compares the two responses.

What do the status codes mean when testing?

Why test from a server instead of the browser console?

If you call someone else's API with fetch() from a web page, the browser usually blocks you from reading the response. That's CORS, and the API has to opt in to allow it. Browsers also refuse to let a page set some headers. A tool that sends the request from a server has neither restriction, so what you see is what any backend client would get.

The flip side is that a server can only reach public addresses. localhost and private network IPs are refused, so test local services from your own machine.

When should I move from testing to monitoring?

As soon as other people depend on the endpoint. A test tells you it works now; a monitor tells you when it stops. Click Monitor this and the same request runs every 5, 15 or 60 minutes with the same assertions, a response-time assertion included. You get:

• an email when it fails and when it recovers, after the number of failed checks in a row you choose;
• a daily or weekly pass/fail report by email;
• alerts in Slack, Discord or Teams;
• a public status page that shows only the hostname, never your URL, headers or token.

Signed in, all your monitors are listed in your dashboard with uptime, response times and incidents. The API uptime monitoring guide covers how often to check and what's worth an alert.