On-call schedules

Update an on-call schedule

Changes only the fields present in the body; an omitted field is left alone, it is not reset to a default. Shifts that already exist are never rewritten — a new timezone or handoff moment applies from the next rotation generation, so fixing a typo in the name cannot move everybody's duty. PATCH is accepted on the same path with identical semantics.

put/api/v1/schedules/{schedule}

Request

  • Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
  • URL: https://wardenpoint.com/api/v1/schedules/{schedule}
  • Auth: API key in header X-API-Key

Path parameters

schedulestring uuid required

Schedule UUID.

Request body

namestring

New display name. Nothing enforces uniqueness on update: a name another schedule of this company already uses is accepted, and you end up with two schedules sharing a name. Create behaves differently — it hands back the existing schedule rather than making a twin — so a create issued afterwards with that shared name resolves to the older of the two.

timezonestring

IANA zone name. The new handoff position applies to rotations generated after this call; existing shifts keep the exact instants they already have. Their rendered boundaries do move, though — they are returned in the schedule timezone, so changing it re-reads the same moments in the new zone.

default_handoff_day_of_weekinteger

ISO-8601 weekday: 1 = Monday … 7 = Sunday.

default_handoff_hourinteger

Hour of the weekly handoff, in the schedule's own timezone. Takes effect on the next rotation generated; shifts already on the calendar are not moved.

default_handoff_minuteinteger

Minute of the weekly handoff. Same as the hour: it positions future rotations, never existing shifts.

is_activeboolean

False takes the schedule out of escalation targeting without deleting anything.

Response

The updated schedule.

Changes

No recorded changes to this operation across all 1 revision of this API.