Limites de débit

Le débit est compté par clé, sur une fenêtre d’une minute glissante. La limite par défaut est de 120 requêtes par minute.

Elle se règle partenaire par partenaire : si votre parc la rend trop étroite, écrivez-nous plutôt que d’étaler artificiellement vos appels. Un PMS à 3000 logements n’a pas la même cadence qu’un gestionnaire à 20, et c’est prévu.

Lire votre consommation dans chaque réponse

Toute réponse authentifiée porte trois en-têtes :

En-tête	Sens
X-RateLimit-Limit	Votre plafond, en requêtes par minute.
X-RateLimit-Remaining	Ce qu’il vous reste dans la fenêtre en cours.
X-RateLimit-Reset	Dans combien de secondes la fenêtre se renouvelle.

Ralentissez avant d’atteindre zéro : quand X-RateLimit-Remaining descend sous 10 % de X-RateLimit-Limit, espacez vos appels jusqu’à X-RateLimit-Reset. C’est ce qui distingue une synchronisation régulière d’une synchronisation qui se fait couper au milieu.

Au-delà

{ "success": false, "error": { "code": "RATE_LIMITED", "message": "Too many requests", "request_id": "req_…" } }

429, toujours avec un en-tête Retry-After en secondes. Respectez-le : réessayer immédiatement ne fait que prolonger la limitation. Le respect du Retry-After fait partie des contrôles de conformité.

Les SDK (TypeScript et PHP) attendent Retry-After et réessaient d’eux-mêmes.

Consommer moins, sans effort

Groupez. Les disponibilités et les tarifs acceptent 1000 dates par requête. Un an de calendrier pour un logement tient en une seule requête, contre 365 si vous les envoyez une par une.

N’envoyez que ce qui a changé. updated_since sur GET /properties et GET /reservations vous évite de tout relire (voir Pagination), et pousser un contenu identique nous fait répondre unchanged: true sans rien écrire.

Écoutez les webhooks plutôt que d’interroger GET /reservations en boucle. Un appel par jour suffit en filet de sécurité.