Limites & fair use
Mis à jour Aug 2026 · API v3Les limites existent pour garder l’API saine pour tout le monde — un usage normal ne les touche jamais.
Rate limits
- Trafic de l’API publique : 60 requêtes/minute par client+utilisateur par défaut.
- S’y ajoutent des limites d’infrastructure par IP — les intégrations normales ne les atteignent jamais.
- Atteindre une limite répond
429avec un headerRetry-After; les headersX-Rate-Limit-*te disent à tout moment où tu en es.
Fair use
Au-delà des limites dures par minute, il existe un guide mensuel souple :
3 000 requêtes/mois (lis la valeur actuelle en direct via
GET /v3/users/me/usage sous fairUse.monthlyReference). C’est une jauge,
pas une sanction : le dépasser change une couleur sur ta page d’utilisation
sur my.pon.app, rien de plus. Tes chiffres en direct (aujourd’hui, mois, par
token) s’y trouvent aussi.
La requête la moins chère est celle que tu ne fais pas.
Les webhooks te disent quand quelque chose a changé ; un fetch conditionnel ensuite suffit. Ça garde la plupart des intégrations très loin sous le guide.Quotas de ressources
Des plafonds généreux contre l’automatisation qui s’emballe
(422 QUOTA_EXCEEDED avec details.resource et details.limit) :
| Ressource | Limite |
|---|---|
| Listes à toi | 200 |
| Articles actifs par liste | 5 000 (LIST_FULL) |
| Images | 2 000 |
| Invitations ouvertes par liste | 50 |
| Adhésions à des listes | 500 |
| Personal access tokens | 10 (TOKEN_LIMIT) |
| Webhooks | 5 (WEBHOOK_LIMIT) |
L’enveloppe d’erreur
Chaque erreur, chaque endpoint, la même forme :
{ "errors": [ { "code": "LIST_FULL", "message": "…", "details": { "limit": 5000 } } ] }
Les réponses réussies sont toujours { "data": …, "meta": … }. Les chemins
d’écriture sont compatibles idempotence — réessayer une écriture échouée est
sans risque.