API Request Builder & Tester

What is an API Request Builder?

An API request builder is a developer tool that lets you construct an HTTP request — method, URL, headers, query parameters, authentication, and body — and then either send it and inspect the response, or export it as code for your application. Think of it as a lightweight alternative to Postman or Insomnia that runs directly in your browser tab, requires no installation, and handles the entire workflow locally.

Developers use online API testers for the same reasons they use cURL: to explore an unfamiliar endpoint, debug a broken integration, verify that a token works, or sanity-check what a server actually returns before wiring the call into production code. The advantage of a browser-based REST API tester is that you don't have to remember flags, you can see the parsed request structure, and you can copy the equivalent code in one click.

This particular tool is built around a few principles. First, transparency: every part of the request you build is visible, editable, and inspectable. Second, privacy: the request is assembled in your browser and, unless you choose to send it, never leaves the page. Third, honesty about browser limits: if a request is blocked by CORS, we tell you precisely what happened instead of pretending it worked.

How to build an API request

Every HTTP request is composed of the same core pieces. Regardless of whether you're using this HTTP request builder, a terminal cURL command, or a language-specific client library, the pieces are identical:

1. Method — the verb that tells the server what to do: GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS.
2. URL — scheme, host, path, and optional query string. Example: https://api.example.com/users?page=2.
3. Headers — metadata sent with the request. Content negotiation (Accept, Content-Type), authentication (Authorization), and API tracking all live here.
4. Authentication — usually a header, sometimes a query parameter. Bearer tokens, Basic auth, and API keys are the three you'll encounter most.
5. Body — only present for methods that submit data. JSON is the default in modern REST APIs, but form-urlencoded and multipart uploads are still common.

Once you have these five pieces, every HTTP tool — this one, cURL, Python requests, Go's net/http — is just a different way of writing the same request.

GET request example

A GET request retrieves data. The simplest form is a single URL:

GET https://api.example.com/users

In this tool: pick GET from the method dropdown, paste the URL, click Send. The response will contain either a JSON array of users or an error status explaining why the server refused the request.

The equivalent cURL command is:

curl https://api.example.com/users

And in JavaScript:

const res = await fetch('https://api.example.com/users');
const users = await res.json();

POST JSON example

POST creates a resource. Most modern APIs expect a JSON body and a matching Content-Type:

POST https://api.example.com/users
Content-Type: application/json

{
  "name": "John",
  "role": "developer"
}

In this tool: select POST, enter the URL, add a header Content-Type: application/json, switch to the Body tab, select JSON, paste the JSON, and click Send.

A successful response is usually a 201 Created status with the newly created object, or a 200 OK with the server's representation. A 422 Unprocessable Entity means the server received the JSON but rejected its contents (often due to validation rules).

PUT and PATCH example

PUT replaces a resource entirely. PATCH partially updates it. In practice, both are used interchangeably by many APIs:

PUT https://api.example.com/users/42
Content-Type: application/json

{
  "name": "John Updated",
  "role": "senior developer"
}

PATCH is more efficient when you only want to change one field, because the server merges the payload into the existing resource:

PATCH https://api.example.com/users/42
Content-Type: application/json

{
  "role": "senior developer"
}

Both methods expect a 200 OK or 204 No Content on success.

DELETE example

DELETE removes a resource. Most DELETE requests have no body:

DELETE https://api.example.com/users/42

Successful deletion usually returns 204 No Content. A 404 Not Found means the resource doesn't exist (or the ID is wrong), while a 403 Forbidden means you're authenticated but not authorized to delete that resource.

Query parameters

Query parameters are appended to the URL after a ? and separated by &:

https://api.example.com/users?page=2&limit=20&sort=created_at

The Params tab in this tool provides a key-value editor that automatically rebuilds the URL as you add or remove parameters. Each row has an enable/disable checkbox, which is useful when you want to temporarily silence a parameter without deleting it.

Two things to remember about query parameters: they appear in server access logs, and they appear in browser history. Never put secrets in a query string.

Headers

Headers carry metadata. The ones you'll use most often:

• Content-Type — tells the server what format your body is in. application/json is standard for modern APIs.
• Accept — tells the server what format you want back. Usually application/json.
• Authorization — carries credentials (see below).
• User-Agent — identifies your client. Some APIs require a specific value.
• X-Request-ID or similar — used for request tracing; some APIs require it.

The Headers tab in this tool provides the same key-value editor as Params, plus a sensitive-value detector that highlights Authorization, Cookie, X-API-Key, and similar headers.

Bearer token authentication

A Bearer token is sent in the Authorization header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Most modern APIs (OAuth 2.0, Firebase, Auth0, GitHub) use Bearer tokens. When you select Bearer Token in the Auth tab, this tool automatically adds the header for you.

Security note: a Bearer token grants full access to whatever the token's scope allows. If someone intercepts it, they can use it exactly as if they were you, until it expires. Never paste real tokens into chat tools, issue trackers, or any tool that logs requests. This tool runs entirely in your browser and never transmits your token — but the generated code will contain it, so replace it with an environment variable before committing.

API keys

An API key is a long random string that identifies your application. It's sent in one of a few common ways:

• As a header: X-API-Key: abc123... (most common)
• As a query parameter: ?api_key=abc123... (avoid if possible — appears in logs)
• As part of the URL: /api/abc123.../users (rare, discouraged)

The API Key auth option lets you specify both the header name and the value, so you can match whatever convention the API uses.

Basic authentication

Basic auth sends a username and password encoded in base64:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Base64 is not encryption — it's just encoding. Anyone who can read the header can decode it. Basic auth should only ever be used over HTTPS.

When you select Basic Auth in this tool, enter the username and password and it will compute the header for you.

JSON body

JSON is the default request body format for modern REST APIs. It's the right choice when your API documentation says Content-Type: application/json. This tool validates JSON as you type and highlights syntax errors before you send.

One common mistake: sending JSON without setting Content-Type: application/json. The server will often treat the body as plain text and reject it with a 400 or 415 Unsupported Media Type.

Form data (URL-encoded and multipart)

Before JSON became dominant, HTML forms used application/x-www-form-urlencoded. The body looks like a query string:

email=test@example.com&password=secret

Multipart form data (multipart/form-data) is used when the form includes file uploads. Each field is a separate "part" with its own headers, and the file is base64-encoded or sent raw.

This tool supports both. For URL-encoded, use the key-value rows in the Form panel. For multipart, the same rows accept file placeholders like @/path/to/file.pdf — but as with the cURL converter, the generated code will emit a placeholder that you'll need to replace.

Reading API responses

A response has four parts you should always check:

1. Status code — 2xx means success, 3xx means redirect, 4xx means client error, 5xx means server error.
2. Response headers — often more informative than the body. RateLimit-Remaining, Retry-After, and X-Request-ID are common.
3. Body — usually JSON, sometimes XML or plain text. This tool auto-formats JSON for readability.
4. Timing — how long the server took to respond. Useful for debugging slow APIs.

This tool shows all four, plus a search feature that lets you find a specific string inside a large response body.

HTTP status codes explained

When a request fails, the status code tells you why. The most important ones:

• 400 Bad Request — the server couldn't parse your request. Usually a malformed body or missing required field.
• 401 Unauthorized — you haven't provided valid credentials, or your token expired.
• 403 Forbidden — you're authenticated, but you don't have permission for this resource.
• 404 Not Found — the URL doesn't exist, or the resource doesn't exist.
• 405 Method Not Allowed — you used the wrong HTTP method (e.g., POST to a GET-only endpoint).
• 408 Request Timeout — the server gave up waiting for your request.
• 409 Conflict — the request conflicts with the current state (e.g., duplicate key).
• 422 Unprocessable Entity — the request is well-formed but semantically invalid (validation errors).
• 429 Too Many Requests — you hit the rate limit. Check Retry-After.
• 500 Internal Server Error — the server has a bug. Not your fault, but you may be able to work around it.
• 502 Bad Gateway — an upstream server failed. Usually transient.
• 503 Service Unavailable — the server is overloaded or in maintenance.
• 504 Gateway Timeout — the upstream server didn't respond in time.

This tool shows a plain-language explanation for each of these status codes when you inspect the "Status explained" tab of the response, drawing on the response headers (like Retry-After) when available. It never invents explanations when the response gives insufficient information.

Response headers

Response headers are a goldmine for debugging. The ones worth knowing:

• Content-Type — what format the body is in. If it says text/html but you expected JSON, you probably hit an HTML error page.
• Retry-After — how long to wait before retrying. Common on 429 and 503.
• X-RateLimit-* — remaining request quota. Rate-limit headers vary by provider.
• Set-Cookie — cookies the server wants you to store. Browser-managed.
• Cache-Control — caching directives. Useful when building caching layers.
• Content-Length — body size in bytes.

CORS limitations — why some requests fail in the browser

This is the single most common source of confusion for developers using browser-based API testers. When you send an API request from a web page (like this one), the browser applies a rule called CORS (Cross-Origin Resource Sharing). It works like this:

1. Your browser sends the request with an Origin header identifying this page.
2. The target server responds. If the response doesn't include the right Access-Control-Allow-Origin header, the browser refuses to hand the response body to JavaScript.
3. Even worse: for non-simple requests (custom headers, PUT/DELETE, JSON bodies), the browser sends a preflight OPTIONS request first. If the server doesn't answer that correctly, the actual request never happens.

The result: a request that works perfectly in cURL or Postman can fail in a browser tool with a cryptic "Failed to fetch" error. This is not a bug in the tool — it's the browser protecting you from malicious websites silently making requests on your behalf.

What this means for you: if you need to test an API that doesn't send CORS headers, use a terminal tool (cURL), a desktop tool (Postman, Insomnia, HTTPie), or a server-side proxy. This tool cannot bypass CORS, and any online tool that claims it can is either (a) proxying your request through their server — which leaks your credentials — or (b) lying.

This tool is honest about this. When a request fails at the network level, it explains that the cause is either CORS or a genuine network error, and suggests checking the browser's developer console for the exact reason.

Browser vs server-side API requests

Understanding the difference is essential for choosing the right approach:

• Browser requests — subject to CORS, cookie restrictions, and browser security policy. Also: your credentials (Authorization headers, API keys) are exposed to the client. Never use them for privileged operations.
• Server-side requests — no CORS, full control over headers, credentials stay on the server. The correct choice for anything sensitive.
• Desktop tools — like cURL, Postman, and this tool's generated code when run locally. No CORS, but they do have access to your full session.

This tool sends requests from your browser, so it's subject to CORS. The code it generates can be run anywhere: in a browser (subject to CORS), in Node.js (no CORS), on a server, or in a mobile app. This distinction matters when you move from testing to production.

How to convert cURL into an API request

cURL commands and API requests are the same thing expressed differently. To convert cURL into a structured request:

1. Copy a cURL command — for example from API documentation, or from Chrome DevTools (Network tab → right-click a request → Copy → Copy as cURL).
2. Click Import cURL in this tool.
3. Paste the command and confirm.
4. The tool populates the method, URL, query params, headers, auth, and body automatically.
5. Review the Request breakdown (visible across the Params, Headers, Auth, and Body tabs) to confirm the parse is correct.

If you want to go deeper — convert the same cURL into Python, Go, Java, or another language — use our cURL to Code Converter, which focuses specifically on multi-language generation.

How to generate cURL from an API request

Once you've built a request in this tool, click Generate cURL. The tool produces a properly-escaped cURL command with one option per line — ready to paste into a terminal, share with a colleague, or include in API documentation.

The generated command preserves everything: method, headers, query string, auth, and body. It's the inverse of the import workflow, which means you can round-trip between this tool and cURL without losing information.

How to convert the response using Universal Data Transformer

Once you've received a JSON or XML response, you can send it directly to our Universal Data Transformer with a single click. This is useful for workflows like:

• API response → CSV, to open the data in Excel or Google Sheets.
• API response → YAML, to embed in a config file.
• API response → SQL, to insert the data into a database.
• API response → Markdown, to share in a chat or documentation.

The tool copies the response to your clipboard and opens the Transformer in a new tab. Nothing is sent to any server; the flow is entirely local.

Common API testing errors and what they mean

• "Failed to fetch" — either CORS or a network error. Check the browser console for the exact reason. If the API is public and the console shows a CORS warning, use cURL or a server-side request instead.
• "net::ERR_NAME_NOT_RESOLVED" — DNS failure. The hostname doesn't exist.
• "net::ERR_CONNECTION_REFUSED" — the server is running but not accepting connections on that port. Common with localhost during development.
• "net::ERR_CERT_AUTHORITY_INVALID" — TLS certificate issue. Usually a self-signed cert on a staging server. In a browser, you cannot bypass this; use cURL with -k.
• Invalid JSON body — the tool highlights the syntax error before sending. Fix the JSON and re-send.
• Empty response with 200 — the server returned successfully but with no body. Common for DELETE and for endpoints that only return a status.

Frequently asked questions

Is this API request builder free?

Yes. No signup, no account, no rate limit. Everything runs in your browser.

Does this tool send my requests through a server?

No. Requests are sent directly from your browser to the target API using the standard fetch API. The tool never proxies your request, never logs it, and never sees your credentials. This is why CORS restrictions apply — it's the price of true client-side privacy.

Can this tool bypass CORS?

No, and no honest browser tool can. If your API doesn't send CORS headers, requests from the browser will be blocked. Use a terminal tool, a desktop app, or a server-side request instead.

Is it safe to send real API tokens through this tool?

Yes — your token is never transmitted anywhere except directly to the API you specify. But be careful with the generated code: it will contain the token in plain text. Replace it with an environment variable before committing.

Does this tool support file uploads?

Multipart form data is supported with a placeholder path. Browsers cannot read arbitrary files from disk without a file input, so the generated code will contain a placeholder that you'll replace in your application.

Can I use this tool to test WebSocket APIs?

No — WebSockets use a different protocol. This tool is for HTTP and HTTPS requests only.

How is this different from Postman?

Postman is a full-featured desktop app with collections, environments, team collaboration, and mock servers. This tool is deliberately minimal: no accounts, no cloud sync, no collections. It's designed for quick request building and inspection, in a browser tab, with zero setup. If you need Postman's features, use Postman.

How is this different from cURL?

cURL is the standard for command-line requests. This tool is for the cases where a graphical interface is easier — building complex requests with many headers, exploring unfamiliar APIs, or converting between cURL and structured code without remembering flags. Both tools are complementary; this tool explicitly bridges them via import/export.

What happens if I close the tab?

Your request is not saved anywhere. This is a privacy feature — nothing persists after you close the tab, not even locally.

Can I send the same request to multiple environments?

Yes — just change the hostname in the URL field and click Send again. There's no concept of "environments" in this version.

Does this tool retry on failure?

No. If a request fails, it fails — the tool does not retry automatically. This is intentional; automatic retries can mask bugs and cause side effects on non-idempotent endpoints.

Can I export my request as a code snippet for my CI pipeline?

Yes. Use Generate code to produce a snippet in JavaScript, Python, Go, Java, C#, PHP, Rust, or Axios. The generated code is self-contained and ready to paste into your project.