Crea un límite de consumo personalizado con el Simbase Usage Guard Toolkit

Los límites de uso integrados de Simbase comprueban el consumo cuando llegan los CDR de la red, normalmente cada pocas horas. Si necesitas controles más frecuentes (cada 30 minutos, cada 5 minutos, bajo demanda) o lógica personalizada (avisar ante una alerta, desactivar solo ciertas SIM, excluir el horario laboral), el Usage Guard Toolkit es una automatización sin código que puedes montar tú mismo con la API de Simbase y Make.com.

En este artículo verás qué hace el Toolkit, cuándo es la opción adecuada y cómo configurarlo.

Qué hace el Toolkit

Una automatización programada que:

consulta la API de consumo de Simbase para cada SIM de tu cuenta (o un subconjunto filtrado).
compara el consumo de cada SIM con un umbral que tú defines.
desactiva las SIM que superan el umbral a través de la API de Simbase.
te avisa (Slack, email, webhook, un registro en Google Sheets, lo que conectes).

Está construido sobre Make.com porque es visual, no requiere código y la mayoría de los clientes lo tienen funcionando en menos de 15 minutos. La misma lógica funciona en Zapier, n8n o un script propio. Make.com es simplemente la opción que Simbase ha documentado.

Cuándo es el Toolkit la opción adecuada

Elige el Toolkit en lugar de los límites de uso nativos (o junto a ellos) cuando necesites:

Intervalos de comprobación más cortos. Los límites de uso nativos se aplican cuando llegan los CDR; el Toolkit puede ejecutarse tan a menudo como permita tu plataforma de automatización.
Flujos de notificación personalizados. ¿Quieres un aviso en Slack al 80 % del límite y desactivar al 100 %? Constrúyelo.
Umbrales en varios niveles. Avisar, luego desactivar y luego alertar al equipo de operaciones, todo en un solo flujo.
Condiciones según reglas de negocio. No desactivar los fines de semana, ignorar ciertos tags, desactivar solo SIM de prueba, etc.
Integración con otros sistemas. Sincronizar el consumo con tu CRM, registrar cada desactivación en un data warehouse, etc.

Quédate con los límites de uso nativos cuando:

El comportamiento por defecto (desactivar al superar el límite, con reinicio mensual automático opcional) es lo que quieres.
No quieres mantener una automatización de terceros.
No necesitas notificaciones ni lógica de negocio personalizadas.

Puedes usar ambos: los límites de uso nativos como base y el Toolkit para los casos especiales. No entran en conflicto.

Lo que el Toolkit no puede hacer

La misma limitación que los límites de uso nativos: depende de los datos de consumo de Simbase, que a su vez dependen de la llegada de los CDR desde la red. Un Toolkit que se ejecuta cada 5 minutos sigue trabajando con CDR que pueden tener horas de antigüedad.

Para un límite estricto en tiempo real de verdad, tendrías que controlar el consumo de datos en el propio dispositivo y hacer que el dispositivo corte la conexión al llegar al límite. Eso queda fuera de lo que Simbase o Make.com pueden ofrecer.

Blueprint

Make.com scenario showing the Usage Guard flow: query usage, iterate, get SIM state, disable SIM.

Si parece complicado, no te preocupes. Este tutorial te guía paso a paso para crear tu propio Usage Guard Toolkit. No tienes que escribir código y te mostramos exactamente cómo configurarlo en Make.com.

Configurar el Toolkit

Paso 1: Elige tu plataforma de automatización

Si es tu primera vez, te recomendamos Make.com:

Editor visual de flujos, sin código.
El plan gratuito basta para flotas pequeñas.
Los planes de pago admiten flotas más grandes e intervalos más cortos.

Zapier, n8n, Pipedream o un script propio en Python o Node también sirven. El resto de esta guía usa Make.com; los mismos módulos y la misma lógica se aplican en otras plataformas.

Paso 2: Crea una clave de API de Simbase

Inicia sesión en dashboard.simbase.com.
Ve a Integrations → API.
Haz clic en Create New API Key.
Ponle el nombre Usage Guard Toolkit (o algo parecido).
Configura All resources en Write. Deja la configuración avanzada con sus valores por defecto.
Haz clic en Create y copia la clave.

Consulta Claves de API para ver qué cubre cada nivel de permisos.

Trata la clave de API como una contraseñaCualquiera con esta clave puede gestionar tus SIM. Guárdala en el gestor de secretos o conexiones de tu plataforma de automatización, nunca en texto plano.

Paso 3: Importa el blueprint de Make.com

Simbase publica un blueprint preconfigurado que puedes importar en un solo paso:

Descarga el blueprint (busca Simbase-Usage-Guard-Toolkit.blueprint.json, ~27 KB).
En Make.com, crea un escenario nuevo.
Usa Import Blueprint y selecciona el JSON descargado.
Abre cada uno de los tres módulos HTTP y sustituye el marcador YoUrApiKeYHeRe por tu clave de API.
Ajusta el umbral de consumo en el módulo de comparación (ejemplo por defecto: 10 GB).
Prueba el escenario manualmente antes de activar la programación.

El blueprint cubre el flujo básico: obtener el consumo → recorrer las SIM → comparar con el umbral → comprobar el estado actual de la SIM → desactivar las SIM que aún no están desactivadas.

Paso 4: Adáptalo a tus necesidades

El blueprint es un punto de partida. Personalizaciones habituales:

Conversión del umbral. La API devuelve el consumo en bytes, en gigabytes binarios: 1 GB = 1.073.741.824 bytes, así que 10 GB = 10.737.418.240. No es la misma convención que en el panel, donde un límite de uso de 1 GB equivale a 1.000 MB. Un umbral de 10 GB en el Toolkit es aproximadamente un 7 % más alto que un límite de uso de 10 GB. Si quieres que coincidan, pon la comparación del Toolkit en 10.000.000.000.
Paginación. Necesaria a partir de unas 500 SIM. Consulta Paginación para flotas grandes más abajo.
Notificaciones. Añade un módulo que envíe un mensaje de Slack, un email o un webhook cuando una SIM supere el umbral.
Filtro por tag. Aplica la comprobación solo a las SIM con un tag concreto (por ejemplo, solo production y no test).

Recorrer el array de SIM

La API de consumo devuelve un array de objetos SIM en el campo data.simcards de la respuesta. Para procesar cada una por separado en Make.com:

En el módulo HTTP, pon Parse response en Yes.
Añade un módulo Iterator a tu escenario.
Configura el array del iterador como data.simcards de la respuesta HTTP.

Cada iteración es entonces una sola SIM que puedes comparar y procesar.

Paginación para flotas grandes

El blueprint no incluye paginación por defecto. Funciona sin cambios para flotas de hasta unos cientos de SIM. Para flotas más grandes:

Comprueba si la respuesta de la API contiene "has_more": true.
Si es así, lee el valor de cursor de la respuesta.
Haz otra solicitud a /v2/usage/simcards?cursor=<value>.
Repite hasta que has_more sea false.

En Make.com, esto se hace con un Repeater y un bucle de solicitudes HTTP, algo que queda fuera del alcance del blueprint básico.

Aviso legal

El Usage Guard Toolkit es una solución que montas tú mismo. Aunque usa la API oficial de Simbase, Simbase no se hace responsable de:

Límites no aplicados por retrasos en los CDR o en la API.
SIM que no se desactivan a tiempo.
Los excesos, costes o interrupciones del servicio que resulten.

Prueba tu configuración con cuidado, vigílala con regularidad y no la uses como única protección para SIM en las que un sobrecoste sería catastrófico.

Preguntas frecuentes

Sí. La lógica se traslada tal cual. El blueprint de Make.com es un punto de partida; recrea los mismos módulos en Zapier con pasos de solicitud HTTP.

Sí. Añade un escenario programado que se ejecute el día 1 de cada mes y reactive las SIM según un tag o un filtro. El Monthly Auto-Reset nativo de los límites de uso ya lo hace por ti si solo necesitas el comportamiento básico.

Más a menudo no significa más preciso. El Toolkit lee los datos de consumo de Simbase, que solo se actualizan cuando llegan los CDR de la red, a menudo con horas de diferencia. Ejecutarlo cada 5 minutos sobre todo vuelve a leer las mismas cifras y gasta operaciones de automatización. Cada 15 a 30 minutos es suficiente para la mayoría de las flotas.

Nada desactiva las SIM. El Toolkit es lo único que aplica tu umbral personalizado, así que un escenario en pausa, una clave de API caducada o un plan de Make.com agotado eliminan la protección sin avisar. Activa las notificaciones de error en Make.com y mantén activados los límites de uso nativos como red de seguridad.