What these are
A bot token is the credential the@traceten/ai-crawl middleware sends when it reports an AI crawler hit from your server. One token per deployment is the shape we expect.
They are a different credential family from your API keys. A tt_bot_ token authenticates crawl reports and nothing else. It cannot read your analytics and it cannot change your configuration.
config:write. Which of your deployments hold live crawl-write credentials, and which are dormant, is not an analytics read.
Revoking needs config:write. Minting needs credentials:write and ingest:write: it hands back a secret, and a key that cannot itself ingest must not be able to manufacture one that can.
Minting and revoking also require that the person behind your key is still an account-wide admin. See who is behind a key. Listing does not make that check, because it would put a call to your identity provider on a read path, but a Clerk session still has to be an account-wide admin to use it.
GET /v1/account/bot-tokens
site_id is optional and narrows the list to one site. A site_id you cannot reach returns an empty list rather than someone else’s tokens.
Metadata only. token_hash is never selected, and the plaintext does not exist anywhere to return.
POST /v1/account/bot-tokens
snippet_key into the middleware’s siteId, not id. The edge compares the value your middleware sends against the snippet key and rejects anything else:
DELETE /v1/account/bot-tokens/{tokenId}
How these are stored
Bot tokens are stored as a SHA-256 hash of the plaintext. API keys are stored with Argon2id. The difference is deliberate: a bot token is verified at the edge on the crawl ingestion path, where a memory-hard hash costs real CPU per request, and the token is 32 bytes of random data, so there is no low-entropy secret for that hash to protect. Either way, we never store the plaintext and cannot show it to you again.Errors
Next
- AI crawler tracking for the middleware itself
- AI crawlers API to read what the crawlers did

