Guide

How to Connect Azure OpenAI to DAVE

Summary

A step-by-step guide to adding Azure OpenAI as an AI provider in DAVE, so your workflows can call your Azure-deployed models with your own credentials and zero platform markup.

The steps

  1. Gather your Azure OpenAI endpoint and API key

    Azure OpenAI endpoints are deployment-specific. Unlike a standard OpenAI account, where a single base URI covers all models, each Azure OpenAI resource has its own endpoint URL tied to your Azure subscription, resource group, and resource name. You need this endpoint and an API key before you configure anything in DAVE.

    Log in to the Azure portal at portal.azure.com and navigate to your Azure OpenAI resource. From there, open Azure OpenAI Studio (or the resource's Keys and Endpoint blade) to find both values. You will also need at least one model deployed in your Azure resource before DAVE can fetch a model catalog. If you have not deployed a model yet, do that first in Azure OpenAI Studio under Deployments.

    Do this
    • Log in to portal.azure.com and open your Azure OpenAI resource.
    • Navigate to Keys and Endpoint to copy your Endpoint URL and one of your API Keys (Key 1 or Key 2).
    • Note the exact endpoint format. It will look similar to https://your-resource-name.openai.azure.com/.
    • Confirm you have at least one model deployed in Azure OpenAI Studio → Deployments. If the deployments list is empty, DAVE's model fetch will return zero models.
    • Copy the API key and store it temporarily in a secure location such as a password manager.
    Example

    An Azure OpenAI endpoint looks like https://contoso-eastus2.openai.azure.com/, not https://api.openai.com/v1. If you paste the standard OpenAI endpoint into the Azure OpenAI provider, the connection will fail. Always copy the endpoint from your Azure resource's Keys and Endpoint blade.

    Best practice
    • Use Key 1 for DAVE and keep Key 2 in reserve. Azure provides two keys so you can rotate one without downtime: update DAVE with Key 2, then regenerate Key 1 for future use.
    • Create a dedicated Azure OpenAI resource for production workloads if you are also using Azure OpenAI for development or experimentation. Separate resources mean separate quotas and separate audit trails.
    • Note the Azure region your resource is deployed in. Latency and model availability vary by region, and you may want to reflect this in the provider name you set in DAVE.
  2. Navigate to Admin > API Management > Providers

    In your DAVE workspace, navigate to Admin → API Management → Providers. This screen lists every AI provider configured for your tenant and is where you create, edit, and delete provider records.

    Access to this screen is restricted to the Admin role. DAVE ships with six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), and only Admin can view or manage providers. If you do not see the Providers option in the menu, ask your workspace Admin to grant you the appropriate role.

    The Providers page displays a card for each configured provider, showing its name, provider type badge, model count, and base URI. If this is a new workspace, the list will be empty.

    Do this
    • Sign in to your DAVE workspace.
    • Open the Admin section from the main navigation.
    • Select API Management, then Providers.
    • Review any existing providers. You can have multiple providers active simultaneously and route different workflow nodes to different providers.
    • Click Add Provider in the top-right corner to open the create form.
    Example

    If your workspace already has an OpenAI or Anthropic provider configured, you will see those cards listed here. Adding Azure OpenAI creates a separate provider entry alongside them. Each provider is independent: editing or deleting one does not affect the others.

    Best practice
    • Providers are scoped per tenant. If you manage multiple tenants in DAVE, you will need to add an Azure OpenAI provider separately in each tenant where you want to use it.
    • If you have multiple Azure OpenAI resources (for example, one per region or one per environment), you can create a separate DAVE provider record for each. Name them clearly so it is obvious which Azure resource each one points to.
  3. Create the Azure OpenAI provider record

    With the create form open, fill in the required fields to register Azure OpenAI as a provider in your tenant.

    Select Azure OpenAI from the Provider Type dropdown. Unlike the OpenAI or Anthropic provider types, selecting Azure OpenAI does not pre-fill the Base URI field. You must enter your deployment-specific Azure endpoint manually.

    In the Base URI field, paste the endpoint URL you copied from the Azure portal. Then paste your Azure API key into the API Key field. The field is masked by default; click the eye icon to toggle visibility if you need to verify the value before saving. The key is encrypted at rest with AES-256-GCM authenticated encryption and is never returned in plain text through the API once saved.

    Because Azure endpoints are deployment-specific, use the provider's Name field to capture enough context to identify it at a glance. For example, a name like Azure OpenAI: eastus2, gpt-4o makes it immediately clear which resource and deployment this provider points to.

    Do this
    • In the Name field, enter a descriptive label that includes the Azure region and primary model, for example Azure OpenAI: eastus2, gpt-4o.
    • Set Provider Type to Azure OpenAI. Note that the Base URI field does not auto-fill.
    • In the Base URI field, paste your Azure OpenAI endpoint URL (for example, https://your-resource-name.openai.azure.com/).
    • Paste your Azure API key into the API Key field.
    • Proceed to configure the model catalog before clicking Create Provider (see Step 4).
    Example

    A completed Azure OpenAI provider form will show: Name = Azure OpenAI: eastus2, gpt-4o, Provider Type = Azure OpenAI, Base URI = https://contoso-eastus2.openai.azure.com/, and a masked API key. The model catalog section will be empty until you fetch models in the next step.

    Best practice
    • Double-check the Base URI before saving. A typo here is the most common cause of a failed model fetch or a runtime connection error. Copy and paste directly from the Azure portal rather than typing it by hand.
    • The Base URI should match the root of your Azure OpenAI resource endpoint, not a specific deployment path. DAVE constructs the full request URL from the base URI and the model/deployment identifier at runtime.
    • If you have separate Azure resources for different environments (production, staging, development), create a separate DAVE provider record for each and name them accordingly.
  4. Build the model catalog

    Before saving, configure the model catalog: the list of models deployed in your Azure OpenAI resource that will be available to agents in your workflows.

    Fetch from API (recommended): Click the Fetch Models button. DAVE calls your Azure OpenAI resource using the endpoint and API key you just entered and returns the list of deployed models. Use the search box to filter by name, then check the models you want to include. Use the All or None buttons to bulk-select. A successful fetch also confirms that your API key and base URI are valid before you save the provider.

    JSON mode: If the fetch returns zero models, or if you prefer to specify models manually, click the JSON button and paste a JSON array of model objects. This is the right fallback if your Azure API key has restricted permissions that prevent listing deployments, or if you want to include only a specific subset of your deployed models.

    Once your catalog is configured, click Create Provider to save the record.

    Do this
    • In the model catalog section, click Fetch Models.
    • Wait for DAVE to retrieve the deployment list from your Azure OpenAI resource.
    • If the fetch succeeds, check the models you want to include and uncheck any you do not need.
    • If the fetch returns zero models, confirm that at least one model is deployed in your Azure resource under Azure OpenAI Studio → Deployments, then try again. If the issue persists, switch to JSON mode and enter your deployment identifiers manually.
    • Click Create Provider to save.
    • Confirm the new provider card appears in the Providers list with the correct model count.
    Example

    If you have deployed gpt-4o in your Azure resource under a deployment named gpt-4o-prod, the fetch will return that deployment identifier. In Azure OpenAI, the model identifier in DAVE corresponds to your deployment name, not the underlying model name. Make sure your deployment names are descriptive enough to be recognisable in the agent configuration dropdown.

    Best practice
    • Always try Fetch from API first. A successful fetch confirms your endpoint and key are correct before you save the provider, catching configuration errors early.
    • If the fetch returns zero models, the most common cause is that no models are deployed in the Azure resource yet. Deploy at least one model in Azure OpenAI Studio before retrying.
    • Keep the catalog lean. Include only the deployments your workflows actually need. You can always edit the provider later to add more.
    • After saving, click the chevron on the provider card to expand it and verify the model list looks correct before wiring up agents.
  5. Use Azure OpenAI in a workflow node

    With the Azure OpenAI provider saved and its model catalog populated, it is immediately available to any workflow node that calls an AI model. In DAVE's workflow runtime, nodes that invoke AI models, such as an Agent Interaction node, let you select a provider and a specific model from that provider's catalog.

    Agents are the bridge between workflow nodes and providers. When you configure an agent, you select the Azure OpenAI provider you just created and choose a deployment from its catalog. The agent uses the provider's stored API key and base URI at runtime. When the node executes, DAVE calls your Azure OpenAI resource directly using your credentials. No request is proxied through DAVE's infrastructure for billing purposes: the call goes from DAVE to your Azure resource, and the usage appears on your Azure invoice.

    Every provider call made during workflow execution is recorded in DAVE's full audit log, giving you a complete trace of which provider was called, by which agent, in which workflow, and when.

    Do this
    • Navigate to the Agents section of your workspace and create or edit an agent.
    • In the agent configuration, select your new Azure OpenAI provider from the provider dropdown.
    • Choose the deployment appropriate for the agent's task.
    • Save the agent.
    • Open or create a workflow and add an Agent Interaction node that references this agent.
    • Run a test execution to confirm the node calls your Azure OpenAI resource successfully and returns the expected output.
    • Check the audit log to verify the call was recorded correctly.
    Example

    A common pattern for teams with Azure compliance requirements is to route all AI calls through an Azure OpenAI provider, keeping inference within their Azure tenant and region, while using DAVE's orchestration layer to manage workflow logic, retries, and human review steps. The provider record in DAVE is the only place the Azure endpoint and key need to be configured: all agents that reference it inherit those credentials automatically.

    Best practice
    • Start with a simple single-node test workflow before wiring Azure OpenAI into a complex multi-step pipeline. Confirm the connection, response format, and latency before building on top of it.
    • If an agent fails with an authentication or invalid API key error, navigate to Admin → API Management → Providers, edit the Azure OpenAI provider, verify the Base URI and API key, and click Fetch Models to confirm the connection before saving.
    • If you are building workflows for regulated industries or need data residency within a specific Azure region, confirm that your Azure OpenAI resource is deployed in the correct region before connecting it to DAVE. The provider record in DAVE does not enforce regional routing: that is determined entirely by the Azure endpoint you supply.
    • Review DAVE's SOC 2 and GDPR compliance modes if your workflows handle sensitive data. These modes govern how execution data, including AI provider responses, is handled and retained across your tenant.

What this guide covers

Azure OpenAI is one of the seven AI provider types DAVE supports out of the box, and it is listed separately from OpenAI because the two are configured differently. Azure serves models from a resource you own in your own subscription, so connecting it means supplying the details of that resource alongside your key.

The steps below cover the path from provisioning access in Azure to running a test execution in DAVE. You need Admin access in the workspace, because provider configuration is a tenant-level setting rather than a per-user one.

Before you start

Azure needs more preparation than a direct provider key, so settle these first.

  • An Azure subscription with access to the OpenAI service, and a deployed model. Azure serves models through deployments you create yourself, so a key alone is not enough: the deployment has to exist before DAVE can call it.
  • Admin role in the workspace. DAVE ships six default roles: Admin, Create, Curate, Use, Reporting and Financial. Provider management sits with Admin. Roles are editable database rows, so your workspace may have been customised.
  • A decision about scope. Providers are configured per tenant. If you run several workspaces, each one needs its own Azure OpenAI provider entry.

How this differs from connecting OpenAI directly

If you have already connected OpenAI, three differences are worth knowing before you start.

  • Models are deployments, not model names. With Azure you reference the deployment you created, so the same underlying model can appear under whatever name you gave it.
  • The endpoint belongs to your resource. Requests go to your own Azure resource rather than to a shared provider endpoint, which is usually the reason teams choose Azure in the first place.
  • Billing and quota are governed in Azure. Rate limits and spend controls are set on the Azure side, so a workflow that runs fine against a direct provider key can still hit a deployment quota here.

Everything downstream is the same: once the provider is saved, any workflow node that calls an AI model can select it.

What to check once it is connected

A provider that saves cleanly is not the same as a provider that works.

  • The credential stored. The key field shows a masked placeholder after saving. Secrets are encrypted at rest with per-tenant keys using AES-256-GCM authenticated encryption and are never returned through the API once stored.
  • A real execution against the deployment. Run a single-node test workflow. A wrong deployment reference is the most common cause of a provider that saves without error and then fails at run time.
  • The audit trail. Every execution is logged, so you can confirm which provider was called and when.

FAQ

Should I use Azure OpenAI or the OpenAI-compatible provider type?

Use Azure OpenAI. It is its own named provider type. OpenAI-compatible is for third-party endpoints that implement the OpenAI API shape and is not the right choice for an Azure resource.

Can I run Azure and direct OpenAI side by side?

Yes. Providers are configured per tenant and selected per node, so one workflow can use both.

Does DAVE mark up my usage?

No. Requests go from DAVE to your Azure resource, and usage appears on your own Azure bill.