Security and Webhooks
The Security and Webhooks pages are where you keep an app usable after the first install.
This is the part that decides whether the app is manageable in real life, not just whether it looked good in development.
App identity and secrets
The security area exposes stable identity values like:
- client ID
- service user ID
- source
It is also where you rotate:
- client secret
- webhook secret
Initial secrets are shown at app creation time and should be stored immediately. If you lose them, rotation is the recovery path.
Treat secret rotation like a real change
When you rotate a secret, assume every dependent system needs to catch up.
That means rotation is not just a click. It is a coordinated update.
Rotate when:
- a secret was lost
- a secret may have been exposed
- you are tightening access after team changes
Manage app members deliberately
The Security page also controls who can manage the app.
Use it to:
- invite members by email
- assign app permissions
- update permissions later
- remove people who should no longer have access
Keep this tight. App access should follow ownership, not convenience.
What the webhook page tells you
The Webhooks page is for delivery visibility across installed workspaces.
Use it to review:
- installed workspace count
- subscribed workspace count
- recent deliveries
- recent failures
- last delivery, success, and failure times
It also shows the webhook categories and data types declared by the latest published version.
When to open webhook analytics
Open Webhooks when:
- you suspect delivery failures
- you need to confirm an app is actually receiving events
- you want to see whether installs are actively subscribed
- you need one place to review failure patterns across workspaces
Good operating habits
- Store secrets immediately when they are first shown.
- Rotate secrets when there is any real doubt, not after a long debate.
- Keep app membership aligned with the actual owning team.
- Treat repeated webhook failures as a product problem, not background noise.