API Request Tester

API Request Tester - Test REST APIs Online

Every API integration starts the same way: read the documentation, send a hand-crafted test request, inspect the response, then write production code only once you've confirmed the contract. For decades that workflow has meant Postman, Insomnia, curl, or HTTPie — all of which require installing software. This tool puts the same workflow inside a browser tab so you can hit a quick endpoint without leaving your current development context. It supports every standard HTTP verb (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), accepts arbitrary headers in clean JSON form (Authorization bearer tokens, X-API-Key, Content-Type, Accept-Language, custom corporate headers), sends JSON/XML/form-encoded/raw text request bodies, and shows you everything that comes back: numeric status code with the standard reason phrase, every response header parsed and labelled, the body pretty-printed if it parses as JSON or kept raw otherwise, the wall-clock round-trip time in milliseconds, and the byte length of the response. The most common gotcha for browser-based API testing is CORS — public APIs designed for browser use (Stripe, GitHub, OpenAI, JSONPlaceholder) work fine, but internal APIs that only expect server-to-server traffic will block the request with a missing Access-Control-Allow-Origin header. When that happens, the error message tells you exactly what to look for in your API server's CORS configuration.

What is an API Request Tester?

An API Request Tester is a tool that allows you to send HTTP requests to APIs and view their responses. It's essential for:

- Testing API endpoints during development
- Debugging API issues
- Exploring third-party APIs
- Verifying authentication and authorization
- Testing different HTTP methods
- Checking API response formats

It acts as a client that can communicate with any REST API, similar to tools like Postman or Insomnia.

How do I test an API?

Testing an API is simple:

1. Enter the API endpoint URL
2. Select the HTTP method (GET, POST, PUT, DELETE, PATCH)
3. (Optional) Add custom headers in JSON format
4. (Optional) Add request body for POST/PUT/PATCH requests
5. Click 'Send Request'
6. View the response status, headers, body, and timing

Example GET request:
URL: https://jsonplaceholder.typicode.com/users/1
Method: GET

Example POST request:
URL: https://jsonplaceholder.typicode.com/posts
Method: POST
Body: {"title": "Test", "body": "Content", "userId": 1}

What HTTP methods are supported?

This tool supports all standard HTTP methods:

- GET: Retrieve data from the server
- POST: Send data to create new resources
- PUT: Update existing resources completely
- PATCH: Partially update existing resources
- DELETE: Remove resources
- HEAD: Get headers only (no body)
- OPTIONS: Check supported methods

Most APIs use GET (read), POST (create), PUT/PATCH (update), and DELETE operations.

How do I add custom headers?

Headers must be added in valid JSON format:

{
"Content-Type": "application/json",
"Authorization": "Bearer your-token-here",
"X-Custom-Header": "value"
}

Common headers:
- Content-Type: Specifies request body format (application/json, text/xml)
- Authorization: Authentication tokens (Bearer, Basic, API keys)
- Accept: Expected response format
- User-Agent: Client identification
- X-API-Key: API key authentication

Headers are key-value pairs that provide metadata about the request.

What about CORS errors?

CORS (Cross-Origin Resource Sharing) is a browser security feature that may block API requests from this tool:

- Many APIs don't allow requests from browsers
- This is normal security behavior
- Public APIs often have CORS enabled
- Private APIs may block browser requests

Solutions:
- Use APIs that support CORS
- Test with browser extensions that disable CORS (for testing only)
- Use backend tools for production testing
- Contact API providers to enable CORS

For serious API testing, consider using dedicated tools like Postman, Insomnia, or backend testing frameworks.

When should I use PUT vs PATCH vs POST for updating a resource?

These three verbs look interchangeable to beginners but have distinct semantics that determine API correctness and caching behaviour. POST creates a NEW resource on the server (or triggers an action with side effects) — the server picks the new resource's ID and returns its location. Use it for /users when registering a new user, /orders when placing an order, /search when running a search that modifies server state. PUT REPLACES an entire existing resource at a known URL — you send the full new representation, and any field you omit is reset to null/default. Use it when updating a user's full profile object at /users/123. PATCH partially modifies an existing resource — you send only the fields that change, leaving others untouched. Use it when changing just the email field at /users/123. The HTTP spec says PUT and PATCH must be IDEMPOTENT (calling the same PUT/PATCH twice produces the same end state), while POST need not be (two POSTs to /orders create two orders). Get this wrong and clients will retry failed POSTs and accidentally create duplicate records.

How do I send an Authorization Bearer token correctly?

Bearer authentication is the dominant API auth pattern in 2026 — used by OAuth 2.0, OpenID Connect, JWT-based APIs, and most modern SaaS platforms. The format is fixed by RFC 6750: the Authorization header value MUST be the literal word 'Bearer' followed by exactly one space and the token string. In this tool's Headers field, paste:

{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}

Common mistakes: (1) Forgetting the space after 'Bearer' — APIs return 401. (2) Using lowercase 'bearer' — RFC says case-insensitive but some strict servers reject it. (3) Including the brackets '<' '>' from documentation examples literally in the token. (4) Sending the raw token without 'Bearer' prefix — that's the older Basic auth pattern. (5) Reusing an expired JWT — decode at jwt.io to check the 'exp' claim. Never paste live production tokens into untrusted tools; this tester runs entirely in your browser but you should still rotate any token you used for debugging once you're done.

What do common HTTP status codes mean (200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503)?

The status code is the first thing to read in any response — it tells you the outcome before you even look at the body.

2xx success:
- 200 OK: request succeeded, body contains the result.
- 201 Created: a POST created a new resource; check the Location header for its URL.
- 204 No Content: success with an empty body (common for DELETE and some PUT/PATCH).

3xx redirect:
- 301 Moved Permanently: the resource has a new URL — update your endpoint.
- 302/307/308: temporary or method-preserving redirects.

4xx client error (your request is wrong):
- 400 Bad Request: malformed syntax or invalid parameters.
- 401 Unauthorized: missing or invalid auth — check your Authorization header / token.
- 403 Forbidden: authenticated but not allowed (permissions/scopes).
- 404 Not Found: wrong URL or the resource doesn't exist.
- 422 Unprocessable Entity: body parsed fine but failed validation rules.
- 429 Too Many Requests: rate-limited — back off and check the Retry-After header.

5xx server error (the server failed):
- 500 Internal Server Error: an unhandled exception on the server.
- 503 Service Unavailable: server overloaded or in maintenance; retry later.

Rule of thumb: 4xx means fix your request, 5xx means the server is at fault.

Do I need to set a Content-Type header when sending a request body?

Yes — when you send a body, the server uses Content-Type to decide how to parse it, and getting it wrong is one of the most common causes of a 400 or 415 response.

- JSON body: set Content-Type to application/json. Most JSON APIs reject or silently ignore a body sent without it. The body must be valid JSON, e.g. {"name":"Ada"}.
- Form data: set application/x-www-form-urlencoded and send key=value&key2=value2 (the classic HTML form format).
- Plain text/XML: use text/plain or application/xml/text/xml so the server doesn't try to JSON-parse it.
- File uploads: use multipart/form-data (note: real multipart boundaries are easier from native curl/Postman than a raw text field).

For GET, HEAD, OPTIONS and DELETE without a body, you do not need Content-Type at all. Also remember the Accept header is the mirror of Content-Type: it tells the server what format you want back (e.g. Accept: application/json).

How does the Copy as cURL feature work?

After you send a request, click 'Copy as cURL' to copy a ready-to-run curl command that exactly reproduces what the tool just sent — same URL, same -X method, one -H flag per header, and a --data flag for the body. Paste it into any terminal, a bug report, a runbook, or a CI script.

This is the single most useful escape hatch from the browser. Because browsers enforce CORS, some APIs that block this in-browser tester will work perfectly from curl, which has no same-origin policy. So when you hit a CORS wall, convert the request to curl and run it from your terminal or server to confirm the API itself works.

The generated command single-quotes and escapes the URL, headers, and body so values containing spaces or special characters stay intact. It is plain, dependency-free, and portable to any shell, making it the universal interchange format between this tester, your teammates, and your automation.

Is my data safe?

Privacy considerations:

- Requests go directly from your browser to the API
- No data passes through our servers
- We don't log or store any request/response data
- Be cautious with sensitive data (passwords, tokens)
- Avoid testing with production credentials
- Consider using test/sandbox API endpoints

Security tips:
- Don't share API keys publicly
- Use environment-specific credentials
- Test with dummy data when possible
- Revoke test tokens after use

Key Features

• Test any REST API endpoint
• Support all HTTP methods (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)
• Add custom request headers
• Send request body (JSON, XML, text)
• View response status codes
• Display response headers
• Show formatted response body
• Measure response time
• Calculate response size
• Syntax highlighting for JSON responses
• Copy response data to clipboard
• Copy any request as a ready-to-run cURL command
• Dark mode support
• 100% client-side - requests go directly to APIs
• No data logging or storage
• Mobile-friendly responsive design