Authentication and API keys

Create a key

In CommentGate, open Settings, then API keys, and choose Create key. Name it after where it will be used ("Zapier", "Store sync") so you can tell keys apart later. The full key is shown once; CommentGate keeps only a SHA-256 hash of it.

Keys start with cg_live_. The first few characters (the prefix) stay visible in Settings and in GET /me, so you can match a key to its name.

Send the key

Send it in the Authorization header as a Bearer token:

curl https://commentgate.com/api/v1/me \
  -H "Authorization: Bearer cg_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"

A request without a key, or with an unknown or revoked one, gets 401 unauthorized with a WWW-Authenticate: Bearer header.

Keep keys on your server. Never put one in a browser, a mobile app or a public repository: anyone holding it can read and act on every comment in the workspace.

What a key can see and do

• A key sees every connected account in its workspace.
• Writes run as the person who created the key, with their current role. Hiding, replying and answering Needs you need a role that can moderate (owner, admin, manager or moderator). Changing guidance and protections needs an owner, admin or manager.
• If that person leaves the workspace or loses the role, those writes answer 403 forbidden; reads keep working. GET /me says so in can_act, so an integration can warn before it fails.
• Every write shows in the comment's history and the audit log under the key's creator, exactly like the same action in the app.

Revoke a key

Revoke a key in Settings, then API keys. It stops working at once, and every REST hook it created is removed with it, so a revoked key never keeps data flowing.

The "last used" time next to each key is updated at most once every 10 minutes.

OAuth for AI assistants

The MCP server also accepts OAuth access tokens, so assistants can sign people in without a key. That flow is described on MCP server. The REST API itself takes API keys only.