How to Test API Endpoints Without Postman or Insomnia

Postman started as a simple Chrome extension for testing APIs. It has since grown into a full platform with teams, collections, environments, monitors, mock servers, and a paid tier that costs $14 per user per month. For many developers, that is way more than they need.

If you just want to fire a GET request at an endpoint and see what comes back, or test a POST with a JSON body to see if your server handles it correctly, you do not need an installed application with an account and a workspace. You need a text field for the URL, a dropdown for the method, and a place to see the response.

The API Request Builder runs entirely in your browser. Enter the URL, pick the HTTP method, add headers and a body if needed, and send the request. The response shows up with status code, headers, and body. No install, no login, no subscription.

Understanding HTTP Methods

REST APIs use HTTP methods to indicate what operation you want to perform. The four you will use constantly:

GET retrieves data. It should not modify anything on the server. When you load a web page, your browser sends a GET request. When you fetch a list of users from an API, that is a GET. No request body needed.

` GET /api/users GET /api/users/123 GET /api/products?category=electronics&sort=price `

POST creates new data. You send a request body with the data you want to create. The server processes it and typically returns the created resource with an ID.

` POST /api/users Content-Type: application/json {"name": "Jane", "email": "jane@example.com"} `

PUT replaces existing data entirely. You send the complete updated resource. If you leave out a field, it gets removed.

PATCH partially updates existing data. You send only the fields you want to change. Fields you do not include remain unchanged.

DELETE removes data. Usually takes just a URL with an ID, no body needed.

` DELETE /api/users/123 `

Less common methods include OPTIONS (used by browsers for CORS preflight checks), HEAD (like GET but returns only headers), and CONNECT/TRACE (rarely used directly by application developers).

Headers That Matter

HTTP headers are metadata that travel with every request and response. Most APIs require at least a few:

Content-Type tells the server what format your request body is in. For JSON APIs, this is almost always application/json. For form submissions, it is application/x-www-form-urlencoded or multipart/form-data.

Authorization carries your credentials. The most common patterns: - Bearer tokens: Authorization: Bearer eyJhbGciOi... - API keys: Authorization: ApiKey your-key-here or X-API-Key: your-key-here - Basic auth: Authorization: Basic base64(username:password)

Accept tells the server what response format you want. Accept: application/json requests JSON. Some APIs support multiple formats and use this header to decide which to return.

Custom headers are common in specific APIs. Stripe uses Stripe-Version to pin the API version. Many APIs use X-Request-ID for tracing. Rate-limited APIs return X-RateLimit-Remaining in responses.

The API Request Builder lets you add any number of custom headers to your request. Each header is a key-value pair, and you can toggle individual headers on and off without deleting them.

Working with Request Bodies

GET and DELETE requests typically have no body. POST, PUT, and PATCH requests almost always do.

The most common body format is JSON:

`json { "name": "New Product", "price": 29.99, "category": "tools", "tags": ["developer", "productivity"], "metadata": { "created_by": "api", "version": 1 } } `

Common mistakes with JSON request bodies:

Trailing commas. JSON does not allow them, unlike JavaScript. {"a": 1, "b": 2,} is invalid.

Single quotes. JSON requires double quotes. {'name': 'test'} is invalid.

Unquoted keys. {name: "test"} is invalid JSON. Keys must be quoted.

Comments. JSON has no comment syntax. {"name": "test" // this is a comment} is invalid.

If your JSON is not valid, the server will return a 400 Bad Request. Use the JSON Formatter to validate and pretty-print your JSON before pasting it into a request body. It catches syntax errors immediately and makes the structure easier to read.

For form-encoded bodies (used by some older APIs), the format is key=value&key2=value2. For file uploads, you need multipart/form-data, which browser-based tools handle through file input fields.

Reading API Responses

An API response has three parts you should check:

Status code. The three-digit number that tells you what happened. - 200: Success - 201: Created (after a POST) - 204: No Content (success, but nothing to return) - 400: Bad Request (your request was malformed) - 401: Unauthorized (missing or invalid credentials) - 403: Forbidden (valid credentials, but no permission) - 404: Not Found (the resource does not exist) - 422: Unprocessable Entity (valid JSON, but the data failed validation) - 429: Too Many Requests (rate limited) - 500: Internal Server Error (the server crashed)

Response headers. Check Content-Type to confirm the format. Check rate limit headers to know how many requests you have left. Check Location on 201 responses to find the URL of the newly created resource.

Response body. The actual data, usually JSON. Pretty-print it with the JSON Formatter if the response comes back as a single long line.

Pay attention to error response bodies. Good APIs include error messages that tell you exactly what went wrong: "email field is required" or "price must be a positive number." Bad APIs just return {"error": "bad request"} and leave you guessing.

From Browser Testing to Code

Once you have a working request in the browser tool, you need to translate it to code for your application. This is where the cURL to Code Converter saves time.

Most API tools can export your request as a cURL command. cURL is a command-line tool that makes HTTP requests, and its syntax has become the universal language for describing API calls. An API's documentation usually shows examples as cURL commands.

A typical cURL command:

`bash curl -X POST https://api.example.com/users \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your-token" \ -d '{"name": "Jane", "email": "jane@example.com"}' `

The cURL to Code Converter transforms this into ready-to-use code in Python (requests), JavaScript (fetch), Node.js (axios), PHP, Go, Ruby, and other languages. Instead of manually translating the request structure, paste the cURL and copy the code.

This workflow (test in browser, export as cURL, convert to code) is faster than writing the HTTP client code from scratch, and it ensures the code matches a request you have already verified works.

FAQ

Is it safe to test APIs with real credentials in a browser tool?

Browser-based tools that run client-side (in your browser, not on a remote server) are generally safe because your data never leaves your machine. Check that the tool does not send your request through a proxy server. Tools that proxy requests through their own backend see your credentials and request data. The API Request Builder on ToolForte runs entirely client-side.

Why do I get a CORS error when testing from the browser?

CORS (Cross-Origin Resource Sharing) blocks browser-based requests to APIs that do not explicitly allow them. This is a browser security feature, not an API bug. Your API call works fine from cURL or server-side code because CORS only applies to browser requests. To test APIs that block CORS, use cURL in your terminal or configure the API server to allow your origin.

Can I test WebSocket connections with these tools?

No, HTTP request builders only handle standard HTTP requests. WebSocket connections require a different protocol and a persistent connection. For WebSocket testing, use browser developer tools (Network tab, WS filter) or dedicated tools like Firecamp or the wscat command-line tool.

How do I handle API rate limits during testing?

Add a delay between requests. Most APIs publish their rate limits in the documentation and return the remaining quota in response headers (typically X-RateLimit-Remaining). During testing, check this header after each request. If you are running automated tests, build in a delay that keeps you under the limit.