# Abo-Kalender für Entwickler

Abo-Kalender per REST-API pflegen und über Webhooks von neuen Abos erfahren.

Source: https://docs.getridian.com/de/subscription-calendars/developers/
Language: de
Reviewed: 2026-11-01

Ein Developer-Projekt pflegt Abo-Kalender mit seinem App-Token über `https://api.getridian.com/v1/public-calendars`. Den Zugang schaltest du unter **Developer > API-Projekte**, Tab **Zugriff**, ein; **API** oben auf der Seite eines Abo-Kalenders zeigt den Stand und führt dorthin. Der Schalter gilt für das ganze Projekt: Es liest und ändert dann alle Abo-Kalender des Workspace. Einträge aus der API erscheinen in der Konsole mit der Quelle „API“ und lassen sich dort weiter bearbeiten.

## REST-API

| Methode und Pfad | Scope | Zweck |
| --- | --- | --- |
| `GET /public-calendars` | `public_calendars:read` | Kalender des Workspace |
| `POST /public-calendars` | `public_calendars:write` | Kalender anlegen; `mode` ist `test` (Standard) oder `live` |
| `GET`, `PATCH`, `DELETE /public-calendars/{id}` | lesen bzw. schreiben | Einen Kalender lesen, ändern, löschen |
| `GET /public-calendars/{id}/events` | `public_calendars:read` | Einträge, seitenweise |
| `GET`, `PUT`, `DELETE /public-calendars/{id}/events/{external_id}` | lesen bzw. schreiben | Einen Eintrag unter deiner eigenen ID lesen, anlegen oder ersetzen, löschen |
| `POST /public-calendars/{id}/events/batch` | `public_calendars:write` | Viele Einträge in einem Aufruf (`operations`) |
| `POST /public-calendars/{id}/syncs` und `…/syncs/{sync_id}/complete` | `public_calendars:write` | Vollabgleich: Was im Abgleich nicht vorkam, wird gelöscht |
| `PUT`, `DELETE /public-calendars/{id}/images/logo` bzw. `/banner` | `public_calendars:write` | Logo und Banner |
| `GET /public-calendars/{id}/stats` | `public_calendars:read` | Aktive und neue Abos |

Einträge adressierst du über deine eigene `external_id`; ein `PUT` mit derselben ID ersetzt den Eintrag, statt einen zweiten anzulegen. Schick beim Anlegen eines Kalenders einen `Idempotency-Key` mit, dann liefert eine Wiederholung denselben Kalender. Fehler kommen als Problem Details (RFC 9457) mit einem `code`.

**Vollabgleich:** Starte einen Abgleich, schreib alle aktuellen Einträge mit `sync_id` über `events/batch` und schließ ihn mit `complete` ab. Einträge, die im Abgleich fehlen, werden gelöscht. Würde das sehr viele Einträge löschen, verlangt `complete` die Bestätigung `confirm_large_delete: true`.

```sh
curl -X PUT https://api.getridian.com/v1/public-calendars/$KALENDER/events/kurs-2027-01-12 \
  -H "Authorization: Bearer $RIDIAN_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Yoga am Abend","start":"2027-01-12T18:00:00+01:00","end":"2027-01-12T19:30:00+01:00","timezone":"Europe/Berlin"}'
```

## Webhooks

Unter **Developer > Webhooks** legst du je Developer-Projekt bis zu fünf Webhooks an, an eine öffentliche `https`-Adresse. Ereignisse:

- `subscriber.created`: Ein neues Abo hat den Kalender zum ersten Mal abgerufen.
- `calendar.updated`: Einträge oder Einstellungen haben sich geändert. Mehrere Änderungen kurz hintereinander kommen als eine Meldung mit dem aktuellen Stand.

Jede Zustellung trägt `x-ridian-event`, `x-ridian-delivery`, `x-ridian-timestamp` und `x-ridian-signature: v1=<HMAC-SHA256>` über `<timestamp>.<body>` mit dem Secret des Webhooks. Das Secret siehst du nur beim Anlegen. Antwortet dein Server nicht mit 2xx, versuchen wir es nach 1 Minute, 5 Minuten, 30 Minuten, 2 Stunden und 12 Stunden erneut. Unter **Developer > Webhooks** siehst du alle Webhooks des Workspace mit Zustellprotokoll: Ereignis, Zeit, HTTP-Status oder Fehlergrund und nächster Versuch. Zustellungen löschen wir 30 Tage nach der Zustellung bzw. nach dem letzten Versuch.

## Assistenten

Mit den Scopes `public_calendars:read` und `public_calendars:write` lesen und pflegen MCP-Clients Abo-Kalender auch im Gespräch. Ändern dürfen auch dort nur Admins und Owner.