1. Overview
The Incident.io integration reads an authorized incident population, response work, and supporting organization configuration with a workspace-managed API key.
Webhook payloads are treated only as future synchronization hints; Seedling fetches current API state and does not expose incident mutations.
2. Connection and scope
Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.
- Incident.io API key
- Create a key with account-level or team-scoped read permissions for the incident population Seedling should index.
- Connection ownership
- This connector is workspace-only. A current Seedling workspace administrator controls installation, credential replacement, disconnect, and purge for the exact connection.
3. Incident.io data Seedling accesses
Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.
- Incidents
- Incident identity, status, severity, summary, timestamps, ownership, incident type, and custom fields.
- Response work
- Actions, follow-ups, roles, updates, milestones, and timeline context.
- Configuration
- Incident types, severities, statuses, teams, users, and available private-incident boundaries.
4. Read-only permission contract
Grant only the Incident.io read permissions required by the released resource families.
- View incidents — ordinary incident records and response state.
- View private incidents — only when private content is intentionally in scope.
- View organization settings and users — incident types, statuses, severities, custom fields, roles, teams, and attribution.
- View follow-ups and actions — response tasks and lifecycle context.
- No incident, action, follow-up, update, or configuration write permission is required.
5. Security and access
- Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
- Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
- The provider does not expose enough complete object-level audience evidence for Seedling to reproduce native permissions safely. Workspace content therefore uses the connection's restricted-by-default workspace-or-no-human-access policy; administrator and steward status grant no raw-content bypass.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized Incident.io records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored Incident.io credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.
- Backups
- Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.