Raw-Endpunkte erfordern einen Key vom Typ
raw; zum Lesen einer Tabelle (GET /v1/raw/{table_name}) braucht er zusätzlich beide Grants für personenbezogene Daten, personal und personal_financial, sonst liefert der Aufruf 403. Ein transformed-Key bekommt auf GET /v1/raw/{table_name} ein 403 und von GET /v1/raw/tables eine leere Liste — siehe Key-Typen. Raw-Tabellen, die für deine Umgebung nicht freigegeben sind, erscheinen weder in /v1/raw/tables noch in /v1/changes; ein direkter Aufruf liefert 404.1
Verfügbare Tabellen auflisten
Rufe Beispiel-Antwort:
GET /v1/raw/tables auf, um herauszufinden, welche Tabellen verfügbar sind, ihre Primärschlüssel, Zeilenanzahlen und den Sync-Status.2
Den Export starten
Fordere die erste Seite der gewünschten Tabelle an. Setze Beispiel-Antwort:
limit bis zum Maximum von 10000.3
Mit dem Cursor paginieren
Übergib den Wert von
next_cursor bei jedem folgenden Request im Query-Parameter cursor. Wiederhole dies, bis next_cursor null ist.4
Snapshot-Konsistenz prüfen
Prüfe bei jeder Seite den Response-Header
X-Snapshot-At. Alle Zeilen innerhalb einer einzelnen Cursor-Sequenz sind zu diesem Zeitstempel konsistent. Wenn sich der Header zwischen den Seiten ändert, starte den Export neu, um eine einheitliche Snapshot-Sicht sicherzustellen.5
Vollständiges Python-Beispiel
Ein vollständiges Skript, das eine Tabelle Seite für Seite exportiert, dem Cursor folgt,
bis dieser erschöpft ist, und die Snapshot-Konsistenz über alle Seiten hinweg prüft.
Erfordert das Paket
requests.bulk_export.py
Cursor-Sequenzen bleiben auch bei gleichzeitigen Schreibvorgängen stabil. Da Raw-Tabellen während eines langen Exports Updates erhalten können, zeigt dir
X-Snapshot-At, zu welcher Sync-Version jede Seite gehört. Für einen garantiert einheitlichen Snapshot-Export wiederhole den Vorgang von Anfang an, wenn sich der Snapshot-Zeitstempel zwischen den Seiten unterscheidet.