El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Por qué contamos las solicitudes masivas por elemento y no por llamada
Un endpoint por lotes que acepta mil direcciones en una sola llamada y solo cuenta como una solicitud contra tu cuota parece generoso en una página de precios. No es generoso. Es un error de redondeo que acabará convirtiéndose en un problema de capacidad, porque el trabajo real detrás de esa llamada, mil consultas individuales, no se ha reducido solo porque llegara en un mismo sobre.
Contamos las solicitudes masivas y por lotes igual que todo lo demás: un elemento, una solicitud. Si envías mil direcciones en una sola llamada por lotes, son mil solicitudes contra tu cuota gratuita o tu crédito prepago, exactamente como si hubieras llamado al endpoint mil veces por separado. La comodidad de los lotes, menos viajes de ida y vuelta y menos sobrecarga de conexión, es real y vale la pena. El coste de las propias consultas no cambia porque las pidas juntas.
Cobrar las llamadas por lotes a un precio artificialmente bajo crea una distorsión extraña. Premia reestructurar tu integración en torno a grandes llamadas por lotes solo para ahorrar dinero, y no porque los lotes encajen de verdad en tu flujo de trabajo. También hace que la planificación de capacidad real de un proveedor sea más difícil de entender desde fuera, ya que una "solicitud" deja de ser una unidad de trabajo coherente. Un cliente que compara proveedores por solicitudes al día no puede compararlos de forma justa si la solicitud de un proveedor puede contener en secreto mil consultas y la de otro no.
Contar por elemento también mantiene útiles nuestras cabeceras de cuota. Cada respuesta incluye cuánto has usado y cuánto te queda, y ese número solo significa algo si una solicitud es una solicitud, sin importar cómo esté construida. Si un lote de mil elementos costara en silencio una sola unidad, esas cabeceras no te dirían casi nada sobre tu consumo real, y descubrirías la cifra verdadera solo cuando un patrón de uso mucho mayor y sin lotes alcanzara un límite que no esperabas.
También hay un argumento de equidad. Un cliente que envía llamadas individuales y un cliente que envía lotes nos piden hacer la misma cantidad total de trabajo por el mismo precio total. Cobrar menos por consulta al cliente de los lotes, solo porque las solicitudes van agrupadas, significaría que el cliente de llamadas individuales está subvencionando en la práctica una infraestructura que no es él quien sobrecarga. Cobrar lo mismo por consulta a ambos mantiene el precio ligado al trabajo, no a cómo se empaquetó ese trabajo.
Nada de esto hace que los lotes no sirvan para nada. Siguen siendo la forma correcta de enviar un conjunto grande y conocido de consultas en un solo viaje de ida y vuelta, y los admitimos porque menos conexiones y menos sobrecarga son una mejora real de eficiencia en tu lado. Lo que los lotes no deberían hacer, en ningún lado de la solicitud, es cambiar lo que cuestan realmente las consultas. Mil consultas son mil consultas, tanto si llegan una a una a lo largo de una tarde como si llegan todas juntas en una sola llamada.