Sume 415 unsupported_media_type: read details.received_content_type

A 415 unsupported_media_type from the Sume API means the request body was not sent as application/json. The error carries details.received_content_type, so the response tells you what the client actually sent. Set Content-Type: application/json and send a JSON string, and the request goes through validation.

This is easy to hit because many clients choose a content type for you. The Errors and rate limits page lists the status next to 400, 401, and 413, and the examples in the docs always set the header.

Which clients send the wrong type

Three client defaults are common. Each is a behavior of the client, not of Sume, so check your own stack.

The call that works

The shape below matches the curl in the Jobs and results page: bearer auth, a JSON content type, and an Idempotency-Key on a paid submit.

const res = await fetch("https://api.sume.com/v1/image-1.0/generate", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SUME_API_KEY}`,
    "Content-Type": "application/json",
    "Idempotency-Key": "hero-shot-2026-10-09-001",
  },
  body: JSON.stringify({ prompt: "Matte black bottle on marble", mode: "async" }),
});
if (res.status === 415) {
  const { error } = await res.json();
  console.error(error.details?.received_content_type, error.request_id);
}

Reading the error in code

The error envelope is the same for every public error: error.code, error.message, error.request_id, and error.details. For a 415, details.received_content_type is the value to log. Put it next to the request id so the next person sees what your client sent without reproducing the call.

A quick way to confirm the cause is to repeat the call from a terminal with the header set. If it works there, the bug is in the library or gateway between your code and the API, not in the payload. Check any HTTP wrapper that sets headers by default, especially one that merges a shared headers object into every request.

What to log when it happens

Log error.request_id. The docs say the request id is safe to share with Sume support and that API keys, signed URLs, and private workspace ids must stay out of logs and tickets.

A 415 is a client bug, not a transient fault. Do not retry it in a loop. A 400 invalid_request is the neighboring error: the content type was right but the body, query, or headers failed validation. A 413 payload_too_large means the body exceeded the configured API limit. Check the status code first, then the code, then details.

If your integration also sends both Authorization and x-api-key, you get a 401, not a 415, so the two problems are easy to tell apart.