How to test a REST API online, step by step

swastik.codes/app

To test a REST API online, open a browser-based API client, enter the endpoint URL, choose the HTTP method, add any query parameters, headers, body and credentials, and send the request. Then check the status code, response time, headers and body against what the API is supposed to return, and turn those checks into a saved test so you can repeat them. In Swastik Codes the whole loop happens in one browser tab, and the steps below take you from a first GET request to a small test suite you can run in one click.

What you need before you start

• An endpoint that is reachable from the public internet. The examples use https://jsonplaceholder.typicode.com, a free fake REST API, and https://httpbin.org, which echoes back what you send. Both can be called right away.
• A free Swastik Codes account. The web app needs an account; sign up with GitHub or email. There are no paid plans.
• The API's documentation, or at least the URL, the expected method and how it authenticates.

Why the API has to be public

A web page cannot send arbitrary cross-origin requests with any header it likes: the browser's CORS rules stop it. So the web app does not call your API directly. It sends the request to the swastik.codes server, which makes the real HTTP call and returns the response. To protect itself and other users, that server refuses private, loopback and link-local addresses, so http://localhost:3000 or http://192.168.1.10 will not work from the web app. For an API on your own machine, use the desktop app for Windows and Linux, which sends requests from your computer. The localhost testing guide covers that case in detail.

Step 1: send your first GET request

1. Open the app and sign in.
2. Click + at the end of the tab bar and choose HTTP. A new request tab opens with the method set to GET.
3. Paste https://jsonplaceholder.typicode.com/users/1 into the URL bar.
4. Press Send, or Ctrl+Enter.

The response panel shows 200 OK, the time the request took, the size of the response and a JSON object describing a user. That is a complete REST API test in its simplest form: you asked for a resource and the server returned it.

Step 2: choose the right HTTP method

REST APIs use the HTTP method to say what you want to do with a resource. The method picker lists GET, POST, PUT, PATCH, DELETE, HEAD and OPTIONS, and you can type a custom verb if your API uses one.

"Safe" and "idempotent" are defined in RFC 9110: a safe method does not change state on the server, and an idempotent one has the same effect whether you send it once or several times. This matters when testing. Repeating a GET or a PUT should be harmless; repeating a POST usually creates a second resource.

Step 3: add query parameters and path variables

Query parameters filter or page a list. Change the URL to https://jsonplaceholder.typicode.com/posts and open the Params tab. Add a row with the key userId and the value 1. The URL updates to .../posts?userId=1 as you type, and editing the URL updates the table: the two stay in sync. Untick a row to leave it out without deleting it.

Path variables are written with a colon. A URL such as https://jsonplaceholder.typicode.com/posts/:id shows an id field in the Params tab where you fill in the value. This keeps the request readable when you save it.

Step 4: set headers

Open the Headers tab to add request headers. The ones you will add most often:

• Accept: application/json to ask for JSON.
• Authorization for credentials (the Authorization tab can build it for you, see step 6).
• Custom headers your API requires, such as X-Api-Version or X-Request-Id.

The Headers tab also lists the headers the app generates automatically, such as Content-Type for a JSON body and the User-Agent. Expand that list to see exactly what will be sent and switch off the optional ones.

Step 5: send a JSON body

To create something you usually POST a JSON body. Create a new request:

1. Set the method to POST and the URL to https://jsonplaceholder.typicode.com/posts.
2. Open the Body tab, choose raw and set the language to JSON.
3. Enter the body:

{
  "title": "Testing a REST API online",
  "body": "First post from Swastik Codes",
  "userId": 1
}

4. Send it.

JSONPlaceholder answers 201 Created with your data plus a new id. (It is a fake API: nothing is stored, so the id will not exist if you request it later. A real API behaves the same way, minus that caveat.) A raw JSON body gets Content-Type: application/json automatically, which is what most APIs need to parse it.

The other body modes cover the remaining cases: form-data for file uploads, x-www-form-urlencoded for classic HTML-form posts, binary to send a whole file, and GraphQL for a query plus variables. For the details of each, see the REST API client page.

Step 6: add authentication

Most real APIs reject anonymous requests with 401 Unauthorized. Instead of building the Authorization header by hand, open the Authorization tab and pick a type:

• Bearer token for an access token: the app sends Authorization: Bearer <token>.
• API key for a key sent in a header or a query parameter.
• Basic for a username and password.
• OAuth 2.0 when you need to obtain a token first; see OAuth 2.0 in an API client.

Other schemes, including JWT signing, Digest, AWS Signature v4 and NTLM, are listed on the authorization page. You can test Basic auth against httpbin: send a GET to https://httpbin.org/basic-auth/demo/secret with Basic auth demo / secret and you get 200; change the password and you get 401.

Do not paste real secrets straight into requests you plan to share. Put them in an environment variable and reference it as {{token}}; see the next step.

Step 7: use variables and environments

Hard-coded URLs become a problem as soon as you have a staging and a production server. Create an environment (for example Staging) with variables such as:

Then write the URL as {{baseUrl}}/users/1 and the bearer token as {{token}}. Switching environments switches every request at once, and unresolved variables are marked in red before you send. Each variable has an initial value, which is shared with your team, and a current value, which stays on your device: keep personal tokens in the current value. More on this on the environments and variables page.

Step 8: read the response properly

A passing status code does not mean the API works. Read the whole response:

• Status line. The code and reason, for example 200 OK or 422 Unprocessable Content. If you are unsure what a code means, the HTTP status codes guide explains the common ones and what to check for each.
• Time and size. The timing breakdown splits the total into DNS lookup, TCP connect, TLS handshake, time to first byte and download, which tells you whether slowness comes from the network or from the server.
• Body. View it pretty-printed, raw or as a rendered preview, and search it. Check field names, types and values, not just that something came back.
• Headers. Content-Type, caching headers, Location after a create, rate-limit headers.
• Cookies. Cookies the server set, kept in a per-domain cookie jar.

If something looks wrong, open the console panel (Ctrl+Alt+C). It shows the exact request that went out, after variables were resolved: a missing header or a mistyped variable name becomes obvious.

Step 9: save the request to a collection

Requests you only send once are not tests. Press Ctrl+S (or Save) and the save dialog asks where to put the request: pick an existing collection or folder, or type a name to create a new collection, and give the request a clear name such as Get user or Create post.

Once your requests live in a collection you can share them with your team, run them all at once, generate code for them, and use them for mock servers and documentation. Sent requests are also kept in history, so you can recover an unsaved one.

If your requests already exist in Postman, you do not need to rebuild them: import the Postman collection.

Step 10: add a test

A test is a short JavaScript check that runs after the response arrives. Open the saved Get user request, go to the Scripts tab and choose Post-response. Paste:

swc.test('status is 200', function () {
  swc.response.to.have.status(200);
});

swc.test('responds in under a second', function () {
  swc.expect(swc.response.responseTime).to.be.below(1000);
});

swc.test('returns the expected user', function () {
  const user = swc.response.json();
  swc.expect(user.id).to.eql(1);
  swc.expect(user.email).to.include('@');
  swc.expect(user).to.have.property('address');
});

Send the request again and open the Test Results tab in the response panel, which lists each test by name with a passed/total count. Change eql(1) to eql(2) and send again to see what a failure looks like.

The script editor offers snippets such as Status code is 200, JSON value check and Validate JSON schema, so you rarely start from nothing. Scripts use the swc.* API; Postman's pm.* is the same object, so scripts written for Postman run unchanged. The guide to swc.* test scripts has many more examples.

Add a test to the Create post request too:

swc.test('post is created', function () {
  swc.response.to.have.status(201);
  const post = swc.response.json();
  swc.expect(post.id).to.be.a('number');
  swc.expect(post.title).to.eql('Testing a REST API online');
});

Step 11: run the collection

With two or more saved requests that have tests, open the collection's menu in the sidebar and choose Run collection. The collection runner lists the requests in order; you can reorder them for this run, pick an environment, set the number of iterations, add a delay between requests and choose when to stop early.

Start the run. Each request is sent in turn, its scripts run, and the summary shows how many requests and tests passed or failed and the average response time. Export the result as JSON, JUnit XML or an HTML report if someone else needs to see it.

From here you can go further:

• Pass data between requests, for example a token from a login call or an id from a create call. See chaining API requests.
• Run the same requests with many inputs from a CSV or JSON file: data-driven API testing.
• Run on a schedule with monitors, which alert you by email or webhook when tests fail.

Online API tester or something else?

They work well together. Swastik Codes can import a curl command into a request and generate a curl snippet from one; see converting curl to code.

Frequently asked questions

Can I test a REST API online for free?

Yes. Swastik Codes is free to use, with no paid plans. You need a free account to send requests, because the web app sends them through the swastik.codes server.

Can an online API tester call localhost?

Not from the Swastik Codes web app: its server refuses private, loopback and link-local addresses. Use the desktop app for Windows and Linux, which sends requests from your own machine, or deploy the API somewhere public.

What should I check when testing a REST API?

The status code, the response time, the headers (especially Content-Type) and the body: field names, types and values. Also test the failure cases: missing auth, invalid input and resources that do not exist should return the right 4xx codes.

Do I need to know JavaScript to write API tests?

Only a little. Most tests are a few lines built from snippets such as Status code is 200 and JSON value check, which the script editor inserts for you.

Will my Postman collections and tests work?

Yes, in most cases. You can import Postman collections (v2.0, v2.1 and v3), environments and globals, and scripts using pm.* run unchanged.