Developer Portal
The developer portal is the control surface for app builders.
You are not there to run workflows. You are there to define, publish, secure, and monitor apps that other workspaces can install.
First-time access
The first real gate is developer terms acceptance.
Until that is complete, you can expect the portal to block app creation, publishing, and install-link generation.
That is normal. It is there to keep developer-only flows deliberate.
What you see on the dashboard
The dashboard is the best starting point when you want to answer basic questions quickly.
It shows:
- app count
- published app count
- draft version count
- your app list
It is also where you create a new app.
How the portal is organized
The portal is app-centric.
Once you open one app, the rest of the work usually happens in these pages:
GeneralVersionsSecurityWebhooks
That structure matters. It keeps stable app identity separate from version work and separate again from security and delivery monitoring.
When to use each page
Use General when
- you need to update name, slug, or description
- you need to review current visibility
- you need to request broader distribution
- you need to manage private-install allowlists
Use Versions when
- you are editing a manifest
- you want to validate a draft
- you need to publish a version
- you need an install link
Use Security when
- you need client credentials
- you need to rotate secrets
- you need to manage app team members
Use Webhooks when
- you need to review delivery health
- you need to see failure patterns
- you need to confirm which categories and data types the current published version declares
A practical working pattern
Most app work follows the same rhythm:
- create or open the app
- shape the app details in
General - build and validate a draft in
Versions - publish when the manifest is ready
- install into the right workspace
- manage access and secrets in
Security - watch delivery health in
Webhooks