The dashboard organizes everything into projects and apps. A project holds your plan, billing, and team. An app is the isolation unit inside it: channels, API keys, channel rules, and usage all belong to one app, and traffic in one app can’t see another. Use separate apps for separate environments, like acme-prod and acme-staging.
Creating an app
In the project’s Apps tab, create an app with a name and a slug. The slug becomes the first part of every key name (acme-chat.kid_a1b2c3) and the Pusher app_id if you use the Pusher compatibility layer. Apps can be renamed, and deleting one is guarded behind a confirmation because it takes its keys and channels with it.
API key management
Keys live in each app’s API keys tab. A key has a name, a capability, and a secret:
- The secret is shown once, at creation and after a rotation. Store it in your secret manager at that moment, because the dashboard only keeps a hash.
- The capability is a set of rules, each a channel pattern with the operations it grants (
subscribe,publish,presence,history, or*). The same grammar as token capabilities, because token capabilities are intersected with the minting key’s. - Capabilities are editable after creation, so tightening a key doesn’t mean re-issuing it.
Keys never expire. The two ways a key stops working are rotation and revocation:
- Rotate issues a fresh secret for the same key id. The old secret stops authenticating the moment the rotation completes, so rotate is the answer to a leaked secret: swap the new value into your deployment and nothing else changes.
- Revoke deletes the key entirely.
Practices that pay off
- One key per service, named after the service. When something misbehaves, the key name in your logs says which deployment to look at, and revoking it hurts nothing else.
- Scope each key to the channels its service touches. A worker that only publishes notifications needs
{ "notifications:*": ["publish"] }, not*. - Keys stay on servers. Browsers and mobile apps get short-lived tokens minted by your backend.
- The key that mints tokens bounds every token it mints, so give your token-minting backend a key scoped to what users may ever do, and minting bugs can’t escalate past it.
Team access
Project members hold a role: owner, admin, developer, or billing. Owners and admins manage keys and settings, developers get read access to apps and monitoring, and billing sees the money pages. Invites are sent by email from the Team tab.