3. Connecting AI providers: Anthropic, OpenAI, and Google credentials

Description

In the previous lesson you decided which model family suits your agent — Claude, GPT, or Gemini, based on cost, latency, and quality. That decision, alone, doesn't move a single token: a model node with no credential is a door with no key. Today you're going to create each provider's credential, connect it to the correct model node inside your agent, and — the part almost nobody explains the first time — decide when it's worth reusing a credential you already have versus creating a new one.

This matters as soon as you step outside a personal experiment. If you build agents for several clients — an agency, a freelancer, an internal team with different cost centers — each client usually brings their own OpenAI or Anthropic account, and mixing those keys into the wrong credential means billing one client for another's usage. Even working alone, you'll want a separate credential for what you test in development and another for what runs in production, so a badly written test doesn't drain the real client's quota.

Connection to the module: you already chose the model (lesson 2); today you connect the key that gives it real access. Lesson 5 assumes your agent already responds — so without this lesson solved, there's no prompt to test.

A credential is a key; each provider is a different building

Think of Anthropic, OpenAI, and Google as three office buildings on the same block. Each has its own lock, and one building's key doesn't turn a millimeter in the door next door, no matter how much the three keys look like the same metal. It doesn't matter how hard you try: an OpenAI key is never going to open Anthropic's door.

n8n doesn't make you load each key every time you need it. It has something like a central front desk with a keyring: you store the key there once, with a name you choose, and from any workflow — today, next month, in a completely different flow — you borrow that same key without writing it again. That's, technically, a credential in n8n: an encrypted object, stored separately from the workflow, identified by a type (Anthropic API, OpenAI API, Google Gemini(PaLM) Api) that only fits nodes expecting exactly that type.

The chat model node — Anthropic Chat Model, OpenAI Chat Model, or Google Gemini Chat Model, depending on the provider you chose — is the lock. It connects to your AI Agent's Chat Model port, and in its panel there's a "Credential to connect with" field where you choose which key from the keyring to use. One detail worth knowing up front: that field only offers you credentials of its own type. The Anthropic Chat Model node is never going to show you an OpenAI credential in its list — the editor filters by design, just like the lock filters by shape.

Worked example

Let's create all three credentials, connect one to a real agent, run it, and then look at what gets saved if you export that workflow.

Step 1 — create the Anthropic credential. In n8n, go to Settings → Credentials → "Add credential" and search for "Anthropic API." The form asks for:

Field	Required	What to put
API Key	Yes	The key you generate at console.anthropic.com → Settings → API Keys → "Create Key"
Base URL	No	Leave it empty; it defaults to https://api.anthropic.com
Add Custom Header	No	Enable it only if a corporate proxy requires it

Name the credential so that six months from now you know what it is without opening it — for example "Anthropic — Acme Client" instead of "Anthropic API." When you save it, n8n tests the connection on its own (it makes a GET /v1/models call with your key) and warns you if the key is invalid before you discover the error halfway through an execution.

Step 2 — repeat for OpenAI and Google. The mechanics are the same; only the fields and where you get the key change:

Provider	Credential type	Required field	Optional fields	Where to generate the key
OpenAI	OpenAI API	API Key	Organization ID, Base URL, custom header	platform.openai.com/api-keys
Google Gemini	Google Gemini(PaLM) Api	API Key	Host (leave it at its default value)	aistudio.google.com/apikey

For Google, the "Host" field comes preloaded with https://generativelanguage.googleapis.com and shows up as editable, but the official documentation is explicit: the related nodes don't yet support a host or proxy other than the default one. Touching it gets you nothing, only the risk of breaking it.

Step 3 — connect the credential to the agent's node. Open your workflow with the AI Agent node (the same one you built in the previous module) and at the "Chat Model" port add the sub-node matching your provider — for example, "Anthropic Chat Model." In its panel, under "Credential to connect with," select the credential you just created. The "Model" field fills itself in with a dropdown that queries live which models that specific account can use — not a fixed list hardcoded into the node — so if the model you decided on in the previous lesson isn't there, the problem isn't the node: it's that this account doesn't have access to that model yet.

Step 4 — run it and confirm. With a test message like "What can you do for me?", run the node. What to expect: the execution panel shows a text response in output, and if you open the call's detail, you see the exact name of the model that answered — useful for confirming you're really hitting the model you think you are, not an older one left selected by accident.

Step 5 — export the workflow and look at what got saved. From the three-dot menu, "Download." Look for the model node inside the JSON:

{
  "name": "Anthropic Chat Model",
  "type": "@n8n/n8n-nodes-langchain.lmChatAnthropic",
  "typeVersion": 1.3,
  "parameters": {
    "model": { "value": "claude-sonnet-4-5" }
  },
  "credentials": {
    "anthropicApi": {
      "id": "7",
      "name": "Anthropic — Acme Client"
    }
  }
}

There's the detail that matters: the credentials key only carries an id and a name. The real API key never leaves your n8n instance's database — it doesn't travel in the exported file, it doesn't end up in a repository if you upload the JSON, it doesn't show up if a colleague opens the file in a text editor. If that colleague imports the workflow into their own instance, id: "7" doesn't exist there, so n8n is going to explicitly ask them to connect their own credential before the node can run.

When to create a new credential and when to reuse the one you have

The question isn't technical, it's organizational. Some criteria that actually matter in practice:

• By client or billing account. If you build agents for different clients and each one pays for their own OpenAI or Anthropic account, each client needs their own credential — they should never share one. Name them unambiguously ("OpenAI — North Client," "OpenAI — South Client") so nobody accidentally connects the wrong client's workflow to the other's key.
• By environment. One credential for what you test in development and another for what runs in production, even if both point to the same real account. That way an experiment that overconsumes, or a prompt stuck in a weird loop during a test, doesn't hit the budget the client expects to see in production.
• Rotation without touching every node. Since nodes reference the credential by id, not by the key's value, you can rotate an expired API key by editing the credential once — every workflow that uses it gets updated without you opening node by node.
• The Base URL / Host field, for real gateways. Some teams put a corporate proxy in front of the provider's API — to centralize spend, apply a content filter, or log every call — and that proxy exposes the same API format as the original provider. That's when it makes sense to change the Anthropic or OpenAI credential's Base URL to point at the proxy instead of the public API. For Google this door is closed for now: the Host stays fixed.
• Organization ID (OpenAI only). If your account belongs to more than one OpenAI organization, this field ensures usage gets attributed to the correct organization on the bill, instead of whichever one the account defaults to.

Common mistakes

Thinking switching providers just means swapping the credential on the same node. This is the most common conceptual mistake for someone coming fresh from other tools: assuming a generic "chat model" node accepts any credential and that swapping it is enough to jump from Claude to GPT. In n8n that's not how it works — Anthropic Chat Model, OpenAI Chat Model, and Google Gemini Chat Model are three different node types, each built against its provider's specific API. You spot it because an Anthropic Chat Model node's credential dropdown is never going to list an OpenAI credential, no matter how many you have saved. The fix is to delete the old provider's sub-node, add the new provider's at the agent's Chat Model port, and only then choose or create its credential.

Pasting the API key into the wrong provider's field. This happens more than it seems when you have several tabs open: you copy Anthropic's key and paste it into the OpenAI credential form that was left open from before. The form accepts it without complaint — it's a text field, it doesn't validate format on save — but when you run the node you hit an authentication error (401, typically invalid_api_key or authentication_error depending on the provider). You spot it by using the credential panel's "Test" button before assuming it's good, not just when saving. It's fixed by checking which console you copied the key from and regenerating it if needed.

Touching the Base URL or Host field with no real need. Someone copies the full endpoint URL (for example, with /v1/messages at the end) instead of the root domain, or leaves a stray space or slash. The credential saves with no visible error — the problem only shows up when you run it, as a connection error or a 404, because n8n builds the final URL by concatenating the endpoint's path onto whatever you put there. You spot it by comparing your value against the documented default (https://api.anthropic.com, https://api.openai.com/v1, https://generativelanguage.googleapis.com). It's fixed by leaving the field at its default value unless you're genuinely pointing at your own proxy, in which case, paste only the root domain.

Exercises

Exercise 1. You create an OpenAI credential, connect it to an "OpenAI Chat Model" node in your agent, and run it. The node responds with an authentication error. List, in order, the first three places you'd check before assuming your OpenAI account has a problem.

See solution

First, the credential's own "Test" button — if it fails there, the problem is the key, not the node or the workflow. Second, whether the key is actually from OpenAI and not another provider pasted by mistake (check the prefix: OpenAI keys start with sk-, Anthropic's with sk-ant-). Third, if "Test" passes but the node execution still fails, check the Organization ID field: a valid key associated with the wrong organization can get the call rejected depending on how the account is configured.

Why it works: each of these three points isolates a different cause of the same symptom (authentication error), and checking them in that order — credential, correct key, organization — rules out the simplest explanation before assuming a stranger account problem.

Exercise 2. You have a single "Anthropic Chat Model" node in a workflow, with a credential named "Anthropic — Acme Client" connected. You need to run that exact same workflow for "Beta Client," who pays for their own Anthropic account. What would you do: edit the existing credential, or create a new one? Justify your answer.

See solution

Create a new credential ("Anthropic — Beta Client"), never edit the existing one. If you edit "Anthropic — Acme Client" to point at Beta's key, any other workflow that already uses that credential by its id — maybe one you thought was Acme-only — starts billing Beta without you having explicitly decided that there. Keeping one credential per client keeps each one's usage isolated and auditable just by looking at the credential name shown on each node.

Why it works: since nodes reference the credential by id, editing a shared credential propagates the change to everything that uses it — a convenient shortcut for rotating your own key, but dangerous when what's changing is whose account it is.

Exercise 3. You export a workflow that uses a Google Gemini credential and send it to a colleague to review on their own n8n instance. They import it and try to run it right away. What's going to happen, and what do they still need to do before it works?

See solution

The execution is going to fail, or the node is going to explicitly ask for a credential, because the exported JSON file only carries the id and name of your Google Gemini(PaLM) Api credential — never the API key itself. That id doesn't exist on your colleague's instance. Before running it, they need to create their own Google Gemini(PaLM) Api credential (with their own Google AI Studio key) and connect it to the imported node.

Why it works: n8n encrypts and stores credentials per instance, separate from the workflow; the export only carries a reference, not the secret. That's exactly the mechanism that lets you share or version workflows without giving away your keys.

Exercise 4 (challenge). Your agent currently uses an "OpenAI Chat Model" node with its credential already connected and tested. A client asks you to switch to Gemini for that same task, without changing anything else about the agent's behavior. Describe the concrete steps on the canvas — not just "change the model."

See solution

1. Add a new "Google Gemini Chat Model" sub-node to the canvas (you can't convert the existing OpenAI node in place, because they're different node types).
2. Connect it to the AI Agent's "Chat Model" port — this replaces the connection the OpenAI node had (the port accepts only one ai_languageModel-type connection).
3. In the new node's panel, select or create the Google Gemini(PaLM) Api credential, and choose the model from the dropdown that queries the account.
4. Delete the "OpenAI Chat Model" sub-node that's now disconnected (optional for it to run, but recommended so you don't leave orphaned nodes confusing whoever opens the workflow later).
5. Run it again with the same test prompt you used before, to confirm the rest of the agent — the system prompt, the tools, the memory — still behaves the same with the new model.

Why it works: the System Message, the tools, and the memory are connected to the AI Agent node, not to the model node — changing the "brain" shouldn't touch those pieces. The only thing that actually changes is which sub-node occupies the Chat Model port and which credential it carries.

Summary and next step

You now know how to create a credential for Anthropic, OpenAI, and Google, connect it to the correct model node, and — more importantly — decide when a new credential is worth it instead of reusing the one you already have: by client, by environment, or to rotate a key without touching every workflow that uses it. You also saw that exporting a workflow never exposes the real key, only a reference.

What you learned today assumes there's a cloud account behind every credential — and those accounts cost money per call. In the next lesson you'll see the other end: running the same agent against a model that lives on your own machine, with no cloud credential and no per-token cost, using Ollama.

Before moving on you should be able to explain, without looking back at this lesson: what fields each credential asks for (Anthropic, OpenAI, Google Gemini), why one provider's model node never lets you pick another provider's credential, and what exactly gets saved in an exported workflow's JSON when that workflow uses a credential.

Resources

• Anthropic credentials — the Anthropic credential's exact fields and which nodes use it.
• OpenAI credentials — the OpenAI credential's fields, including Organization ID.
• Google PaLM/Gemini credentials — how to generate the key in Google AI Studio and why the Host doesn't accept proxies yet.
• Anthropic Console — where you generate and manage your Anthropic API keys.
• OpenAI API keys — where you generate your API key and see which organization it belongs to.
• Google AI Studio — API keys — where you generate the Gemini key and choose the associated Google Cloud project.