# How to Integrate Azure OpenAI with gpt_academic: Complete Configuration Guide

> Integrate Azure OpenAI with gpt_academic using single model or dynamic multi-model deployment. Follow our configuration guide for enterprise AI without source code changes.

- Repository: [binary-husky/gpt_academic](https://github.com/binary-husky/gpt_academic)
- Tags: how-to-guide
- Published: 2026-03-02

---

**gpt_academic supports Azure OpenAI through two configuration modes—single-model setup using `AZURE_ENDPOINT` and `AZURE_API_KEY` in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py), or dynamic multi-model deployment via the `AZURE_CFG_ARRAY` dictionary—enabling enterprise-grade AI without modifying source code.**

The **gpt_academic** project provides native support for Microsoft Azure OpenAI Service, allowing researchers and developers to leverage enterprise-grade GPT deployments within the same interface used for standard OpenAI models. Integrating Azure OpenAI with gpt_academic requires only configuration changes in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py), with runtime model discovery handled automatically by the bridge layer in [`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py).

## Configuration Modes for Azure OpenAI

gpt_academic offers two distinct approaches for Azure OpenAI integration, depending on whether you manage a single deployment or multiple regional endpoints.

### Single-Model Configuration (Legacy Mode)

Use this approach when you have only one Azure deployment and want a quick setup. In [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py), set the following three variables:

- **`AZURE_ENDPOINT`**: Your Azure OpenAI resource URL (e.g., `https://myresource.openai.azure.com/`)
- **`AZURE_API_KEY`**: Your Azure OpenAI API key
- **`AZURE_ENGINE`**: The deployment name you specified in Azure AI Studio (e.g., `gpt-35-turbo-deployment`)

These parameters are defined in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py) at lines 25-29. After configuration, the model names `azure-gpt-3.5` or `azure-gpt-4` (depending on your deployment) automatically appear in the UI dropdown, provided they exist in `AVAIL_LLM_MODELS`.

### Dynamic Multi-Model Configuration

For organizations running multiple Azure deployments—such as separate GPT-3.5 and GPT-4 instances across different regions—use the **`AZURE_CFG_ARRAY`** dictionary in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py) (lines 31-33). This configuration allows runtime switching between endpoints without restarting the application.

Each entry in `AZURE_CFG_ARRAY` specifies its own endpoint, engine, API key, and optional `max_token` limit. During startup, [`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py) iterates over this dictionary (lines 77-99), constructs model entries (e.g., `azure-gpt-3.5`, `azure-gpt-4`), and injects them into `AVAIL_LLM_MODELS` (lines 98-99) for immediate UI availability.

## How the Azure Integration Works Internally

Understanding the data flow helps troubleshoot configuration issues and enables custom plugin development.

### Configuration Loading

The **[`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py)** file serves as the central registry for Azure credentials. Whether using single-model variables or the multi-model array, this file stores raw connection data without business logic.

### Runtime Model Registration

In **[`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py)**, the integration logic processes Azure configurations during module initialization:

1. If `AZURE_CFG_ARRAY` is populated, the script iterates through each key-value pair
2. For each entry, it constructs an Azure-specific endpoint URL and injects the corresponding `azure_api_key` into the `model_info` registry
3. Generated model names (prefixed with `azure-`) are appended to `AVAIL_LLM_MODELS`, making them selectable in the Gradio interface

### Request Routing

When a user selects an Azure model from the dropdown, the UI passes the model name to generic functions like `predict()` or `predict_no_ui_long_connection()`. These functions look up the correct endpoint and API key from the populated `model_info` dictionary, then route the request to Azure's `chat/completions` endpoint using the same HTTP client infrastructure employed for standard OpenAI requests.

## Step-by-Step Configuration Examples

### Configuring a Single Azure Deployment

Add your Azure credentials to [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py):

```python

# config.py - Single Azure deployment configuration

AZURE_ENDPOINT = "https://myresource.openai.azure.com/"
AZURE_API_KEY = "YOUR_AZURE_OPENAI_KEY"
AZURE_ENGINE = "gpt-35-turbo-deployment"  # Your custom deployment name

```

After restarting gpt_academic, select **azure-gpt-3.5** from the model dropdown. The system routes all requests to your specified Azure endpoint using the provided engine deployment.

### Configuring Multiple Azure Deployments

Define separate configurations for each deployment using `AZURE_CFG_ARRAY`:

```python

# config.py - Multiple Azure deployments

AZURE_CFG_ARRAY = {
    "azure-gpt-3.5": {
        "AZURE_ENDPOINT": "https://myresource1.openai.azure.com/",
        "AZURE_ENGINE": "gpt-35-turbo-deployment",
        "AZURE_API_KEY": "KEY_FOR_RESOURCE1",
        "AZURE_MODEL_MAX_TOKEN": 16384,
    },
    "azure-gpt-4": {
        "AZURE_ENDPOINT": "https://myresource2.openai.azure.com/",
        "AZURE_ENGINE": "gpt-4-deployment",
        "AZURE_API_KEY": "KEY_FOR_RESOURCE2",
        "AZURE_MODEL_MAX_TOKEN": 32768,
    },
}

```

This configuration creates two distinct model entries. The [`bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/bridge_all.py) module automatically registers both models, allowing you to switch between GPT-3.5 and GPT-4 deployments—or between different Azure regions—directly from the UI.

### Programmatic Access in Custom Plugins

To call Azure OpenAI from within a custom plugin or script:

```python
from shared_utils.config_loader import get_conf
from request_llms.bridge_all import predict

# Configure LLM parameters

llm_kwargs = {
    "llm_model": "azure-gpt-4",  # Must match key in AZURE_CFG_ARRAY

    "temperature": 0.7,
    "max_tokens": 1024,
}

inputs = "Explain quantum entanglement in simple terms."

# Execute prediction through the bridge layer

response = predict(inputs, llm_kwargs, {}, None)
print(response)

```

The `predict` function handles Azure authentication transparently by retrieving the endpoint and API key from the `model_info` registry populated during startup.

## Key Files in the Azure Integration

- **[`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py)**: Central configuration hub containing `AZURE_ENDPOINT`, `AZURE_API_KEY`, `AZURE_ENGINE`, and `AZURE_CFG_ARRAY` definitions
- **[`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py)**: Runtime model registry that translates Azure configurations into usable model entries and populates `AVAIL_LLM_MODELS`
- **[`docs/use_azure.md`](https://github.com/binary-husky/gpt_academic/blob/main/docs/use_azure.md)**: Official documentation providing additional context for Azure-specific deployment scenarios
- **[`toolbox.py`](https://github.com/binary-husky/gpt_academic/blob/main/toolbox.py)**: Provides runtime configuration editing capabilities through the UI, reading the same Azure configuration structures

## Summary

- **gpt_academic** supports Azure OpenAI through configuration-only changes in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py), requiring no source code modifications
- **Single-model mode** uses `AZURE_ENDPOINT`, `AZURE_API_KEY`, and `AZURE_ENGINE` for simple, single-deployment scenarios
- **Multi-model mode** uses `AZURE_CFG_ARRAY` to define multiple Azure deployments with distinct endpoints, keys, and token limits
- **[`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py)** automatically registers Azure models by injecting them into `model_info` and `AVAIL_LLM_MODELS` during startup
- The generic `predict()` function routes requests to Azure's `chat/completions` endpoint using the same infrastructure as standard OpenAI calls

## Frequently Asked Questions

### What is the difference between single-model and multi-model Azure configuration?

Single-model configuration uses three global variables (`AZURE_ENDPOINT`, `AZURE_API_KEY`, `AZURE_ENGINE`) to define one Azure deployment, suitable for simple setups. Multi-model configuration uses the `AZURE_CFG_ARRAY` dictionary to define multiple deployments with individual credentials and endpoints, enabling runtime switching between different Azure resources or model versions.

### Do I need to modify gpt_academic source code to add Azure OpenAI support?

No. Azure OpenAI integration is entirely configuration-driven. By setting the appropriate variables in [`config.py`](https://github.com/binary-husky/gpt_academic/blob/main/config.py), the [`bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/bridge_all.py) module automatically handles model registration and request routing. No changes to Python source files are required for standard integration.

### How does the gpt_academic UI populate the Azure model dropdown?

During startup, [`request_llms/bridge_all.py`](https://github.com/binary-husky/gpt_academic/blob/main/request_llms/bridge_all.py) (lines 77-99) processes `AZURE_CFG_ARRAY` or single-model variables, constructs model descriptors with Azure-specific endpoints, and appends the generated model names (e.g., `azure-gpt-3.5`, `azure-gpt-4`) to the `AVAIL_LLM_MODELS` list (lines 98-99). The Gradio interface reads this list to populate the model selection dropdown.

### Can I use different API keys for different Azure regions?

Yes. When using `AZURE_CFG_ARRAY`, each dictionary entry contains its own `AZURE_API_KEY` field. This allows you to configure separate API keys for different Azure OpenAI resources deployed in various regions, with gpt_academic routing requests to the appropriate endpoint based on the selected model name.