API Client Code Generator

API Client Boilerplate: The Code You Write Identically Every Time

Every HTTP request from frontend code follows the same template: method, URL, headers, body, await response, parse JSON, handle error. The details differ; the shape doesn't. Writing it by hand for every endpoint wastes time you should spend on actual logic.

This generator takes the request specification (method, URL, headers, body) and outputs ready-to-paste code in Fetch, Axios, cURL, and other HTTP client formats. Same input, different output formats, pick the one your codebase uses.

The Three Client Formats

Fetch (browser-native, Node 18+):

Pros: zero dependencies, modern, works in browsers and Node.
Cons: doesn't reject on HTTP errors, no automatic JSON parsing, no interceptors.

Axios:

Pros: automatic JSON, throws on 4xx/5xx, interceptors, cancellation, broad node support.
Cons: ~13 KB bundled (small but not zero), one more dependency.

cURL (universal CLI):

Pros: works everywhere, no setup, reproducible.
Cons: not directly usable in app code; for testing and docs only.

When to Generate vs Write by Hand

Generators shine when you're:

• Prototyping a new API. Quickly test the endpoint shape before integrating.
• Documenting an API. Generated snippets are consistent across your docs.
• Switching libraries. Migrating from Axios to Fetch? Generate both and compare.
• Debugging. Reproduce a curl that worked outside your app.

Hand-writing is better when:

• You have a fully typed SDK already (don't re-roll).
• You need custom interceptors, retry logic, or wrapped error types.
• Your codebase has an established pattern, don't deviate just because the generator looks slick.

The Fetch Gotchas

Fetch is great but has rough edges:

HTTP errors don't reject.

Forgetting this check means your code happily treats a 500 as success and tries to parse the error page as JSON. Bug guaranteed.

JSON parsing is manual.

Forgetting .json() gives you a Response object, not the data. Easy mistake.

Body needs JSON.stringify.

Passing a raw object sends "[object Object]" as the body. Always stringify.

Content-Type is not automatic.

Without this header, many servers refuse the request or misinterpret the body.

Axios handles all four automatically. Fetch doesn't. Hence the boilerplate.

CORS: The Cross-Origin Problem

When frontend code at app.example.com calls an API at api.example.com, browsers enforce CORS. Without proper server-side headers, the request fails with no useful error:

The fix is server-side. The API must respond with:

For requests with custom headers or non-simple methods, browsers send a preflight OPTIONS request first. The server must respond to it correctly too. CORS issues are the most common reason a fetch that "works in Postman" fails in browser code.

cURL doesn't have CORS, it's a CLI, not a browser. That's why "the request works in cURL" doesn't mean it'll work in the browser.

Authentication Patterns

Bearer tokens (most common):

OAuth, JWT, most modern APIs. Token usually expires; clients refresh it.

API keys:

Or as query string for some APIs. Don't put API keys in client-side code that ships to users, they get extracted. Use a backend proxy.

Basic auth (legacy):

Base64-encoded user:password. Still common for internal tools. Always over HTTPS.

Cookie/session (server-rendered apps):

Sends cookies with the request. Backend treats it as an authenticated session.

Request Body Encodings

JSON (modern APIs):

Form-urlencoded (legacy / OAuth):

Multipart (file uploads):

For uploads, use FormData:

Don't set Content-Type manually, browser sets it with the correct boundary.

Common Debugging Steps

When a request fails:

1. Check status code. response.status tells you what kind of error. 400 = bad request body. 401 = auth missing/invalid. 403 = auth valid but no permission. 404 = wrong URL. 500 = server error.
2. Check the response body. Many APIs return JSON error details. await response.text() reveals what the server actually said.
3. Check headers sent. Browser devtools' Network tab shows exactly what went out.
4. Reproduce with cURL. If cURL works and the browser doesn't, it's CORS. If both fail, it's the API.
5. Check CORS. OPTIONS request first; the actual request follows only if OPTIONS succeeds.

Practical Workflows

1. API prototyping. Generate Fetch code for a new endpoint, drop into your component.
2. Writing API docs. Generate cURL + Fetch + Axios for each endpoint in your reference.
3. Migrating client libraries. Generate equivalent code in the new library for each existing request.
4. Debugging. Reproduce a failing browser request as cURL to test outside the browser.
5. Teaching. Show developers what a request "really looks like" by generating from a high-level description.

Privacy

URL, headers, and body content all stay local. The generator builds the output string in JavaScript, no server-side compilation, no telemetry on what endpoints you're testing. Paste internal staging URLs and bearer tokens without exposure.