---
title: "Who is on call"
method: GET
path: "/api/v1/schedules/{schedule}/on-call"
tags: ["On-call schedules"]
---

# Who is on call

`GET /api/v1/schedules/{schedule}/on-call`

## 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}/on-call`
- Auth: API key in header `X-API-Key`

Answers "who would this alert wake up" for a given instant, using the very resolver escalation steps use at dispatch time — handovers first, then shifts. This is the endpoint to poll instead of subscribing to the iCal feed: the feed is a bearer-credential URL issued only in the dashboard, and it answers a question about a file rather than about a person.

## Path parameters

- `schedule` string, uuid, required

## Query parameters

- `at` string, date-time

## Response `200`

The responders at that instant.

- object
  - `data` object
    - `at` string, date-time: The instant the answer is about, echoed back with its offset.
    - `schedule` Schedule: One rotation. The iCal subscription link and its revocation token are deliberately absent from every API response: that URL is a bearer credential for the whole roster and is issued only in the dashboard, by a human. Ask GET /api/v1/schedules/{schedule}/on-call or /shifts instead — they answer from the same resolver the feed renders from.
      - `uuid` string, uuid
      - `name` string
      - `timezone` string: IANA zone name, e.g. "Europe/Warsaw". Two things depend on it: the weekly handoff moment below is placed in this zone (so a DST change does not shift it), and shift and handover boundaries are RENDERED in it — a handoff set for 09:00 answers `09:00+02:00`. Changing it moves nothing in the database: existing shifts keep the very instants they had, and the new handoff position applies from the next rotation generation. Their rendered wall-clock does change, because it is now read in the new zone — the same instant, told differently.
      - `handoff` object: When the weekly baton passes, expressed in the schedule's own timezone. The rotation generator starts each week here, so a DST transition never moves the wake-up boundary.
        - `day_of_week` integer: ISO-8601 weekday: 1 = Monday … 7 = Sunday.
        - `hour` integer
        - `minute` integer
      - `is_active` boolean: An inactive schedule is skipped by escalation steps that target it — they fall through to the next target or to the step's fallback recipient. Shifts and overrides are kept.
      - `on_call` ScheduleOnCall: Who is on duty per role at the moment asked about. A role with nobody on duty is absent from the object — an empty object means the rotation covers nobody right now.
        - `primary` object: First to be paged.
          - `uuid` string, uuid
          - `name` string
        - `secondary` object: Covers when primary does not acknowledge.
          - `uuid` string, uuid
          - `name` string
        - `manager` object: Operational escalation tier for prolonged incidents.
          - `uuid` string, uuid
          - `name` string
      - `created_at` string, date-time
      - `updated_at` string, date-time

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks the config.read ability, or the schedule belongs to another company.
- `404`: No schedule with this UUID, or on-call schedules are switched off for this deployment.
- `422`: `at` is not a date, or carries no UTC offset.

---

[API](https://skmtc.dev/wardenpoint/apis/wardenpoint-api.md) · [All operations](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/llms.txt) · [OpenAPI document](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/revisions/259ee445728e?raw)