N8n Gateway credits and CometAPI are different choices

General
1

Suppose an existing n8n workflow needs its AI requests to use your CometAPI account rather than n8n Cloud Gateway credits. The first decision is the credential path—not the model name.

Choose an explicit CometAPI-backed credential, conditional on your installed node supporting the required base URL override. Selecting Use Gateway credits is a different path; do not treat it as a way to attach your CometAPI token or establish CometAPI billing.

What the two documents actually establish

The n8n OpenAI credential documentation says that, on n8n Cloud, supporting nodes offer Use Gateway credits so you can skip setting up OpenAI credentials. It separately lists OpenAI, Chat OpenAI, Embeddings OpenAI, and LM OpenAI as users of the OpenAI credential.

That is a list of credential consumers, not a compatibility guarantee for another API provider. The captured credential page describes API-key authentication but does not document a base URL override or establish which installed node versions expose one.

The CometAPI n8n integration guide describes the other route: create an OpenAI API credential, supply a CometAPI token, set the base URL, select that credential in the workflow, and test a supported model ID. Its endpoint overview gives https://api.cometapi.com/v1. Later setup bullets put a trailing period inside the URL formatting; use the endpoint without that punctuation.

These documents support a conditional setup plan, not a claim that every node accepting OpenAI credentials will work unchanged.

A small migration check before changing the workflow

  1. Inspect the installed node and credential configuration. Confirm where its base URL override is supported and that it applies to the operation you intend to run. If no supported override is available, stop this migration path and check the documentation for that installed version. Do not paste a gateway token into an unchanged provider configuration and assume it redirects the request.
  2. Create a separate credential for the test. Following the CometAPI guide, pair the CometAPI token with https://api.cometapi.com/v1. Keep the token in credential storage, not prompt text, screenshots, or a shared workflow description. Preserve the existing workflow configuration for rollback.
  3. Select that credential explicitly. For this test, do not select Use Gateway credits. Enter the exact model ID from the current CometAPI catalog rather than guessing from a display name.
  4. Run one minimal, non-sensitive request. Check the response and the corresponding usage in the intended provider account before expanding the migration. A response alone is not proof of the billing path; an unresolved usage attribution is a reason to pause.

This is a proposed verification sequence, not a reported successful migration. One successful call establishes only that tested node, operation, model, and configuration—not embeddings, tools, or every other operation in the workflow.

The practical distinction: Gateway credits is n8n Cloud’s documented credential-free choice for supporting nodes. An external gateway migration requires deliberately binding the token and endpoint, then verifying that specific route before relying on it.

2

I’d separate the credential migration from the model migration. If the endpoint and model change together, a failed workflow leaves two competing explanations: the request path is wrong, or the replacement model does not meet the workflow’s output contract.

For a workflow that may later move between hosted and local inference, I’d keep a small, non-sensitive acceptance fixture outside the credential configuration. Record the input, the fields the downstream node requires, and what should happen when those fields are missing. Test those requirements rather than expecting identical generated prose.

Where both routes document support for the same exact model version and operation, keep those fixed for the first comparison. A matching display name is not enough to establish that equivalence. If no documented match exists, label the exercise as a combined route-and-model migration; don’t attribute an output difference to the credential choice alone.

The rollback decision should then have two separate gates: can you attribute the request to the intended account, and can the downstream node consume the result? Passing the first but failing the second is a reason to hold the workflow migration, not to cycle through tokens. This is a proposed diagnostic method, not a claim that the n8n credential supports a local server or that either guide proves model equivalence.