n8n credentials pass but the workflow returns 404: check the endpoint

A successful n8n OpenAI credential test does not prove that the endpoint used by your workflow is supported. The credential can test the model-list route while generation uses a different route. If the provider accepts /models but not the selected /responses request, the test can pass and the workflow can still fail.

This guide distinguishes the OpenAI credential, the OpenAI action node and the OpenAI Chat Model sub-node. It uses version-specific source evidence rather than assuming that every n8n version has the same defaults. The existing Chinese article records a historical local fixture test; this English edition does not present that old run as a new production test.

Base URL belongs in the credential

The OpenAI credential has a Base URL field. Its purpose is to point compatible nodes at an alternative API root. Use the provider’s documented root, not the full URL of a specific chat or response operation.

For example, a provider root might end in /v1. A generation operation then appends its own path. Pasting a complete /chat/completions URL into a field that expects the root can produce a malformed path when the node appends another endpoint. The exact resulting error depends on the provider; a 404 alone does not identify the cause.

The fixed n8n 2.36.9 credential source shows the Base URL field and a credential test against /models. It does not send a full chat generation request as that test.

Three different operations to keep apart

If the provider exposes its model list without authentication, a successful list request is also weak evidence about the key. Do not infer that every provider behaves this way, or that the key is invalid simply because generation fails. Check the provider’s authentication requirements and the actual response.

Identify which node failed

The OpenAI action-node documentation lists different generation operations. The OpenAI Chat Model is a separate sub-node, often connected to an AI Agent, with its own options. Instructions for one should not be blindly applied to the other.

In n8n 2.36.9, the Chat Model implementation exposes the Responses option for node typeVersion 1.3 or later and defines its UI default as true. A saved workflow’s explicit parameters and its runtime behavior still matter. This is a statement about that fixed source version, not a promise about every current installation.

The general documentation and older tutorials can describe a different default. Export the affected node, record its type and typeVersion, and inspect the option actually saved in your workflow. Do not replace that evidence with a screenshot from another release.

Build a minimal workflow that tests the generation route

Duplicate the affected workflow and keep the copy inactive. Disconnect nodes that send email, write records, charge accounts or publish content. For an initial check, a Manual Trigger followed by a single OpenAI generation action is enough. This isolates the API call from an agent’s tool loop, memory and downstream parsing. Running generation can still consume provider quota or incur charges.

Create or select the OpenAI credential for the intended provider. Enter its documented API root and key, then save it. If the documented root is https://provider.example/v1, that is the shape of the Base URL; provider.example here is a placeholder, not a service to call. Do not paste /chat/completions or /responses into this root field. Do not append /v1 twice merely because another tutorial contains it.

In the action node, choose the operation corresponding to the endpoint your provider documents. Use the exact model ID offered for that endpoint, not a marketing display name. For a provider that supports Chat Completions but not Responses, use the chat-generation operation supported by your installed node version. Supply one user message, “Reply with ready,” and remove optional tools, images and structured-output settings from the first check.

Execute only this isolated node chain. Expected success is a completed node with inspectable generated content, not just a green credential badge. Save the execution’s timestamp, route, status and returned shape. Then reconnect the next production dependency one at a time. If the first model call works but adding a tool fails, investigate that feature rather than changing a now-verified Base URL.

For a workflow using an AI Agent with an OpenAI Chat Model sub-node, inspect that sub-node’s saved typeVersion and Responses option instead. A working action-node test is a useful comparison, but it does not modify the agent’s configuration. Verify the agent’s actual outgoing request path after any change; the two nodes need not construct identical requests.

Compare two request shapes without mixing their fields

These simplified JSON bodies illustrate why the endpoint matters. Replace MODEL_ID with a documented ID. They are not n8n workflow exports and do not prove that any particular provider supports either route.

Chat Completions uses a messages array:

{"model":"MODEL_ID","messages":[{"role":"user","content":"Reply with ready."}]}

Responses uses input:

{"model":"MODEL_ID","input":"Reply with ready."}

A custom provider may implement one, both or only a subset of either. Pointing a Responses body at the chat URL does not turn it into a chat request. Similarly, a response parser written for choices[0].message.content cannot automatically handle a Responses output-item structure. When inspecting an n8n execution, distinguish the raw provider response from the node’s own normalized output.

If you need to bypass node-specific behavior for diagnosis, use a separate HTTP Request node with the provider’s documented method, full endpoint URL, authentication and JSON body. Use n8n’s credential mechanism for secrets. Compare this one harmless request with the failing node; do not replace the production workflow merely because an isolated HTTP request succeeds. It tests the provider route, while the original node may additionally require streaming, tool calling or another unsupported feature.

Trace the failing request

1. Record the n8n version, node type, node typeVersion and operation.
2. Confirm the Base URL root and exact model ID without exposing the key.
3. Read a redacted request log or provider trace to determine whether the request went to /responses or /chat/completions.
4. Compare that route with the provider’s support for the exact model.
5. If the model is documented for Chat Completions, select that operation or adjust the Chat Model option, then verify the outgoing route again.

Turning off one option is not a universal guarantee: library behavior or another configured feature can affect route selection. The acceptance check is the actual request path and response, not merely the toggle’s appearance.

Do not replay a production workflow with side effects just to inspect a URL. Isolate the model call with harmless input and disconnect tools that send messages or mutate records. Keep the reproduction small enough that the response can be inspected directly.

Interpret the observed URL before editing credentials again

These are diagnostic patterns, not claims about the precise URL construction of every release. A provider trace, reverse-proxy access log or authorized application trace gives stronger evidence than inferring the URL from a generic wrapper error. Redact authorization headers before storing or sharing the trace.

If the provider sees no request at all, investigate DNS, TLS, proxy and network reachability from the n8n execution environment. Your laptop’s successful browser request does not prove that a container or hosted worker can reach the same host. Avoid disabling certificate checks as a default fix; preserve the actual transport error.

Test data flow after the endpoint works

Use one input item first, then two visibly different items such as “Return ALPHA” and “Return BETA.” Verify which prompt each execution actually sends. Sub-nodes can resolve expressions differently from ordinary nodes; consult the Chat Model documentation before assuming that every item is independently mapped. This catches a different failure from endpoint compatibility: the request can succeed while processing the wrong input.

Next restore only the features your workflow needs. For structured extraction, validate the required fields; for tools, check the tool call and its result; for streaming, confirm how the node collects the final content. Preserve an ordinary text-only request as the baseline so that a later failure can be tied to the feature you just added.

Finish by exporting a redacted configuration record and retaining a known-working copy. Record the n8n version, node typeVersion, operation, API root, model ID and relevant options. Do not include the credential value. When updating n8n, rerun this small fixture before enabling the full automation. That provides an operational acceptance test instead of relying on a green badge or an old screenshot.

A minimal record for support

n8n version:
node type and typeVersion:
selected operation / Responses option:
provider API root:
exact model ID:
observed HTTP method and path:
HTTP status and redacted error body:
request ID, if supplied:

Never paste an API key, authorization header or a full private workflow export into a public issue. A redacted record should preserve the route and error fields while removing credentials and sensitive prompts.

The historical issue #21651 reports a successful credential test and a runtime 404 against a custom provider in n8n 1.118.2. It demonstrates that this symptom has occurred; its existence does not prove that the same old bug remains in your current version.

Do not stop at the first explanation

A 404 can also arise from an incorrect model ID, a provider-specific route, an extra path segment or a reverse proxy. If /chat/completions itself fails, preserve the response and check those possibilities before concluding that Responses compatibility is the only issue.

Our model-not-found troubleshooting guide covers model access and identifiers. The API migration guide explains the broader provider switch. Neither replaces validation of the exact endpoint you are using now.