Configuration reference

This is the authoritative reference for configuring Unit Oncall resources via JSON. It describes each resource's fields, valid values, defaults, and how resources depend on one another.

Use the per-resource pages for field details:

• Team — the top-level container for members, schedules, and webhooks.
• Schedule — on-call rotation, members, escalation, and VoIP call behavior.
• Webhook — how external alerts are received and routed.
• Transformation Rule — how an incoming webhook payload is mapped to a normalized alert.
• Routing Rule — which alerts are routed to which schedule.

Setup order

Resources must be created in dependency order, because some fields reference the IDs of other resources that must already exist:

1. Team — no prerequisites.
2. Schedule — requires a Team.
3. Webhook — requires a Team and a Schedule (used as default_schedule_id).
4. Transformation Rule — can be created independently.
5. Routing Rule — requires a Schedule (referenced by schedule_id).
6. Routing binding — attach a Routing Rule to a Webhook (requires both to exist).

Cross-resource references

When a field points to another resource, that resource must already exist and you must use its real ID (do not invent IDs):

Key rules

• Use real IDs / emails. Reference fields (schedule_id, default_schedule_id, member identifiers) must point to resources that already exist.
• Schedule members must belong to the Team. Both schedule members and the final-escalation user are resolved against the Team's membership.
• Webhook updates are declarative. On a Webhook, transformation and routing_bindings are not preserved when omitted — omitting them (or sending null) unbinds them. Always include the values you want to keep. See Webhook.
• Use exact enum values. For example, a Routing Rule's match_mode is all or any; a Schedule's rotation_period is one of manual, daily, weekly, biweekly, monthly.