AI model providers · Model provider

Azure OpenAI and TestingOps: test agents on your own Azure deployment

Give TestingOps your Azure OpenAI endpoint, deployment name and key, and the agents on your projects run on your Azure resource through the Codex adapter.

Model provider
Available with limits

Request a demo Azure OpenAI v1 API

Azure OpenAI AnswerPrompt TestingOpsAI test agents

Connection: Model provider
Writes back: Nothing, only model requests
Last checked: 7 Nov 2026

In short

Azure OpenAI and TestingOps in short

The Azure OpenAI connection runs TestingOps agents against your own Azure OpenAI resource: the customer admin enters the resource's OpenAI-compatible endpoint (ending in /openai/v1) as Base URL, the deployment name as Model and the resource's API key.

While Azure OpenAI is your first provider, your agents run through the Codex adapter on that deployment, and a run whose endpoint is missing stops instead of sending your key to api.openai.com.

There is no separate deployment or API-version field, and TestingOps' own AI features outside agent runs do not use an Azure key.

What it does

What it does for your testing

1
Agents on your Azure resource
Input
Endpoint, deployment name and key, first under Your providers
TestingOps
Switches your agents to the Codex adapter and attaches the key, endpoint and deployment to all of your projects
Output
Agent runs that call your deployment in your Azure subscription
2
No fallback to OpenAI's public API
Input
A run whose endpoint address went missing
TestingOps
Stops the run before it starts and names the missing address
Output
The run does not fall back to api.openai.com with your Azure key
3
Endpoint rules that fit private resources
Input
The endpoint you enter
TestingOps
Accepts http and https addresses, including private ones, and refuses link-local or cloud metadata addresses and URLs with credentials in them
Output
An endpoint that matches how your resource is reached, as long as the agents can reach it

Step by step

How it works

Enter the endpoint, deployment and keyThe customer admin picks Azure OpenAI under Add a model provider. Base URL * is required: your resource's endpoint ending in /openai/v1. Model takes the deployment name exactly as it is in Azure.
Address checked on saveTestingOps accepts http and https endpoints, including private addresses, and refuses link-local or metadata addresses and URLs with a user name or password in them.
Attached to your projectsThe key, endpoint and deployment are attached to every project of your organisation; agents read them as OPENAI_API_KEY, OPENAI_BASE_URL and OPENAI_MODEL.
Codex agents on AzureWhile Azure OpenAI is marked Default · drives agents, your agents run through the Codex adapter against your endpoint. Without an endpoint, a run stops before it starts.

If you leave Model empty, TestingOps uses gpt-5, which works only if your deployment has exactly that name.

Connect

Setup

In Azure, note your resource's endpoint (https://<resource>.openai.azure.com/openai/v1), the name of the model deployment and an API key.
In TestingOps, as customer admin, open Integrations → AI models and pick Azure OpenAI under Add a model provider.
Enter the endpoint in Base URL *, the deployment name in Model and the key in API key, then select Save.
Open the entry and select Test connection to send one short request to the deployment.
Move Azure OpenAI to the top under Your providers and select Save order.

Documentation: Azure OpenAI v1 API

Where you connect it in TestingOps: Integrations → AI models → Your providers → Azure OpenAI

Use cases

Keep agent model calls in your Azure tenant

Trigger: Your security policy allows AI calls only to the company's Azure OpenAI resource
Uses: The resource endpoint, a deployment and its key
Agent activity: Agents on your projects run through Codex against that deployment
Result: Agent model calls go to your resource and are billed to your Azure subscription
Condition: TestingOps' own AI features outside agent runs use other models

Use the deployment your platform team approved

Trigger: Only one named deployment is approved for test work
Uses: The deployment name in Model
Agent activity: Your agents use that deployment from their next run
Result: Agent runs on your projects on the approved deployment

Move from OpenAI to Azure OpenAI

Trigger: Procurement moves the company from OpenAI to Azure
Uses: Your provider list
Agent activity: After you remove the OpenAI key and add Azure OpenAI, the Codex agents use your Azure endpoint
Result: The same adapter and agents on a different service
Condition: OpenAI and Azure OpenAI share the key variable on your projects, so keep only one

Capabilities

Capabilities and limits

What is read

Responses from your deployment while agents work on your projects
One short reply from the deployment when you select Test connection

What is produced

Agent runs on your projects that call your Azure deployment through Codex
A Reachable or Unreachable mark after Test connection

Where it can write

Nothing in your Azure subscription; only model requests are sent to your deployment.

How it connects

Your Azure OpenAI resource's OpenAI-compatible v1 endpoint with its API key; agents through the Codex adapter. A linked RunningOps organisation gets a copy of the key and endpoint.

Account and permissions

An Azure OpenAI resource with a model deployment, its endpoint and an API key
Customer admin rights in TestingOps, or a company admin of the TestingOps workspace managing keys for your organisation

Limits

Base URL is required; the Model field holds the deployment name, and there is no API-version field
Key-based access only: there is no Microsoft Entra ID sign-in option
The endpoint must be reachable from where TestingOps agents run
TestingOps' own AI features outside agent runs do not use an Azure key
Shares one slot and the key variable with OpenAI and the other OpenAI-compatible providers: keep one per organisation
Runs against a live Azure resource have not been verified end to end yet

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

An insurance company may send test data only to its own Azure OpenAI resource. Its platform team gives the QA lead the resource endpoint (https://<resource>.openai.azure.com/openai/v1), the name of the approved deployment and a key.

The customer admin enters them under Azure OpenAI, selects Test connection and moves Azure OpenAI to the top of Your providers. The team's agents now run through Codex against that deployment.

Frequently asked questions

What goes into Base URL?

Your resource's OpenAI-compatible endpoint with /openai/v1 at the end, for example https://<resource>.openai.azure.com/openai/v1. Saving is refused without it.

Where do we enter the deployment name?

In Model, exactly as the deployment is named in Azure. There is no separate deployment or API-version field.

Can we use Microsoft Entra ID instead of a key?

No. TestingOps asks for the resource's API key.

Can the endpoint be private?

TestingOps accepts private addresses, but the agents must be able to reach the endpoint from where they run. A private network connection for test runs is not confirmed to carry model traffic.

Do TestingOps' own AI features use our Azure deployment?

No. The Azure key is used for agent runs, the connection test and the copy on RunningOps; other AI features use other models.

Can agents look up Azure documentation while they work?

Yes, if you also connect the Microsoft Learn MCP tool under Integrations → API & MCP. That is a separate connection from the model provider.

Next step

Request a demo to see agents run against an Azure OpenAI deployment of your own.

Request a demo More ai models integrations