Topics are governed the same way connections are: they are account-level resources that you register to the integrations that use them, and registration determines which users can see and manage each one. External systems publishing through the Topics API are governed separately, by API token scope. This article explains both gates and who can do what under each.
Topics deliberately reuse the connections model rather than introducing a permission concept specific to topics. If you already administer registered connections, you already know how this works.
Before you begin
- The Topics license must be enabled for your account.
- To register or deregister a topic, edit a shared topic's settings, or view who has access, you need to be the account owner, an administrator, or a Manage All user — or a manage user on the specific integration. See Account permissions.
- To create or edit an API token's Topics scope, you need to be the account owner or an administrator. API tokens are owner/admin-created; any user can create their own Personal Access Token.
- You need at least one topic and one integration to register it to. See Create and manage topics.
The two access gates
| Where the request comes from | What governs it |
|---|---|
| Inside integrator.io — the Topics page, flow steps, message history | Integration registration and the user's role |
| Outside integrator.io — the Topics API | The API token's scope |
The API needs its own gate because an external caller has no integration context to register against.
Account permissions
| Role | Topics they can see | What they can do |
|---|---|---|
| Account owner, administrators | Every topic in the environment, registered or not | Create, edit, delete, purge, view history, register, deregister |
| Manage All | Every topic in the environment, registered or not | Create, edit, delete, purge, view history, register, deregister |
| Monitor All | Every topic in the environment, registered or not | View topics and message history only |
| Manage user on an integration | Topics registered to integrations they manage | Create, edit, delete, purge, view history, register, deregister |
| Monitor user on an integration | Topics registered to integrations they manage | View topics and message history only |
Two things to note:
Editing, deleting, and purging share one rule. There is no separate permission for destructive actions on a topic. Any user who can edit a topic can also delete and purge it.
Monitor access is strictly read-only. Monitor users can browse message history and read payloads, but they never see the Purge messages action, and they can't edit or delete anything. Payload visibility is deliberate: those same users already see the same data as record and retry data in the run console and error management once a subscribing flow processes it.
Register a topic to an integration
Registration is the recorded relationship between a topic and an integration. It drives which users can see the topic, the used-by trail, and the deregistration check.
Registration happens automatically most of the time. A builder doesn't need to register a topic before they can use it.
Automatic registration
When a builder selects a topic in a publish step or a topic listener and saves the step, the topic is registered to that integration automatically — exactly as selecting a connection does.
This is why the topic picker in a flow step lists every topic the builder can access, not only topics already registered to the current integration. Registration is a record of what an integration uses, not a hoop to clear before building.
Register a topic manually
- Open the integration.
- Go to the Topics tab.
- Register an existing topic, or create a new one — a topic created here is registered to this integration automatically.
The Topics tab lists the integration's registered topics, in the same slot and table pattern as the integration's Connections tab.
Deregister a topic from an integration
Deregistering removes a topic from that integration's pickers and from its users' visibility. Registrations to other integrations are unaffected.
- Open the integration.
- Go to the Topics tab.
- Deregister the topic.
Deregistration is available to the account owner, administrators, and manage users on that integration.
If deregistration is blocked
A topic can't be deregistered while any flow in that integration still references it:
This topic can't be deregistered from this integration while its flows use it. {{count}} flows here still reference it.
Remove the publish steps and listeners in the listed flows first. This matches how connections behave.
Note: A topic must be deregistered from every integration before it can be deleted. See Create and manage topics.
Edits affect every integration
A topic can be registered to several integrations at once. Any change you make — including shortening retention — applies everywhere it is registered.
Warning: Before you shorten retention on a shared topic, check the Used by view. A retention window that suits one integration's flows can lose messages for another integration's flows that run less often or recover more slowly.
The edit view shows which integrations a topic is registered to.
Grant API publish access with token scopes
External systems publish through the Topics API using an API token. The token's scope determines which topics it can publish to. Topics use the existing token model — there is no separate topic API key.
| Token type | Publish access |
|---|---|
| API token, Full access | Every topic in the environment |
| API token, Custom | Only the topics selected in the token's Topics list |
| Personal Access Token (PAT) | Whatever the owning user can access |
Scope a token to specific topics
API tokens are created by the account owner and administrators.
- Go to Resources > API tokens.
- Create or edit a token and set its permissions to Custom.
- In the Topics multi-select, choose the topics this token can publish to.
- Save the token.
Changes to a custom token's scope are recorded in the audit log.
Personal Access Tokens
A Personal Access Token (PAT) follows its owner's access:
- An owner, administrator, or Manage All user's token can publish to any topic.
- A manage user's token can publish to topics registered to integrations they manage.
- A monitor user's token can't publish at all — monitor access stays read-only, including through the API.
Existing tokens
Tokens you already have are unaffected:
- Full access tokens can publish to topics, because full access covers every platform API.
- Custom tokens can't publish until someone edits the token and selects topics in its scope.
A publish request for a topic outside the token's scope returns a standard authorization error.
Flow steps don't use a connection
Neither the publish step nor the topic listener has a Connection field. This is deliberate: the builder's own topic access is what gates the step, so a connection field would govern nothing.
Permissions behave identically whether a topic is reached through the interface or the API.