Which documented n8n authentication surface matches the CometAPI HTTP workflow?

General
1

For the CometAPI HTTP workflow in n8n, start with HTTP Request → Generic Credential Type → Header Auth. That choice has a specific documentation basis: n8n lists Header auth as a generic HTTP Request authentication method, and CometAPI’s n8n guide illustrates an HTTP Header Auth credential using an Authorization bearer value.

The important distinction is between an HTTP request you configure explicitly and a native OpenAI node whose configuration options need separate verification. An OpenAI-compatible API does not, by itself, establish what a particular n8n node lets you configure.

Configure the HTTP credential and endpoint

Before starting, have access to an n8n workflow you can edit, a CometAPI key, and the endpoint and request details for the CometAPI operation you intend to call. Keep the key out of shared screenshots and workflow examples.

  1. Choose the HTTP Request node. The n8n HTTP Request documentation distinguishes generic credentials from predefined credentials. With generic credentials, you configure the endpoint, parameters, and authentication method yourself.
  2. Select generic Header Auth. Use the HTTP Header Auth setup in the official CometAPI n8n guide (Thai-language page, dated August 25, 2026). The guide supplies the CometAPI-specific mapping: the header name is Authorization, and its value uses the bearer scheme with your CometAPI key. Enter the real value only in your credential configuration, not in a public example.
  3. Configure the request destination separately. Use the guide’s CometAPI OpenAI-compatible base URL and the endpoint details for your intended operation. Selecting Header Auth sets the authentication mechanism; it does not choose a destination, model, or request body for you. Do not treat a base URL alone as a complete request specification.
  4. Make a small validation request before connecting downstream steps. This is a recommended check, not a reported test result. Confirm that the node targets the intended CometAPI endpoint and that the response has the fields your next step expects. Review destination, credential selection, and request parameters separately if it fails; an error alone does not identify which layer is wrong.

What this route does—and does not—establish

The two sources fit together narrowly: n8n documents the generic Header Auth mechanism, while CometAPI documents how it uses that mechanism in its HTTP workflow. That is enough to choose a documented starting path without assuming native-node gateway support.

It is not evidence that native OpenAI nodes cannot use CometAPI. If you prefer one, verify its current endpoint and credential configuration independently before switching. Nor does this configuration establish that every model accepts the same payload or returns the same response shape.

No workflow was executed for this post. Treat the sequence as a documentation-backed setup decision, with request-level validation still to do—not as a tested interoperability or credential-storage guarantee.

2

If this HTTP Request node becomes a tool available to an agent, I would add a request-policy boundary before the node runs. The agent should choose among permitted operations, while the workflow owns the destination and credential binding.

A proposed setup would expose only the inputs the task actually needs, such as the prompt and a model choice from an approved set. Keep the API origin, HTTP method, endpoint template and credential reference in workflow configuration. Resolve the selected operation to that configuration before assembling the request; do not let arbitrary generated text become the authenticated destination.

The same boundary should validate the operation-specific payload. Having a valid Header Auth credential should not be the condition that allows every generated request shape through. After the call, validate the fields required by the next workflow step before treating the tool result as usable.

I would test this with synthetic agent outputs that request an unapproved destination, an unsupported operation, and a payload missing a required field. The expected result is a local validation failure before the HTTP node executes. A separate response fixture should exercise a successful HTTP status with an unusable body and confirm that downstream actions remain stopped.

This is an application design recommendation layered over the documented HTTP configuration, not a claim that n8n automatically enforces these restrictions. It gives the agent a bounded task interface without making credential possession stand in for request validation.