Configuration
Roles & Access
Three roles within an org, plus how new Endpoints inherit their retry and rate-limit defaults from the Application they belong to.
Org roles
| Role | Can do |
|---|---|
| Org Admin | Full read/write within the org — create, edit, delete, replay, rotate secrets, everything. |
| Monitor | Full read access — identical visibility to Org Admin, including raw payloads and delivery response bodies. Zero write access: every mutating action (create, edit, delete, replay, rotate, deploy, send test event) is rejected. |
Monitor is full visibility, not partial visibility. There's no field-level redaction —
the role exists purely to let someone see everything (for support, auditing, or oversight)
without being able to change or trigger anything. An Org Admin can assign the Monitor role
to a member of your org.
Application-level defaults
Set once per Application; every new Endpoint inherits them unless you explicitly override it at creation.
Default max retries
Applied to any new Endpoint that doesn't specify its own retry count (platform default: 10).
Default rate limit
Applied to any new Endpoint that doesn't specify its own delivery rate limit (platform default: 100/min).
Default retry schedule
Seeds every new Endpoint's retry delay curve. Defaults to the same platform curve shown on Reliability & Limits — set it once here if you want every new Endpoint in this Application to start from a different curve. See Endpoint Configuration for the per-Endpoint override.
Dashboard → Application → Application Settings
Defaults never cascade. Changing an Application's default after Endpoints already exist
only affects future Endpoints — every existing Endpoint keeps whatever value it was
created or last explicitly set with.