- REGISTRO #55: validación del prototipo Etapa 0 (24-jul) APROBADA; único bloqueo = definir el flujo de facturación en Jira (sesión propuesta por Araceli para el martes 28) - REGISTRO #56: sesión de API de Jira con Pedro (27-jul) — token PAF a 1 año, bandeja FAC; + seguimiento por correo del mismo día con los límites de velocidad (65k puntos/h, burst/s, por-issue) y entrega del token por Google Drive - REGISTRO #57: hilo de WhatsApp con Erika (21-27 jul) — coordinación, envío del flujo por correo y reagenda 23→24 jul; 3 imágenes inferidas - Transcripciones y correo en fuentes/; guion de validación en planeacion/ - Avance-Etapa1-2026-07-27 (nota + mensaje para Erika) y Excel del corte del 27-jul (núcleo verificado; capa de escritura en pausa por definición de Balam) - Seguimiento-horas: sesiones del 24-jul (validación) y 27-jul (API Jira) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.3 KiB
Correo — Pedro Ayala → Johann · medición de consumo de la API de Jira y entrega del token
Canal: Correo
Fecha: 2026-07-27, 07:40 am
De: Pedro Alberto Ayala Elizondo <pedro.ayala@balamtalentoestrategico.com>
Para: Johann · CC: Noe Rocha, Erika Chávez
Asunto: Seguimiento: medición de consumo API de Jira y accesos
Relación: cumple los compromisos de Pedro en la sesión de API de Jira del mismo día (REGISTRO #56): entregar el token e investigar los límites de consumo.
Transcripción del correo
Buenos días, Johan. Espero te encuentres bien.
Gracias por la sesión y por tu tiempo. Te comparto el detalle de cómo se mide el consumo de la API de Jira, porque tiene un par de puntos que hay que tener claros.
Cómo funciona el límite:
No existe un límite de volumen del tipo "X llamadas por mes". El uso de la API tampoco genera costo adicional sobre la licencia. Lo que sí existen son los límites de velocidad, y actualmente son tres independientes que operan en paralelo:
- Cuota por puntos (por hora). Cada llamada consume puntos según el trabajo que implica: 1 punto base más 1 punto por objeto de dominio (issues, proyectos) o 2 puntos por objeto de identidad (usuarios, grupos, roles). Las escrituras solo cobran el punto base. La bolsa por defecto es de 65,000 puntos por hora.
- Burst por segundo. Aplica a todo el tráfico, incluido el de API token. Los defaults son 100 request por segundo para GET y POST, y 50 para PUT y DELETE, con un bucket independiente por endpoint y por tenant. Hay endpoints con límites propios más bajos; el más notable es el de consulta de clientes de un service desk, restringido a 5 por segundo.
- Límite por issue en escrituras. 20 operaciones de escritura cada 2 segundos y 100 cada 30 segundos sobre un mismo ticket.
Cualquiera de los tres devuelve HTTP 429. El header
RateLimit-Reasonindica cuál se activó.Sobre la página de desarrolladores para revisar consumo: aquí la respuesta es que no existe y es una limitante de Jira.
- No hay dashboard de consumo en la administración de Jira. No hay pantalla de administrador ni reporte nativo.
- El Developer Console de Atlassian solo sirve si uno publica una app propia, y ahí únicamente se ve el tier asignado, no el consumo de la instancia.
- El detalle de uso por API token requiere Atlassian Guard Premium, que es una licencia aparte.
- Existen apps de terceros en Marketplace que estiman el consumo, pero trabajan por muestreo, no con telemetría real de Atlassian.
La única fuente confiable son los headers de respuesta:
X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-NearLimit(que se activa cuando queda menos del 20% de capacidad), y en respuestas 429 tambiénX-RateLimit-Reset,Retry-AfteryRateLimit-Reason.Te comparto el API token en el siguiente link de Google Drive:
https://drive.google.com/drive/folders/1J4GZcV7gndpXJ6qlXtcpK6ZiNZbvkM_0?usp=sharingSi se presenta algún problema con el acceso, estoy al pendiente.
Saludos,
Respuesta de Johann
Enterado, muchas gracias Pedro! Saludos
Notas e implicaciones para el desarrollo
- Cierra el pendiente de la sesión #56: ya no hay incógnita sobre el límite. No hay tope mensual ni costo por uso; el diseño del sync debe respetar límites de velocidad, no un cupo diario como en BIND (20K/día).
- El sync debe autorregularse leyendo los headers
X-RateLimit-*: pausar/reducir ritmo cuandoX-RateLimit-NearLimitaparezca (<20% de capacidad) y respetarRetry-Afterante un 429. No hay dashboard, así que la telemetría vive en las respuestas. - Las escrituras son baratas en puntos (solo el punto base): favorece la capa de escritura (crear cotizaciones/tickets) frente a las consultas de identidad (2 puntos c/u).
- Cuidado con el límite por-issue en escrituras (20/2 s, 100/30 s por ticket): relevante si la automatización hiciera varias escrituras sobre el mismo ticket en ráfaga.
- ⚠️ El token vive en el enlace de Google Drive de arriba — tratar como credencial: descargarlo, moverlo a user-secrets / Key Vault y no dejarlo en texto plano en el repo ni en el disco. (El conector de Google Drive de claude.ai requiere autorización; el token no se consultó desde aquí.)