Mitarbeiter eines Termins ändern

Weist einem einzelnen Slot eines bereits bestehenden Termins einen anderen Mitarbeiter zu. Ein Termin besteht aus einem oder mehreren Slots – den einzelnen Positionen des Termins –, und jeder Slot hat seinen eigenen Mitarbeiter. Diese Schnittstelle ändert genau einen davon; Uhrzeiten, Leistungen und alle übrigen Slots des Termins bleiben unverändert.

Der Termin wird über internalid angesprochen, der Slot über seine Position slot. Beide Werte liefert Daten für einen einzelnen Termin abfragen: Die Antwort enthält je Slot einen Eintrag mit der internalid, der Position appointment_slots_idx (0 für den ersten Slot) und dem bisher zugeordneten Mitarbeiter servicer_id. Die ID des neuen Mitarbeiters stammt aus Mitarbeiter; angegeben werden darf auch die ID einer Ressource, also zum Beispiel eines Geräts oder eines Raums.

Übergabe der Werte

Die vier Felder können als URL-Parameter angehängt oder – mit dem Header Content-Type: application/json – als JSON-Body geschickt werden:

{
  "token": "IHR_TOKEN",
  "internalid": 51078854,
  "slot": 0,
  "servicerId": 136
}

Beide Wege führen zum selben Ergebnis, lassen sich aber nicht mischen: Sobald der Aufruf als JSON ausgezeichnet ist, werden internalid, slot und servicerId ausschließlich aus dem Body gelesen – dieselben Werte in der URL bleiben dann unbeachtet. Einzige Ausnahme ist der token: Fehlt er im Body, wird er weiterhin aus der URL genommen.

Was geprüft wird

Vor der Änderung prüft die Schnittstelle der Reihe nach, ob alle Angaben vollständig sind, ob es den Termin gibt, ob die Position innerhalb des Termins existiert und ob es den Mitarbeiter gibt. Termin und Mitarbeiter müssen dabei zu dem Standort gehören, für den der verwendete API-Zugang gilt – sonst antwortet die Schnittstelle so, als gäbe es sie nicht.

Antwort

Bei Erfolg antwortet die Schnittstelle mit 200 OK und dem Ergebnis der Änderung als JSON-Objekt.

Jeder Aufruf wird beim API-Zugang mitgezählt: erfolgreiche als Nutzung, fehlgeschlagene als Fehler. Weil an einer Schnittstelle niemand angemeldet ist, wird als Urheber der Änderung der Benutzer eingetragen, der den API-Zugang angelegt hat – unter diesem Namen erscheint die Änderung anschließend auch im Kalender.

Parameter