Politique de Rate-Limit
Référence des limites publiées et du comportement recommandé côté partenaire.
Endpoints avec limites explicites
| Endpoint | Limite | Fenêtre | Clé de limitation | Réponse 429 |
|---|---|---|---|---|
GET /api/w/verify-status/:requestId?pt=... | 30 requêtes | 60s | request_id | RATE_LIMITED + Retry-After: 60 |
POST /api/partner/verify-request | 60 requêtes | 60s | IP client | {"error":"Too many requests"} |
GET /api/partner/verify-status/:requestId | 60 requêtes | 60s | IP client | {"error":"Too many requests"} |
POST /api/billing/session (pré-auth) | 30 requêtes | 60s | IP client | {"error":"Too many requests"} |
POST /api/billing/session (post-auth) | 100 requêtes | 60s | Partner ID | {"error":"Too many requests"} |
Endpoints Partner API (api.zykay.com)
Pour POST /v1/exchange et POST /v1/introspect, il n'y a pas de quota public figé dans cette version de référence.
Par prudence, votre backend doit:
- traiter toute réponse
429comme transitoire - appliquer un backoff exponentiel borné
- conserver l'idempotence côté appelant
Stratégie de retry recommandée
- Si header
Retry-Afterprésent, respectez-le en priorité - Sinon, utilisez un backoff exponentiel avec jitter (max 30s)
- Limitez à 3 tentatives avant échec utilisateur
Exemple:
tentative 1: 1s (+ jitter)
tentative 2: 2s (+ jitter)
tentative 3: 4s (+ jitter)Bonnes pratiques
- Ne poll pas plus vite que nécessaire (évitez un intervalle inférieur à 1s côté client).
- Arrêtez immédiatement les retries sur erreurs
401/403/400(non transitoires). - Journalisez
X-ZK-CIDpour corrélation support.