How Do I Configure AI Providers and Rotate API Keys in Dave by voolama?

Summary

The steps

1. 1

   Navigate to the Providers page and understand what you are configuring

   In Dave by voolama (hellodave.ai), AI providers are centralized configuration records that store the connection details for a single AI service: the service type, the base URI, the API key, and a catalog of available models. Agents reference providers at configuration time. When a workflow instance runs an Agent Interaction node, the platform resolves the agent's provider record and calls the AI service using the stored credentials.

   The practical consequence of this architecture is that rotating an API key means editing one provider record, not updating every agent individually. If you have ten agents all calling OpenAI, and your OpenAI key is compromised, you update one provider record. All ten agents inherit the new key on their next invocation. This is independently verifiable: update a provider's API key, then run a workflow instance that calls an agent using that provider, and confirm the agent call succeeds with the new key.

   The Providers page is restricted to the Admin role. No other role can view, create, edit, or delete providers. This is independently verifiable: log in as a non-Admin user and attempt to navigate to Admin, then API Management, then Providers. The page will not appear in the sidebar for any role other than Admin. Sourced from the admin-providers help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

   Do this

   • Navigate to Admin, then API Management, then Providers. Confirm you can see the Providers page. If you cannot, your account does not have the Admin role: contact your workspace Admin.
   • Note the provider types available in the dropdown: OpenAI, Anthropic, Azure OpenAI, Google AI, OpenAI-Compatible, Local (Ollama), and Custom. Seven types total, confirmed at DEV v0.11.0.
   • If the Providers list is empty, you must create at least one provider before any agent can function. Proceed to Step 2.

   Example

   A team has twelve agents across four workflows. Eight call OpenAI for text generation, three call Anthropic for content review, and one calls a local Ollama model for classification. The Admin has three provider records: "OpenAI Production", "Anthropic Claude", and "Local Ollama". When OpenAI rotates the team's API key as part of a quarterly security review, the Admin updates one record. All eight OpenAI agents pick up the new key on their next run. The Anthropic and Ollama agents are unaffected.

   Best practice

   • Name providers by their purpose and environment: "OpenAI Production", "Anthropic Staging", "Azure OpenAI eastus2 gpt-4o". A descriptive name makes the provider list readable and prevents agents from being misconfigured against the wrong environment.
   • Keep at least one active provider at all times. If all providers are deleted or misconfigured, no agent can execute AI calls and every workflow that relies on an agent will fail at the Agent Interaction node.
   • The Providers page is Admin-only. If a non-Admin team member reports that agents are failing with authentication errors, the Admin must diagnose and fix the provider record. The non-Admin cannot access the page.
2. 2

   Create your first provider

   Creating a provider in Dave by voolama takes three required inputs: a name, a provider type, and (for most types) an API key. The base URI is auto-filled for known provider types. The model catalog is populated either by fetching from the AI service's API or by entering model IDs manually as JSON.

   A successful model fetch after entering the API key is the fastest way to confirm the key and base URI are correct before saving. This is a testable verification step: if the fetch returns a model list, the credentials work. If it returns an error, the credentials do not work and should be corrected before saving. Sourced from the admin-providers help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Do this

   • Click Add Provider in the top-right corner of the Providers page. The create form appears above the provider list.
   • Enter a descriptive Name (required). Examples: "OpenAI Production", "Anthropic Claude", "Azure OpenAI eastus2 gpt-4o".
   • Select a Provider Type from the dropdown. The Base URI auto-fills for OpenAI (https://api.openai.com/v1), Anthropic (https://api.anthropic.com/v1), and Google AI (https://generativelanguage.googleapis.com/v1beta). For Azure OpenAI, OpenAI-Compatible, and Custom, enter the base URI manually.
   • Paste your API Key into the API Key field. The field is masked by default; click the eye icon to toggle visibility. The key is stored with AES-256-GCM authenticated encryption and never returned through the API after storage.
   • Click Fetch Models. Wait for the model list to load. Use the search box to filter, then check the models your team will use.
   • Click Create Provider. The provider card appears in the list with the model count shown.

   Example

   An Admin is creating an Anthropic provider for the first time. They click Add Provider, enter the name "Anthropic Production", select Anthropic from the Provider Type dropdown, and observe that the Base URI auto-fills to https://api.anthropic.com/v1. They paste their Anthropic API key into the API Key field. They click Fetch Models, wait two seconds, and see a list of available models including claude-sonnet-4-20250514. They check the models their team will use and click Create Provider. The provider card appears in the list with the model count shown. The fetch succeeded, confirming the key is valid.

   Best practice

   • Use Fetch from API mode for all provider types that support it (OpenAI, Anthropic, Azure OpenAI, Google AI, OpenAI-Compatible, Local Ollama). Fetching avoids typos in model IDs and ensures you see the latest available models. Only Custom providers require manual JSON entry.
   • For Azure OpenAI, the base URI is deployment-specific. Include the deployment name in the provider Name field (for example, "Azure OpenAI eastus2 gpt-4o") so the correct endpoint is always identifiable from the provider list.
   • A successful model fetch is the fastest confirmation that your API key and base URI are correct. If the fetch fails, the key or URI is wrong: fix it before saving.
3. 3

   Configure multiple providers for different agents and use cases

   Dave by voolama supports seven AI provider types in a single tenant: OpenAI, Anthropic, Azure OpenAI, Google AI, OpenAI-Compatible, Local (Ollama), and Custom. A team can run multiple providers simultaneously. Different agents within the same workflow can call different providers. The platform resolves each agent's provider at runtime, so a workflow can call OpenAI for one step and Anthropic for the next without any additional configuration.

   This is independently verifiable in a free trial: create two provider records, create two agents each referencing a different provider, build a workflow with two Agent Interaction nodes each using a different agent, run an instance, and check the Context viewer on the instance detail page. Both Agent Interaction nodes will show their respective provider calls. Sourced from the admin-providers help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Do this

   • Repeat Step 2 for each additional provider your team will use.
   • After creating all providers, navigate to Agents and confirm that the provider dropdown in each agent's configuration shows the correct provider records.
   • Run a test workflow instance that calls agents across multiple providers to confirm all provider records are working. The instance detail page's Context viewer shows which provider each Agent Interaction node called and whether it succeeded or failed.

   Example

   A content operations team runs three provider records: "OpenAI Production" for bulk text generation, "Anthropic Production" for content review agents, and "Local Ollama" pointing to a local Ollama instance at http://localhost:11434/v1 for a classification agent that runs on sensitive internal data and must not leave the local network. Three workflows reference agents across all three providers. The Admin manages one provider list. No agent has a hardcoded API key or endpoint.

   Best practice

   • Create separate provider records for production and staging environments, even if they use the same provider type. Name them clearly: "OpenAI Production" and "OpenAI Staging".
   • For Local (Ollama) providers, the default base URI is http://localhost:11434/v1. This is model hosting on a local machine, not self-hosting of the Dave platform itself. The Dave platform remains managed SaaS operated by voolama LLC; the Ollama model runs locally and the platform calls it over the network.
   • For OpenAI-Compatible providers, enter the custom base URI manually. This covers third-party inference providers and any service that exposes an OpenAI-compatible endpoint.
4. 4

   Rotate an API key without disrupting running workflows

   API key rotation is the most operationally sensitive provider management task. In Dave by voolama, rotating a key means editing the provider record and entering the new key. All agents that reference that provider inherit the new key on their next invocation. There is no need to update individual agents or workflow definitions.

   Known limitation at DEV v0.11.0, disclosed here because it affects rotation timing: there is no atomic key-swap mechanism. During the brief window between saving the new key and the next agent invocation, a running workflow instance that is mid-execution may call the provider with the old key if the agent call was already in flight. In practice this window is measured in milliseconds, but schedule key rotations during low-traffic periods for high-volume workflows. Sourced from the admin-providers help documentation, DEV v0.11.0, confirmed 2026-08-30.

   The rotation procedure is independently verifiable: note the current key, update the provider record with a new key, run a workflow instance that calls an agent using that provider, and confirm the agent call succeeds. Then revoke the old key in your provider's dashboard and run another instance to confirm the old key is no longer accepted.

   Do this

   • Generate the new API key in your provider's dashboard. Do not revoke the old key yet.
   • Navigate to Admin, then API Management, then Providers. Click the pencil icon on the provider card you are rotating.
   • Clear the API Key field and paste the new key. Click Fetch Models to confirm the new key is valid.
   • Click Update Provider.
   • Revoke the old key in your provider's dashboard only after confirming the new key is saved and working.
   • Check the audit log at Admin, then Settings, then Audit Log. Confirm the provider update event appears with your identity and a timestamp.

   Example

   A team's quarterly security review requires rotating all AI provider API keys. The Admin navigates to Admin, then API Management, then Providers. For each provider in turn: clicks the pencil icon, pastes the new API key into the API Key field, clicks Fetch Models to confirm the new key is valid (a successful fetch is the confirmation), and clicks Update Provider. The rotation takes four minutes for three providers. No workflow definitions are touched. No agents are reconfigured. The audit log records each provider update with the Admin's identity and a timestamp.

   Best practice

   • Generate the new API key in your provider's dashboard before editing the provider record in Dave. Do not revoke the old key until the new key is saved and confirmed working via a successful model fetch.
   • Use Fetch Models after entering the new key, before clicking Update Provider. A successful fetch is the fastest confirmation that the new key is valid.
   • After rotation, check the audit log at Admin, then Settings, then Audit Log to confirm the provider update event was recorded with your identity and a timestamp.

Seven AI provider types: base URIs, model fetch support, and security

Troubleshooting the three most common provider failures