Google Calendar API: Pagination und Sync

In diesem Guide verwendete Befehlsreferenzen: nylas calendar events list für paginierte Terminabfragen, nylas calendar list zum Auflisten der Kalender, nylas auth config für Headless-Setup, nylas webhook create für Terminbenachrichtigungen und nylas calendar find-time für Planungs-Workflows.

Wie funktionieren nextPageToken und maxResults in der Google Calendar API?

Bei events.list der Google Calendar API legt maxResults die Seitengröße fest, und nextPageToken verweist auf die nächste Seite von Terminen. Eine Antwort kann weniger Termine als angefordert enthalten und trotzdem ein weiteres Token zurückgeben, besonders wenn wiederkehrende Termine, gelöschte Termine oder Zeitfenster-Filter im Spiel sind.

Für die häufige Suchanfrage google calendar api nextPageToken maxResults ist der entscheidende Punkt, dass die Pagination immer auf genau einen Kalender beschränkt ist. Hat ein Nutzer 8 Kalender, braucht Ihr Sync-Code 8 unabhängige Pagination-Schleifen und 8 gespeicherte Sync-Status — keinen globalen Cursor.

Wie funktioniert die Pagination der Google Calendar API?

Die Pagination der Google Calendar API verteilt Terminlisten auf mehrere HTTP-Antworten, die jeweils einen nextPageToken-String enthalten, den der Aufrufer zurückgibt, um die nächste Seite abzurufen. Der events.list-Endpoint liegt unter /calendars/{calendarId}/events, der Pagination-Status ist also pro Kalender getrennt — ein Nutzer mit fünf Kalendern hat fünf unabhängige Pagination-Cursor.

Laut der events.list-Dokumentation der Google Calendar API beträgt die Standard-Seitengröße 250 und das Maximum 2.500 Ergebnisse pro Anfrage (5x mehr als Gmails messages.list-Limit von 500). Ein Kalender mit 10.000 Terminen erfordert daher mindestens 4 sequenzielle API-Aufrufe bei maximaler Seitengröße oder 40 Aufrufe beim Standardwert. Die folgende Schleife paginiert einen einzelnen Kalender:

from googleapiclient.discovery import build

service = build("calendar", "v3", credentials=creds)

all_events = []
page_token = None

while True:
    response = service.events().list(
        calendarId="primary",
        maxResults=2500,
        pageToken=page_token,
        singleEvents=True,
        orderBy="startTime",
    ).execute()

    all_events.extend(response.get("items", []))
    page_token = response.get("nextPageToken")

    if not page_token:
        break

print(f"Fetched {len(all_events)} events")

Dieser Code paginiert einen Kalender. Nutzer haben typischerweise einen primären Kalender plus freigegebene, sekundäre und abonnierte Kalender, daher umschließt ein produktionsreifer Sync-Client diese Schleife mit einer äußeren Schleife über die Ergebnisse von calendarList.list.

Wo gehören ETag-, If-Match- und 412-Fehler der Google Calendar API hin?

ETag, If-Match und 412 Precondition Failed in der Google Calendar API sind ein Concurrency-Control-Problem, kein Pagination-Token-Problem. Behalten Sie Pagination und Sync-Token-Handling auf dieser Seite, und nutzen Sie Fix Google API 412 Errors (ETag, If-Match), wenn es um veraltete Termin-Updates, events.patch oder Optimistic Concurrency geht.

Wie funktioniert die inkrementelle Synchronisierung von Google Calendar?

Die inkrementelle Synchronisierung von Google Calendar nutzt einen syncToken, der nur in der letzten paginierten Antwort zurückgegeben wird — der Seite, auf der nextPageToken fehlt. Dieses Token speichern Sie pro Kalender. Beim nächsten Sync übergeben Sie es als syncToken an events.list, und die Antwort enthält nur Termine, die seit dem letzten Sync erstellt, aktualisiert oder gelöscht wurden. Laut dem Sync-Guide der Calendar API ist das das empfohlene Muster, um eine lokale Kopie aktuell zu halten.

Wird ein syncToken ungültig (typischerweise nach mehreren Wochen Inaktivität oder wenn Google das Token rotiert), gibt events.list 410 Gone zurück. Der analoge Fehler bei Gmail liefert stattdessen 404. Ihr Code muss 410 abfangen, das gespeicherte Token verwerfen und eine vollständige Pagination von vorn ausführen, um einen frischen syncToken zu erhalten. Der Codepfad sieht so aus:

def incremental_sync(service, calendar_id, stored_token):
    """Sync changes since stored_token, or full-sync on 410."""
    try:
        response = service.events().list(
            calendarId=calendar_id,
            syncToken=stored_token,
        ).execute()
        return response.get("items", []), response.get("nextSyncToken")
    except HttpError as e:
        if e.resp.status == 410:
            # Token invalidated — full re-paginate
            return full_paginate(service, calendar_id)
        raise

Beachten Sie eine weitere Feinheit: syncToken-Anfragen können die meisten Filterparameter der initialen Pagination nicht verwenden, darunter q (Textsuche), timeMin, timeMax und singleEvents. Wenn Sie einen Sync mit singleEvents=True initialisiert haben, muss auch jeder folgende inkrementelle Aufruf den Parameter weglassen, sonst gibt die API 400 Bad Request zurück.

Warum sind wiederkehrende Termine ein Pagination-Problem?

Google Calendar speichert ein wöchentliches Standup oder ein monatliches All-Hands als einen einzigen Termin mit einer Wiederholungsregel (RRULE, gemäß RFC 5545) — nicht als separate Termine pro Vorkommen. Der events.list-Endpoint verhält sich je nach singleEvents-Parameter unterschiedlich. Mit singleEvents=False (dem Standard) enthält die Antwort wiederkehrende Termine nur als Master-Einträge; Sie erhalten einen Eintrag für das Standup und müssen ihn clientseitig expandieren. Mit singleEvents=True expandiert die API jede Wiederholung in einzelne Instanzen, und die Antwort kann 10-100x größer ausfallen.

Die Expansion von 500 Master-Terminen mit täglichen Wiederholungen über ein 90-Tage-Fenster erzeugt 45.000 Instanzen. Dieselbe Abfrage ohne singleEvents liefert 500 Zeilen. Beide Varianten haben legitime Anwendungsfälle (Analytics will Master-Termine, Dashboards wollen Instanzen), aber der Kontrakt verändert, wie die Pagination-Kosten skalieren. Das Setzen von timeMin und timeMax begrenzt das Expansionsfenster und ist Pflicht, wenn Sie singleEvents=True auf einem Kalender mit offenen Wiederholungen verwenden.

Was geht schief, wenn Sie die Pagination selbst bauen?

Ein produktionsreifer Google-Calendar-Sync-Client ist komplexer als das Gmail-Pendant, wegen des Pro-Kalender-Pagination-Modells und der Expansion wiederkehrender Termine. Was als 25-Zeilen-Schleife beginnt, wächst auf 150-200 Zeilen, sobald Sie jeden erforderlichen Fall behandeln:

• Ein Sync-Cursor pro Kalender — ein Nutzer mit 8 verbundenen Kalendern braucht 8 gespeicherte syncToken-Werte, 8 Full-Sync-Fallback-Pfade und 8 Sätze von State-Tracking-Metadaten.
• 410-Gone-Fallback — jeder inkrementelle Aufruf braucht ein try/except um den 410, mit einem Re-Paginate-Codepfad, der einen Kalender zurücksetzt, ohne die anderen anzufassen. Zwei Codepfade, beide müssen korrekt funktionieren.
• OAuth2-Token-Lebenszyklus — Google-Calendar-Access-Tokens laufen alle 3.600 Sekunden ab. Die Sync-Schleife braucht einen Refresh-Token-Callback, Retry-Logik bei abgelaufenen Tokens und persistente Speicherung für das Refresh-Token selbst.
• Semantik wiederkehrender Termine — Analytics-Pipelines brauchen Master-Termine, Dashboard-UIs brauchen expandierte Instanzen, und eine einzige Abweichung bei singleEvents zwischen initialem und inkrementellem Sync liefert 400 Bad Request.
• Rate-Limits — die Google Calendar API erzwingt 600 Abfragen pro Minute pro Nutzer und 1.000.000 Abfragen pro Tag pro Projekt. Eine naive Pro-Kalender-Sync-Schleife erreicht das Pro-Nutzer-Limit schneller als das globale, besonders beim Expandieren wiederkehrender Termine.
• OAuth-Consent-Screen — bevor irgendein Code läuft, brauchen Sie ein Google-Cloud-Projekt, einen unter console.cloud.google.com konfigurierten OAuth-Consent-Screen, eine Client-ID samt Secret, den Scope calendar oder calendar.readonly und eine Redirect-URI. Das sind 15-20 Minuten Klicken durch Webformulare.

Wie listen Sie Google-Calendar-Termine mit einem Befehl auf?

Das Nylas CLI ersetzt den gesamten Pagination-, Sync- und OAuth-Stack durch einen einzigen Terminal-Befehl. Wo der Calendar-API-Ansatz 150-200 Zeilen Python und ein Google-Cloud-Projekt erfordert, reduziert das CLI das Ganze auf eine Zeile und eine 2-Minuten-Installation.

Die drei Befehle unten decken die häufigsten Muster ab: anstehende Termine auflisten, auf einen Datumsbereich eingrenzen und einen einzelnen Termin lesen. Jeder führt unter der Haube einen API-Aufruf aus, während das CLI die Pagination über die Provider-Antworten hinweg übernimmt:

# List the next 50 upcoming events on the primary calendar
nylas calendar events list --limit 50 --json

# Events in the next 7 days
nylas calendar events list --days 7 --json

# Read one event by ID
nylas calendar events show <event-id> --json

Siehe nylas calendar events list, nylas calendar events show und die vollständige Befehlsreferenz für jedes Flag. Neu beim Tool? Beginnen Sie mit dem Erste-Schritte-Guide.

Wie listen Sie alle Kalender auf, bevor Sie Termine paginieren?

Ein typischer Google-Workspace-Nutzer hat 4-8 Kalender: den primären Kalender, 1-3 freigegebene Team-Kalender, optional einen sekundären persönlichen Kalender und 1-2 abonnierte Kalender (US-Feiertage, Sportpläne, Geburtstage von Kontakten). Jeder davon ist ein eigener Pagination-Scope. Die Calendar API verlangt, dass Sie zuerst calendarList.list aufrufen, um die zugänglichen Kalender zu ermitteln, und dann events.list für jede calendarId in einer Schleife ausführen — was Anfragenzahl und gespeicherten Sync-Status mit N multipliziert.

Das CLI nutzt nylas calendar list für diese Aufzählung. Kombiniert mit nylas calendar events list --calendar-id paginiert ein einziges Shell-Script jeden Kalender:

# List every calendar the user has access to
nylas calendar list --json

# Loop pagination across all calendars
for cal in $(nylas calendar list --json | jq -r '.[].id'); do
  nylas calendar events list \
    --calendar-id "$cal" \
    --days 30 \
    --json
done

Wie paginieren Sie über mehrere Konten hinweg?

Produktive Kalender-Workflows erstrecken sich oft über mehrere verbundene Google-Konten — eine Führungskraft, die Arbeits- und Privatkalender zusammenführt, eine Assistenz, die über fünf Kundenkonten plant, oder ein Sales-Ops-Tool, das die Kalender aller Vertriebsmitarbeiter eines Workspace liest. Google Calendar erzwingt Kontingente pro OAuth-Grant, das parallele Synchronisieren von 10 Konten funktioniert also ohne kontoübergreifende Drosselung — aber der Anwendungscode muss 10 Sätze von Refresh-Tokens, 10 Pro-Kalender-syncToken-Bündel und 10 aktive Grant-Status verwalten.

Grants sind im CLI erstklassige Objekte. nylas auth list zeigt jedes verbundene Konto. nylas auth whoami gibt aus, welchen Grant der nächste Befehl verwendet. nylas auth switch wechselt den aktiven Grant. Jeder Kalenderbefehl akzeptiert die Grant-ID als positionales Argument, sodass ein einziges Shell-Script über Grants iterieren kann, ohne den aktiven Status zu ändern.

# Show every connected Google grant
nylas auth list --provider google --json

# Pull today's events from every connected calendar account
for grant in $(nylas auth list --provider google --json | jq -r '.[].id'); do
  nylas calendar events list "$grant" \
    --days 1 \
    --json
done

Wie synchronisieren Sie in CI, Cron-Jobs und Headless-Umgebungen?

Google-Calendar-OAuth2-Access-Tokens laufen alle 3.600 Sekunden ab, und der browserbasierte Refresh-Flow funktioniert nicht in CI, Docker, KI-Agent-Sandboxes oder anderen unbeaufsichtigten Umgebungen. Googles Offline-Access-Flow erfordert ein einmaliges interaktives Setup, um ein Refresh-Token zu erhalten, das die Anwendung dann in einem Secret-Manager speichert und für die nächsten 6 Monate bis zur erneuten Einwilligung wiederverwendet. Die Service-Account-Alternative erfordert Google Workspace Domain-Wide Delegation, ein Admin-Feature, das für private Google-Konten nicht verfügbar ist.

Das Nylas CLI umgeht den Browser mit API-Key-Authentifizierung. nylas auth config --api-key speichert einen Key, ohne einen Browser zu öffnen. nylas auth token generiert ein Bearer-Token mit begrenztem Scope für nachgelagerte API-Aufrufe. nylas auth status meldet den aktuellen Auth-Status — nützlich für Health-Checks in containerisierten Deployments.

# Generate a daily schedule digest in a cron job — no browser
export NYLAS_API_KEY="nyk_..."
nylas auth config --api-key "$NYLAS_API_KEY"
nylas calendar events list --days 1 --json > /var/log/agenda.json

Wann sollten Sie Webhooks statt Polling verwenden?

Einen Google Calendar alle 5 Minuten abzufragen erzeugt 288 API-Aufrufe pro Tag und Konto. Bei 1.000 verbundenen Nutzern sind das 288.000 Aufrufe täglich, und die meisten liefern null Änderungen. Google Calendar bietet eine Push-Benachrichtigungs-Alternative via Cloud Pub/Sub oder eine Webhook-Callback-URL, aber das Setup erfordert ein Pub/Sub-Topic, IAM-Bindings für calendar-api-push@system.gserviceaccount.com, Watch-Channels für jeden Kalender und einen Erneuerungs-Job, weil Google Watches alle 7 Tage ablaufen lässt.

Webhooks im CLI registrieren sich ohne Pub/Sub-Topic. nylas webhook create registriert einen HTTPS-Endpoint und eine Liste von Triggern. nylas webhook list zeigt, was registriert ist. nylas webhook triggers listet jedes unterstützte Ereignis auf, darunter event.created, event.updated, event.deleted und calendar.created. nylas webhook test send schickt eine Beispiel-Payload an Ihren Endpoint, damit Sie den Empfänger validieren können. nylas webhook verify validiert die HMAC-Signatur eingehender Payloads.

# Register a webhook for calendar event changes
nylas webhook create \
  --url https://example.com/hooks/calendar \
  --triggers event.created,event.updated,event.deleted \
  --json

# Verify an inbound payload signature
nylas webhook verify \
  --payload-file ./incoming.json \
  --signature "$X_NYLAS_SIGNATURE" \
  --secret "$WEBHOOK_SECRET"

Bei typischer Kalendernutzung liegt das Webhook-Aufkommen im Schnitt bei 5-20 Ereignissen pro Nutzer und Tag, verglichen mit den 288 Polling-Aufrufen. Die Latenz zwischen einer Terminänderung und dem Moment, in dem die Anwendung sie sieht, sinkt von bis zu 5 Minuten auf etwa 1 Sekunde.

Wie handhaben andere Kalenderanbieter die Pagination?

Google Calendar ist nicht der einzige Anbieter mit einem Pagination-Kontrakt. Microsoft Graph (Outlook- und Exchange-Online-Kalender) nutzt @odata.nextLink, eine vollständige URL, der der Client unverändert folgt, plus einen Delta-Link-Mechanismus für inkrementellen Sync. CalDAV (iCloud, Yahoo, gehostetes Apple) paginiert nicht im REST-Sinne: REPORT-Abfragen mit calendar-query-Filtern liefern passende Termine in einer einzigen Antwort, wobei der Sync über sync-collection und ETags läuft. Exchange Web Services (EWS, in älteren Exchange-Server-Installationen) nutzt FindItem mit IndexedPageItemView.

Anbieterspezifische Guides behandeln dasselbe Problem in jedem Kontrakt: Google Calendar vom Terminal verwalten, Outlook-Kalender verwalten, Exchange-Kalender verwalten, iCloud-Kalender verwalten und Yahoo-Kalender verwalten. Derselbe Befehl nylas calendar events list ist dokumentiert, gegen jeden Anbieter mit identischen Flags zu laufen.

Das oben beschriebene anbieterseitige Verhalten für Outlook, Exchange, iCloud und Yahoo stammt aus der öffentlichen Dokumentation des jeweiligen Anbieters, nicht aus einem verifizierten End-to-End-Lauf auf jedem Backend. Testen Sie lokal, bevor Sie anbieterspezifische Workflows deployen.

Wie lange dauert die Synchronisierung eines Google Calendars?

Die Synchronisierung eines einzelnen Google Calendars mit 500 Terminen läuft mit einem CLI-Befehl in etwa 2 Sekunden, ein Multi-Kalender-Konto mit 50.000 expandierten Terminen in etwa 1 Minute. Dieselbe Last braucht via sequenzieller Python-Pagination-Schleife mit Backoff ~4 Sekunden bzw. ~6 Minuten, weil die Schleife ohne explizite Thread-Pools nicht parallel bis zur Pro-Nutzer-Grenze von 600 Abfragen pro Minute auffächern kann. Die Benchmarks unten wurden über eine private Breitbandverbindung mit ~150 ms Median-Latenz zu Google-Servern gemessen.

Der Unterschied in der Wanduhrzeit kommt größtenteils von der Parallelität. Pythons naive sequenzielle Schleife iteriert Kalender nacheinander; das CLI fächert die Pro-Kalender-Pagination parallel bis zur Pro-Nutzer-Grenze von 600 Abfragen pro Minute auf. Die API-Aufrufzahlen oben bleiben gleich — das CLI kann Googles zugrunde liegende Aufrufe nicht billiger machen, nur schneller absetzen.

Was sind gängige Google-Calendar-Sync-Rezepte?

Vier Shell-Muster, die Kalender-Pagination mit Standard-UNIX-Tools kombinieren. Jedes nutzt jq zum Parsen der JSON-Ausgabe und --json für maschinenlesbare Formatierung.

Die heutige Agenda

Ein tägliches Agenda-Script umschließt nylas calendar events list --days 1 mit einem jq-Filter, der Startzeit und Titel für jeden Termin der nächsten 24 Stunden ausgibt. Nützlich für Shell-Begrüßungsprompts, Terminal-Dashboards oder zum Pipen in ein LLM für eine Morgenzusammenfassung. Läuft gegen ein durchschnittliches Konto in etwa 2 Sekunden.

nylas calendar events list --days 1 --json \
  | jq -r '.[] | "\(.when.start_time) - \(.title)"'

Freie Zeit über mehrere Kalender hinweg finden

nylas calendar find-time fragt Frei/Belegt-Daten für jeden Teilnehmer ab und liefert Slots, in denen alle für die gewünschte Dauer frei sind. Das CLI übernimmt die Zeitzonen-Normalisierung über alle Teilnehmer hinweg, sodass ein um 9 Uhr PT vorgeschlagener 30-Minuten-Slot in der Antwort auch als 12 Uhr ET lesbar ist. Kombinieren Sie das mit nylas calendar availability check für rohe Belegt-Fenster.

nylas calendar find-time \
  --participants you@example.com,colleague@example.com \
  --duration 30 \
  --days 7 \
  --json

Konflikte im Kalender dieser Woche erkennen

nylas calendar ai conflicts scannt die nächsten N Tage und markiert drei Schweregrade: harte Konflikte (gleichzeitige Termine), weiche Konflikte (weniger als 15 Minuten zwischen Meetings) und Reisezeit-Risiken. Der Standard-Vorausblick beträgt 7 Tage. Kombinieren Sie das mit nylas calendar ai reschedule, um Lösungsvorschläge für jeden Konflikt zu erhalten.

nylas calendar ai conflicts --days 7 --json

Termine eines bestimmten Organisators massenhaft absagen

Kombinieren Sie nylas calendar events list mit nylas calendar events rsvp, um jede Einladung eines Absenders in einer Pipeline abzulehnen. Der RSVP-Befehl akzeptiert --status yes, --status no oder --status maybe. Verwenden Sie stattdessen nylas calendar events delete, wenn Ihnen der Termin gehört. Für Posteingangs-artige Analytics siehe nylas calendar analyze.

nylas calendar events list --json \
  | jq -r '.[] | select(.organizer.email == "noisy@example.com") | .id' \
  | xargs -I{} nylas calendar events rsvp --id {} --status no

Wie schneidet CLI-Sync im Vergleich zur rohen API-Pagination ab?

Die Tabelle unten vergleicht den Python-Ansatz der Google Calendar API mit dem Nylas CLI über 9 Fähigkeiten hinweg. Der größte Unterschied ist der Pro-Kalender-Sync-Status — Kalender-Sync-Clients müssen für jeden Kalender eines Nutzers einen Cursor und einen Fallback-Pfad verwalten, während das CLI diese Auffächerung intern erledigt.

Was sollten Entwickler vor dem Deployment wissen?

Was ist nextPageToken in der Google Calendar API?

Wenn Sie events.list auf einem Kalender aufrufen, liefert die API bis zu 2.500 Termine pro Seite (Standard: 250). Existieren weitere Termine, enthält die Antwort einen nextPageToken-String. Diesen übergeben Sie als pageToken-Parameter in der nächsten Anfrage, um die folgende Seite abzurufen. Sie wiederholen das, bis die Antwort keinen nextPageToken mehr enthält — dann haben Sie das Ende erreicht, und die Antwort enthält einen nextSyncToken für den inkrementellen Sync.

Wie funktioniert der inkrementelle Sync von Google Calendar mit syncToken?

Nach vollständiger Pagination eines Kalenders enthält die letzte Antwort einen nextSyncToken. Speichern Sie ihn pro Kalender. Beim nächsten Sync übergeben Sie ihn als syncToken an events.list, und die Antwort enthält nur Termine, die seit dem letzten Sync erstellt, aktualisiert oder gelöscht wurden. Wurde das Token ungültig, gibt die API 410 Gone zurück, und Sie müssen eine vollständige Pagination von vorn ausführen, um ein frisches Token zu erhalten.

Warum gibt die Calendar API 410 statt 404 zurück?

410 Gone teilt dem Client mit, dass die Ressource (hier die durch das Token identifizierte Sync-Session) existierte, aber gezielt invalidiert wurde. Gmails analoger Fehler bei einer veralteten historyId liefert 404, weil Gmails History-Einträge in einem rollierenden Fenster ablaufen; Calendar nutzt 410, weil das Token selbst widerrufen wurde. Funktional bedeuten beide dasselbe: gespeichertes Token verwerfen und vollständig neu paginieren.

Kann ich Calendar-Termine ohne Google-Cloud-Setup auflisten?

Ja. Das Nylas CLI übernimmt OAuth2 und die Provider-Authentifizierung intern. Führen Sie nylas calendar events list --limit 50 --json aus, um Termine aufzulisten, ohne ein Google-Cloud-Projekt zu erstellen, einen OAuth-Consent-Screen zu konfigurieren oder Access-Tokens zu verwalten. Derselbe Flow funktioniert mit Google, Outlook, Exchange, iCloud und Yahoo.

Wie synchronisiere ich nur einen bestimmten Kalender?

Übergeben Sie --calendar-id an nylas calendar events list. Nutzen Sie nylas calendar list, um jede Kalender-ID des verbundenen Kontos zu sehen. Kalender-IDs sehen aus wie primary, en.usa#holiday@group.v.calendar.google.com oder eine UUID bei freigegebenen Kalendern.

Wie gehe ich mit wiederkehrenden Terminen um?

Das CLI expandiert wiederkehrende Termine standardmäßig — ein wöchentliches Standup über 12 Monate erscheint als 52 separate Zeilen, jede mit eigener Vorkommenszeit. Der zugrunde liegende events.list-Aufruf von Google Calendar nutzt singleEvents=true, sodass Konsumenten expandierte Instanzen erhalten, ohne RRULE-Syntax interpretieren zu müssen. Master-Termine mit intakten Wiederholungsregeln sind über die CLI-Oberfläche derzeit nicht zugänglich.

Kann ich Kalender in einem Cron-Job ohne OAuth-Pop-up synchronisieren?

Ja. Nutzen Sie nylas auth config --api-key statt nylas auth login. Der API-Key-Flow öffnet keinen Browser und läuft daher auf Headless-Maschinen, in Docker-Containern und in CI-Pipelines. Speichern Sie den Key als Secret dort, wo der Cron-Job läuft.

Funktioniert das CLI mit Outlook- und iCloud-Kalendern genauso?

Ja. nylas calendar events list, nylas calendar events show und nylas calendar events create funktionieren mit Google Calendar, Microsoft Graph (Outlook und Exchange Online), CalDAV (iCloud, Yahoo) und EWS (Legacy-Exchange). Anbieterspezifische Anleitungen finden Sie in Outlook-Kalender verwalten, iCloud-Kalender verwalten und Exchange-Kalender verwalten.

Kann ich Push-Benachrichtigungen für Kalenderänderungen erhalten?

Ja. nylas webhook create registriert einen HTTPS-Endpoint für Ereignisse wie event.created, event.updated und event.deleted, ohne ein Cloud-Pub/Sub-Topic zu erfordern. Führen Sie nylas webhook triggers aus, um jeden unterstützten Ereignistyp zu sehen.

Nächste Schritte

Kalender-Pagination ist eine von mehreren wiederkehrenden Herausforderungen bei der API-Integration. Diese verwandten Guides behandeln angrenzende Workflows, darunter Gmail-Sync, ETag-basierte Concurrency-Kontrolle, anbieterspezifische Kalenderverwaltung und die vollständige Befehlsoberfläche.

• Gmail API Pagination und Sync — dieselben Muster, angewendet auf messages.list und historyId
• Google Calendar vom Terminal verwalten — Erstellen, Aktualisieren, RSVP und Frei/Belegt-Workflows
• Outlook-Kalender vom Terminal verwalten — das Microsoft-Graph-Pendant @odata.nextLink
• iCloud-Kalender vom Terminal verwalten — CalDAV-Pagination mit denselben Befehlen
• Gmail API If-Match und ETag-Handling — 412 Precondition Failed und Concurrency-Kontrolle
• Google-Calendar-Eigentumsänderungen — wenn Kalender zwischen Konten übertragen werden
• Kalender vom Terminal verwalten — der Multi-Provider-Hub-Guide
• Erste Schritte — Installationsmethoden und erste Authentifizierung
• Befehl calendar events list — exakte Flags für --limit, --days, Kalenderauswahl und JSON-Ausgabe
• Befehl calendar list — Kalender aufzählen, bevor Sie über Terminseiten iterieren
• Vollständige Befehlsreferenz — jedes Flag und jeder Unterbefehl dokumentiert