API & webhooks
Fix REST API 415: Match the Body to Its Content Type
Resolve a REST API 415 by matching Content-Type and Content-Encoding to the actual body, then distinguish unsupported formats from malformed JSON.
Check the request representation the server received
A 415 Unsupported Media Type response means the server does not support the request content format for that operation. Inspect the actual Content-Type, any Content-Encoding and the transmitted body. Changing only the response format requested in Accept does not describe or convert the body you sent.
The HTTP 415 reference distinguishes problems with media type, content coding and the processed message content. Read the endpoint's contract before assuming it accepts JSON; some operations require form data, multipart uploads or another specific representation.
Send JSON bytes with a JSON content type
POST /notes HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
{"title":"Route notes","published":false}
This fictional request has a JSON object body and declares application/json. The boolean is a JSON boolean, not the string "false". The example host is a placeholder; use your own documented test endpoint and a permitted synthetic payload when reproducing the request.
async function createNote(url, note, fetcher = fetch) {
const response = await fetcher(url, {
method: "POST",
headers: {
"Content-Type": "application/json",
Accept: "application/json"
},
body: JSON.stringify(note)
});
const body = await response.text();
if (response.status === 415) {
throw new Error("The endpoint rejected the request format.");
}
if (!response.ok) {
throw new Error(`Note request failed: HTTP ${response.status}`);
}
return {status: response.status, body};
}
The function serializes the object rather than passing a JavaScript object directly as the request body. It reads a successful response as text so an empty response is not automatically treated as invalid JSON. The endpoint's response contract determines whether callers should parse that returned body further.
Find common header and body mismatches
A form-encoded body such as title=Route+notes is not a JSON object, even if Content-Type says application/json. Conversely, a JSON string sent with a form content type may be routed to the wrong server parser. Inspect the request payload rather than relying only on what the input editor looks like.
For browser FormData uploads, normally let the browser create the multipart Content-Type and boundary. Manually setting only multipart/form-data can omit the boundary needed to interpret the body. Use the API's expected field names and file part types as well as the correct outer format.
Content-Encoding describes an encoding such as compression applied to the content. Do not label an uncompressed JSON string as gzip. If the API does not accept compressed request bodies, adding gzip because the response supports compression will not help.
Keep format, syntax and validation failures separate
After the correct media type reaches the right parser, malformed JSON may produce a different client error. A valid JSON object with a missing required field may produce an application validation error. Fixing a 415 can therefore expose the next real problem rather than making the whole operation succeed immediately.
Use the documented response codes and body fields for the specific service. Do not treat every failure as a 415, and do not automatically retry a write request after a network interruption without considering whether the first attempt may have reached the server.
Change one request property at a time
In the REST API Testing Tool, choose the intended method, enter the complete endpoint URL, add the matching Content-Type header and paste the serialized body. The request leaves your browser for that endpoint, so use a controlled test resource when the operation creates or changes data.
Compare a known supported request with one deliberately using an unsupported type. Then test malformed JSON separately while keeping application/json. Record the status and actual server explanation for each case. Browser CORS failures can prevent a readable response, so inspect the network panel when no HTTP status is available to the client.


