An AI provider record in Maverick is more than an API key. It defines how Maverick communicates with the AI service, what credentials it uses, and who has access to it. Getting these seven fields right means a working integration; getting one wrong means errors that are easy to misdiagnose.
1. Provider Type
The provider type tells Maverick which API format to use — OpenAI, Anthropic, Google, Azure OpenAI, or a generic OpenAI-compatible option for self-hosted models. Select the correct type or Maverick will send malformed requests. An incorrect type typically produces authentication errors that look identical to a bad API key, making it one of the most common setup mistakes to overlook.
2. API Key
The API key is the credential that authenticates every request Maverick sends to the provider. Paste it exactly as the provider issued it — no spaces, no line breaks, no extra characters. Maverick stores it encrypted; you cannot retrieve it after saving, so keep a copy in a secure password manager before you close the provider record for the first time.
3. API Secret
Some providers require a secondary credential alongside the API key — the API secret. Most major providers (OpenAI, Anthropic) do not use this field. If your provider requires it, the provider's documentation will specify where to find it in your account settings. Leave this blank if your provider doesn't use it — entering an incorrect value where none is needed can cause authentication failures.
4. Base URL
The base URL is the endpoint Maverick sends API requests to. For standard cloud providers this is pre-filled and correct. For Azure OpenAI or self-hosted models (Ollama, LocalAI), you must enter your custom deployment URL. An incorrect base URL produces connection errors that look identical to authentication failures — always verify the URL from your deployment configuration before assuming the key is wrong.
5. API Version
Azure OpenAI deployments require a specific API version string (e.g., "2024-02-01"). Other providers ignore this field. If you're using Azure, check your deployment configuration for the exact version string your deployment supports — older strings may trigger deprecation warnings or errors. If you're not on Azure, leave this field blank.
6. Active Flag
The active flag enables or disables the provider without deleting it. Set a provider to inactive when you want to temporarily block access — during a billing dispute, a key rotation, or a security review — without losing the configuration. Inactive providers cannot be selected in resource or model records, so deactivating one immediately prevents new usage without affecting existing records.
7. Folder
Providers can be organized into folders in the Maverick interface. Use folders to group providers by type (cloud versus local), by department (Engineering, Finance, HR), or by environment (Production, Testing). Folder organization matters most when you manage a large number of providers — without it, the provider list becomes difficult to navigate and prone to duplicate entries.