Tous
Erreurs & limites
Codes HTTP, rate limits, retry et bonnes pratiques de résilience.
Dans cet article
Codes HTTP
| Code | Signification | Action recommandée |
|---|---|---|
| 200 | Succès | — |
| 201 | Créé | — |
| 401 | Clé API invalide ou absente | Vérifier x-njanggo-api-key et plan Pro actif |
| 403 | Plan insuffisant ou scope refusé | Upgrade ou élargir scopes clé |
| 404 | Ressource introuvable | Vérifier slug, eventId, IDs |
| 409 | Conflit (ex. déjà check-in) | Afficher message utilisateur |
| 422 | Validation échouée | Lire errors[] pour champs invalides |
| 429 | Rate limit | Attendre Retry-After, backoff exponentiel |
| 501 | Preview — endpoint pas encore déployé | Consulter changelog |
| 500 | Erreur serveur | Retry avec backoff ; contacter support si persistant |
Corps d'erreur
422 Validation
{
"statusCode": 422,
"message": "Validation failed",
"errors": [
{ "field": "startAt", "message": "Doit être une date ISO 8601 valide" },
{ "field": "endAt", "message": "Doit être postérieur à startAt" }
]
}429 Rate limit
{
"statusCode": 429,
"message": "Too Many Requests",
"retryAfter": 60
}Rate limits
| Plan / ressource | Limite |
|---|---|
| Pro — requêtes / jour / clé | 10 000 |
| Pro — burst | 50 req/s sur fenêtre 5 s |
| Pro — moyenne | 10 req/s sur fenêtre 2 min |
| Webhooks sortants | 50 req/s burst (plateforme) |
| Enterprise | Contractuel — contact sales |
Sur 429, l'en-tête
Retry-After (secondes) indique quand réessayer.Retry côté client
Recommandations pour intégrations robustes :
- GET idempotent — retry safe avec backoff (max 3 tentatives).
- POST non-idempotent — utiliser
Idempotency-Key(remboursements). - Webhooks entrants — répondre 200 rapidement, traiter en async.
- Ne jamais retry un 422 — corriger le payload.