Quickstart Pricing

Home → Help

404 on /responses — the Responses API needs the version prefix too

The Responses API lives under the same version prefix as everything else. If chat/completions works at /v1/chat/completions, responses is at /v1/responses. A request to /responses hits the website, not the API.

What you are seeing

Why it happens

The prefix belongs to the base URL, not to the individual endpoint. Once base_url ends with /v1, the SDK produces the right path for every endpoint it supports and you never think about it again.

Hand-written requests are where this breaks. Someone copies a curl example from a blog that wrote out the full URL, changes the host, and loses the prefix in the edit.

Because the 404 is returned at the edge, it leaves no trace in the account's request history. People then assume the endpoint is not supported at all, when in fact they have never reached it.

Confirm it is this

Compare the two paths with the same key — the difference is unambiguous:

curl -s -o /dev/null -w 'no prefix: %{http_code}\n' -X POST \
  'https://YOUR_DOMAIN/responses' -H 'Authorization: Bearer YOUR_KEY'
curl -s -o /dev/null -w 'with /v1:  %{http_code}\n' -X POST \
  'https://YOUR_DOMAIN/v1/responses' -H 'Authorization: Bearer YOUR_KEY'

A 404 on the first and 400 or 200 on the second confirms it. A 401 on the second means the path is right and the key is wrong — a different problem.

How to fix it

  1. Set the prefix once, in base_urlPut /v1 at the end of the base URL and let the SDK build every endpoint path. Editing individual URLs is how the prefix gets lost.
  2. Check which endpoints the gateway actually servesNot every OpenAI-compatible gateway implements the Responses API. If /v1/responses returns 404 while /v1/chat/completions works, the prefix is fine and the endpoint is genuinely absent — use chat/completions instead.
APICLAN serves /v1/responses, /v1/chat/completions and /v1/messages on the same base URL and the same key. Which models answer on which endpoint is in GET /v1/models.

Related

Unexpected token '<' when calling an OpenAI-compatible API401 invalid API key — when the key looks right but still fails

Last checked 2026-10-01. Written from problems diagnosed on a live OpenAI-compatible gateway, not collected from other sites.