Integrations
On-Call integrates with multiple products in The One Stack and supports external webhook sources for any monitoring tool.
The One Stack Integrations
The One Defend (EDR)
Direction: Defend → On-Call
What flows: When Defend detects a critical or high-severity threat, it calls On-Call's internal escalation endpoint. The incident includes device name, MITRE technique, severity, and recommended action.
Setup: Set DEFEND_SERVICE_KEY on both theoneoncall-api and theonedefend-api. See Defend Alert Integration for full setup.
What breaks if misconfigured: If keys don't match or are missing, Defend escalation calls return 401. On-Call incidents for security threats will not be created. The technician won't be paged for critical endpoint threats.
The One RMM
Direction: RMM → On-Call (via bus event)
What flows: Critical device alerts from RMM agents are published to the shared event bus. On-Call's bus event listener receives these events and creates incidents. The source field on the incident is set to rmm.
Setup: Ensure BUS_CONNECTION_STRING is set on theoneoncall-api. No additional key exchange is needed for bus-based integration.
What breaks if misconfigured: Missing BUS_CONNECTION_STRING means On-Call never receives RMM events. Device alerts will not trigger on-call pages.
The One Security
Direction: Security → On-Call (via bus event)
What flows: Critical and high-severity security events — M365 posture changes, dark web monitoring hits — arrive via the bus. On-Call creates incidents for any event above the severity threshold.
Severity filter: Only critical and high severity events create incidents. Medium/low/info are dropped.
Setup: Same bus connection as RMM — uses the shared BUS_CONNECTION_STRING.
What breaks if misconfigured: Same as RMM — no BUS_CONNECTION_STRING = no Security events processed.
The One Backups
Direction: Backups → On-Call (via bus event)
What flows: Backup failure events from the Backups service. On-Call creates an incident for each received failure event, regardless of severity (all backup failures are treated as actionable).
Setup: Same bus connection.
The One PSA
Direction: On-Call → PSA (ticket creation on acknowledgment)
What flows: When a technician acknowledges an on-call incident, On-Call creates a PSA ticket with incident details. Notes added to the On-Call incident sync to the PSA ticket. Resolution syncs on close.
Setup: Set PSA_API_URL and PSA_SERVICE_KEY on theoneoncall-api. See PSA Ticket Creation.
What breaks if misconfigured: Acknowledgment still works in On-Call, but no PSA ticket is created. Incident records exist only in On-Call — no billable ticket, no PSA history.
The One Hub
Direction: Bidirectional
What flows:
- Hub → On-Call: User authentication via Hub SSO. Hub role (
owner,admin,member) maps to On-Call role. - On-Call → Hub Bus: Incident lifecycle events (
incident.created,incident.acknowledged,incident.resolved) published to the shared event bus. - On-Call → Hub Billing: Daily active user count reported to Hub for billing calculation.
Setup: Hub SSO is automatic for all Hub-authenticated products. No additional configuration needed.
What breaks if misconfigured: If Hub SSO fails, users cannot log in to On-Call. If billing reporting fails, active user count may not be accurate in Hub Billing.
External Webhook Integrations
On-Call accepts alerts from any monitoring tool that can send HTTP webhooks. Each integration has its own secret key.
Supported Alert Sources
| Tool | Integration Type | Notes |
|---|---|---|
| Any HTTP-capable monitoring tool | Generic webhook | Full payload parsing with auto-extraction |
| Nagios / Icinga | Webhook | Configure notification command to POST to On-Call |
| Zabbix | Webhook | Media type: HTTP — point to On-Call webhook URL |
| Datadog | Webhook | Add On-Call URL as outbound webhook |
| PagerDuty (migration) | Webhook | Set forwarding from PagerDuty outbound webhooks |
| Custom scripts | Webhook | POST JSON with title + severity + dedup_key |
Creating a Webhook Integration
- Go to Alert Sources → New Integration.
- Set Type:
Webhook. - Assign to a Service.
- Copy the generated webhook URL and key.
- Configure your monitoring tool to POST to that URL.
Rotating Integration Keys
If an integration key is compromised:
- Go to Alert Sources → open the integration.
- Click Rotate Key.
- A new key is generated immediately. The old key is invalidated.
- Update the webhook URL in your monitoring tool with the new key.
Bridge API (External Read Access)
The Bridge API provides read-only access to On-Call data for external systems (dashboards, BI tools, NOC screens):
Authentication: X-Integration-Key and X-Tenant-Id headers
Endpoints:
| Endpoint | Returns |
|---|---|
GET /api/bridge/incidents | Active and recent incidents |
GET /api/bridge/schedules | Schedule layers and current on-call users |
GET /api/bridge/escalations | Escalation policy definitions |
Use this for:
- NOC wall dashboards showing current on-call coverage
- External reporting tools pulling incident metrics
- Slack bots that surface current on-call info on demand
Search Integration
On-Call participates in the Hub-wide search via the bus search integration:
GET /api/search?q=<query>&tenant_id=<id>
X-Integration-Key: <key>
Returns matching incidents, services, schedules, and technicians. Used by the Hub global search bar to surface On-Call entities.