Access and ownership

A webhook target belongs to one scope: a project, the organization, or your personal project. The scope decides which events the target can receive and who can see and manage it. The same rules apply in Settings > Webhooks, in the CLI and in the API.

Project targetsCopy Anchor Link

Your role on the project decides what you can do. See roles and permissions for how roles work.

Viewers and operators see no targets. Your project role can come from a direct grant, a group or an organization-wide grant, and the highest one counts. Your organization role gives no access to a project's targets.

Organization targetsCopy Anchor Link

Only organization admins can see, create and manage organization targets. Service accounts cannot manage them, even when they are admin on a project.

Personal targetsCopy Anchor Link

Only the owner of a personal project can see and manage the targets in it. A grant on someone else's personal project is not enough, even an admin grant.

Every person in the organization can create a personal target. Helios creates your personal project first when you do not have one yet.

What you seeCopy Anchor Link

• The targets list shows only the targets you can see, with your role on each one.
• A target you cannot see answers 404, the same as a target that does not exist.
• The create form offers only the scopes where you can create a target. If you are admin nowhere, the form creates a personal target.

Confirming admin loses accessCopy Anchor Link

Each target records who last set or confirmed its URL. That person, or service account, vouches for the URL. When they lose access, Helios asks another admin to confirm it.

The target gets the reason owner_lost_access when any of these happens.

• The person no longer holds admin on the target's project.
• The person left the organization. This also counts for project targets.
• For an organization target, the person is no longer an organization admin.
• The service account that confirmed the URL is disabled or deleted.

The target keeps delivering for 7 days and shows a banner with the deadline. Any admin of the target can confirm the URL during that time. The banner then clears and that admin becomes the confirming admin. If nobody confirms within 7 days, the target turns off. An admin can still confirm the URL after that, which turns the target back on.

Changing the URL or turning a target back on also makes you the confirming admin.

Helios checks project targets within minutes of a grant change, a group member change or a service account change. It also checks every target once a day, so an organization target, or a target whose confirming person left the organization, gets the banner within 24 hours. Time while Helios paused delivery does not count toward the 7 days.

Version retirementCopy Anchor Link

Each target is pinned to a dated payload version. A version is supported for at least 12 months after the next version ships.

• From 90 days before support ends, every target on that version shows a banner on the list and settings pages with the end date and the version to move to.
• When support ends, targets still on that version turn off with the reason version_retired. Helios never sends a body in a retired version again.

To move a target, change its payload version in its settings, or run helios webhook update <target-id> --payload-version <version>. The next delivery uses the new version and the target stays on. A target that is already off for version_retired needs the new version before you can turn it back on. Check the event types for the schema of each version.

Change logCopy Anchor Link

Helios logs these actions with the user ID and the time.

• Target create and delete.
• URL changes, with the old and the new URL.
• Pause and resume.
• Secret reveal and secret rotation.
• Resends.

Each secret reveal is logged, from the dashboard and from helios webhook secret show.