Welche Tarife unterstutzen Webhooks?

Webhooks sind in den Tarifen Pro, Business und Enterprise verfugbar. Im kostenlosen Tarif sind Webhooks nicht verfugbar -- verwenden Sie den manuellen Export oder das offentliche API.

Wie oft wiederholt tikento die Zustellung bei einem Fehler?

Drei Wiederholungen mit exponentiellem Abstand: nach 1 Minute, nach 5 Minuten, nach 30 Minuten. Wenn alle drei Versuche erfolglos sind, wird das Ereignis als failed markiert.

Wie prufe ich die Webhook-Signatur?

Berechnen Sie den HMAC-SHA256 des Anfragetextes mit Ihrem Webhook Secret und vergleichen Sie ihn mit dem Header X-Tikento-Signature. Verwenden Sie einen Constant-Time-Vergleich zum Schutz vor Timing-Angriffen.

Kann ich mehrere URLs fur Webhooks konfigurieren?

Ja. Im Bereich Einstellungen - Integrationen konnen Sie mehrere URLs hinzufugen und auswahlen, welche Ereignistypen an welche URL gesendet werden sollen.

Webhooks: Ereignisse und Signaturprufung

Uberblick

Webhooks ermoglichen es Ihnen, Benachrichtigungen uber Ereignisse auf der tikento-Plattform in Echtzeit zu erhalten. Bei Eintreten eines Ereignisses (neue Registrierung, erfolgreiche Zahlung, Absage einer Veranstaltung) sendet tikento eine HTTP-POST-Anfrage an Ihre URL mit den Ereignisdaten.

Webhooks sind in den Tarifen Pro, Business und Enterprise verfugbar.

Einrichtung

Webhook-URL hinzufugen

Offnen Sie Einstellungen im Seitenmenuu.
Gehen Sie zum Bereich "Integrationen".
Klicken Sie auf "Webhook hinzufugen".
Geben Sie die Endpunkt-URL an (HTTPS ist erforderlich).
Wahlen Sie die Ereignistypen aus, die Sie erhalten mochten.
Klicken Sie auf "Speichern".

Nach dem Speichern sendet tikento eine Testanfrage an die angegebene URL, um die Erreichbarkeit zu prufen.

Webhook Secret

Bei der Erstellung eines Webhooks generiert das System ein Webhook Secret -- eine Zeichenkette zur Signaturprufung. Speichern Sie es an einem sicheren Ort. Das Secret wird nur einmal angezeigt.

Ereignistypen

Ereignis	Beschreibung
`registration.created`	Neue Registrierung erstellt
`registration.updated`	Registrierungsdaten aktualisiert (Status, Felder)
`payment.completed`	Zahlung erfolgreich abgeschlossen
`payment.refunded`	Zahlungsruckerstattung durchgefuhrt
`event.published`	Veranstaltung veroffentlicht
`event.cancelled`	Veranstaltung abgesagt

Sie konnen alle Typen abonnieren oder nur die benotigten in den Integrationseinstellungen auswahlen.

Payload-Format

Jeder Webhook wird als HTTP POST mit einem JSON-Body gesendet.

Anfrage-Header

Header	Beschreibung
`Content-Type`	`application/json`
`X-Tikento-Event`	Ereignistyp (z.B. `registration.created`)
`X-Tikento-Signature`	HMAC-SHA256-Signatur des Anfragetextes
`X-Tikento-Timestamp`	Unix-Zeitstempel der Absendung (Sekunden)
`X-Tikento-Request-Id`	Eindeutiger Anfrage-Identifikator

Body-Struktur

{
  "event": "registration.created",
  "timestamp": "2026-06-30T14:30:00Z",
  "requestId": "req_01912345abcdef",
  "data": {
    "id": "01912345-6789-7abc-def0-123456789abc",
    "event_id": "01900000-0000-7000-0000-000000000001",
    "status": "registered",
    "fields": {
      "registrant_email": "user@example.com",
      "first_name": "Ivan",
      "last_name": "Petrov"
    },
    "created_at": "2026-06-30T14:30:00Z"
  }
}

Das Feld requestId ist in jedem Webhook enthalten. Verwenden Sie es zur Deduplizierung und bei Support-Anfragen.

Payload-Beispiele nach Ereignistyp

registration.created

{
  "event": "registration.created",
  "timestamp": "2026-06-30T14:30:00Z",
  "requestId": "req_01912345abcdef",
  "data": {
    "id": "01912345-6789-7abc-def0-123456789abc",
    "event_id": "01900000-0000-7000-0000-000000000001",
    "event_slug": "tech-conference-2026",
    "status": "registered",
    "ticket_definition_id": "01900000-0000-7000-0000-000000000010",
    "fields": {
      "registrant_email": "user@example.com",
      "first_name": "Ivan",
      "last_name": "Petrov",
      "company": "Acme Corp"
    },
    "created_at": "2026-06-30T14:30:00Z"
  }
}

payment.completed

{
  "event": "payment.completed",
  "timestamp": "2026-06-30T14:31:00Z",
  "requestId": "req_01912345abcdf0",
  "data": {
    "id": "01912345-6789-7abc-def0-000000000099",
    "registration_id": "01912345-6789-7abc-def0-123456789abc",
    "amount": 5000,
    "currency": "RUB",
    "method": "card",
    "gateway": "yookassa",
    "idempotency_key": "idem_abc123",
    "completed_at": "2026-06-30T14:31:00Z"
  }
}

event.cancelled

{
  "event": "event.cancelled",
  "timestamp": "2026-06-30T15:00:00Z",
  "requestId": "req_01912345abcdf1",
  "data": {
    "id": "01900000-0000-7000-0000-000000000001",
    "slug": "tech-conference-2026",
    "title": "Tech Conference 2026",
    "cancelled_at": "2026-06-30T15:00:00Z",
    "reason": "Venue unavailable"
  }
}

Signaturprufung

Jeder Webhook wird mit HMAC-SHA256 signiert. Die Signaturprufung garantiert, dass die Anfrage von tikento und nicht von einem Angreifer stammt.

Algorithmus

Lesen Sie die Werte der Header X-Tikento-Timestamp und X-Tikento-Signature.
Bilden Sie die Zeichenkette fur die Signatur: <timestamp>.<body>, wobei body der Raw Body der Anfrage ist.
Berechnen Sie den HMAC-SHA256 dieser Zeichenkette mit Ihrem Webhook Secret.
Vergleichen Sie das Ergebnis mit X-Tikento-Signature im Hex-Format.

Beispiel in Node.js

const crypto = require('crypto');

function verifySignature(body, timestamp, signature, secret) {
  const payload = `${timestamp}.${body}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(payload)
    .digest('hex');

  // Constant-Time-Vergleich zum Schutz vor Timing-Angriffen
  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(signature)
  );
}

Beispiel in Python

import hmac
import hashlib

def verify_signature(body: str, timestamp: str, signature: str, secret: str) -> bool:
    payload = f"{timestamp}.{body}"
    expected = hmac.new(
        secret.encode(),
        payload.encode(),
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

Schutz vor Replay-Angriffen

Prufen Sie X-Tikento-Timestamp: Wenn er alter als 5 Minuten ist, lehnen Sie die Anfrage ab. Dies verhindert die Wiederverwendung abgefangener Webhooks.

Wiederholungsrichtlinie

Wenn Ihr Endpunkt nicht mit HTTP 2xx antwortet, wiederholt tikento die Zustellung:

Versuch	Verzogerung
1	Sofort
2	Nach 1 Minute
3	Nach 5 Minuten
4	Nach 30 Minuten

Wenn alle 4 Versuche (Erstversuch + 3 Wiederholungen) erfolglos sind, wird das Ereignis als failed markiert. Sie sehen die Liste fehlgeschlagener Webhooks im Bereich Einstellungen - Integrationen - Zustellungshistorie.

Was als Erfolg gilt

HTTP 200, 201, 202, 204 -- die Zustellung gilt als erfolgreich.
Timeout: Die Antwort muss innerhalb von 10 Sekunden eingehen.

Was als Fehler gilt

HTTP 4xx (ausser 410) -- Wiederholung, mogliches Problem auf Empfangerseite.
HTTP 5xx -- Wiederholung mit Verzogerung.
Timeout (keine Antwort innerhalb von 10 Sekunden) -- Wiederholung.
HTTP 410 (Gone) -- Webhook wird automatisch deaktiviert, keine Wiederholungen.

Deduplizierung

Durch Wiederholungen kann Ihr Endpunkt dasselbe Ereignis mehrfach erhalten. Verwenden Sie die requestId aus dem Payload zur Deduplizierung:

Prufen Sie beim Empfang eines Webhooks, ob Sie die requestId bereits verarbeitet haben.
Falls ja -- geben Sie HTTP 200 zuruck, ohne erneut zu verarbeiten.
Falls nein -- verarbeiten Sie das Ereignis und speichern Sie die requestId.

Akzeptieren Sie Webhooks nur uber HTTPS.
Prufen Sie immer die Signatur uber HMAC-SHA256.
Prufen Sie den Zeitstempel zum Schutz vor Replay-Angriffen.
Speichern Sie das Webhook Secret in Umgebungsvariablen, nicht im Code.