Onboarding von Kundenseiten ohne Mehraufwand: Provisionierung per API

Jede Agentur kennt den Moment: Ein neuer Kunde ist unterschrieben, und bevor das erste Monitoring läuft, klickst du dich durch Formulare: Kunde anlegen, Paket zuweisen, Seite eintragen, Monitore konfigurieren, interne Notizen ergänzen. Bei einem Kunden ist das lästig. Bei zwanzig ist es ein halber Arbeitstag. Die Provisionierung per API macht aus diesem Klickpfad ein Skript, das in Sekunden durchläuft. Neue Kundenseiten werden in Minuten statt manuell angelegt. Dieser Artikel zeigt dir die konkrete Sequenz, die Rolle von Custom Fields und wie du ein ganzes Onboarding automatisierst.

Das Problem: manuelles Onboarding skaliert nicht

Das manuelle Anlegen eines Kunden ist einzeln betrachtet harmlos: ein paar Formulare, ein paar Minuten. Das Problem ist die Wiederholung. Jeder Schritt ist fehleranfällig (ein vergessenes Feld, eine falsche URL, ein übersehener Monitor), jeder Schritt ist unproduktive Zeit, und die Summe wächst linear mit deiner Kundenzahl. Genau in dem Moment, in dem deine Agentur wächst, wird das Onboarding zum Flaschenhals.

Dazu kommt die Inkonsistenz. Wer manuell anlegt, macht es jedes Mal ein bisschen anders: mal ist die Kundennummer hinterlegt, mal nicht, mal heißt der Monitor „DNS Acme", mal „acme dns check". Diese Unsauberkeiten rächen sich später bei Reports, Filtern und Übergaben. Automatisierung löst beide Probleme auf einmal: Sie kostet pro Kunde nahezu keine Zeit mehr, und sie legt jeden Kunden nach exakt demselben Muster an.

Die Grundmechanik: Bearer-Token und ein REST-Aufruf

Bevor die eigentliche Sequenz kommt, die Basis. Die Uptimeify-API ist eine klassische REST-Schnittstelle: Du schickst JSON an einen Endpoint, du bekommst JSON zurück. Authentifiziert wird über einen Bearer-Token, den du im Dashboard unter Einstellungen → API erzeugst. Jeder Token beginnt mit wsm_. Fehlt dieses Präfix, antwortet die API mit 401 Unauthorized.

Ein Aufruf sieht in seiner einfachsten Form so aus:

BASE_URL="https://uptimeify.io"
TOKEN="wsm_<dein-api-token>"

curl -H "Authorization: Bearer $TOKEN" "$BASE_URL/api/customers"

Mehr Grundwissen brauchst du für den Anfang nicht. Wer schon einmal ein Shell-Skript geschrieben hat, hat alles beisammen, um das Onboarding zu automatisieren: kein SDK, kein Framework, keine Build-Pipeline. Ein Detail lohnt sich vorab: Tokens lassen sich organisationsweit oder kundenspezifisch ausstellen. Für Provisionierungs-Skripte, die alle Kunden anlegen dürfen, nimmst du einen organisationsweiten Token; für eine Integration, die nur einen einzelnen Kunden betreffen soll, einen kundenspezifischen. Alles außerhalb des Scopes wird mit 403 Forbidden abgewiesen.

Die Provisionierungs-Sequenz in zwei Aufrufen

Der Kern des Onboardings sind zwei Aufrufe. Der erste legt den Kunden an, der zweite die erste Seite, und verknüpft sie über die zurückgegebene ID.

Schritt 1: Kunde anlegen. Ein POST auf /api/customers erstellt den Kunden. Paket und beliebige Custom Fields gehen in derselben Anfrage mit:

curl -X POST "$BASE_URL/api/customers" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Acme GmbH",
    "email": "ops@deinkunde.com",
    "packageType": "business",
    "customFields": {
      "internalReference": "KD-999",
      "region": "EU"
    }
  }'

Die Antwort enthält die neue Kunden-ID, sowohl als interne id als auch als publicId (UUID). Diese ID ist der Faden, an dem alles Weitere hängt.

Schritt 2: Erste Seite verknüpfen. Mit der customerId aus Schritt 1 legst du per POST auf /api/websites die erste zu überwachende Seite an:

curl -X POST "$BASE_URL/api/websites" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": 123,
    "name": "Acme Marketing-Website",
    "url": "https://deinkunde.com"
  }'

Wichtig: Die url muss das Protokoll enthalten (https://…). Ab diesem Moment wird die Seite von mehreren EU-Standorten überwacht. Jeder Ausfall wird bestätigt, bevor ein Alarm ausgelöst wird. Zwei Aufrufe, und der Kunde ist im Monitoring. Was im Interface ein mehrminütiger Klickpfad war, ist jetzt ein Skript-Fragment, das in unter einer Sekunde durchläuft.

Weitere Monitore anhängen: DNS, Ping, SSL & Co.

Eine reine Uptime-Überwachung der Website ist oft nur der Anfang. Für einen vollständigen Monitoring-Sockel hängst du mit derselben customerId weitere Monitore an. Jeder Typ hat seinen eigenen Endpoint. Ein DNS-Monitor etwa:

curl -X POST "$BASE_URL/api/dns-monitors" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "customerId": 123,
    "name": "DNS: deinkunde.com",
    "hostname": "deinkunde.com",
    "dnsConfig": {
      "rrtypes": ["A"],
      "matchMode": "exact",
      "expectedValues": { "A": ["93.184.216.34"] }
    }
  }'

Nach demselben Muster laufen ICMP (Ping), SMTP, SSH, FTP und IMAP/POP, jeweils mit customerId, name und den typspezifischen Feldern. So entsteht aus der Provisionierungs-Sequenz eine Vorlage: ein Skript, das pro Kunde einen definierten Baseline-Satz an Monitoren anlegt, jedes Mal identisch. Ein Tipp aus der Praxis: Nutze konsistente Namens-Präfixe (DNS:, Ping:, SMTP:), damit Reports und Filter später sauber greifen.

Custom Fields: deine internen Strukturen von Sekunde eins

Der Unterschied zwischen „irgendwie angelegt" und „sauber ins System einsortiert" sind Custom Fields. Sie hängen deine eigenen Metadaten an einen Kunden oder eine Seite: die interne Kundennummer, das betreuende Team, die Umgebung (Produktion, Staging), die Region. Es gibt sie in drei Ausprägungen: als freies Textfeld, als Auswahlfeld (Select) und als Mehrfachauswahl (Multiselect).

Angelegt werden die Feld-Definitionen einmalig über /api/custom-fields:

curl -X POST "$BASE_URL/api/custom-fields" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "organizationId": 1,
    "name": "Umgebung",
    "fieldType": "select",
    "options": ["production", "staging", "development"],
    "isRequired": true
  }'

Danach befüllst du sie, wie oben gesehen, direkt im customFields-Objekt beim Anlegen des Kunden. Der Effekt: Jeder per Skript provisionierte Kunde ist von der ersten Sekunde an vollständig verschlagwortet. Keine „das trage ich später nach"-Zettel, keine halbgepflegten Datensätze. Automatisierung erzwingt hier die Sauberkeit, die manuelles Anlegen ständig unterläuft.

Vom Einzelfall zum Bulk-Onboarding

Der volle Hebel der API zeigt sich erst im Mengengeschäft. Sobald die Provisionierungs-Sequenz als Skript steht, ist der Sprung von einem Kunden zu hundert nur noch eine Schleife. Du hinterlegst deine Kunden in einer Liste, etwa einer CSV mit Name, E-Mail und URL, und rufst pro Zeile dieselbe Sequenz auf:

while IFS=, read -r name email url; do
  # 1) Kunde anlegen, customerId aus der Antwort lesen
  # 2) Seite mit dieser customerId verknüpfen
  # 3) Baseline-Monitore anhängen
done < kunden.csv

Weil die API bis zu 600 Anfragen pro Minute zulässt, lassen sich auch größere Migrationen in einem einzigen Durchlauf abwickeln. Genau hier zahlt sich Automatisierung am deutlichsten aus: Ein bestehender Kundenstamm, der bisher außerhalb des Monitorings lag, wandert in einem Rutsch hinein, ohne dass jemand hundertmal dieselben Formulare ausfüllt. Aus einem Projekt, das man wochenlang vor sich herschiebt, wird ein Skript-Lauf von wenigen Minuten.

Der eigentliche Gewinn: Onboarding als gelöstes Problem

Provisionierung per API ist im Kern keine technische Spielerei, sondern die Entscheidung, ein wiederkehrendes Problem ein einziges Mal zu lösen. Du schreibst die Sequenz einmal, Kunde, Seite, Monitore, Custom Fields, und danach ist jedes weitere Onboarding nur noch ein Aufruf dieses fertigen Ablaufs. Der Aufwand pro Neukunde fällt von Minuten auf nahezu null, und die Fehlerquelle „Mensch klickt Formular" verschwindet ganz.

Für die Tech-Spur deiner Agentur heißt das zweierlei. Erstens wird das Onboarding vom Flaschenhals zum Nicht-Thema. Es skaliert nicht mehr mit deiner Kundenzahl. Zweitens ist jeder Kunde vom ersten Moment an konsistent angelegt, sauber verschlagwortet und vollständig überwacht. Das ist der unsichtbare Unterbau, auf dem verlässliche Reports, Übergaben und Automatisierungen erst aufsetzen können.

Der Klickpfad war nie die Arbeit, für die dich dein Kunde bezahlt. Die API nimmt ihn dir ab, und gibt dir die Zeit zurück für das, was zählt.

Und wenn du lieber fragst als skriptest: Dieselbe Oberfläche erreicht auch ein KI-Assistent. Die Prompt-Bibliothek sammelt zwanzig fertige Prompts für die Checks und Kundenreports nach dem Onboarding, zehn davon ohne Konto.