API keys
Create and scope the API keys that authenticate the v1 API, the MCP server, and crawler ingest, shown in plaintext exactly once at creation.
API keys authenticate programmatic access to your workspace: the v1 REST API, the MCP server, and crawler event ingest. You create and manage them under Settings.
What it does
A key ties a request to your workspace and to a scope that decides what the request may do. Keys are created, listed, and revoked from the settings area; each one carries a name so you can tell them apart later.
How to use it
Create a key, give it a name (what will use it), and copy the value shown. Every request then sends it as a bearer token.
Keys are prefixed mf_, and every request passes the key in an Authorization: Bearer <key> header — see Authentication for the full auth model.
Authorization: Bearer mf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
A key's plaintext value is shown exactly once, at creation. Only a hash is stored afterward, so MentionFlow cannot show it to you again. Copy it into your integration or secret store immediately; if you lose it, revoke the key and create a new one.
Scopes
| Scope | What it can do |
|---|---|
full | Reads the v1 API and the MCP server. This is the default scope. |
ingest | Can only POST crawler events to /api/v1/crawler-events. It cannot read any workspace data. |
Use an ingest key wherever a key has to live somewhere exposed — a customer's Cloudflare Worker, for example. A key exfiltrated from there can submit crawler events and nothing else; it cannot read your data.
How it's computed / enforced
Only owners and admins can create or revoke keys, the same guard used for member management. On creation, MentionFlow generates the key, records only its SHA-256 hash and a short prefix, and returns the plaintext once.
Creating a key also requires a verified email address for accounts created on or after 2026-07-11 — a key reads workspace data, so minting one is one of the egress-gated actions. Revoking a key is never gated. Accounts created before that date are grandfathered and unaffected.
Read access fails closed. The single read guard that fronts the v1 resource reads and the MCP server accepts only an explicit full workspace key. An ingest key is refused with a 403, and a key whose stored scope the current build does not recognize never authenticates at all. Ingest itself accepts both scopes, but only for posting crawler events. A workspace key can only ever see its own workspace's brands, so a key can never read across tenants.
Revoking a key does not delete its record. The row is retained — name, prefix, and last-used time — so the audit trail stays intact; the key simply stops authenticating.
Limits
- Up to 10 active keys per workspace. Revoke one to make room.
- Creating and revoking keys is owner/admin only.
- Creating a key requires a verified email (accounts created on or after 2026-07-11).
ingestkeys cannot read any workspace data.
Related
- Authentication — the full bearer-token auth model.
- Password and email verification — the verification gate on key creation.
- Crawler ingest — how an ingest-scoped key posts crawler events.
- Crawlers — what the ingested crawler data feeds.