Schedule aktualisieren

PATCH /api/im/schedules/:id

Hier wird die Rotation eines Schedules tatsächlich konfiguriert. Das Anlegen eines Schedules liefert eine leere Hülle (rotationMode: "none", keine Mitglieder); dieser Endpunkt setzt Kadenz, Wochenfenster und die Rotationsbesetzung.

Jedes Feld ist optional. Nur die im Body vorhandenen Felder werden angefasst — ein Body { "name": "Primär" } benennt den Schedule um und ändert sonst nichts.

Authentifizierung

Erfordert den Basiszugriff auf Incident Management, den jeder Endpunkt dieser API braucht, plus die Schreibhürde: Deine Rolle muss admin sein, oder du musst Team-Admin des Teams sein, zu dem der Schedule gehört. Ein organisationsweites API-Token gilt als Organisations-Admin.

Request-Body

Dazu die Kadenzfelder — rotationMode, rotationRepeats, customRepeatUnit, customRepeatValue, autoRotationSize, roundRobinSize, startsOnTime, startsOnDayOfWeek, startsOnDateOfMonth. Sie sind mitsamt ihren erlaubten Werten einmal unter Rotationskadenz dokumentiert.

teamId und tierId sind nicht patchbar. Einen Schedule zwischen Teams oder Stufen zu verschieben würde stillschweigend umlenken, wen er alarmiert — das ist keine Teilaktualisierung.

Wie die Kadenz validiert wird

Kadenzfelder werden auf die aktuelle Zeile des Schedules gemergt und dann als Ganzes validiert, nicht Feld für Feld. Genau das erlaubt es, ein einzelnes Feld zu patchen — etwa roundRobinSize —, ohne die restliche Kadenz erneut zu senden, und trotzdem eine unmögliche Kombination abzulehnen (zum Beispiel rotationRepeats: "weekly" ohne ein startsOnDayOfWeek irgendwo in der effektiven Konfiguration).

Die Validierung läuft, bevor irgendetwas geschrieben wird. Eine Kadenz, an der sich der Materializer verschlucken würde, erreicht die Datenbank nie.

Wann Schichten neu berechnet werden

Änderungen an Zeitzone, Gültigkeitszeitraum, Wochenfenstern, einem Kadenzfeld oder den Rotationen lösen eine Neuberechnung der Schichten aus. Eine reine Umbenennung nicht — sie würde die Sperre des Schedules ziehen und Zeilen ohne Grund neu schreiben.

Beispiel (cURL)

curl -X PATCH "$BASE_URL/api/im/schedules/7" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rotationMode": "explicit",
    "rotationRepeats": "custom",
    "customRepeatUnit": "minutes",
    "customRepeatValue": 30,
    "startsOnTime": "09:00",
    "rotations": [
      { "members": ["u_abc123"] },
      { "members": ["u_def456"] }
    ]
  }'

Response

200 OK: die Konfiguration des Schedules nach der Änderung.

{
  "id": 7,
  "displayName": "Primary On-Call",
  "timezone": "Europe/Berlin",
  "effectiveFrom": "2026-08-01T00:00:00.000Z",
  "effectiveUntil": null,
  "weeklySchedules": [],
  "rotationMode": "explicit",
  "rotationRepeats": "custom",
  "customRepeatUnit": "minutes",
  "customRepeatValue": 30,
  "autoRotationSize": null,
  "roundRobinSize": 1,
  "startsOnDayOfWeek": null,
  "startsOnDateOfMonth": null,
  "startsOnTime": "09:00",
  "rotations": [
    {
      "id": 12,
      "rotationOrder": 1,
      "members": [{ "userId": "u_abc123", "userName": "Ada Lovelace", "memberOrder": 1 }]
    },
    {
      "id": 13,
      "rotationOrder": 2,
      "members": [{ "userId": "u_def456", "userName": "Bob Fixit", "memberOrder": 1 }]
    }
  ]
}

Der Schlüssel rotations ist nur enthalten, wenn du rotations gesendet hast. Eine Anfrage, die sie nicht angefasst hat, lässt ihn ganz weg, statt einen Zustand nachzulesen, den du nicht geändert hast; für den aktuellen Rotationsstand gibt es GET /api/im/teams/:id/escalations.

Häufige Fehler