Webhooks in Simbase einrichten

Ein Webhook ist eine Nachricht, die deine App in dem Moment erhält, in dem etwas passiert. So musst du nicht ständig in einer Schleife fragen: "Gibt es schon was Neues?" Passiert etwas in deinem Simbase-Konto, schickt Simbase dieses Event in Echtzeit an eine URL, die du kontrollierst.

So bindest du Simbase an den Rest deines Stacks an. Eine SMS kommt auf einer SIM an und dein Slack-Kanal meldet sich. Ein Gerät wechselt die IMEI und dein Ticketsystem eröffnet einen Incident. Das monatliche Datenvolumen überschreitet einen Schwellenwert und dein Nutzungs-Dashboard wird aktualisiert. Und das alles ohne Code, der ständig unsere API abfragt.

Webhooks decken die Events ab, die auf Seiten von Simbase passieren: eingehende SMS, IMEI-Wechsel, Statusänderungen von SIMs und erreichte Nutzungslimits.

Bereit für den Live-Betrieb? Registriere deinen Webhook-Endpoint im Dashboard, damit Simbase weiß, wohin die Events gehen sollen.

So nutzt Simbase Webhooks

Wenn in deinem Konto etwas passiert, sendet Simbase einen HTTPS-POST an die von dir angegebene URL, mit einem JSON-Body, der das Event beschreibt. Deine App liest den Body, macht damit, was du willst, und antwortet mit einem 2xx-Statuscode, um den Empfang zu bestätigen.

Auf der Empfängerseite musst du nichts Aufwendiges bauen. Die "von dir angegebene URL" kann Folgendes sein:

• Eine No-Code-Automatisierungsplattform wie Zapier oder Make.com

• Ein Team-Chat wie Slack oder Microsoft Teams, über die eingebauten Incoming-Webhook-URLs (direkt oder mit Zapier oder Make.com dazwischen)

• Eine Funktion in deinem eigenen Backend, in jeder Programmiersprache

• Ein externer SMS-Anbieter wie Twilio oder MessageBird, wenn du SMS an öffentliche Telefonnummern weiterleiten willst

• Eine Serverless-Funktion auf AWS Lambda, Vercel, Cloudflare Workers, Google Cloud Functions usw.

Wenn du uns eine HTTPS-URL gibst, können wir Events dorthin senden.

Webhook-Events

Simbase unterstützt diese Event-Typen:

• Empfangene SMS

• IMEI-Wechsel

• Statusänderungen der SIM

• Nutzungslimit erreicht

Empfangene SMS

SIMs mit den Profilen Black, Red und Green befinden sich in einem sogenannten geschlossenen SMS-Kreislauf. Konkret: Die SIM kann SMS an unseren Server unter der Kurznummer +55555 senden und SMS von unserem Server empfangen, aber keine SMS mit anderen Telefonnummern austauschen. Das ist Absicht. Diese Sicherheitsmaßnahme macht deine Geräteflotte aus dem öffentlichen SMS-Netz unerreichbar: Niemand kann deinen Geräten schreiben, kein Premium-SMS-Betrug kann dein Guthaben leeren, und SMS lässt sich nicht als Angriffsweg gegen deine Hardware nutzen.

SIMs mit den Profilen Blue, Yellow und Cyan haben eine MSISDN, externe Nummern können ihnen also SMS schicken. Nachrichten, die diese Geräte senden, bleiben trotzdem innerhalb von Simbase und werden nie an ein externes Telefon zugestellt. Der Webhook verhält sich daher bei jedem Profil gleich. Siehe SMS für die Details pro Profil.

Wenn dein Gerät eine SMS an +55555 sendet, passieren zwei Dinge:

1. Die Nachricht erscheint im Simbase-Dashboard.

2. Wenn du einen SMS-Webhook registriert hast, leitet Simbase die komplette Nachricht per HTTPS an deinen Endpoint weiter.

Diesen zweiten Schritt unterschätzen die meisten Kunden. Die Payload enthält den Nachrichtentext, die ICCID der SIM, den Gerätenamen und einen Zeitstempel. Sobald sie auf deinem Endpoint ankommt, kannst du damit machen, was du willst.

Ein paar echte Beispiele, was Kunden mit diesem Webhook bauen:

• Den SMS-Text an einen Slack- oder Microsoft-Teams-Kanal weiterleiten, damit das Team Gerätemeldungen live sieht. Praktisch für Asset-Tracker, Verkaufsautomaten, entfernte Sensoren oder jedes Gerät, das per SMS berichtet.

• Die Payload an Zapier oder Make.com übergeben und alles auslösen, was diese Plattformen können: in Google Sheets protokollieren, eine E-Mail senden, ein CRM aktualisieren, ein Ticket in Zendesk oder Intercom anlegen, in Notion posten usw. Ganz ohne Code.

• Die SMS über Twilio, MessageBird oder einen anderen SMS-Anbieter an eine externe Telefonnummer weiterleiten. Dein Gerät sendet eine SMS über Simbase, dein Webhook empfängt sie, dein Code gibt den Text an Twilio weiter, und Twilio stellt ihn auf einem normalen Handy zu. So bauen Kunden eine Einbahnbrücke von einer abgeschotteten IoT-Flotte zu einer normalen Telefonnummer, ohne die Sicherheit des geschlossenen Kreislaufs aufzugeben.

• Messwerte oder Befehle aus dem SMS-Text auslesen und in deiner eigenen Datenbank oder einer Zeitreihendatenbank wie InfluxDB oder TimescaleDB speichern.

• Eine Aktion auf der SIM auslösen. Dein Endpoint empfängt die SMS, entscheidet "dieses Gerät verhält sich falsch" und ruft die Simbase API auf, um die SIM zu deaktivieren.

Für alle, die keinen Code schreiben, die Kurzfassung: Der SMS-Webhook macht aus "eine SMS ist auf einer SIM angekommen" ein "Slack hat sich gemeldet", "die Tabelle wurde aktualisiert", "das Team hat eine E-Mail bekommen" oder "ein Ticket wurde eröffnet". Du musst nicht wissen, wie SMS-Routing funktioniert. Du musst Simbase nur die richtige URL geben. Siehe SMS.

JSON-Body des Webhooks

{
  "event": "sms",
  "iccid": "8900000000001234567",
  "timestamp": "2026-08-06 12:00:00",
  "message": "test SMS message",
  "deviceName": "Demo device"
}

IMEI-Wechsel

Jedes Gerät hat eine IMEI (International Mobile Equipment Identity), eine eindeutige 15-stellige Kennung, die fest in der Hardware steckt. Wird deine SIM in ein anderes Gerät eingesetzt, erkennt das Mobilfunknetz die neue IMEI und meldet sie. Simbase kann deinen Endpoint sofort darüber informieren.

Warum das wichtig ist, hängt von deinem Geschäft ab. Bei Asset-Tracking, Logistik oder Flottenmanagement ist ein unerwarteter IMEI-Wechsel eines der stärksten Signale, dass eine SIM aus ihrem vorgesehenen Gerät entfernt wurde: durch Diebstahl, Manipulation oder eine schiefgelaufene Wartung. Für OEMs, die vorkonfigurierte Geräte ausliefern, bestätigen IMEI-Wechsel, dass jede SIM im richtigen Gerät gelandet ist.

Was Kunden typischerweise mit diesem Webhook machen:

• Das Event an Slack oder per E-Mail senden, damit dein Operations-Team es prüfen kann.

• Automatisch ein Ticket in deinem Support-Tool eröffnen, wenn die neue IMEI zu keinem erwarteten Gerät passt.

• Die SIM über die Simbase API deaktivieren, wenn deine Sicherheitsrichtlinie unerwartete IMEI-Wechsel als Betrugssignal wertet.

• Den Wechsel in deiner Asset-Datenbank protokollieren, damit du immer weißt, welche SIM in welchem Gerät steckt, ohne manuellen Abgleich.

• Das Event für Compliance und Forensik an ein SIEM oder Audit-Log übergeben.

JSON-Body des Webhooks

{
  "event": "imei",
  "timestamp": "2026-08-06 12:00:00",
  "iccid": "8900000000001234567",
  "oldIMEI": "None",
  "newIMEI": "355234090012345",
  "action": "disabled",
  "deviceName": "Demo device"
}

Statusänderungen der SIM

Eine SIM hat einen Status, der angibt, ob sie gerade aktiviert oder deaktiviert ist. Der Status kann sich aus mehreren Gründen ändern:

• Manuelles Aktivieren oder Deaktivieren über das Dashboard oder die API

• Automatische Aktivierung bei der ersten Nutzung der SIM

• Aufgebrauchtes Guthaben

• Vorfälle wie Diebstahl oder Betrugsverdacht

• Nicht autorisierte IMEI-Wechsel

Ändert sich der Status, sendet Simbase den neuen Status an deinen Webhook, damit der Rest deines Stacks reagieren kann. Siehe SIM-Status.

Was Kunden meist mit diesem Event machen:

• Ein internes CRM, ERP oder eine Asset-Datenbank mit dem tatsächlichen Status jeder SIM synchron halten, ohne ständig die Simbase API abzufragen.

• Eine Benachrichtigung in Slack oder per E-Mail erhalten, sobald eine SIM deaktiviert wird, damit der Support davon weiß, bevor der Kunde anruft.

• Die Abrechnung automatisch anstoßen, wenn eine SIM zum ersten Mal aktiviert wird, indem das Event über Zapier oder dein eigenes Backend an Stripe, Chargebee oder einen eigenen Abrechnungsdienst geht.

• Überraschungen früh erkennen. Wurde eine SIM deaktiviert und niemand im Team hat damit gerechnet, behandle das automatisch als Incident.

JSON-Body des Webhooks

{
  "event": "sim_state",
  "timestamp": "2026-08-06 12:00:00",
  "iccid": "8900000000001234567",
  "old_state": "enabled",
  "new_state": "disabled",
  "deviceName": "Demo device"
}

Nutzungslimit erreicht

Du kannst für jede SIM ein monatliches Daten- oder SMS-Limit festlegen. Überschreitet die Nutzung dieses Limit, deaktiviert Simbase die SIM automatisch, und dieser Webhook informiert den Rest deines Stacks sofort darüber.

Limits werden geprüft, wenn Nutzungsdaten vom Netzbetreiber eintreffen, nicht in Echtzeit. Eine SIM kann ihr Limit daher leicht überschreiten, bevor sie deaktiviert wird. Unter Nutzungslimits erfährst du, warum das passiert und wie du dafür planst.

So erkennst du ein auffälliges Gerät frühzeitig. Eine SIM, die normalerweise 10 MB im Monat verbraucht und plötzlich ihr Limit erreicht, will dir meist etwas sagen: ein Firmware-Bug, ein schiefgelaufener WLAN-Fallback, ein Gerät, das im Debug-Modus geblieben ist, ein außer Kontrolle geratenes OTA-Update oder im schlimmsten Fall eine gestohlene SIM, die für Tethering genutzt wird.

Was Kunden typischerweise mit diesem Event machen:

• Eine Benachrichtigung an Slack oder per E-Mail senden, damit das Team weiß, dass eine SIM offline ist, bevor der Kunde anruft

• Bei Deployments mit hoher Priorität einen Incident in PagerDuty oder Opsgenie eröffnen

• Das Gerät prüfen und die SIM dann über die Simbase API wieder aktivieren oder ihr Limit erhöhen

• Einen Zapier- oder Make.com-Flow auslösen, der den Geräteinhaber informiert

• Das Event in einem Dashboard für Nutzungsanomalien protokollieren, um flottenweite Trends über die Zeit zu erkennen

JSON-Body des Webhooks

{
  "event": "usage_limits",
  "timestamp": "2026-08-06 12:00:00",
  "iccid": "8900000000001234567",
  "usage_mb": 102,
  "threshold_mb": 100,
  "usage_sms": 0,
  "threshold_sms": null
}

So empfängst du Webhooks

In wenigen Schritten empfängst du Event-Benachrichtigungen in deiner App:

1. Lege fest, auf welche Events du hören willst und welche Felder der Payload du wirklich brauchst.

2. Erstelle einen HTTP(S)-Endpoint für die Events. Das kann eine Route in deinem Backend sein, eine Serverless-Funktion, eine Webhook-URL von Zapier oder Make.com, ein Slack Incoming Webhook (mit einer kleinen Umwandlung davor) oder jede andere URL, die POST-Requests annimmt.

3. Parse den JSON-Body auf deiner Seite und gib einen 2xx-Statuscode zurück. Für Simbase zählt nur der Statuscode, nicht der Response-Body.

4. Teste den Endpoint mit einem Tool wie Postman oder curl. Willst du echte Simbase-Events empfangen, während du auf deinem Laptop entwickelst, eignet sich ein Tunnel-Tool wie ngrok oder Cloudflare Tunnel.

5. Stelle deinen Endpoint hinter einer öffentlich erreichbaren HTTPS-URL bereit.

6. Registriere diese URL im Simbase-Dashboard unter Integrations → Webhooks.

7. Simbase sendet ein Test-Event an deine URL. Antwortet dein Endpoint mit einem 2xx-Code, wird der Webhook gespeichert und empfängt ab dann Live-Events.

Spezifikationen

Methode

Alle Aufrufe von Simbase an deinen Webhook sind HTTP-POST-Requests mit einem JSON-Body.

Sicherheit

• Nutze keine IP-Filterung als Sicherheitsmaßnahme. Unsere Server sind weltweit verteilt und die öffentlichen IPs, von denen gesendet wird, ändern sich mit der Zeit. Eine IP-Allowlist bricht also im ungünstigsten Moment.

Häufige Fragen

Weiterführende Artikel

• SMS: die Nachrichten, die der Webhook für empfangene SMS weiterleitet, und wie sie sich je Profil unterscheiden

• Diebstahlschutz: eine SIM an eine IMEI binden, damit ein Wechsel blockiert und nicht nur gemeldet wird

• SIM-Status: was Aktiviert und Deaktiviert bedeuten und was den Status ändert

• Nutzungslimits: das Limit festlegen, das den Nutzungs-Webhook auslöst

• API-Schlüssel: einen Schlüssel erstellen und auf das beschränken, was die Integration braucht

• API: Webhooks per Code auflisten, anlegen und löschen