Connecting Azure OpenAI to n8n: credentials, deployments and first workflows

Azure OpenAI gives you access to OpenAI's models — GPT-4o, GPT-4.1, the o-series, the embeddings — but served from Microsoft Azure's infrastructure, in the region of your choice, under your organization's contract and governance. For many European companies, it's the only route their IT department will sign off on for using these models in production. The good news: n8n supports Azure OpenAI natively, with a dedicated credential and ready-made chat and embeddings nodes. The subtlety that trips everyone up on the first try: on Azure, you don't call a model by its name, you call a deployment that you created and named yourself. This guide walks the full path, from the Azure portal to your first AI agent in n8n.

Why Azure OpenAI rather than OpenAI directly

If you already use the regular OpenAI API in n8n (our OpenAI + n8n guide covers that case), what does the Azure detour buy you? Four things, all enterprise-oriented:

• Data residency by region. You choose where the model runs: a resource created in a European region processes your prompts in Europe. For customer, HR or health data, that's often the non-negotiable condition set by legal.
• Governance and identity. Access to the resource is administered like any other Azure service: Azure AD (Entra ID), RBAC roles, network policies, audit logs. IT keeps control over who consumes what.
• Unified Azure billing. Consumption shows up on your existing Azure invoice, with the portal's cost-tracking tools — no credit card to register on a separate OpenAI account.
• Contractual commitments. SLAs, enterprise terms and Microsoft's commitment not to use your data to train models fit into a contractual framework large organizations already know.

The investment pays off beyond compliance: the study "Generative AI at Work" by Erik Brynjolfsson, Danielle Li and Lindsey Raymond (NBER 2023, later published in The Quarterly Journal of Economics — see on Google Scholar), run in real-world conditions with customer support agents, measures a productivity gain of roughly 14% on average with a generative AI assistant, with the largest gains going to the least experienced agents. In other words, it's precisely the assistance and support workflows — n8n's natural playground — that have the most to gain from unlocking these models in a framework the company accepts.

Step 1: create the resource and a deployment in Azure

Everything happens in the Azure portal and Azure AI Foundry (the new name of the studio that brings Microsoft's AI services together).

1. In the Azure portal, create an Azure OpenAI resource: pick the subscription, a resource group, the region (this is what determines where processing takes place) and a resource name. That name matters: it's what n8n will ask you for.
2. Open the resource in Azure AI Foundry and go to the deployments section.
3. Create a deployment: select a model (GPT-4o, say), give it a deployment name and confirm the proposed deployment type and quota.

This is where Azure's quirk lives: the deployment name replaces the model name in every API call. You can call your deployment gpt-4o to keep things readable, or prod-support-chat to reflect its purpose — either way, that exact string is what n8n will send to the API. A model that isn't deployed is invisible to the API, even if it exists in the catalog.

Then grab two pieces of information from the resource's "Keys and Endpoint" section: the endpoint (of the form https://<resource-name>.openai.azure.com/) and one of the two API keys.

Step 2: create the "Azure Open AI" credential in n8n

In n8n, open Credentials → Add credential → Azure Open AI. Three fields:

Field	Value
Resource Name	Your Azure resource's name (the <resource-name> part of the endpoint)
API Key	One of the resource's two keys
API Version	The Azure OpenAI API version (date format, e.g. the one shown in the docs or the portal's code samples)

Two classic pitfalls: pasting the full endpoint URL into "Resource Name" (n8n only expects the name and rebuilds the URL itself), and leaving an outdated api-version (the Azure API is versioned by dates, and some recent features require a recent version).

As always, the key should live only in the credential manager — never in a Code node or a plain-text variable. The right habits (rotation, separate environments, least privilege) are covered in our guide to securing API credentials in n8n.

Step 3: the Azure OpenAI Chat Model node

The Azure OpenAI Chat Model node is a LangChain sub-node: it doesn't run on its own, it plugs in as the language model of a parent node — AI Agent, Basic LLM Chain, Text Classifier, Information Extractor…

Chat Trigger ──▶ AI Agent ──▶ Response
                   │
                   ├── Azure OpenAI Chat Model  (Azure Open AI credential)
                   │     Model (Deployment) Name: prod-support-chat
                   └── Tools (HTTP Request, Vector Store…)

1. Add an AI Agent (or a Basic LLM Chain for a simple call without tools).
2. Attach an Azure OpenAI Chat Model as the model, with your credential.
3. In the model field, enter your deployment's name — not the catalog model name. That's the key difference from the regular OpenAI node, which lists public models.

From there, everything that applies to n8n agents applies here: memory, tools, system prompts — our complete guide to the AI Agent node covers the mechanics. And if your workflow was already using Claude or GPT through the standard nodes, migrating often boils down to swapping the chat model sub-node and changing the model name into a deployment name.

Azure OpenAI embeddings for RAG

RAG follows the same logic. Deploy a model from the text-embedding family in your resource (it's a separate deployment, with its own name), then use the Embeddings Azure OpenAI node with the same credential. It plugs into n8n's vector store nodes (for indexing as well as querying) exactly like its regular OpenAI counterpart.

The enterprise appeal is obvious: the documents you vectorize — internal knowledge base, contracts, tickets — never leave the chosen Azure region, neither at indexing time nor at query time. One consistency rule to respect: use the same embeddings deployment for indexing and querying, otherwise the vectors aren't comparable and retrieval returns noise.

Common errors and how to diagnose them

Three errors come up again and again with Azure OpenAI in n8n:

• 404 DeploymentNotFound: the name entered in the node doesn't match any deployment in the resource. You probably typed the model name ("gpt-4o") instead of the deployment name, or the deployment lives in a different resource than the credential's. Check the deployment list in Azure AI Foundry and copy the name verbatim.
• Invalid or unsupported api-version: the credential points to an API version that doesn't exist or is too old for the requested feature. Switch to a version documented by Microsoft (date format) and retest.
• 429: tokens-per-minute quota exceeded: on Azure, the rate limit is set per deployment, as a tokens-per-minute quota allocated at creation time. A high-volume workflow can saturate its deployment while the resource still has headroom. Two levers: raise the quota allocated to the deployment in Azure AI Foundry, and make the workflow resilient with retries and smoothing — our guide to handling AI API rate limits gives the concrete n8n patterns (retry with backoff, queues, batching).

Production best practices

• One deployment per use case. Rather than a single deployment shared by every workflow, create one deployment per use case (support chatbot, document extraction, RAG embeddings…). Each gets its own tokens-per-minute quota: a spike on the chatbot no longer starves invoice extraction, and 429s become diagnosable at a glance.
• Name deployments for humans. prod-support-gpt4o says what it does; the day you switch the underlying model version, the deployment name — and therefore the n8n config — may not need to change at all.
• Track costs on both sides. Azure aggregates consumption in its billing, but doesn't tell you which n8n workflow consumes what. Log usage per execution on the n8n side: our method for tracking AI call costs per workflow applies as-is to Azure OpenAI.
• Plan a fallback. Even in the enterprise, a deployment can saturate or a region can have an incident. The multi-provider fallback pattern also works intra-Azure: a second deployment (different region, different model) as backup for the first.

Key takeaways

• Azure OpenAI serves OpenAI models from your Azure subscription: data residency by region (including Europe), Azure AD governance, unified billing and contracts.
• Create the resource, then a deployment in Azure AI Foundry: n8n will use the deployment name, not the model name.
• n8n's Azure Open AI credential needs three fields: resource name (not the full URL), API key, api version.
• Plug the Azure OpenAI Chat Model node into an AI Agent or a Basic LLM Chain, and the Embeddings Azure OpenAI node for RAG.
• The three classic errors — 404 DeploymentNotFound, invalid api-version, 429 quota — are fixed on the Azure side (names, versions, per-deployment quotas) and on the n8n side (retries, smoothing).