What are adapters

An adapter is a service that implements a DIAL model: it translates Unified API requests into a provider's native API, and the response back. The word describes what a service does, not who built it: DIAL ships its official adapters in one service, DIAL Model Provider, and anything you write that sits behind a model deployment is an adapter too.

So Azure OpenAI, AWS Bedrock, Google Vertex AI and the rest reach your application through one interface, with no provider-specific code.

Why adapters exist

Enterprise deployments typically consume models from multiple providers. Each provider exposes a different API: different authentication, different request formats, different streaming protocols. Without a normalization layer, every client application must handle each provider individually. Changes to a provider's API ripple through every consumer.

Adapters eliminate this coupling. They sit between DIAL Core and the provider, translating requests and responses in both directions. Applications, interceptors, and DIAL Chat interact with all models identically through the Unified API, regardless of which provider serves the model.

How adapters work

When a client sends a chat completion request to DIAL Core, Core looks up the target model's deployment in config.json and forwards the request to the adapter endpoint configured for that model. The adapter translates the request into the provider's native format, sends it upstream, then translates the response back into the Unified API format before returning it to Core.

Request:   Client → DIAL Core → Adapter → Provider API
Response:  Provider API → Adapter → DIAL Core → Client

The official adapters run together in DIAL Model Provider, each under its own /compat/<adapter> path; a custom adapter runs in its own container. A single adapter can serve multiple models from the same provider. Adapters support streaming, embeddings, and all Unified API features that the underlying provider supports.

If the model declares upstreams, DIAL Core also chooses one of them per request and passes it to the adapter in the X-UPSTREAM-ENDPOINT and X-UPSTREAM-KEY headers. Load balancing and per-upstream credentials are therefore Core's job, not the adapter's — the adapter follows the upstream it is handed. Tutorial: custom adapter builds one that does exactly this.

Adapters, models, and applications

These three are easy to confuse, because an adapter and an application are built the same way and differ only in what they are registered as.

• A model is a deployment declared under models in DIAL Core configuration. Only models carry per-token pricing, and only models can declare upstreams — so DIAL Core load-balances across several provider endpoints and authenticates to each one separately.
• An adapter is the service behind that model deployment's endpoint. The model entry is the declaration; the adapter is the thing that answers.
• An application is a deployment declared under applications, implementing business logic of your own. Applications have no pricing and no upstreams; they typically call models rather than providers.

So "adapter" and "application" are two roles for the same kind of service, and the choice shows up in configuration:

	Adapter	Application
Declared under	models	applications
Purpose	Make an external provider callable as a DIAL model	Implement business logic
Per-token pricing	Yes	No
upstreams — load balancing and per-upstream auth	Yes	No
Typically calls	A provider API	Other DIAL models
SDK	DIAL SDK (aidial-sdk)	DIAL SDK (aidial-sdk)

Both subclass ChatCompletion, both register with DIALApp, and both expose Unified API endpoints, so building a custom adapter takes the same skills as building a Custom App. The DIAL SDK reference covers the API surface for both.

Official adapters

DIAL ships its official adapters in DIAL Model Provider, one service that covers the major AI model providers:

Adapter	Providers	Path in DIAL Model Provider
OpenAI Adapter	Azure OpenAI, OpenAI, Mistral, Databricks, vLLM, Ollama, and other OpenAI-compatible APIs	/compat/openai
Bedrock Adapter	AWS Bedrock (Anthropic Claude, Amazon Titan, Meta Llama, Stability AI, Cohere, AI21, DeepSeek)	/compat/bedrock
Vertex AI Adapter	Google Vertex AI (Gemini, Imagen, Veo, Anthropic Claude and Mistral on Vertex)	/compat/vertexai

The same three adapters also ship as standalone services, which will be deprecated. For the full model compatibility table, see Supported providers.

Building a custom adapter

Build a custom adapter when you need to integrate a provider that the official adapters do not cover — for example, a proprietary model behind a non-standard API, or a fine-tuned model hosted on internal infrastructure.

A custom adapter is a Python application that subclasses ChatCompletion from the DIAL SDK, translates requests to the target API format, and translates responses back. The Tutorial: custom adapter walks through the process end to end.

Configuration

Deploying an adapter in DIAL requires two pieces of configuration:

1. Adapter container environment variables — credentials, connection settings, and feature flags for the adapter itself. For the official adapters, these are set on DIAL Model Provider; see DIAL Model Provider configuration.

2. Model routing in DIAL Core — each model deployment in config.json specifies the adapter endpoint and upstream settings. See the config.json models reference for the schema.