API Client

Why a lightweight browser-based client?

Full-featured API clients like Postman and Insomnia are excellent engineering tools. They support collections, team workspaces, automated test scripts, CI integration, and a great deal more. But that power comes with friction: a download, an installer, often an account sign-up, and a learning curve for team members who only occasionally need to poke an endpoint.

A browser-based client removes all of that overhead. Open a tab, type a URL, click send. There is nothing to install and nothing to log in to. This makes it the right tool for a specific set of common scenarios: quickly checking that a new endpoint is live, debugging a header value during development, verifying an API key works before wiring it into application code, or walking a new team member through a REST API during onboarding without asking them to install anything first.

Requests are sent using the browser's native Fetch API, which means they originate from your browser directly — there is no proxy server in the middle that could alter headers, cache responses, or log your credentials. What the server receives is exactly what you configured, and what you see in the response panel is exactly what the server returned.

HTTP methods explained

REST APIs are built around the semantics of HTTP methods. Each method conveys intent — it tells the server what kind of operation you want to perform on a resource. Understanding the difference between them matters both for using this client correctly and for designing APIs that are predictable and consistent.

The client also supports HEAD (like GET but the server omits the response body — useful for checking whether a resource exists or reading headers without downloading a large payload) and OPTIONS (asks the server which methods and headers it accepts on a given URL — the browser sends this automatically for CORS preflight checks).

Request headers and query parameters

Headers are metadata attached to an HTTP request. They communicate information about the client, the expected response format, the authentication credentials, and more. Common headers you will use in day-to-day API testing:

Query parameters are key-value pairs appended to the URL after a ? and separated by &. They are used for filtering, sorting, pagination, and search:

# Paginated user list — page 2, 20 items per page
GET /api/users?page=2&per_page=20

# Filter active users only, sorted by name ascending
GET /api/users?status=active&sort=name&order=asc

# Full-text search
GET /api/products?q=wireless+headphones&category=electronics

In the client, you can type the full URL with query parameters directly into the URL bar, or use the Params tab to add them as key-value pairs — the client builds the query string for you and URL-encodes special characters automatically.

Request bodies

POST, PUT, and PATCH requests typically carry a body — the data you are sending to the server. The client supports three body formats:

{
  "name": "Alice Chen",
  "email": "alice@example.com",
  "role": "editor",
  "notify_on_signup": true
}

grant_type=client_credentials
client_id=my_app_id
client_secret=my_app_secret
scope=read:users write:users

Authentication

Almost every production API requires some form of authentication. The three schemes you will encounter most often are API key, Bearer token (JWT), and Basic auth. All three work via the Headers tab in the client.

X-API-Key: sk_live_abc123xyz789

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

# username: alice, password: s3cur3p@ss
Authorization: Basic YWxpY2U6czNjdXJlcEBzcw==

Reading responses and status codes

Every HTTP response has three components: a status code, response headers, and an optional body. The client displays all three. Understanding what the status code tells you saves significant debugging time.

Status codes are grouped into five classes by their first digit:

The response panel in the client shows the status code, the total round-trip time in milliseconds, and the response body size. JSON responses are automatically pretty-printed with syntax highlighting and can be collapsed and expanded by nesting level. For non-JSON responses (HTML, XML, plain text) the raw response string is shown.

CORS basics

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that controls which websites can make HTTP requests to a given server. If your browser-based API client receives a CORS error, it means the target server did not include the right headers in its response to allow requests from this origin.

When a page at https://sourcecodestack.com tries to fetch from https://api.example.com, the browser first sends a preflight OPTIONS request to api.example.com asking: "Is this origin allowed?" The server must respond with an Access-Control-Allow-Origin header that matches the requesting origin (or * to allow any origin). If it does not, the browser blocks the response and your JavaScript code sees a network error.

Access-Control-Allow-Origin: https://sourcecodestack.com
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-API-Key
Access-Control-Max-Age: 86400

The fix for a CORS error must be made on the server side. Common solutions:

Note that CORS is a browser restriction only. Command-line tools like curl and server-to-server requests are not subject to CORS at all — they always receive the response regardless of what CORS headers the server includes.

What you can do

The client covers the full set of HTTP methods and request options you need for REST API testing. Requests are made from the browser using the Fetch API — your network traffic goes directly from your browser to the target server (no proxy needed).

Request history and environment variables

How to make a request

Using the API client with the mock server

This client pairs naturally with the Mock API Server tool. Define your fake endpoints in the mock server, then use the API client to send requests against them and verify that the response body, status code, and headers are exactly what your frontend code expects. Because both tools run in the same browser and the mock server uses a Service Worker scoped to the origin, all requests from the API client are intercepted by the mock automatically — no extra configuration is needed.

This is particularly useful when you want to validate a new mock route before wiring it into your application code. You can iterate on the JSON response body in the mock server and fire requests from the API client to confirm the shape is correct, all without touching your React components or data-fetching logic.

Frequently Asked Questions