Pagination

Les listes de l’API se parcourent par curseur. Trois paramètres, les mêmes partout :

Paramètre	Sens
limit	Nombre d’éléments par page, de 1 à 500. Par défaut 100.
cursor	Le next_cursor de la page précédente. Opaque : ne le construisez pas, ne le décodez pas.
updated_since	Date ISO 8601 : ne rendre que ce qui a été modifié depuis.

Les routes paginées :

Route	Liste dans data	Filtre de date	Ordre	limit
GET /properties	properties	updated_since	plus ancienne modification d’abord	100 par défaut, 500 au plus
GET /reservations	reservations	updated_since	plus ancienne modification d’abord	100 par défaut, 500 au plus
GET /events	events	since (date de création)	plus ancien d’abord	100 par défaut, 500 au plus
GET /webhooks/deliveries	deliveries	status	plus récente d’abord	50 par défaut, 200 au plus

Un curseur illisible (modifié, ou venu d’une autre route) est refusé en 400 INVALID_PAYLOAD.

La réponse

data garde son champ de liste et gagne next_cursor :

{
  "success": true,
  "environment": "production",
  "data": {
    "properties": [ { "external_property_id": "PROP-4821", "…": "…" } ],
    "truncated": true,
    "next_cursor": "eyJ0IjoiMjAyNi0wOS0yOFQwODowMTo1MiIsImlkIjoiOWYyYyJ9"
  }
}

next_cursor vaut null sur la dernière page. truncated reste présent sur GET /properties et GET /reservations pour les intégrations écrites avant la pagination : il vaut true quand une page suivante existe.

Parcourir une liste

let cursor = null;
do {
  const url = new URL('https://localoge.com/api/v1/channel/properties');
  url.searchParams.set('limit', '200');
  if (cursor) url.searchParams.set('cursor', cursor);
  const r = await fetch(url, { headers: { Authorization: `Bearer ${process.env.LOCALOGE_KEY}` } });
  const { data } = await r.json();
  for (const p of data.properties) traiter(p);
  cursor = data.next_cursor;
} while (cursor);

Les SDK fournissent un itérateur qui fait cette boucle pour vous (voir Référence).

Gardez les mêmes filtres d’une page à l’autre

Un curseur vaut pour la requête qui l’a produit. Changer updated_since, since ou status en cours de route donne des pages incohérentes : repartez sans curseur.

Synchronisation incrémentale

Le schéma recommandé pour un passage régulier :

1. Notez l’heure avant de commencer (debut).
2. Parcourez GET /reservations?updated_since=<dernier_passage> jusqu’à next_cursor: null.
3. Enregistrez debut comme nouveau dernier_passage.

Prendre l’heure avant le parcours, et non après, garantit qu’une modification survenue pendant le parcours ressortira au passage suivant. Un élément vu deux fois est sans danger si vous traitez par identifiant ; un élément jamais vu, lui, est une double réservation en puissance.

Sur GET /reservations, updated_since porte sur la date de modification : une réservation annulée depuis votre dernier passage ressort, avec status: "cancelled".