Allow overriding `Content-Type` per OpenAPI operation

[nasoooor29]

Describe the feature

Feature Request:

orpc currently always uses application/json as the Content-Type for OpenAPILink and other generated links (not sure). While this works for most cases, some APIs require different content types such as:

• application/x-www-form-urlencoded
• multipart/form-data

When using these content types, the request payload must be encoded differently than JSON.

Problem

There is no way to override Content-Type per operation, which prevents calling endpoints that do not accept JSON request bodies.

Expected Behavior

• Allow overriding Content-Type per OpenAPI operation or link.
• Automatically serialize request data based on the selected content type.

Examples (JavaScript)

application/json

fetch("/login", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    username: "help",
    password: "help",
  }),
})

application/x-www-form-urlencoded

fetch("/login", {
  method: "POST",
  headers: {
    "Content-Type": "application/x-www-form-urlencoded",
  },
  body: new URLSearchParams({
    username: "help",
    password: "help",
  }),
})

multipart/form-data

const form = new FormData()
form.append("username", "help")
form.append("password", "help")

fetch("/login", {
  method: "POST",
  body: form,
})

Use Case

Required for authentication endpoints, legacy APIs, and form-based submissions that do not accept JSON payloads.

Additional information

• Would you be willing to help implement this feature?

[nasoooor29]

it also seems that there is something related to this on body.ts already but i don't know

this part

const authloginpost = oc
  .route({
    method: "POST",
    path: "/auth/login",
    inputStructure: "detailed",
  })
  .input(
    z.object({
      headers: z.object({
        Referer: z.string().optional(),
        Origin: z.string().optional(),
        "content-type": z.literal("application/x-www-form-urlencoded"), // pass the guy here didn't work it got overriden
      }),
      body: zodTypes.AuthLoginPostInputSchema,
    })
  )
  .output(zodTypes.AuthLoginPostResponseSchema);

this was the only way i found to override the content-type but then i needed to go and restructure the body to match the needed type

export function createQbittorrentClient(baseUrl: string) {
  const link = new OpenAPILink(contract, {
    url: baseUrl,

    fetch: (request, init) => {
      const newRequest = request.clone()
      newRequest.headers.set("content-type", "application/x-www-form-urlencoded"); // set the header from the api link

      console.log("Fetching:", newRequest, init);
      return globalThis.fetch(newRequest, {
        ...init,
        credentials: "include", // Include cookies for cross-origin requests
      });
    },
  });

  return createORPCClient(link) as JsonifiedClient<
    ContractRouterClient<typeof contract>
  >;
}

[dosubot]

The reason setting "content-type" in the route input headers doesn't work is that orpc internally deletes and overwrites this header based on the body type it actually sends. For example, if the body is a URLSearchParams, orpc sets the header to application/x-www-form-urlencoded; if it's FormData, it sets multipart/form-data with the correct boundary; otherwise, it defaults to application/json—regardless of what you set in the input schema or headers object. This logic is enforced in the server's toNodeHttpBody function.

There’s currently no built-in way to override Content-Type per operation and have orpc automatically serialize the body for you. If you need to send non-JSON payloads, you have to manually serialize the body (e.g., use new URLSearchParams() or FormData) and set the Content-Type header in a custom fetch wrapper, as you did in your createQbittorrentClient example. Just keep in mind: the body and header must match, or the server will reject or misinterpret the request. For multipart/form-data arrays, orpc expects bracket notation (like field[0], field[1]) for correct deserialization—repeated keys with the same name won't work for arrays (details).

For more advanced or automatic handling, the maintainers recommend using plugins or interceptors to customize serialization/deserialization logic, since the core intentionally keeps this behavior simple and consistent (discussion).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[LudovicGen]

Same problem! 👍 Looking forward to V2