AI provider API keys are stored encrypted in WordPress and never returned in plaintext. Maxi AI Core masks all keys in responses, tracks when they were last used and rotated, and validates new keys with a live test call before replacing an existing one. This page covers how to set keys, check their status, rotate them safely, and configure which provider handles each type of AI task.Documentation Index
Fetch the complete documentation index at: https://docs.maxicore.ai/llms.txt
Use this file to discover all available pages before exploring further.
Encryption protects keys against database-only compromise — for example, a leaked database backup or SQL injection. It does not protect keys if an attacker also has filesystem access to
wp-config.php.Setting API keys
Usemaxi/update-ai-settings to set one or more provider API keys. The ability merges your input with existing settings, so you only need to include the keys you want to change.
| Field | Provider |
|---|---|
openai_api_key | OpenAI |
anthropic_api_key | Anthropic / Claude |
openrouter_api_key | OpenRouter |
replicate_api_key | Replicate |
bfl_api_key | Black Forest Labs (BFL) |
key. The response masks the key as first8...last4 — you will never see the full value again after setting it.
Viewing key status
Callmaxi/list-provider-keys to see the current state of all configured credentials. Raw keys are never returned — only masked prefixes and status metadata.
Each key entry includes:
- Masked prefix — the first 8 and last 4 characters, for identification
last_rotated_at— when the key was last changedlast_used_at— when a successful API call last used the keyage_days— how old the current key isstale—truewhen the key is older than 180 days
stale flag as a prompt to rotate. Keys that have not been used recently are worth reviewing too.
Rotating keys
Usemaxi/rotate-provider-key to replace a provider API key. The ability validates the new key with a live test call before overwriting the old one. If validation fails, the old key stays in place and the failure is recorded in the audit log — you are never left with an untested key protecting a live provider connection.
provider values: openai, anthropic, openrouter, replicate, bfl.
On a successful rotation, a rotated event is written to the audit log. On failure, a validation_failed event is written with the provider name, and the original key remains active.
Per-capability provider configuration
You can configure which provider handles each type of AI task independently. This lets you use, for example, Anthropic for text generation while using OpenAI for image editing. Set these fields viamaxi/update-ai-settings:
| Field | Controls |
|---|---|
provider_text | Text generation (maxi/generate-text-ai) |
provider_image | Image generation (maxi/generate-image-ai) |
provider_edit_image | Image editing (maxi/edit-image-ai) |
provider_vision | Vision / image analysis |
OpenRouter is explicit-only — it is never added to automatic fallback chains. Specify
"provider": "openrouter" directly when calling generation abilities if you want to route through it.Auditing credential activity
All credential-related events are recorded in the audit log under categorykey. Query them with maxi/get-audit-events:
rotated— a key was successfully rotated, with provider infovalidation_failed— a rotation attempt failed validation, with provider info
maxi/update-ai-settings are also logged under category key.