# Keys and permissions

Give each integration the access it needs, with a key you can expire or revoke.

Stage: sandbox beta. Live purchasing requires explicit activation.

## Projects, applications and keys

Projects belong to your organization. An application belongs to a project and has a fixed sandbox or live environment. Keys belong to that application. Orders, files, quotes, events and usage are isolated by application.

Send Authorization: Bearer YOUR_KEY with every REST or MCP request. Secret values appear once on creation; stored credentials contain a digest and a display prefix. The console shows permissions, expiry, last use and revocation status.

## Choose a scope

catalog:read discovers products and capabilities. files:write registers and preflights sandbox files. quotes:write creates and reads quotes. orders:write creates orders and performs supported order actions. orders:read retrieves orders, jobs, shipments and events. billing:read reads usage, invoice projections and the disabled credit balance. webhooks:write manages webhook endpoints, signing-secret rotation and delivery replay.

For an agent that only researches options, start with catalog:read. For a sandbox printing workflow, add files:write, quotes:write, orders:write and orders:read. Add billing or webhook permissions when your integration uses those endpoints. MCP lists only tools permitted by the presented key.

## Rotate and revoke

Create a replacement key, update the server secret, verify it works, then revoke the old key in the console. Revocation and expiry are checked on each request. Use a separate application per environment and a named key per integration.

Keep keys in environment variables or a secret manager. Serve requests from your backend. Never place credentials in a public repository, browser bundle, document, shared prompt or URL.