Limites de débit

La RealityConnect API limite le débit des requêtes par organisation à l’aide d’un bucket de jetons par famille de routes. Cette page couvre les buckets, les en-têtes que porte chaque réponse limitée en débit, et la marche à suivre en cas de 429 Too Many Requests.

---

Buckets

Chaque bucket a une capacité (nombre maximal de jetons, c’est-à-dire la taille de rafale) et un taux de remplissage (jetons ajoutés par seconde, c’est-à-dire le débit soutenu). Une requête consomme un jeton ; lorsque le bucket est vide, la requête est rejetée avec 429.

Bucket	Capacité	Taux de remplissage	Couvre
assets	1000	10/s	RealityAssets, types d’actifs, catégories d’actifs, création/lecture/liste/suppression d’objets métier
twin	1000	10/s	Espace twin, POI, zones, brouillons
platform	1000	10/s	Site, nœud de données, Data Bundle, plugins
plan	1000	10/s	Espace reality plan, actifs de modèle
library	1000	10/s	Modèles et tags de la bibliothèque d’actifs
embed	100	2/s	Émission de sessions d’embed
users	1000	10/s	Utilisateurs, groupes, rôles, invitations
sitefiles	1000	10/s	Fichiers de site

La limitation de débit s’applique par organisation : toutes les applications OAuth et tous les utilisateurs agissant au nom de la même organisation partagent un bucket par famille.

En-têtes de réponse

Chaque réponse limitée en débit, qu’elle réussisse ou non, porte ces en-têtes :

En-tête	Signification
X-RateLimit-Limit	La capacité du bucket
X-RateLimit-Remaining	Jetons restants dans le bucket
X-RateLimit-Reset	Secondes avant que le bucket ne soit à nouveau plein
X-RateLimit-Policy	{capacity};w={window}, où window (en secondes) vaut capacity / refillRate

Uniquement sur 429 Too Many Requests, la réponse porte également Retry-After (secondes avant qu’au moins un jeton soit disponible) et ce corps :

{
  "statusCode": 429,
  "message": "Too Many Requests",
  "error": "rate_limited"
}

Gérer les 429

Temporisez en utilisant Retry-After plutôt qu’un délai fixe ou une nouvelle tentative immédiate : retenter immédiatement contre un bucket vide ne fait que produire un nouveau 429. Pour les charges de travail soutenues à fort volume, cadencez les requêtes pour rester sous le taux de remplissage du bucket plutôt que de solliciter la capacité maximale puis d’attendre la réinitialisation.

Et ensuite ?

• Consultez la référence API pour les opérations exactes sous chaque bucket.