Tickets aus deinen eigenen Systemen

• ticket:createTickets öffnen
• ticket:readTickets, Nachrichten und Panels lesen
• ticket:replyAls Team in ein Ticket schreiben
• stats:readKennzahlen lesen

Fehlt ein Recht, antwortet die API mit 403 statt 401. Der Schlüssel stimmt dann – ihm fehlt nur das Häkchen.

Schick nur Felder, die hier dokumentiert sind. Ein unbekannter Feldname wird nicht stillschweigend ignoriert, sondern mit 422 abgelehnt — ein Tippfehler soll dir nicht als leeres Ticket auffallen, sondern sofort.

{
  "event": "message.created",
  "sent_at": "2026-08-01T12:34:56Z",
  "guild_id": "1470847667327471738",
  "ticket": {
    "id": 42, "number": 17,
    "panel_id": 3, "panel_name": "Support",
    "status": "open", "priority": 2,
    "opener_id": "234...", "metadata": null
  },
  "message": {
    "id": 8891,
    "discord_message_id": "13...",
    "origin": "discord",
    "is_staff": true,
    "is_ai": false,
    "author_id": "234...",
    "author_bot": false,
    "author_name": "Lisa",
    "content": "Ich schaue mir das an.",
    "created_at": "2026-08-01T12:34:56Z"
  }
}

X-Ticketanizer-Event: message.created
X-Ticketanizer-Delivery: 90183
X-Ticketanizer-Timestamp: 1785600896
X-Ticketanizer-Signature: t=1785600896,v1=9f2c…

Signatur prüfen

Berechne HMAC-SHA256 über <timestamp>.<rawBody> mit deinem Secret und vergleiche das Ergebnis mit einem der v1-Werte. Zwei Dinge, die man leicht übersieht: Der Header kann mehrere v1-Werte enthalten (während einer Secret-Rotation), und der Vergleich sollte in konstanter Zeit laufen.

const crypto = require("crypto");

function verify(rawBody, header, secret) {
  const parts = header.split(",").map(p => p.split("="));
  const ts = parts.find(([k]) => k === "t")?.[1];
  // v1 kann MEHRFACH vorkommen — waehrend einer Secret-Rotation
  const sigs = parts.filter(([k]) => k === "v1").map(([, v]) => v);
  if (!ts || Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;

  const expected = crypto.createHmac("sha256", secret)
    .update(ts + "." + rawBody)
    .digest("hex");

  return sigs.some(s => s.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(s), Buffer.from(expected)));
}

Signiert wird der rohe Rumpf — genau die Bytes, die ankommen. Wer erst nach JSON-Parsen und Neuserialisieren prüft, bekommt eine andere Signatur und wundert sich über lauter Fehlschläge.

Welche Ereignisse es gibt

Beim Anlegen des Endpunkts hakst du an, was du bekommen willst. Ohne Auswahl bekommst du alle Ereignisse — mit einer Ausnahme, siehe unten.

Was du übers Zustellen wissen solltest

• WiederholungAntworte mit einem 2xx-Status. Alles andere gilt als Fehlschlag, und wir versuchen es erneut — nach 1, 5, 15 und 60 Minuten, danach nicht mehr.
• SchleifenschutzJede Nachricht trägt ein origin (discord, web, inbox, relay). Wer auf ein Ereignis hin selbst antwortet, filtert seine eigenen heraus — sonst löst die eigene Antwort das nächste Ereignis aus.
• DoppelteAntwortest du zu langsam, kommt dieselbe Zustellung erneut. Das ist gewollt: lieber zweimal als gar nicht. Gegen doppelte Verarbeitung hilft die Delivery-ID.
• Tote ZieleNach 20 endgültig fehlgeschlagenen Zustellungen in Folge schalten wir den Endpunkt ab und schreiben den Grund ins Dashboard. Eine kurze Störung reicht dafür nicht — gezählt wird erst, wenn alle Wiederholungen erschöpft sind.
• Secret wechselnBeim Wechseln bleibt das alte Secret 7 Tage gültig, und wir signieren mit beiden. So stellst du in Ruhe um, ohne eine Zustellung zu verlieren.

Zustellungen sind im Dashboard einsehbar — mit gesendetem Payload und der Antwort deines Servers. Von dort lässt sich eine Zustellung auch von Hand wiederholen, solange sie im Protokoll steht.