Integrationen

REST-API, Webhooks,
SDKs ohne Magie.

OpenAPI 3.1 als Source-of-Truth. Webhooks signed mit HMAC. SDKs für Node und Python aus der Spec generiert. Verbinde dein CRM, dein ERP, dein Buchhaltungs-Tool.

OpenAPI 3.1 · HMAC-SHA-256 Webhook-Signaturen · Idempotency-Keys eingebaut
Webhook delivered200 OK · 142 ms
{
  "event": "message.received",
  "conversation_id": "cnv_8h2f",
  "channel": "whatsapp",
  "from": "+49 30 123",
  "body": "Geht morgen um 14:30?",
  "ts": "2026-05-02T09:14:22Z"
}
signiert mit HMAC-SHA-256 · X-SG-Signature
Was du bekommst

Eine API, mit der du arbeiten willst

Wir haben die API gebaut, weil wir sie selbst für Customer-Migrations brauchen. Konsistente Naming-Konvention, klare Fehler, ehrliche Limits.

Public-REST-API mit OpenAPI 3.1

Hand-kuratierte OpenAPI-Spec, kein Auto-Export-Müll. Alle Hot-Path-Endpunkte dokumentiert, mit Beispielen, Fehler-Codes und Rate-Limits.

Webhooks für jedes wichtige Event

message.received, conversation.created, conversation.tagged, automation.executed. Signed mit HMAC-SHA-256, Retry mit exponential Backoff.

SDKs für Node und Python

@sg/sdk-node und sg-sdk (Pip). Auto-generiert via Fern aus der OpenAPI-Spec, getypt, mit Auth-Helpers und Pagination eingebaut.

API-Keys pro Workspace

Keys mit Scopes (read, write, admin), pro Mitglied erstellbar, jederzeit rotierbar. Letzte Nutzung sichtbar, sofort widerrufbar.

Idempotency-Keys eingebaut

Doppelte Anfragen werden automatisch erkannt und nicht zweimal ausgeführt. Wichtig für Webhook-Retries und unzuverlässige Netze.

Rate-Limits pro Workspace

Default 60 Requests/Minute, Pro 600/Minute, Business individuell. Limits werden in Response-Headern sauber kommuniziert.

Wie es aussieht

Ein Webhook-Payload und ein API-Call

So sieht ein eingehender message.received-Webhook aus, und so triggerst du eine Antwort über die REST-API. Kein Mock, das ist echtes Format.

Webhook: message.received
POST → dein Endpoint
JSON
POST /your-webhook HTTP/1.1
X-SG-Signature: t=1714637662,v1=4f1a...
Content-Type: application/json

{
  "event": "message.received",
  "workspace_id": "ws_abc",
  "conversation_id": "cnv_8h2f",
  "message": {
    "id": "msg_2k9p",
    "channel": "whatsapp",
    "direction": "in",
    "from": "+49 30 1234567",
    "body": "Geht morgen um 14:30 Uhr?",
    "received_at": "2026-05-02T09:14:22Z"
  }
}
API: send_message
POST /v1/conversations/:id/messages
bash
curl -X POST https://api.sg-platform.de/v1/conversations/cnv_8h2f/messages \
  -H "Authorization: Bearer sk_live_..." \
  -H "Idempotency-Key: 8a3f-2b9c" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "whatsapp",
    "body": "Hallo Sarah, 14:30 passt. Bis morgen!"
  }'

# 201 Created
# {"id":"msg_4n2x","status":"queued"}
Node SDK
@sg/sdk-node
typescript
import { SgClient } from "@sg/sdk-node";

const sg = new SgClient({ apiKey: process.env.SG_API_KEY! });

await sg.conversations.sendMessage("cnv_8h2f", {
  channel: "whatsapp",
  body: "Hallo Sarah, 14:30 passt. Bis morgen!",
}, { idempotencyKey: "8a3f-2b9c" });

// optional: webhook-signatur verifizieren
sg.webhooks.verify(rawBody, headers["x-sg-signature"]);
Häufige Fragen

Was Entwickler uns vorher fragen

Wo finde ich die OpenAPI-Spec?

+
Unter developers.sg-platform.de gehostet (Stoplight Elements). Source ist apps/api-spec/openapi.yaml im Repo, falls du eine eigene Code-Generation fahren willst. Lizenz: AGPL für Spec, MIT für SDK-Wrapper.

Welche Webhook-Events gibt es heute?

+
message.received, message.sent, conversation.created, conversation.assigned, conversation.tagged, conversation.snoozed, conversation.closed, automation.executed, ai.action_logged. Die Liste wächst mit jedem Slice, eine Vollübersicht im Developer-Portal.

Wie verhindere ich, dass jemand meinen Webhook-Endpoint missbraucht?

+
Jedes Webhook-Payload ist mit HMAC-SHA-256 über deinem Webhook-Secret signiert (Header X-SG-Signature). Du verifizierst die Signatur server-seitig, alles andere wird verworfen. Beispiel-Code in Node und Python in der Doku.

Werden API-Aufrufe in den Audit-Log geschrieben?

+
Ja. Jeder Schreib-Zugriff (POST/PATCH/DELETE) wird mit Akteur (API-Key-ID), Zeit, IP und Diff in den Hash-Chain-Audit-Log eingetragen. Read-Aufrufe werden bei Bedarf in einem separaten Access-Log gesammelt (DSGVO-konform mit 30 Tagen Retention).

Kann ich eigene Channels (Telegram, Signal, …) anbinden?

+
Heute nicht direkt, du kannst aber den public/webchat-Inbound-Endpunkt als „Generic-Channel" missbrauchen - wir liefern dir per Webhook zurück, du übersetzt in dein Protokoll. Native Channel-Adapter für Telegram und Signal sind für 2026 Q4 geplant.

Verbinde sg.platform mit deinem Stack.

Der erste API-Call dauert 5 Minuten. SDKs, Beispiele und Postman-Collection liegen bereit. Wir antworten auf jede Developer-Frage persönlich.