Azure AI on DNotifier: Setup Guide

Part of a series on running AI workflows across model providers — this one's the second account-native setup after AWS Bedrock, where deployment names matter as much as credentials.

Azure AI is the second provider in this series (after AWS Bedrock) where "connect your API key" isn't the whole story. Like Bedrock, Azure AI is account-native — you're not just picking a model, you're connecting to infrastructure that lives inside your own Azure subscription. Get one detail wrong in that setup and you'll hit an error that looks like a DNotifier problem but is actually a one-character mismatch on the Azure side. This guide covers the setup and, more importantly, that one detail.

What you're connecting

Unlike OpenAI, Anthropic, Gemini, Hugging Face, or Perplexity — where you get an API key and start calling model names directly — Azure AI requires you to have already deployed a model inside your own Azure resource before DNotifier can call it. Azure doesn't let you address a model by its public name; you address it by whatever name you gave the deployment when you created it inside the Azure portal.

That single fact causes more setup confusion than everything else about Azure AI combined, so it's worth internalizing before writing any code.

Step 1: Connect Azure AI in the DNotifier portal

In the dashboard: Projects → AI Studio → Providers → Azure AI. You'll need:

Two things have to exist before this works: an Azure resource, and a model actually deployed inside it.

Step 2: Install the SDK

npm install @dnotifier-realtime/dnotifier

Step 3: The detail that causes most setup failures

Here's the part that trips people up: the model field in your sendAI() call isn't OpenAI's public model name. It's whatever you named your deployment inside the Azure portal. DNotifier's own documentation puts it plainly: "they can match, but don't assume."

const notifier = new DNotifier({ apiKey: process.env.DNOTIFIER_API_KEY });

const response = await notifier.sendAI({
  senderId: USER_ID,
  provider: "azure_ai",
  model: "gpt-4o",  // this must match your Azure DEPLOYMENT name, not a public model name
  message: {
    messages: [{ role: "user", content: "Summarize this quarter's key metrics." }]
  },
  saveHistory: true,
});

If you named your deployment gpt-4o when you created it in Azure, the code above works exactly as written. If you named it prod-summarizer-v2 or team-gpt4o-eastus instead — which is common in larger organizations that use descriptive deployment names — that string needs to go in the model field, not gpt-4o.

What a mismatch actually looks like

DNotifier's documentation is direct about this failure mode: "404 / deployment errors almost always mean the portal model string doesn't match Azure." In practice, this shows up as a call that fails immediately with an error that doesn't obviously point at the real cause — it's easy to spend twenty minutes checking your API key and network configuration before realizing the deployment name is simply wrong.

A use case that shows how this plays out in practice

An engineering team migrating from direct OpenAI API calls to Azure AI copied their existing code and swapped in provider: "azure_ai", keeping model: "gpt-4o" unchanged. It failed immediately. The team's actual Azure deployment — created months earlier by a different engineer — was named chatapp-gpt4o-prod. Once they checked the Azure portal's deployment list and corrected the model string to match, the exact same code worked without any other changes. The fix took two minutes once someone knew to look at deployment names specifically, and considerably longer before that.

The error looks like an integration problem. It's almost always a naming mismatch, checked against the Azure portal's deployment list.

Where to check your deployment names

Your deployment names live in the Azure portal (or Microsoft Foundry portal, depending on which resource type you're using — Azure AI Foundry vs. Azure OpenAI covers that distinction), under your resource's model deployments list. Whatever appears there, verbatim, is what belongs in DNotifier's model field — not the underlying model's public name, not an abbreviation, not what you assume it "should" be called.

Frequently asked questions

Can I just use the model's public name if I haven't renamed my deployment?

If you deployed a model and accepted Azure's default deployment name (which sometimes matches the model name), it'll work. The risk is assuming this is always true — check the actual deployment list rather than guessing.

Does DNotifier support Entra ID authentication, or only API keys?

Both — Azure AI's setup form in DNotifier accepts either an API key or Entra ID-style credentials. Entra ID vs. API Keys on Azure covers when each is the better choice.

Is this deployment-name requirement unique to Azure among the providers in this series?

Among the providers covered so far, yes — it's part of what makes Azure AI (like AWS Bedrock) an account-native setup rather than a simple API-key setup. Every other provider in this series addresses models by their public name directly.

What happens if I rename a deployment after connecting it to DNotifier?

Update the model field in your sendAI() calls (or your defineAgent() definitions) to match the new name — DNotifier doesn't track Azure's internal deployment renames automatically.

The Bottom Line

Next in this series: what "Azure AI Foundry," "Azure OpenAI Service," and "Microsoft Foundry" each actually mean, since the naming alone has confused a lot of otherwise capable engineers.

Read part two: Azure AI Foundry vs. Azure OpenAI. Explore dnotifier.com.