Zum Hauptinhalt springen
GET /v1/changes listet jede Tabelle, deren letzter erfolgreicher Sync nach dem Zeitstempel in since liegt. Jeder Eintrag enthält die endpoint_url, über die du die Tabelle abrufst. So erfährst du, welche Tabellen du neu laden musst, statt bei jedem Lauf alle abzurufen. Den vollständigen Ablauf beschreiben Delta-Sync und Inkrementeller Sync.
Es gibt kein Delta auf Zeilenebene. Eine hier gelistete Tabelle wurde vollständig neu geladen — rufe sie über ihre endpoint_url vollständig erneut ab und ersetze deine lokale Kopie. Siehe Sync-Zyklus.

Request

Response

200 OK mit einem JSON-Array, neuester Sync zuerst. Hat sich nichts geändert, ist das Array leer.
Gelistet werden nur Tabellen mit abgeschlossenem Sync. Tabellen, die für dein Konto nicht freigegeben sind, erscheinen nicht.

ETag und bedingte Requests

Speichere das ETag zusammen mit dem since und der category, für die es ausgegeben wurde, und sende es bei der nächsten Abfrage als If-None-Match zurück. Hat sich der Sync-Stand nicht geändert, liefert die API 304 Not Modified ohne Body. Das ETag ändert sich, wenn eine Tabelle einen neuen Sync abschließt, wenn since oder category abweichen und — bei transformed-Keys — wenn sich die Zugriffsrechte des Keys ändern. Auch ein 304 zählt zum Rate-Limit.

Key-Typen

Siehe Key-Typen.

Fehler

Fehler kommen im Problem-JSON-Format.

Beispiele

Das Python-Beispiel fragt /v1/changes ab und lädt jede gelistete Tabelle über ihre endpoint_url vollständig neu; dabei folgt es next_cursor, bis der Wert null ist (siehe Pagination).
reload_changed_tables.py