Credentials Vault
Store reusable authentication secrets encrypted at rest and reference them from webhooks instead of pasting raw Authorization headers.
Save authentication credentials once — Bearer token, Basic auth (username + password), API key in a custom header, or a raw custom Authorization value — and reference them from any webhook by name. Secrets are encrypted at rest with AES-256-GCM and are write-only over the API: they are never returned to any caller, only a masked hint (e.g. `Bearer ****1234`). The decrypted value is used only at dispatch time to build the outgoing header, and resolved auth headers are redacted in delivery logs.
Credential types
`bearer` → `Authorization: Bearer <secret>`. `basic` → `Authorization: Basic base64(user:pass)` (covers WordPress Application Passwords on a target site). `api_key` / `custom` → a named header such as `X-API-Key: <secret>`.
Safe for AI agents
A webhook references a credential via `auth_credential_id` (which takes precedence over the legacy plaintext `auth_header`). An `agent`-scope token can assign credentials to webhooks but can never read a secret value — so AI assistants can manage webhooks without ever seeing your PATs or passwords.
Encryption key
By default the encryption key is generated and stored in the database (zero-config, survives WordPress salt rotation). For stronger protection, define `FSWA_SECRET_KEY` in `wp-config.php` to move the key out of the database. Adding it never breaks existing credentials — a one-click in-app migration re-encrypts everything with the new key and then deletes the database copy.
REST access
Manage credentials via `/wp-json/fswa/v1/credentials` (list, create, update, delete — `full`/`agent` scope), with `GET /credentials/key-status` and `POST /credentials/reencrypt` for the encryption-key migration. Delete is blocked with 409 when a credential is in use unless `force=true` is passed.