Introduction

HTTP 415 Unsupported Media Type means the server rejected the request body's declared format. In JSON APIs, the usual cause is a mismatch between the request's Content-Type header and what the endpoint is configured to accept. The fix is not just "send JSON". The fix is sending the right body with the right header to an endpoint that is configured to parse it.

415 Is About Request Content Type

The key header here is Content-Type, not Accept.

If a client sends:

1POST /api/users HTTP/1.1
2Host: example.com
3Content-Type: text/plain
4
5{"name":"Ava"}

then the body may look like JSON to you, but the server sees it as text/plain. A framework that expects application/json is allowed to reject it with 415.

A correct JSON request looks like this:

1POST /api/users HTTP/1.1
2Host: example.com
3Content-Type: application/json
4
5{"name":"Ava"}

That distinction is the heart of the problem.

Client Code Must Set the Header and Serialize the Body Correctly

A very common mistake is sending a JavaScript object directly without proper JSON serialization.

1fetch('/api/users', {
2  method: 'POST',
3  headers: {
4    'Content-Type': 'application/json'
5  },
6  body: JSON.stringify({ name: 'Ava' })
7});

If you forget either the header or JSON.stringify, many servers will reject the request or parse it incorrectly.

In Python requests, the json= parameter is the easiest safe option.

1import requests
2
3response = requests.post(
4    'https://example.com/api/users',
5    json={'name': 'Ava'},
6)
7print(response.status_code)

Using json= sets the body and Content-Type appropriately. That is better than manually serializing unless you have a specific reason.

Server Configuration Must Match the Expected Format

The server also has to be configured to consume JSON. In Express, for example, JSON parsing middleware is required.

1const express = require('express');
2const app = express();
3
4app.use(express.json());
5
6app.post('/api/users', (req, res) => {
7  res.json({ received: req.body });
8});

In frameworks such as Spring, ASP.NET, or Flask, the same principle applies: the endpoint must accept JSON and the server must have the appropriate parser configured.

A client can send a perfect JSON request and still get 415 if the endpoint is only configured for form data or XML.

Do Not Confuse 415 with 400 or 406

These statuses are related but different:

• '415: the request body format is unsupported'
• '400: the request format may be accepted, but the content is malformed or invalid'
• '406: the requested response type in Accept is not available'

For example, malformed JSON often produces 400, not 415, because the server accepted application/json but could not parse the body successfully.

That distinction helps narrow the debugging quickly.

Check for Middleware and Proxy Interference

Sometimes the application code is fine, but an API gateway, reverse proxy, or middleware layer rewrites headers or rejects certain media types before the request reaches the handler. If the client and endpoint code both look correct, inspect the full request as it arrives at the server boundary.

This is especially common in systems with autogenerated clients, proxies, or strict API gateways.

Common Pitfalls

• Sending JSON data with the wrong Content-Type header.
• Forgetting to serialize the body properly while still claiming it is JSON.
• Debugging the Accept header when the problem is actually the request Content-Type.
• Assuming the server accepts JSON without verifying that JSON parsing is enabled for the endpoint.
• Mistaking malformed JSON for a 415 issue when the server is really returning 400.

Summary

• HTTP 415 means the server rejected the request body's media type.
• For JSON requests, Content-Type: application/json is usually required.
• The client must both serialize the body correctly and set the matching header.
• The server must also be configured to consume JSON.
• Distinguish 415 from 400 and 406 so you debug the right layer.