Aus dem Englischen übersetzt. Bei Abweichungen gilt die englische Seite. Auf Englisch lesen

Paginierung

Cursor-Paginierung und inkrementelle Sync-Durchläufe.

Die Listen, die groß werden können, verwenden Cursor-Paginierung (Produkte, Angebote, Bestellungen, Events, Operations, Aktionen, ignorierte Angebote, Unternehmen, Storefront-Bestellungen):

curl "https://api.nembol.com/rest/v1/products?limit=50" \
  -H "Authorization: Bearer $NEMBOL_API_KEY"
{
  "data": [ { "id": "…" } ],
  "has_more": true,
  "next_cursor": "eyJ1IjoiMjAyNi0wNy0yNFQx…"
}

Gib next_cursor als ?cursor= zurück, um die nächste Seite zu erhalten. Wenn has_more false ist, bist du fertig. limit liegt zwischen 1 und 100 (Standard 25). Cursor sind opak. Parse sie nicht und speichere sie nicht langfristig. Ein Cursor, den Nembol nicht ausgegeben hat (gekürzt, bearbeitet, leer), antwortet mit 422 validation_failed und param: cursor: Er wird nie als erste Seite gelesen.

Listen ohne Cursor

Einige Listen sind von Natur aus klein oder begrenzt und kommen in einer Antwort zurück. Sie haben kein limit / cursor; wo has_more vorhanden ist, ist es immer false.

ListeWie sie paginiert
GET /customersSeitenbasiert: page (ab 1), limit 1 bis 100, total in der Antwort
GET /promotionsDie 200 neuesten. Ältere sind weiterhin per ID erreichbar (GET /promotions/{id})
GET /notificationsDie 200 neuesten
GET /storefront/discounts, GET /storefront/bundlesAlle, in einer Antwort
GET /channel_accounts, GET /webhook_endpoints, GET /redirect_urls, GET /error_fixesAlle, in einer Antwort (ein Shop hat nur eine Handvoll)
GET /sales, GET /catalog/diagnosticsBerichte: ein Objekt, keine Liste

Garantierte Reihenfolge

Listen sind nach „neueste zuerst“ sortiert, mit einer stabilen Entscheidung über id bei Gleichstand: Produkte und Angebote nach updated_at, Bestellungen nach created_at (dem Zeitpunkt, zu dem die Bestellung aufgegeben wurde), Events nach created_at. Diese Reihenfolge ist Teil des Vertrags. Seiten überspringen oder wiederholen innerhalb eines einzelnen Durchlaufs nie Einträge.

Inkrementelle Synchronisierung

Um ein externes System synchron zu halten, ohne alles neu zu lesen, durchlaufe die Liste mit updated_after:

curl "https://api.nembol.com/rest/v1/products?updated_after=2026-07-24T00:00:00Z&limit=100" \
  -H "Authorization: Bearer $NEMBOL_API_KEY"

Notiere den Zeitpunkt, zu dem du den Durchlauf gestartet hast, blättere bis zum Ende und verwende diesen Zeitpunkt dann als updated_after des nächsten Durchlaufs. Gelöschte und zusammengeführte Produkte verlassen die Standardliste: Um sie in einem Durchlauf zu erfassen, lies zusätzlich status=archived&updated_after=… (oder nutze den Webhook product.deleted). (Für eine Push-basierte Synchronisierung verwende stattdessen Webhooks. Der Durchlauf ist der Fallback für den Abgleich.)

Geänderte Bestellungen. GET /orders?updated_after=… gibt die Bestellungen zurück, die nach diesem Zeitpunkt aufgegeben oder geändert wurden (Status, Abwicklung, Sendungsverfolgung: z. B. auf dem Kanal storniert oder erstattet); updated_at jeder Bestellung sagt, wann sie zuletzt geändert wurde. Frage mit dem Zeitpunkt deiner vorherigen Abfrage ab. Für Push verwende die Webhooks order.created und order.status_changed.

Zuletzt aktualisiert am 20. Oktober 2026

Brauchst du Hilfe?

Schreib uns, und ein Mensch antwortet, meist innerhalb eines Werktags.

Auf dieser Seite