Skip to main content
Jeder Listen-Endpunkt unter /v1/ — Category wie Raw — nutzt dieselbe Cursor-Pagination. Die Pagination-Felder stehen im Response-Body. Es gibt keine Pagination-Header und keinen offset-Parameter; ein Request mit offset liefert 400 Bad Request.

​
Request

​
integer
Standard:"1000"
Zeilen pro Seite. Maximal 100.000 bei Category-Endpunkten, 10.000 bei Raw-Endpunkten.
​
string
Der next_cursor-Wert aus der vorherigen Antwort, unverändert übergeben. Für die erste Seite weglassen.
Behalte innerhalb eines Laufs auf jeder Seite dieselben Filterparameter bei.

​
Response

​
array
Die Zeilen dieser Seite.
​
integer
Anzahl der Zeilen in data.
​
string | null
Opaker Cursor für die nächste Seite. null auf der letzten Seite.
​
integer
Zeilen, die ab der Cursor-Position zur Abfrage passen. Auf der ersten Seite: alle passenden Zeilen.
Raw-Endpunkte (/v1/raw/{table_name}) ergänzen den Body um table_name und senden einen X-Snapshot-At-Header mit dem Zeitstempel des letzten erfolgreichen Syncs der Tabelle.

​
Beispiel

Wiederhole das, bis next_cursor null ist. Eine vollständige Python-Schleife steht unter Incremental Sync.

​
Reihenfolge und Stabilität

Die Zeilen sind nach der Sortierspalte der Tabelle (oder dem Primärschlüssel) sortiert, NULL-Werte zuletzt, bei Gleichstand entscheidet die interne Zeilenposition — Zeilen mit gleichem Wert werden weder übersprungen noch doppelt geliefert. Tabellen ohne Sortierspalte und Primärschlüssel werden allein nach Zeilenposition paginiert.
Ein Cursor gilt nur innerhalb eines Sync-Laufs. Die Tabellen werden täglich neu geladen (siehe Sync-Zyklus); danach können sich Zeilenpositionen verschieben. Speichere next_cursor nicht zwischen Läufen — starte jeden Lauf mit der ersten Seite. Ein veränderter oder veralteter Cursor liefert 400 Bad Request; starte dann ebenfalls bei der ersten Seite.