generated client didn't set Content-Type application/json - the API 415d and the agent blamed the endpoint for a week

TL;DR

Set the Content-Type header to application/json on every request with a JSON body, and the 415s stop. The client was sending a body the server could not identify, so it refused it before even parsing.

Set the header in one shared request helper so no endpoint can forget it, and assert it in tests.

Verbatim query

generated client didn't set Content-Type application/json  -  the API 415d and the agent blamed the endpoint for a week

Steps

1. Confirm the missing header

Capture a raw failing request and inspect its headers. Check whether Content-Type is absent or set to something wrong. Expected: The failing request visibly lacks the Content-Type header.

1. Reproduce with the header set

Resend the same request with Content-Type application/json added. Confirm the 415 becomes a 2xx or a different error. Expected: Adding the header clears the 415, proving it was the cause.

1. Set the header centrally

Add the header in the shared HTTP helper every generated call goes through. Cover POST, PUT, and PATCH - any method that sends a body. Expected: Every body-carrying request leaves the client with the header set.

1. Check for per-endpoint overrides

Search for calls that set their own headers and might drop the shared ones. Make the helper merge, not replace, headers. Expected: No call site can silently drop the Content-Type.

1. Add a header assertion test

Test that a sample POST includes Content-Type application/json. Run it on every regen. Expected: The test passes and would catch a regen that drops the header.

Use this when

• POST or PUT calls return 415 and the client never sets Content-Type
• The same payload succeeds from curl with the header but fails from the client
• An agent spent days blaming the endpoint while the header was missing

Not for this skill when

• The header is set and the 415 persists - the body itself is malformed
• The API expects a different media type like multipart - check the docs
• Failures are 400, not 415 - the body parses but the content is wrong

Variant phrasings

API returns 415 unsupported media type

415 almost always means the server could not identify the body format - check the Content-Type first.

missing Content-Type header

No header means the server guesses, and strict servers refuse to guess.

client sends JSON without content type

The body can be perfect JSON and still 415 if the header does not say so.

Why it happens

HTTP servers route on the Content-Type header before parsing the body: no header means unknown format, and a strict server answers 415 rather than sniffing. Generators sometimes set the header only when the spec declares consumes explicitly, and sloppy specs omit it. The agent saw 415, assumed the endpoint was broken, and debugged everything except the one header the client never sent.

Edge cases

• Some endpoints need a charset suffix; application/json alone is fine for most, but check the docs
• File-upload endpoints want multipart with a boundary - do not force JSON there
• Proxies can strip headers; if the header is set client-side but missing server-side, check the middle

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZ7bmZgW5wP6i2CLuDDyAA