# How to Configure Multiple Provider API Keys in the aisuite Client

> Effortlessly configure multiple provider API keys in the aisuite Client. Learn how to map provider names to API keys for seamless service initialization.

- Repository: [Andrew Ng/aisuite](https://github.com/andrewyng/aisuite)
- Tags: how-to-guide
- Published: 2026-06-15

---

**The aisuite `Client` accepts a dictionary of provider configurations via the `provider_configs` parameter, mapping provider names like `"openai"` or `"anthropic"` to sub-dictionaries containing `api_key` values that the `ProviderFactory` uses to lazily initialize each service.**

The aisuite library by Andrew Ng provides a unified interface for multiple LLM providers. When working with diverse AI services, you need to configure multiple provider API keys in the aisuite Client to authenticate across OpenAI, Anthropic, Google, and other platforms simultaneously without hardcoding sensitive data in your source files.

## Understanding the provider_configs Architecture

According to the andrewyng/aisuite source code, the `Client` class in [`aisuite/client.py`](https://github.com/andrewyng/aisuite/blob/main/aisuite/client.py) (lines 23-40) defines a `provider_configs` parameter that expects a nested dictionary structure. The constructor stores this mapping in `self.provider_configs`, and the `_initialize_providers` method (lines 58-65) iterates over these entries to create provider instances via `ProviderFactory.create_provider`.

Each top-level key represents a provider identifier string (e.g., `"openai"`, `"anthropic"`, `"aws-bedrock"`), while the value is a dictionary containing authentication credentials and provider-specific options. The `ProviderFactory` in [`aisuite/provider.py`](https://github.com/andrewyng/aisuite/blob/main/aisuite/provider.py) extracts the `api_key` (or service-specific alternatives like `aws_access_key`) from these sub-dictionaries and passes them to the underlying SDK clients.

## Initializing the Client with Multiple API Keys

Pass your credentials during instantiation by providing the complete `provider_configs` dictionary:

```python
from aisuite import Client

client = Client(
    provider_configs={
        "openai": {"api_key": "sk-openai-123"},
        "anthropic": {"api_key": "sk-anthropic-456"},
        "google": {"api_key": "AIza-google-789"},
        "aws-bedrock": {
            "aws_access_key": "AKIA…",
            "aws_secret_key": "wJalrXUtnF…",
            "aws_region": "us-west-2",
        },
    },
    extra_param_mode="warn",
)

```

This configuration allows you to route requests to any specified provider using the `provider:model` syntax:

```python
response = client.chat.completions.create(
    model="openai:gpt-4o-mini",
    messages=[{"role": "user", "content": "Explain quantum tunneling"}],
)

```

## Dynamically Updating API Keys with configure()

You can add new providers or rotate existing keys after instantiation using the `configure()` method implemented in [`aisuite/client.py`](https://github.com/andrewyng/aisuite/blob/main/aisuite/client.py) (lines 80-88). This method merges new configurations into the existing `provider_configs` mapping.

```python
client.configure({
    "mistral": {"api_key": "sk-mistral-abc"},
    "openai": {"api_key": "sk-openai-new-key"},  # Overwrites existing

})

# Immediately use the new configuration

response = client.chat.completions.create(
    model="mistral:mistral-large",
    messages=[{"role": "user", "content": "Summarize the latest news"}],
)

```

Subsequent calls automatically utilize the updated credentials without requiring a new `Client` instance.

## Security Best Practices for API Key Management

Never hardcode sensitive credentials in source files. Instead, inject API keys at runtime using environment variables:

```python
import os

client = Client(
    provider_configs={
        "openai": {"api_key": os.getenv("OPENAI_API_KEY")},
        "anthropic": {"api_key": os.getenv("ANTHROPIC_API_KEY")},
    }
)

```

This approach keeps secrets out of version control while maintaining the flexibility to configure multiple provider API keys in the aisuite Client across different deployment environments.

## Summary

- The `Client` constructor accepts a `provider_configs` dictionary mapping provider names to credential dictionaries.
- Each provider entry must include an `api_key` or service-specific authentication fields like `aws_access_key`.
- The `ProviderFactory` in [`aisuite/provider.py`](https://github.com/andrewyng/aisuite/blob/main/aisuite/provider.py) lazily initializes providers by reading credentials from this configuration.
- Use the `configure()` method to add or update provider API keys after initialization.
- Always load sensitive keys from environment variables rather than committing them to source code.

## Frequently Asked Questions

### How do I add a new provider API key after creating the Client?

Call the `configure()` method with a dictionary containing the new provider configuration. As implemented in [`aisuite/client.py`](https://github.com/andrewyng/aisuite/blob/main/aisuite/client.py) (lines 80-88), this method updates the internal `provider_configs` mapping and makes the new credentials available for subsequent chat completion requests without restarting your application.

### Can I configure providers that use different authentication schemes?

Yes. While OpenAI and Anthropic use `api_key`, other providers accept provider-specific fields. For example, AWS Bedrock requires `aws_access_key`, `aws_secret_key`, and `aws_region`. The `ProviderFactory` passes these values directly to the underlying provider implementation.

### Where does aisuite store my API keys internally?

The `Client` stores the configuration dictionary in `self.provider_configs`. The actual provider objects are created lazily through `ProviderFactory.create_provider`, which extracts the credentials and instantiates the underlying SDK clients. The raw keys remain accessible only within your application instance.

### Is it safe to commit provider_configs containing API keys to version control?

No. The aisuite source code intentionally never hardcodes credentials, and you should follow the same practice. Always inject API keys via environment variables or secure secret management systems. This prevents accidental exposure of sensitive tokens in repository history.