How do I authenticate my request?

Per the API's scheme, as a header: Authorization: Bearer (OAuth/JWT), or X-API-Key: . Keys go in headers, not query strings, wherever the API allows — URLs leak into logs.

HTTP Request Builder — cURL & Code Generator

Headers (one per line: Key: Value) Body (JSON)

Generates ready-to-run request code (it does not send the request from this page).

Share X / Twitter Facebook LinkedIn WhatsApp

How to use HTTP Request Builder

Pick the method and paste the URL — query parameters included.
Add headers one per line — Content-Type: application/json and your Authorization at minimum for JSON APIs.
Write the JSON body for POST/PUT/PATCH.
Copy the cURL or code export and run it — same request, your choice of runtime.

What is HTTP Request Builder?

An HTTP request builder assembles API calls from parts — method (GET/POST/PUT/PATCH/DELETE), URL, headers, JSON body — and generates the runnable forms: the curl command for a terminal, and code for your language. It's the request-construction step of API work, minus the syntax recall.

The recall it replaces is real: curl's flags (-X, -H per header, -d for body, quoting rules that differ by shell), fetch's options object, the Content-Type header everyone forgets on POSTs. Fill the form once; every export is syntactically correct.

About the HTTP Request Builder

Choose the method, paste the URL, add headers line by line (the form suggests the standard ones — Content-Type: application/json, Authorization: Bearer …), write the JSON body for writing methods, and copy the generated cURL or code.

Where it fits in API work: constructing the first test call against an unfamiliar endpoint (the docs say POST with a JSON body — build it, run the cURL, see what actually returns); producing reproducible bug reports (a cURL command is the standard way to hand a failing request to an API's support); converting between forms (you have a cURL from docs but need fetch for the frontend — rebuild here, export the other way); and teaching — the form-to-command mapping is the clearest illustration of what an HTTP request even is.

The classic errors it prevents: missing Content-Type (server ignores or rejects the body), unquoted URL ampersands in shells (silently truncated query strings), and GETs with bodies (legal in theory, dropped by many servers — the builder hides body input for GET as a hint).

Frequently Asked Questions

GET reads, POST creates (or triggers actions), PUT replaces whole resources, PATCH updates fields, DELETE removes. REST APIs document per endpoint; when unsure, the docs' example method is the answer.

Almost always a missing Content-Type: application/json header — the server didn't parse the body as JSON. Second suspect: shell quoting mangled the -d payload. The builder's exports handle both.

Per the API's scheme, as a header: Authorization: Bearer <token> (OAuth/JWT), or X-API-Key: <key>. Keys go in headers, not query strings, wherever the API allows — URLs leak into logs.

The universal command-line HTTP client — present on every Mac/Linux/modern Windows. A cURL command is a complete, runnable description of a request, which makes it the lingua franca of API docs and bug reports.

The spec permits it but servers and proxies widely ignore or reject it — never rely on it. Data for GETs goes in the query string; data that needs a body wants POST.