Johann
bee2d02f50
- 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>
58 lines
4.3 KiB
Markdown
58 lines
4.3 KiB
Markdown
# 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](../bitacora/REGISTRO.md)): 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**:
|
|
>
|
|
> 1. **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**.
|
|
> 2. **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**.
|
|
> 3. **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-Reason`** indica 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én `X-RateLimit-Reset`, `Retry-After` y `RateLimit-Reason`.
|
|
>
|
|
> Te comparto el API token en el siguiente link de Google Drive:
|
|
>
|
|
> `https://drive.google.com/drive/folders/1J4GZcV7gndpXJ6qlXtcpK6ZiNZbvkM_0?usp=sharing`
|
|
>
|
|
> Si 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 cuando `X-RateLimit-NearLimit` aparezca (<20% de capacidad) y respetar `Retry-After` ante 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í.)
|