How to Test a REST API Offline Without Postman
Learn how to send API requests, inspect responses, set headers, use authentication tokens, and debug REST endpoints from your desktop with the offline API client in MyDevTools.
Get the tool mentioned in this guide in the desktop app:API Client
Why test APIs from an all-in-one desktop toolkit
Heavy API clients like Postman and Insomnia are powerful for team collaboration, collection management, and test automation. But for quick one-off requests — checking a public endpoint, debugging an auth header, or verifying a payload format — launching a separate heavyweight app and signing in adds friction.
An API client built into an all-in-one desktop toolkit lets you send requests immediately, offline, without maintaining a collection or juggling separate apps. It is particularly useful when you are already working locally alongside your other developer tools.
Anatomy of a REST API request
Every HTTP request has four key parts:
Method — The verb: GET (fetch), POST (create), PUT (replace), PATCH (update), DELETE (remove).
URL — The endpoint, e.g., https://api.example.com/users/42. May include query parameters: ?page=1&limit=20.
Headers — Metadata about the request. Common headers include Authorization, Content-Type, Accept, and custom API headers like X-API-Key.
Body — The request payload for POST/PUT/PATCH. Usually JSON. Must match the Content-Type header (typically application/json).
// Example: POST request structure
POST https://api.example.com/users
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json
{
"name": "Alice",
"email": "[email protected]",
"role": "admin"
}Authentication types in API testing
Bearer token (JWT): Add Authorization: Bearer as a header. Paste the token from your login response. Use a JWT decoder to inspect the claims and check the expiry before testing.
API key: Usually sent as a header (X-API-Key: abc123) or a query parameter (?api_key=abc123), depending on the API's convention.
Basic Auth: Base64-encoded username:password in the Authorization header: Authorization: Basic dXNlcjpwYXNz.
OAuth 2.0: Obtain an access token via the token endpoint first, then use it as a Bearer token in subsequent requests.
// Bearer token
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
// API key in header
X-API-Key: sk_live_abc123xyz
// Basic Auth (base64 of "user:pass")
Authorization: Basic dXNlcjpwYXNz
// Query parameter
GET https://api.example.com/data?api_key=abc123Reading and debugging API responses
A response has three parts:
Status code — The three-digit HTTP status (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error). Always check this first — a 200 with an error in the body is an API antipattern.
Response headers — Metadata from the server: Content-Type, X-RateLimit-Remaining, Retry-After, caching headers, and correlation IDs for log tracing.
Response body — The payload, usually JSON. If it is minified, paste it into a JSON formatter to make it readable before inspecting field values.
Common API testing mistakes
Forgetting Content-Type — POST/PUT requests with a JSON body must include Content-Type: application/json. Without it, many servers reject or misparse the body.
Sending expired tokens — JWT access tokens expire (typically 15 minutes to 1 hour). Decode the token and check the exp claim before a test run.
Trailing slashes — Some APIs treat /users and /users/ differently. Check the API documentation.
Case-sensitive headers — HTTP/2 requires lowercase headers. Some API gateways normalize these; others do not. Use lowercase when in doubt.
Ignoring CORS errors — CORS is a browser security restriction, not a server-side API error. If you get a CORS error in the browser, the request may succeed from a server-side client (curl, Node). Check whether the API allows browser origins.
Testing with curl vs a desktop API client
curl is ideal for scripting, CI pipelines, and reproducing requests in documentation. A desktop API client is faster for interactive exploration, header autocompletion, and working alongside your other developer tools.
The API Client in MyDevTools runs offline on your machine, supports GET/POST/PUT/PATCH/DELETE, custom headers, authentication, JSON body editing, and shows the formatted response and status side by side.
# Equivalent curl command for the browser request
curl -X POST https://api.example.com/users \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"name":"Alice","email":"[email protected]"}'Frequently asked questions
What is the difference between REST and GraphQL API testing?
REST uses multiple endpoints with specific HTTP methods. GraphQL uses a single endpoint (usually POST) with a query or mutation in the body. For GraphQL, use the GraphQL Formatter to write and validate queries, then send them via an API client.
Can I test APIs that require OAuth 2.0 in a desktop API client?
Yes, if you manually obtain the access token first (via the token endpoint or an OAuth flow) and paste it into the Authorization header.
Why does my API request work in curl but fail in the browser?
Most likely a CORS issue. The browser blocks cross-origin requests if the server does not include the appropriate Access-Control-Allow-Origin header. This is a browser security policy, not an API error.
How do I test a paginated API?
Send the first request and check the response for pagination metadata (next page URL, cursor, or total pages). Then modify the query parameter (page=2, cursor=abc) and repeat. An API client makes this faster than curl for interactive exploration.