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.
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 Beispiel-Antwort:
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.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 Der
ETag-Header aus der ersten erfolgreichen /v1/changes-Antwort. Sende ihn bei deiner nächsten Abfrage als If-None-Match zurück.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