Eigenes Nutzungslimit mit dem Simbase Usage Guard Toolkit bauen

Die integrierten Nutzungslimits von Simbase prüfen die Nutzung, sobald CDRs aus dem Netz eintreffen, meist alle paar Stunden. Wenn du engmaschigere Prüfungen (alle 30 Minuten, alle 5 Minuten, auf Abruf) oder eigene Logik brauchst (Benachrichtigung bei einer Warnung, nur bestimmte SIMs deaktivieren, Geschäftszeiten ausnehmen), ist das Usage Guard Toolkit eine No-Code-Automatisierung, die du selbst mit der Simbase API und Make.com baust.

Dieser Artikel erklärt, was das Toolkit macht, wann es die richtige Wahl ist und wie du es einrichtest.

Was das Toolkit macht

Eine zeitgesteuerte Automatisierung, die:

1. die Usage API von Simbase für jede SIM in deinem Konto (oder eine gefilterte Auswahl) abfragt.

2. die Nutzung jeder SIM mit einem von dir festgelegten Schwellenwert vergleicht.

3. SIMs über dem Schwellenwert über die Simbase API deaktiviert.

4. dich benachrichtigt (Slack, E-Mail, Webhook, Google-Sheets-Log, was auch immer du anbindest).

Es basiert auf Make.com als Plattform, weil das visuell ist, ohne Code auskommt und die meisten Kunden es in unter 15 Minuten zum Laufen bringen. Dieselbe Logik funktioniert in Zapier, n8n oder einem eigenen Skript. Make.com ist einfach der Weg, den Simbase dokumentiert hat.

Wann das Toolkit die richtige Wahl ist

Nimm das Toolkit statt der nativen Nutzungslimits (oder zusätzlich dazu), wenn du Folgendes brauchst:

• Kürzere Prüfintervalle. Die nativen Nutzungslimits greifen beim Eintreffen der CDRs; das Toolkit läuft so oft, wie deine Automatisierungsplattform es erlaubt.

• Eigene Benachrichtigungsabläufe. Eine Slack-Nachricht bei 80 % des Limits und Deaktivierung bei 100 %? Bau es einfach.

• Mehrstufige Schwellenwerte. Warnen, dann deaktivieren, dann das Ops-Team alarmieren, alles in einem Ablauf.

• Bedingungen nach Geschäftsregeln. Am Wochenende nicht deaktivieren, bestimmte Tags ignorieren, nur Test-SIMs deaktivieren und so weiter.

• Systemübergreifende Integration. Nutzung mit deinem CRM synchronisieren, jede Deaktivierung in einem Data Warehouse protokollieren und so weiter.

Bleib bei den nativen Nutzungslimits, wenn:

• das Standardverhalten (Deaktivierung bei Überschreitung, optionaler monatlicher Auto-Reset) genau das ist, was du willst.

• du keine Automatisierung bei einem Drittanbieter pflegen willst.

• du keine eigenen Benachrichtigungen oder Geschäftslogik brauchst.

Du kannst auch beides nutzen: native Nutzungslimits als Basis, das Toolkit für Sonderfälle. Die beiden kommen sich nicht in die Quere.

Was das Toolkit nicht kann

Gleiche Einschränkung wie bei den nativen Nutzungslimits: Es hängt von den Nutzungsdaten von Simbase ab, und die hängen davon ab, wann CDRs aus dem Netz eintreffen. Auch ein Toolkit, das alle 5 Minuten läuft, arbeitet mit CDRs, die Stunden alt sein können.

Für ein echtes Limit in Echtzeit musst du die Datennutzung auf dem Gerät selbst überwachen und das Gerät die Verbindung trennen lassen, sobald das Limit erreicht ist. Das können weder Simbase noch Make.com leisten.

Blueprint

Sieht kompliziert aus? Keine Sorge. Diese Anleitung führt dich Schritt für Schritt durch den Aufbau deines eigenen Usage Guard Toolkit. Du musst keinen Code schreiben, und wir zeigen dir genau, wie du alles in Make.com einrichtest.

Das Toolkit einrichten

Schritt 1: Automatisierungsplattform wählen

Für den Einstieg empfehlen wir Make.com:

• Visueller Flow-Builder, kein Code nötig.

• Die kostenlose Version reicht für kleine Flotten.

• Bezahlte Versionen schaffen größere Flotten und kürzere Intervalle.

Zapier, n8n, Pipedream oder ein eigenes Python- oder Node-Skript funktionieren ebenfalls. Der Rest dieser Anleitung nutzt Make.com; dieselben Module und dieselbe Logik gelten auch anderswo.

Schritt 2: Simbase API-Schlüssel erstellen

1. Melde dich an bei dashboard.simbase.com.

2. Geh zu Integrations → API.

3. Klick auf Create New API Key.

4. Gib ihm den Namen Usage Guard Toolkit (oder etwas Ähnliches).

5. Setz All resources auf Write. Lass die erweiterten Einstellungen auf den Standardwerten.

6. Klick auf Create und kopier den Schlüssel.

Unter API-Schlüssel steht, was jede Berechtigungsstufe abdeckt.

Schritt 3: Make.com-Blueprint importieren

Simbase stellt einen vorkonfigurierten Blueprint bereit, den du in einem Schritt importierst:

1. Lade den Blueprint herunter (die Datei heißt Simbase-Usage-Guard-Toolkit.blueprint.json, ca. 27 KB).

2. Leg in Make.com ein neues Szenario an.

3. Nutze Import Blueprint und wähle die heruntergeladene JSON-Datei aus.

4. Öffne jedes der drei HTTP-Module und ersetze den Platzhalter YoUrApiKeYHeRe durch deinen API-Schlüssel.

5. Passe den Nutzungsschwellenwert im Vergleichsmodul an (Standardbeispiel: 10 GB).

6. Teste das Szenario manuell, bevor du den Zeitplan aktivierst.

Der Blueprint deckt den Grundablauf ab: Nutzung abrufen → über SIMs iterieren → mit Schwellenwert vergleichen → aktuellen SIM-Status prüfen → SIMs deaktivieren, die noch nicht deaktiviert sind.

Schritt 4: An deine Anforderungen anpassen

Der Blueprint ist ein Ausgangspunkt. Typische Anpassungen:

• Schwellenwert umrechnen. Die API liefert die Nutzung in Bytes, gerechnet in binären Gigabyte: 1 GB = 1.073.741.824 Bytes, also 10 GB = 10.737.418.240. Das Dashboard rechnet anders: Dort entspricht ein Nutzungslimit von 1 GB genau 1.000 MB. Ein Toolkit-Schwellenwert von 10 GB liegt also rund 7 % über einem Nutzungslimit von 10 GB. Sollen beide übereinstimmen, setz den Vergleichswert im Toolkit stattdessen auf 10.000.000.000.

• Paginierung. Ab etwa 500 SIMs nötig. Siehe Paginierung für große Flotten weiter unten.

• Benachrichtigungen. Füge ein Modul hinzu, das eine Slack-Nachricht, E-Mail oder einen Webhook sendet, wenn eine SIM den Schwellenwert überschreitet.

• Tag-Filter. Prüfe nur SIMs mit einem bestimmten Tag (zum Beispiel nur production und nicht test).

Über das SIM-Array iterieren

Die Usage API liefert ein Array von SIM-Objekten im Feld data.simcards der Antwort. So verarbeitest du sie in Make.com einzeln:

1. Setz im HTTP-Modul Parse response auf Yes.

2. Füge ein Modul vom Typ Iterator hinzu.

3. Setz das Array des Iterators auf data.simcards aus der HTTP-Antwort.

Jede Iteration ist dann eine einzelne SIM, die du vergleichen und verarbeiten kannst.

Paginierung für große Flotten

Der Blueprint enthält standardmäßig keine Paginierung. Für Flotten bis zu ein paar hundert SIMs funktioniert er ohne Änderungen. Für größere Flotten:

• Prüfe die API-Antwort auf "has_more": true.

• Wenn ja, lies den Wert von cursor aus.

• Sende eine weitere Anfrage an /v2/usage/simcards?cursor=<value>.

• Wiederhole das, bis has_more false ist.

In Make.com löst du das mit einem Repeater und einer HTTP-Request-Schleife, was über den Basis-Blueprint hinausgeht.

Haftungsausschluss

Das Usage Guard Toolkit ist eine Do-it-yourself-Lösung. Es nutzt zwar die offizielle Simbase API, aber Simbase übernimmt keine Verantwortung für:

• Verpasste Limits durch Verzögerungen bei CDRs oder der API.

• SIMs, die nicht rechtzeitig deaktiviert werden.

• Daraus entstehenden Mehrverbrauch, Kosten oder Serviceunterbrechungen.

Teste dein Setup sorgfältig, überwache es regelmäßig und verlass dich bei SIMs, bei denen Kostenüberschreitungen katastrophal wären, nicht allein darauf.

Häufige Fragen

Weiterführende Artikel

• Nutzungslimits: die native Alternative mit weniger Aufwand

• Auto-disable: Deaktivierung nach Kalender

• API-Schlüssel: den Schlüssel erstellen und eingrenzen, mit dem sich das Toolkit authentifiziert

• API: die zugrunde liegende Schnittstelle

• Tags: praktisch, um das Toolkit auf Teile deiner Flotte zu beschränken