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.
Prerequisites:
- 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 Who can do what.
- To create or edit an API token's Topics scope, you need to be the account owner or an administrator. 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.
Who can do what
| 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 |
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 to a topic is 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.
Replay follows flow access, not topic access. Anyone who can run a flow can replay its topic listeners, including monitor users. Replaying doesn't change the topic. See Replay messages.
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.
Cloning or pulling an integration into another environment also registers its topics automatically. See how ILM handles topics.
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 step you complete before building.
If the topic a builder needs doesn't exist, a builder with topic access can select Create topic in the picker to create one without leaving the flow. They can also select Create topic at the top of the integration's Topics tab. A builder with no topic access can't create topics. Their picker stays empty until they're granted access to a topic.
Register a topic manually
- Open the integration.
- Select Topics.
- 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 with these columns: Name and Description, Last updated, Retention, and View messages. From each row's Actions menu, you can select Edit topic, View audit log, Used by, or Deregister.
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.
- Select Topics.
- In the topic's row, select Actions, and then select Deregister.
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. See A topic can't be deregistered.
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, the same as editing a shared connection.
Warning: Before you shorten retention on a shared topic, check the Used by view (see Find out what uses a topic). 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, and then select API tokens.
- Create or edit a token and set its permissions to Custom.
- In Topics, select the topics this token can publish to.
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. Delivery to a listener is internal to the platform, so no connection is needed there either.
Permissions behave identically whether a topic is reached through the interface or the API.