Credentials
The three public-API credential types — api-key, webhook-bearer, webhook-header — and how each maps to allowed HTTP header methods.
A credential is the secret that authenticates you to the public API. PrivacyFlow issues three credential types. They all unlock the same endpoint surface — the only thing that differs is which HTTP headers you are allowed to send. The type is set in the dashboard when the credential is created; it cannot be changed without re-issuing.
The three types
| Credential type | Allowed header(s) | Use case |
|---|---|---|
api-key | Authorization: Bearer <key> or X-API-Key: <key> | General automation. The default; pick this unless you have a reason not to. |
webhook-bearer | Authorization: Bearer <key> only | Webhook receivers that speak Bearer natively. Can still poll and send over Bearer. |
webhook-header | X-Webhook-Token: <key> only | Webhook receivers that prefer a dedicated header. Cannot use Bearer. |
Note
A credential with no type recorded — for example, keys created before the type field existed — is treated as api-key for backwards compatibility. The dashboard displays the type as a colored badge so you can tell at a glance.
How the API chooses a header
On every authenticated request the API checks headers in this priority order: Authorization → X-API-Key → X-Webhook-Token. The first one present wins. If the credential type doesn’t permit that header, you get 401 with "Authentication method not allowed for this credential type". See Authentication for the full matrix and curl examples.
Lifecycle
Creation
Credentials are issued from the dashboard’s Credentials section via a 3-step wizard. The wizard asks for the auth type, the secret details, and shows you the final secret string once — copy it then, because the dashboard does not let you retrieve it later. The dashboard stores the credentialId, the appIds it covers, and (in the case of webhook types) the webhook URL and auth config. See Credentials in the dashboard.
Rotation
The dashboard lets you replace a credential. The new key string is fresh; the credentialId stays the same. Rate limits and any configured webhook auth keep working — only the key string changes. This is operationally important: rotation is a security hygiene step, not a quota reset.
Deletion
Deleting a credential frees the credentialId immediately. Any client still holding the key string gets 403 (poll/send) or 401 (verify) on the next request. There is no grace period — coordinate deletion with key rotation in your downstream integrations.
App-scoping
Every credential carries an appIds[] list set in the dashboard:
- Poll: the API round-robins across every appId in the list. You can’t opt to poll one.
- Send: each message’s
appIdmust be in the list, or it lands infailedMessageswith"AppId not associated with this API key". - Verify: the response returns the full
appIds[].
Tip
Issue one credential per integration. If your n8n node and MCP server share a credential, a leak in one compromises the other. Separate keys also isolate rate budgets cleanly.
Mapping to dashboard config
| Dashboard action | Credential section | Creates |
|---|---|---|
| New API key | Credentials → New → api-key | A pf_live_… string usable with Authorization: Bearer or X-API-Key. |
| Webhook via Bearer | Apps → Webhook Auth Wizard → Bearer | A webhook-bearer credential and the app’s delivery setting pointing at your URL. |
| Webhook via custom header | Apps → Webhook Auth Wizard → Header | A webhook-header credential and the app’s delivery setting. See webhook auth. |
The public API is agnostic to whether a credential is “for” webhook delivery or not — the type only controls the allowed header. A webhook-bearer credential can poll and send from a script; it cannot use X-API-Key.