Quotas

L'endpoint /v1/quotas montre trois choses :

1. Les limites du tier de base (l'API est réservée au plan Enterprise, donc le tier est toujours enterprise).
2. Tout override par boutique défini par le support (deals custom, intégrations partenaires).
3. Les limites effectives — l'override l'emporte, défaut au tier sinon.

L'accès à l'API exige un plan Enterprise actif. Quitter Enterprise — par rétrogradation ou expiration — ne change pas les limites rapportées : cela supprime l'accès entièrement (403 forbidden à chaque appel, y compris celui-ci) jusqu'au retour de la boutique sur Enterprise. Vous n'avez jamais besoin de réémettre une clé.

Limites API uniquement

Ces quotas comptent les appels API effectués avec une clé vers https://api.dzbuild.app/v1. Votre vitrine, votre tunnel de commande et votre tableau de bord ne sont jamais throttlés par eux et ne les consomment jamais. Voir Limites de taux.

Limites par tier

Tier	Requêtes / mois	Inscriptions / mois	Webhooks / mois	Requêtes / minute
enterprise	-1	-1	-1	600

Les tiers hérités Free / Pro / Unlimited ont été retirés en août 2026, lorsque l'API est devenue réservée au plan Enterprise. La valeur rapportée sous effective est toujours celle qui est appliquée.

GET /v1/quotas

Auth : clé plateforme avec usage:read (ce scope est réellement appliqué ici).

Requête

curl https://api.dzbuild.app/v1/quotas \
  -H "Authorization: Bearer $DZ_KEY"

Réponse 200

{
  "data": {
    "tier": "enterprise",
    "tier_limits": {
      "requests_per_month":  -1,
      "signups_per_month":   -1,
      "webhooks_per_month":  -1,
      "requests_per_minute": 600
    },
    "overrides": null,
    "effective": {
      "requests_per_month":  -1,
      "signups_per_month":   -1,
      "webhooks_per_month":  -1,
      "requests_per_minute": 600
    }
  }
}

Lorsqu'un override est en place :

{
  "data": {
    "tier": "enterprise",
    "tier_limits": {
      "requests_per_month":  -1,
      "signups_per_month":   -1,
      "webhooks_per_month":  -1,
      "requests_per_minute": 600
    },
    "overrides": {
      "store_id":            13,
      "requests_per_month":  null,       // non surchargé, retombe sur le tier
      "signups_per_month":   null,
      "webhooks_per_month":  null,
      "requests_per_minute": 1200,       // surcharge
      "notes": "Partner integration — Q2 2026",
      "set_by_user_id":      1,
      "updated_at":          "2026-04-30 19:27:55"
    },
    "effective": {
      "requests_per_month":  -1,         // du tier
      "signups_per_month":   -1,
      "webhooks_per_month":  -1,
      "requests_per_minute": 1200        // de la surcharge
    }
  }
}

Quand demander un override

• Pic saisonnier sans upgrader le mois entier (Aïd, Black Friday).
• Intégration partenaire — un service type Zapier se connecte pour vous et a besoin d'un RPS plus haut.
• Contrat custom — deals Enterprise.

Contactez le support avec votre store id pour en mettre un en place. Un override remplace la valeur du tier pour les champs renseignés ; les champs null retombent sur le défaut du tier. Un override peut aussi être inférieur au défaut du tier — en pratique le support ne fait que les relever, mais traitez effective comme la référence plutôt que de supposer qu'il est égal ou supérieur à tier_limits.

overrides est renvoyé tel quel : des champs supplémentaires peuvent apparaître avec le temps. Elle vaut null quand aucun override n'existe pour la boutique.

-1 = illimité

Tout champ à -1 signifie pas de limite. Le tier enterprise met les trois champs mensuels à -1 par défaut ; requests_per_minute est toujours une vraie valeur (jamais -1), afin qu'aucune intégration ne puisse à elle seule saturer les serveurs qui font aussi tourner les vitrines des marchands. Voir Limites de taux.

Quand vous toucherez un quota

• Burst par minute → 429 avec Retry-After. Appliqué par boutique — toutes les clés de la boutique partagent le budget. Les compteurs sont à cohérence différée : lors d'un burst marqué, vous pouvez être brièvement sur-toléré, ou voir un 429 un peu plus tôt que ne le laisse penser votre propre décompte.
• Quota mensuel de requêtes → 402 quota_exceeded jusqu'au 1er du mois suivant. Appliqué par boutique, cumulé sur toutes ses clés, et rejeté avant le traitement de la requête.
• Quota d'inscriptions — rapporté mais non appliqué en v1. Dépasser signups_per_month ne bloque pas /v1/signups ; le compteur est informatif (GET /v1/usage) jusqu'à la sortie de la facturation à l'usage.
• Quota de livraison de webhooks — ni appliqué ni mesuré en v1. Les livraisons ne sont jamais comptées ni suspendues pour cause de quota ; le seul garde-fou automatique s'applique par livraison : après 5 tentatives échouées, cette livraison est abandonnée et cesse de réessayer. Le endpoint webhook lui-même n'est jamais suspendu — de nouveaux événements continuent d'être mis en file pour lui.

Voir Erreurs et Limites de taux pour les stratégies de retry.