Quickstart: set the right request headers for

Q: What if I forget the Accept header?

The API still returns JSON for API routes, but sending Accept: application/json is the contract and protects you if content negotiation ever changes.

2 min read

AcceptAlways request JSON

Idempotency-KeyOn every POST

User-AgentName and version your client

The four headers that matter

Accept: application/json — guarantees a JSON body even on errors.
Content-Type: application/json — required on POST/PUT bodies.
Idempotency-Key: <uuid> — makes a retried POST safe to send twice (see idempotency).
User-Agent: my-app/1.4 (+https://example.com) — lets support correlate your calls.

Set them once

Centralise headers in one place — a base client, an interceptor or a wrapper function — so every call is consistent:

const base = (extra = {}) => ({
  Accept: 'application/json',
  'User-Agent': 'my-app/1.4',
  ...extra,
});

// GET
fetch(url, { headers: base() });
// POST
fetch(url, {
  method: 'POST',
  headers: base({ 'Content-Type': 'application/json', 'Idempotency-Key': crypto.randomUUID() }),
  body: JSON.stringify(payload),
});

Frequently asked questions

What if I forget the Accept header?

The API still returns JSON for API routes, but sending Accept: application/json is the contract and protects you if content negotiation ever changes.

Is Idempotency-Key needed on GET?

No. GETs are already idempotent. Add the key to POSTs that create or submit something, such as enquiries.

Why a custom User-Agent?

When you contact support, a descriptive User-Agent plus the request_id lets the team find your exact call quickly. Default library agents are anonymous.