Zum Hauptinhalt springen
Finde heraus, welche Tabellen seit deinem letzten Sync aktualisiert wurden, ohne jeden Endpunkt abzurufen. Der Endpunkt GET /v1/changes der Data API liefert Metadaten für geänderte Tabellen und unterstützt bedingte Requests über ETag, um Polling zu überspringen, wenn nichts Neues vorliegt.
Frage /v1/changes alle 15–60 Minuten ab. Der zugrunde liegende Sync läuft als täglicher Batch — häufigeres Abfragen liefert keine neueren Daten, sondern verbraucht nur mehr von deinem 2.500-Requests/h-Budget, das sich alle Endpunkte teilen. Kombiniere das mit dem since/ETag-Muster weiter unten, damit unveränderte Abfragen günstig bleiben.
Mit einem transformed-Key listet /v1/changes nur Tabellen innerhalb der Kategorien und Tabellen des Keys; Tabellen ohne Kategorie erscheinen nie, und ?category=X außerhalb des Keys liefert 403. Ein raw-Key sieht alle Tabellen — siehe Key-Typen.
1

Geänderte Tabellen abfragen

Sende einen GET-Request an /v1/changes mit einem ISO-8601-Zeitstempel since (UTC, z. B. …Z). Ein Offset wie +02:00 wird nach UTC umgerechnet; schreibe das + in der Query-String als %2B, sonst wird es als Leerzeichen gelesen und die Anfrage scheitert mit 400. Die Antwort listet jede Tabelle auf, deren last_sync_at nach diesem Zeitstempel liegt, inklusive der zugehörigen Endpunkt-URL. Eine hier gelistete Tabelle musst du vollständig neu abrufen — /v1/changes meldet geänderte Tabellen, keine geänderten Zeilen. endpoint_url zeigt auf den abzurufenden Pfad: /v1/{category}/{table} für Category-Tabellen, /v1/raw/{table} für Raw-Tabellen. Für dein Konto gesperrte Raw-Tabellen werden nicht gelistet. Mit dem optionalen Parameter category (z. B. category=property) werden nur Tabellen dieser Kategorie zurückgegeben.
Beispiel-Antwort:
2

Nur geänderte Tabellen abrufen

Rufe für jedes von /v1/changes zurückgegebene Element nur den entsprechenden Endpunkt ab. Überspringe jede Tabelle, die nicht in der Antwort enthalten ist. So vermeidest du unnötigen Datentransfer und schonst dein Rate-Limit-Budget von 2.500 Req/h.
3

Bedingtes GET bei nachfolgenden Abfragen nutzen

Speichere den ETag-Header aus der ersten erfolgreichen /v1/changes-Antwort. Sende ihn bei deiner nächsten Abfrage als If-None-Match zurück.
Der ETag hängt auch von since und category ab; bewahre ihn deshalb zusammen mit dem since auf, für das er ausgestellt wurde. Wenn sich seit der Ausstellung des ETag keine Tabellen geändert haben, liefert die API 304 Not Modified mit leerem Body und überspringt die Datenbankabfrage. Der Request zählt trotzdem auf dein Rate-Limit.
4

Den Parameter since fortschreiben

Speichere nach einem erfolgreichen Sync das höchste last_sync_at aus der /v1/changes-Antwort und nutze es als Wert für since bei der nächsten Abfrage. So entsteht ein gleitendes Zeitfenster, sodass jeder Lauf nur das Intervall seit dem vorherigen Lauf bewertet. Ist die Antwort leer, bleibt das bisherige since bestehen.Nimm dafür nicht deine eigene Uhr. Client- und Serveruhr weichen voneinander ab, und eine Tabelle, die kurz vor deinem Zeitstempel fertig synchronisiert wurde, würde in keiner späteren /v1/changes-Antwort mehr auftauchen.
5

Vollständiges Python-Beispiel

Ein vollständiger Poller, der den Zeitstempel since und den ETag zwischen den Läufen verfolgt und nur Tabellen verarbeitet, die sich tatsächlich geändert haben. Erfordert das Paket requests.
poll_changes.py
Der Parameter since darf nicht älter als 120 Tage sein. Requests mit einem Zeitstempel jenseits dieses Rückblickfensters liefern einen Fehler. Führe einen vollständigen Tabellen-Refresh aus, wenn dein letzter erfolgreicher Sync mehr als 120 Tage zurückliegt.