API Request Builder
Build, inspect and export HTTP requests — methods, headers, query parameters, bodies and auth — as ready-to-run cURL commands.
Pick a method, enter the endpoint, add query parameters, headers and a request body, and this
tool assembles the full request for you. It watches the whole thing live — flagging invalid
JSON, duplicate or empty fields and missing Content-Type headers — and exports
the result as a cURL command, the raw HTTP wire format, or a JavaScript
fetch() snippet. Bearer, Basic and API-key auth are handled for you.
Request
Authentication
Added as Authorization: Bearer <token>.
Added as Authorization: Basic <base64(user:pass)>. The base64 encoding is
computed locally in your browser.
Header is the safer choice — query parameters end up in server logs, proxies and browser history. Use query only when the API requires it.
Query parameters
Any query string you type into the URL above is imported here automatically. Values are percent-encoded in the output; untick a row to exclude it.
| Use | Key | Value |
|---|
Headers
| Use | Header | Value |
|---|
Body
Sent as application/x-www-form-urlencoded. For file uploads you need
multipart/form-data, which requires a real client (cURL -F) —
this tool exports the rest for you.
| Use | Key | Value |
|---|
cURL options
Generated request
Report
Nothing to report yet.
Reading the generated cURL
Every value is wrapped in single quotes, which tell the shell to treat the contents
literally — spaces, &, # and $ all pass through
untouched. The one character that can’t appear inside single quotes is the single quote
itself; cURL convention escapes it as '\'' (close the quote, add an escaped quote,
reopen). That’s why a body containing O’Brien looks like
--data-raw '{...O'\''Brien...}' — it’s correct, and pasting it into a
terminal works as-is.
The body flag matters. --data-raw sends the body exactly as written. Plain
--data would interpret a leading @ as “read the body from this
file”, which is a classic footgun when your JSON starts with "@type".
Form data uses --data-urlencode per field instead, because cURL then percent-encodes
each value for you — spaces become %20, & becomes
%26 — which is exactly what
application/x-www-form-urlencoded requires.
Finally, the method flag: curl defaults to GET, so a JSON POST doesn’t
need -X POST (the --data flag implies it), but DELETE
always does — without -X DELETE curl would silently send a GET. Tick
“Always add an explicit -X flag” if you prefer the method spelled out everywhere.
HTTP methods at a glance
Two properties from RFC 9110 are worth knowing when you pick a method. Safe means the
request is intended only to retrieve data and must not change server state. Idempotent
means repeating the same request any number of times has the same effect as doing it once —
so retrying a failed idempotent request is safe, while retrying a non-idempotent one (like a
payment POST) can double-charge.
| Method | Safe | Idempotent | Typical use |
|---|---|---|---|
| GET | yes | yes | Read a resource; never carries a body |
| POST | no | no | Create a resource or submit data for processing |
| PUT | no | yes | Replace a resource entirely at a known URI |
| PATCH | no | no | Apply a partial update to a resource |
| DELETE | no | yes* | Remove a resource (*idempotent in practice) |
| HEAD | yes | yes | Same as GET but returns headers only |
| OPTIONS | yes | yes | Discover what methods and features a server supports |
Query string vs request body
Query parameters travel in the URL, which means they show up in server access logs, proxy logs, browser history and analytics — so never put secrets or tokens in them (this tool defaults API-key auth to a header for exactly that reason). They’re also subject to practical length limits: most servers and intermediaries cap URLs around 2 KB, while request bodies can be many megabytes.
The split in practice: GET/DELETE take their inputs as query parameters (filters,
pagination, the resource id); POST/PUT/PATCH carry their payload in the body with a
matching Content-Type. If an API asks for the same thing both ways, prefer the
body — it’s private, cacheable-safe and has no length ceiling.
Content-Type quick reference
| Content-Type | Body shape | Notes |
|---|---|---|
application/json | {"key": "value"} | The default for modern REST APIs; this tool validates the JSON live |
application/x-www-form-urlencoded | a=1&b=two | What HTML form submits use; values must be percent-encoded |
multipart/form-data | parts with boundaries | Required for file uploads — build those with cURL -F, not this tool |
application/xml | <root><item/></root> | Still common in SOAP and some government/finance APIs |
text/plain | any text | Webhooks, raw CSV drops, simple key/value endpoints |
Need the other direction? Paste any exported cURL command into the cURL to Code Converter to turn it into Python, JavaScript, Go and six more languages.
Suggested
