How to Test an API Without Writing Code

October 17, 2026 • NOFYI Editorial Team

An API is a way for one piece of software to ask another piece of software for information or to do something. You use APIs every day without noticing them. When a weather app shows the forecast, a map shows directions, or a shop shows stock levels, an API is often working behind the scenes. Testing an API sounds like a job for programmers, but you can test many APIs without writing any code. You only need a browser, a free API testing tool, or a built-in browser tool, and a clear idea of what you want to check. This guide explains how to do it safely, with a worked example you can try in minutes.

Start with a simple idea: an API test is a question and an answer. You send a request, which is a message that asks for something. The API sends back a response, which contains data and a status code. The status code tells you whether the request worked. A status of 200 usually means success. A status of 404 usually means the requested item was not found. A status of 401 or 403 usually means you do not have permission. A status of 500 usually means something went wrong on the server. You do not need to memorise every code, but you should always read the status before you read the data, because the status tells you whether the data can be trusted.

How to Test an API Without Writing Code

First, find the API documentation. Good documentation tells you the base address, the endpoints, the methods, and what data each endpoint returns. An endpoint is a specific address for one kind of request, such as a list of posts or one post by its identifier. A method tells the API what kind of action you want. GET asks to read data. POST asks to create data. PUT or PATCH asks to update data. DELETE asks to remove data. For a first test, use GET, because it only reads data and does not change anything. Do not test POST, PUT, PATCH, or DELETE on a real service unless you understand what they will change and you have permission.

Second, choose a tool. The simplest tool is your browser address bar. Paste a GET endpoint address into the address bar and press Enter. The browser will show the response, usually as JSON, which is a plain-text format for structured data. This works well for public GET endpoints that do not need authentication. For more control, use a free API client such as Postman, Insomnia, or Hoppscotch, or a browser-based API tester. These tools let you choose the method, add headers, add query parameters, and view the status, headers, and body in a clear layout. They also let you save requests, so you can repeat a test later.

Third, send a GET request. In your tool, choose GET, enter the endpoint address, and send the request. Do not add a username, password, token, or API key unless the documentation says it is required and you are using a test key. If the API needs authentication, use a test account or a demo key provided by the documentation, and never use a real production credential in a shared tool or a screenshot. When the response arrives, note the status code, the time it took, and the content type. Then read the response body, which is the actual data.

Fourth, check the response body. JSON data is organised into fields, such as an identifier, a title, and a body. Check that the fields you expected are present, that the values look sensible, and that the data type matches your expectation. For example, an identifier should be a number, a title should be text, and a list should contain items. If a field is missing, empty, or has an unexpected type, that is a useful finding. Write it down exactly as you saw it, including the endpoint, the status, and the field name.

Fifth, test one change at a time. If you want to check what happens with a different identifier, change only the identifier. If you want to check a filter, change only the filter. Changing several things at once makes it hard to know which change caused the result. Keep a simple log: what you sent, what you expected, what you received, and whether it matched. This log is the most valuable part of a test, because it lets someone else repeat your work and confirm the result.

Worked Example: A GET Request to JSONPlaceholder

JSONPlaceholder is a free fake API for testing and learning. It returns placeholder data, not real user data, which makes it safe to use for practice. A common first request is a GET request to https://jsonplaceholder.typicode.com/posts/1. This asks for the post with the identifier 1. You can paste that address into a browser address bar, or enter it as a GET request in an API client. Do not add any credentials, because this public test endpoint does not need them.

When you send the request, you should receive a status of 200. That means the request succeeded. The response body should contain a JSON object with four fields: userId, id, title, and body. The id should be 1, matching the identifier in the address. The userId should be a number. The title and body should be text. Read the whole body, not just the first line. If the body is long, use the pretty-print or format option in your tool to make it readable. If the browser shows the JSON on one line, use a JSON formatter or an API client to view it more clearly.

Now test a small variation. Change the identifier from 1 to 2, so the address becomes https://jsonplaceholder.typicode.com/posts/2. Send the request again. You should still receive a status of 200, but the id should now be 2, and the title and body should be different. This confirms that the identifier in the address controls which post is returned. If you change the identifier to a value that does not exist, such as 999999, you may receive a 404 or an empty object, depending on how the API handles missing data. That result is also useful, because it shows how the API behaves when data is not found.

Finally, check the response headers if your tool shows them. Headers can tell you the content type, which should be JSON, and other details such as caching or rate limits. You do not need to understand every header, but you should notice whether the content type matches the body. If the body looks like JSON but the content type says something else, note it in your log. A mismatch can cause problems for apps that rely on the header to decide how to read the data.

Limitations

First, do not send real credentials. Never put a real password, token, API key, or personal access token into a test request, a screenshot, a shared collection, or a public example. If you must test an authenticated endpoint, use a test account, a demo key, or a short-lived token that you can revoke. If you accidentally share a credential, treat it as compromised and revoke or change it immediately.

Second, CORS may block browser tests. CORS, or Cross-Origin Resource Sharing, is a browser security rule that controls whether a web page on one origin can read data from an API on another origin. If you test an API from a web page or a browser-based tool, the browser may block the response even though the API is working. This does not always mean the API is broken. It means the browser is enforcing a security rule. Use a dedicated API client, which does not apply the same browser rule, to confirm whether the API itself is working.

Third, a successful test does not prove the API is safe for production. A GET request that returns 200 in a test does not guarantee that the API handles errors, rate limits, large data, or malicious input correctly. It also does not prove that authentication, permissions, or data privacy are correct. Treat a no-code test as a first check, not as a full security or load test.

Fourth, test data is not real data. JSONPlaceholder returns placeholder data for learning. Real APIs may return different fields, different errors, and different limits. Always read the documentation for the real API you are testing, and do not assume that a test on one API proves how another API behaves.

Fifth, check the response body, not just the status. A status of 200 can still come with incomplete, outdated, or incorrect data. A status of 404 can be correct if the item does not exist. Always read the body, compare it with what you expected, and record both the status and the data.

Frequently Asked Questions

Can I test an API in my browser without installing anything? Yes, for public GET endpoints. Paste the endpoint address into the address bar and read the JSON response. For more control, headers, or methods other than GET, use a free API client. A browser test is a good first step, but it is not a replacement for a proper client when you need to inspect headers or send parameters.

What does status 200 mean? Status 200 means the request succeeded and the server returned a response. It does not guarantee that the data is correct, complete, or current. Always check the response body as well. If you expected an error and received 200, note it, because the API may be returning a success status for a case that should fail.

Why does my browser block an API request that works in an API client? The most likely reason is CORS. The browser blocks cross-origin requests that the API has not allowed. An API client does not apply the same rule, so it can show that the API is working. If you are building a web app, you need to check the API CORS settings, not just the API itself.

Is it safe to test a POST request? Only on a test API, a test account, or a service that is designed for practice. POST, PUT, PATCH, and DELETE can create, change, or remove data. Do not send them to a real service unless you have permission, you understand the effect, and you can undo it. For learning, start with GET requests on a fake API such as JSONPlaceholder.

Testing an API without code is a practical skill. Start with GET, use a public test endpoint, read the status and the body, change one thing at a time, and keep a simple log. With that habit, you can check whether an API works, explain what you found, and avoid the common traps of credentials, CORS, and misleading status codes.