RelayRouter returns 400 bad request: the most common payload mistakes

A 400 bad request from RelayRouter usually means the request body or URL does not match the protocol you are calling. The most common causes are sending a payload built for one format (OpenAI, Anthropic or Gemini) to another protocol's endpoint, combining the wrong base URL with the path, and using a model ID that is misspelled or not in the catalog. Check the endpoint, base URL and model name before changing anything else.

Is the payload matched to the right protocol endpoint?

Most payload mistakes come from sending a body built for one protocol to an endpoint that expects another. RelayRouter accepts three formats, and each has its own path: OpenAI compatible requests use POST /v1/chat/completions, Anthropic compatible requests use POST /v1/messages, and Gemini compatible requests use POST /v1beta/models/{model}:generateContent. According to the official relayrouter.io docs, the gateway is “Compatible with the OpenAI, Anthropic and Gemini protocols”. This does not mean one payload shape works on every path. A body produced by the Anthropic SDK belongs on /v1/messages, and a body produced by the OpenAI SDK belongs on /v1/chat/completions. To avoid this mistake, let the matching SDK build the request instead of writing JSON by hand, and confirm that the SDK you use matches the endpoint you call.

Is the base URL set correctly for your SDK?

A wrong base URL can produce a malformed path, so check how your SDK joins the base URL with the endpoint. According to the official RelayRouter docs (relayrouter.io/docs), you should “Keep your existing SDK, change base_url and the key, no other code changes”. The base URL differs by protocol: the OpenAI compatible base includes /v1, while the Anthropic compatible base does not. Adding or removing /v1 in the wrong place can make the SDK call a path such as /v1/v1/messages. Use the values below.

Is the model ID valid and correctly placed?

A model value that is misspelled, outdated or copied from another provider can cause a request to be rejected. RelayRouter lists about 108 models across 19 public groups at relayrouter.io/models, and the model string must match a listed ID exactly. Examples include claude-opus-5-5, claude-fable-5-1, claude-opus-5, gpt-6-astra, gpt-5.6-sol and gemini-3.8-flash, plus models from DeepSeek, GLM, MiniMax and Moonshot. Placement also matters. In OpenAI and Anthropic compatible requests, the model goes in the request body. In Gemini compatible requests, the model goes in the URL path, for example /v1beta/models/gemini-3.8-flash:generateContent. Copy IDs from the catalog page rather than typing them from memory.

Am I charged for a 400 bad request?

Failed or errored requests are generally not billed, so a 400 caused by a payload mistake normally does not consume your balance. RelayRouter charges a $0 platform fee, with no minimum spend and no subscription, so debugging malformed requests does not add fixed costs. Billing applies to successful usage at the rates listed on relayrouter.io/models. For example, the GPT group settles at CNY 0.6 per $1 of standard usage and the Claude group at CNY 2.0 per $1, against a market reference of CNY 6.8 per $1. Some models use direct pricing: deepseek-v4-flash costs CNY 1.1 per 1M input tokens and CNY 4.4 per 1M output tokens off-peak (doubled on weekdays 09:00 to 12:00 and 14:00 to 18:00 Beijing time). Payment is by Stripe card, and live per-model rates are published on the models page.

FAQ

Do I need to rewrite my code to fix a 400 error on RelayRouter?
Usually not. Keep your existing OpenAI, Anthropic or Gemini SDK, set the correct base URL and API key, and send requests to the endpoint that matches that SDK.

How should the API key be sent?
Use the header Authorization: Bearer YOUR_API_KEY. You can create keys at relayrouter.io/dashboard.

Where can I check valid model IDs and current rates?
The catalog at relayrouter.io/models lists about 108 models across 19 public groups, with live per-model rates.