Límites y fair use
Actualizado Aug 2026 · API v3Los límites existen para mantener la API sana para todos — el uso normal nunca los roza.
Rate limits
- Tráfico de la API pública: 60 solicitudes/minuto por cliente+usuario de forma predeterminada.
- Además se aplican límites de infraestructura por IP — las integraciones normales nunca los alcanzan.
- Alcanzar un límite responde
429con un headerRetry-After; los headersX-Rate-Limit-*te dicen en todo momento dónde estás.
Fair use
Más allá de los límites duros por minuto hay una guía mensual blanda:
3.000 peticiones/mes (lee el valor actual en vivo desde
GET /v3/users/me/usage como fairUse.monthlyReference). Es un indicador,
no una sanción: superarla cambia un color en tu página de uso en
my.pon.app, nada más. Tus cifras en vivo (hoy, mes, por token) también
están ahí.
La petición más barata es la que no haces.
Los webhooks te avisan cuando algo cambió; un fetch condicional después es todo lo que necesitas. Eso mantiene a la mayoría de integraciones muy por debajo de la guía.Cuotas de recursos
Topes generosos contra la automatización desbocada (422 QUOTA_EXCEEDED
con details.resource y details.limit):
| Recurso | Límite |
|---|---|
| Listas propias | 200 |
| Artículos activos por lista | 5.000 (LIST_FULL) |
| Imágenes | 2.000 |
| Invitaciones abiertas por lista | 50 |
| Membresías de listas | 500 |
| Personal access tokens | 10 (TOKEN_LIMIT) |
| Webhooks | 5 (WEBHOOK_LIMIT) |
El sobre de errores
Cada error, cada endpoint, la misma forma:
{ "errors": [ { "code": "LIST_FULL", "message": "…", "details": { "limit": 5000 } } ] }
Las respuestas de éxito son siempre { "data": …, "meta": … }. Las rutas
de escritura son amigables con la idempotencia — reintentar una escritura
fallida es seguro.