Guide
Authentication
One API key for both MCP and REST. It is a bearer token, so treat it like a password.
#Getting a key
Sign in and open trypitch.co/api-keys. Press Create key, give it a name, and copy the value. Keys look like pk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
We store a SHA-256 hash of the key and the first 12 characters, nothing else. That prefix is what you see in the list, so you can tell keys apart without us keeping the secret.
#Sending it
Use a bearer token. This is the form to prefer everywhere.
Authorization: Bearer pk_your_keySome MCP clients only let you set a plain header with a plain value. For those, this also works:
X-API-Key: pk_your_keyThe two are equivalent. If both are present, Authorization wins.
#What a key can do
A key acts as the user who created it. There are no scopes and no per-key limits yet. Anything that user can do in the app, the key can do through the API, and every credit it spends lands in that user’s ledger next to their browser usage. Projects created with a key appear in that user’s app, and vice versa.
#Revoking
Press Revoke on the keys page. It takes effect on the next request. Revoked keys stay in the list so you can see what was in use and when it was last used.
Projects already working under a revoked key keep working. Revoking stops new requests, it does not cancel work in flight.
#Keeping keys safe
- Put keys in environment variables, never in source control.
- Never ship a key to a browser or a mobile app. Anyone can read it there. Call Pitch from your server.
- Use one key per system, so you can revoke one without breaking the rest.
- Rotate by making the new key first, switching over, then revoking the old one.
#When auth fails
A missing, unknown, or revoked key returns 401 on both surfaces.
{ "error": { "code": "unauthorized", "message": "Invalid or revoked API key" } }There is no way to tell those three cases apart from the response, on purpose. Check for a typo, a stray newline from a copy and paste, and whether the key is still active on the keys page.