El acceso de equipo a un saldo compartido es cómodo solo hasta el primer mes en que el gasto no coincide con lo esperado. Una cuenta común, sin separar por empleado ni por tarea, no responde quién gastó el presupuesto y en qué, hasta que abres el historial de operaciones línea por línea. Vemos cómo limitar el gasto con claves, umbrales y direcciones, y cómo encontrar rápido el proceso que quema dinero más deprisa que los demás.
Por qué un saldo compartido sin límites se agota sin que lo notes
Un solo saldo para todo el equipo funciona hasta el primer error. En cuanto se conectan varios empleados o varios procesos automatizados, el dinero se descuenta en paralelo, y lo notas solo a posteriori, cuando el saldo ya está cerca de cero. Un saldo compartido y sin separación responde a la pregunta «cuánto queda», no a la pregunta «quién lo gastó».
El problema se agrava porque el gasto por API no pide confirmación en cada paso: un script que lanza mil activaciones seguidas descontará mil activaciones seguidas, y el primero en enterarse no será el autor del script, sino quien se quedó sin saldo para una tarea urgente. El límite no hace falta porque no confíes en tus empleados, sino porque nadie puede vigilar físicamente el contador de gasto en tiempo real.
Claves separadas con distintos límites: dividir tareas y empleados
La práctica que funciona no es una sola clave de API para todo el equipo, sino una clave por empleado o por tarea: registro masivo, monitoreo, entorno de pruebas. Cada clave tiene su propio límite de gasto, así que la falla de un proceso no bloquea a los demás ni se come el presupuesto asignado a otra tarea. La configuración de las claves y sus parámetros está descrita en la documentación de la API.
Dividir por claves también resuelve la cuestión de la responsabilidad: si el gasto de una clave concreta se sale de lo normal, se ve de inmediato qué proceso o qué empleado lo causó, sin revisar el historial general línea por línea. Puedes desactivar una clave comprometida o que funciona mal sin detener el resto de las tareas del equipo.
Umbrales de gasto diarios y mensuales
Un único límite para todo el período pagado no detecta una quema rápida: si el umbral mensual es de quinientas unidades, y un proceso con un error gasta esa suma en tres horas, el límite mensual lo detendrá solo cuando el presupuesto ya esté en cero. El umbral diario detecta el problema ese mismo día, y no a fin de mes.
El esquema que funciona es mantener ambos umbrales a la vez: el diario limita la velocidad de quema en una clave concreta, y el mensual limita el presupuesto total de la tarea o del empleado durante el período. El límite diario conviene fijarlo con margen para la carga de trabajo normal, no al ras, porque de lo contrario frenará trabajo legítimo en los días de mayor actividad.
Monitoreo por dirección y alertas al llegar al umbral
Una dirección es un par concreto de país más servicio, y el gasto casi nunca se reparte de forma pareja: una o dos direcciones suelen consumir una parte desproporcionada del presupuesto. Monitorear el gasto por direcciones, y no solo por el total, muestra rápido qué combinación está drenando el presupuesto, antes de que se convierta en un problema para todo el saldo.
Una alerta que salta cuando el límite ya se agotó no sirve de nada: la tarea ya se detuvo. El esquema que funciona es una notificación escalonada al 70–80% del umbral asignado, para que te dé tiempo de revisar, y una segunda al 95%, cuando toca detener a mano los procesos no críticos. Ambos umbrales se configuran a nivel de clave, no del saldo general; si no, la alerta volverá a llegar demasiado tarde.
Escenario típico: un ciclo de reintentos en una dirección muerta se come el presupuesto en horas
Un incidente frecuente es este: una dirección que ayer entregaba el código con estabilidad de repente deja de entregar SMS por completo, porque el operador cambió la ruta o la dirección cayó temporalmente en el proveedor. Un proceso con reintento automático ante una activación cancelada no distingue entre «tuve mala suerte una vez» y «la dirección está muerta»: pide un número una y otra vez, y cada intento se descuenta del saldo.
Sin un límite diario en la clave, un ciclo así puede gastar en unas horas el presupuesto calculado para una semana. Por eso, en el historial de operaciones conviene revisar cada semana no solo el gasto total, sino también la serie de cancelaciones seguidas en una misma dirección: tres a cinco cancelaciones seguidas en un mismo par país-servicio son una señal para detener esa dirección, y no para volver a intentarlo.
Preguntas frecuentes
¿Cuántas claves conviene crear para un equipo?
Como referencia, una clave por empleado o por proceso independiente, y no una sola clave común para todo el equipo. Dividir tiene sentido mientras cada clave corresponda a una zona de responsabilidad y no se convierta en un mero trámite.
¿Qué hacer si el límite de una clave se agota en medio de una tarea?
Subir el límite de esa clave de forma puntual suele ser más rápido y seguro que quitar la restricción por completo: así el problema de un proceso no se traslada al resto de las claves del equipo. Si un límite siempre queda corto en una tarea activa, conviene revisarlo al alza, y no desactivar el control del todo.
¿Cómo distinguir un pico normal de gasto de una quema en una dirección muerta?
Un pico normal se reparte entre distintas direcciones y servicios. Una quema es la concentración del gasto en un solo par país-servicio, con una alta proporción de intentos cancelados o fallidos seguidos, algo que se ve en el historial de operaciones del mismo día.
El historial completo de descuentos por cada clave y dirección está en la sección de historial de operaciones: ahí ves qué clave y qué dirección conviene detener primero. Otra partida de gasto oculta de un equipo son los números en alquiler que están parados; la analizamos en el artículo revisión de la flota de números.