API y empresas

Cuota de consultas de multas: cómo se reparte entre equipos

Varios equipos consumiendo la misma cuota contratada terminan en una discusión sin datos cuando se agota. Credenciales separadas, un esquema de reparto explícito y topes para los lotes permiten atribuir el consumo antes del reclamo.

Foto de Marco FerreiroMarco FerreiroAutor en multas.ar
4 min de lectura
Mesa de reuniones de madera con carpetas repartidas en pilas iguales frente a cada silla, iluminada por luz natural de una ventana con persianas.
Mesa de reuniones de madera con carpetas repartidas en pilas iguales frente a cada silla, iluminada por luz natural de una ventana con persianas.

Una empresa contrata una cuota de consultas y, a la semana, tres equipos la consumen a la vez: administración verifica unidades antes de liquidar, operaciones revisa la flota activa y sistemas corre una conciliación nocturna. La cuota es una sola; el consumo, no. Cuando se agota antes de fin de período, la discusión inevitable es quién la gastó, y esa pregunta no tiene respuesta si todas las llamadas salieron por la misma credencial.

Conviene separar dos cosas que suelen mezclarse. El límite del proveedor es técnico: una cantidad de solicitudes o de patentes consultadas en una ventana, que el servidor hace cumplir. El reparto interno es una decisión de gestión: cuánto de esa capacidad corresponde a cada equipo. El proveedor no conoce el organigrama de la empresa; el reparto se sostiene con identidad, medición y acuerdos propios.

Una credencial por equipo, no una clave en una planilla

La atribución empieza por la identidad. OAuth 2.0 define que cada cliente se registra ante el servidor de autorización y recibe un identificador propio —con credenciales propias cuando puede custodiarlas—, y ese principio sirve puertas adentro: si cada equipo consume con una credencial propia, cada consulta de patente queda atribuida tanto en el registro del proveedor como en los logs locales. Una clave única compartida por correo hace imposible saber quién gastó qué, y además obliga a cortar a todos para revocar a uno.

La credencial por equipo también habilita decisiones finas: pausar el barrido de patentes de un sector sin tocar las demás, o dar de baja el acceso de un despachante cuando termina su contrato.

Reserva fija, bolsa común o esquema mixto

No existe un reparto correcto universal; existen esquemas que responden preguntas distintas:

  • una reserva fija por equipo garantiza previsibilidad: nadie puede consumir la parte de otro, pero la capacidad que un equipo no usa se pierde;
  • una bolsa común aprovecha toda la cuota, con el riesgo de que un consumo intensivo deje sin margen al resto;
  • un esquema mixto reserva un mínimo por equipo y deja el resto compartido, a costa de reglas más difíciles de explicar.

El criterio para elegir no es técnico sino operativo: qué consulta es más grave posponer. Si la entrega de un vehículo no puede esperar y la conciliación mensual sí, esa prioridad debe quedar escrita antes de que la cuota se tense, no durante la discusión.

Los trabajos programados compiten con el mostrador

El consumo interactivo y el consumo por lotes no se comportan igual. Un proceso nocturno puede consultar en horas las patentes que un equipo de atención genera en semanas, y hacerlo justo antes de que empiece la jornada. Conviene que los lotes tengan techo propio, corran en ventanas acordadas y se detengan solos al alcanzar su parte, en lugar de heredar el margen de todos.

Qué leer cuando el proveedor dice basta

Cuando las solicitudes exceden una política del servidor, la respuesta puede ser 429 Too Many Requests, que RFC 6585 define para el exceso de solicitudes en un período. Esa señal habla del ritmo, no del resultado de negocio: la consulta rechazada no falló, todavía no fue aceptada. RFC 9110 define Retry-After para indicar cuánto conviene esperar antes de volver a intentar; ignorarlo y reintentar de inmediato sólo adelanta el próximo rechazo.

El grupo HTTPAPI del IETF trabaja además en campos RateLimit para comunicar la política y la cuota restante. Al cierre de esta verificación sigue siendo un borrador, no un RFC publicado: sirve como orientación cuando el proveedor lo implementa, no como garantía contractual.

La lectura fina de esas señales —qué política se excedió, cómo reintentar sin duplicar trabajo— la tratamos en rate limits interpretables. Para el reparto interno importa otra cosa: distinguir el origen del freno. Un 429 del proveedor deja sin consultar a toda la flota; un tope interno alcanzado afecta a un solo equipo. Registrar cuál de los dos ocurrió evita diagnósticos cruzados entre áreas.

Medir por credencial antes de discutir el reparto

Un reparto sin medición es una expresión de deseo. El registro mínimo por consulta incluye credencial, fecha y resultado, sin la patente ni datos del titular en las etiquetas. Con eso alcanza para responder las tres preguntas del ciclo: cuánto consumió cada equipo, en qué momento del período y cuánto quedó sin usar.

Las alertas deberían dispararse en umbrales acordados con cada equipo antes del agotamiento. La revisión del reparto conviene alinearla con la ventana de renovación del contrato: rediscutir cuotas a mitad de ciclo mezcla el consumo de dos períodos distintos.

Qué verificar antes del próximo ciclo

Antes de renovar o ampliar un plan, revisá:

  • que cada equipo consuma con una credencial propia y revocable;
  • que exista una prioridad escrita para cuando la cuota se tense;
  • que los lotes tengan techo y ventana horaria definidos;
  • que el registro distinga rechazos del proveedor de topes internos.

Ampliar la cuota sin ese orden compra tiempo, no resuelve el problema: el equipo que hoy consume sin registro también va a agotar la cuota nueva, y otra vez sin que nadie pueda explicar en qué se fue.

Metodología

Alcance
Cómo distribuir internamente una cuota de consultas contratada entre los equipos de una misma organización. No cubre precios, condiciones comerciales ni las funciones concretas de un proveedor en particular.
Unidad de análisis
Una consulta atribuida a una credencial de equipo dentro de una ventana de cuota.
Cobertura
La semántica de 429, Retry-After y los campos RateLimit proviene de los estándares y el borrador citados. Los esquemas de reparto son patrones de gestión interna, no funciones garantizadas de una API.

Limitaciones

  • Los campos RateLimit siguen siendo un Internet-Draft y cada proveedor decide si los implementa.
  • Los esquemas de reparto descriptos son patrones generales; cada contrato define la ventana, la renovación y la unidad de medida de la cuota.
  • La nota no evalúa gateways ni productos que automaticen sub-cuotas por consumidor.

Fuentes

Preguntas frecuentes

¿Conviene que todos los equipos usen la misma API key?

No. Sin una credencial por equipo no se puede atribuir el consumo ni revocar un acceso sin cortar a los demás. Una clave compartida también impide saber qué parte del gasto corresponde a cada área cuando la cuota se agota antes de tiempo.

¿Un 429 significa que la cuota del período se terminó?

No por sí solo. Indica que las solicitudes excedieron una política del servidor, que puede ser un límite de ritmo en una ventana corta. Conviene leer la respuesta, respetar la espera indicada por Retry-After y verificar el estado de la cuota antes de concluir que se agotó.

¿El proveedor puede repartir la cuota entre equipos automáticamente?

Depende de lo que ofrezca cada contrato. Si la API no distingue consumidores internos, el reparto se administra del lado de la empresa, con credenciales separadas, topes propios para los procesos por lotes y medición del consumo por credencial.

Notas relacionadas