Scopes & product APIs
Every OAuth scope on the Ionhour developer platform, grouped by product API — monitoring, incidents, alerting, on-call, and status pages — plus capping rules.
Scopes are fine-grained resource:action grants. In the Developer Console they're grouped by product API — a presentational grouping that mirrors Ionhour's products; the underlying grant is always the individual scope.
The two capping rules
- Scopes are consent ceilings. A granted scope is the most an installation can be granted — not a floor.
- Installer coupling. An installation's effective authority is capped by the installing member's live workspace role, and never exceeds Admin. Owner-only actions are unreachable over OAuth, whatever scopes you request.
Request the minimum you need — over-scoped apps are the most common reason for review rejections.
Monitoring API
Checks, jobs, dependencies, deployments, maintenance windows, and signal ingest.
| Scope | Grants |
|---|---|
checks:read | View checks and their status |
checks:write | Register, update, and control checks |
jobs:read | View jobs and their status |
jobs:write | Register, update, and control jobs |
dependencies:read | View dependencies |
dependencies:write | Manage dependencies |
deployments:read | View deployments |
deployments:write | Manage deployments |
maintenance:read | View maintenance windows |
maintenance:write | Manage maintenance windows |
signals:write | Send heartbeat and failure signals ⚠️ |
Incidents API
| Scope | Grants |
|---|---|
incidents:read | View incidents and timelines |
incidents:write | Manage incidents through their lifecycle |
Alerting API
| Scope | Grants |
|---|---|
alerts:read | View alert channels and routing |
alerts:write | Manage alert channels and routing |
On-Call API
| Scope | Grants |
|---|---|
escalation:read | View escalation paths |
escalation:write | Manage escalation paths |
Status Pages API
| Scope | Grants |
|---|---|
status_pages:read | View status pages |
status_pages:write | Manage status pages and components |
Workspace API
| Scope | Grants |
|---|---|
workspace:read | View workspace details and members |
workspace:members:write | Invite workspace members ⚠️ |
projects:read | View projects |
projects:write | Manage projects |
There is no signals:read scope — signal history isn't exposed over OAuth in v1. signals:write covers sending heartbeats and failure signals.
Sensitive scopes ⚠️
Two scopes confer unusual authority and get extra treatment:
workspace:members:write— your app can invite people to the user's workspace.signals:write— your app reports heartbeats and failures as the monitored service, which means it can mask a real outage or fabricate one.
Both are called out with an explicit warning on the consent screen, and apps requesting either require Ionhour review before publication. Request them only when they're central to what your app does, and explain the use in your review submission.
Scope tiers are stable
Read/write tiers are the granularity contract: :read grants viewing, :write grants the full mutating set for that resource (create, update, delete, and lifecycle actions where they exist). A published :write scope will never silently narrow. If finer grants (for example a separate :delete) are introduced later, they will be additive — new scopes alongside the existing ones, never a change to what you already hold.
Scopes and webhooks
Webhook events are gated by read scopes: check.* events require checks:read, job.* events require jobs:read, and incident.* events require incidents:read. See Webhooks.
OAuth apps
Register an OAuth app on the Ionhour developer platform — client types, one-time credentials, configuration, and the full review and distribution lifecycle.
Webhooks
Subscribe your own app to Ionhour events — configuring delivery, the signed envelope format, verifying HMAC signatures, rotating secrets, and retry behavior.