Skripte, CI und Automatisierung: n8n, Zapier, Make

Skripte, CI und Automatisierung (n8n, Zapier, Make)

In Skripten und CI-Pipelines genügt die API selbst: ein Token aus Einstellungen → API im Kopf Authorization: Bearer, der Rest ist curl und jq. Die Antworten sind dieselben JSON-Strukturen wie im Dashboard.

Für einen Deploy-Job ist meist die Frage entscheidend, ob etwas offen ist: status=critical auf der Domainliste, oder eine der kostenlosen Prüfungen, die ganz ohne Token läuft. Wer den Schritt scheitern lassen will, wertet die Anzahl der Befunde aus – jq macht daraus einen Exit-Code.

Schreibende Aufrufe (Domain anlegen, sofort prüfen) brauchen ein Token mit Schreibrecht; lesende genügen für alles andere.

CI-Schritt

export DOMAINWARN_TOKEN=dw_…
BASIS=https://api.domainwarn.com/api/v1/orgs/agentur

# kritische Domains; bricht den Schritt ab, wenn es welche gibt
curl -sf -H "Authorization: Bearer $DOMAINWARN_TOKEN" "$BASIS/domains?status=critical" \
  | jq -e '.data | length == 0'

# vor dem Deploy: Zertifikat prüfen, ohne Token
curl -sf "https://api.domainwarn.com/api/v1/tools/ssl?domain=kunde.de" \
  | jq -e '.data.issues == 0'

n8n, Zapier und Make brauchen keinen eigenen Knoten: Der HTTP-Request-Knoten mit Authorization: Bearer <TOKEN> spricht dieselbe API, und für den umgekehrten Weg – DomainWarn meldet etwas an den Workflow – gibt es Webhooks als Benachrichtigungskanal. Ein Szenario „Vorfall eröffnet → Ticket im Helpdesk“ besteht damit aus einem Webhook-Kanal in DomainWarn und einem Webhook-Trigger im Automatisierungswerkzeug.

Siehe auch: API-Dokumentation

Skripte und Automatisierung

Skripte, CI und Automatisierung (n8n, Zapier, Make)