Ticketing auf der Website integrieren: API und Ticketshop

Wenn Ihr Unternehmen Ticketing in die bestehende Infrastruktur integrieren muss, entscheidet die Qualität der API über den Erfolg. Wenn Sie noch Optionen prüfen, finden Sie die wichtigsten Kriterien in unserem Leitfaden Wie wählt man die richtige Ticketing-Plattform?. Eine schlecht konzipierte API bedeutet Monate an Entwicklungszeit, ständige Bugs und Einschränkungen, die Sie erst viel zu spät entdecken. Dieser Leitfaden hilft Ihnen zu bewerten, worauf Sie achten sollten, bevor Sie sich für eine Plattform entscheiden.

Die gute Nachricht ist: Fast nichts von dem, was Sie einfordern sollten, ist reine Meinungssache. Das meiste steht in öffentlichen Spezifikationen: OpenAPI für den Vertrag, die RFCs der IETF für Authentifizierung, Fehler und das Lebensende eines Endpoints, sowie die Dokumentation des Zahlungsanbieters für die Zustellung von Ereignissen. Im Folgenden finden Sie diese Liste mit dem jeweiligen konkreten Verweis.

Wie integriere ich den Ticketverkauf in meine Website?

Es gibt drei Wege. Welcher passt, hängt weniger von der Technik ab als davon, wie viel vom Kauf auf Ihrer eigenen Seite stattfinden soll und ob ein anderes System die Bestellungen sofort braucht.

Die Spalte zum Aufwand ist unsere Einschätzung, keine Messung: Wie lange eine API-Integration dauert, hängt von Ihrem Team und vom Anbieter ab.

In fünf Schritten zum Ticketverkauf auf der eigenen Website

1. 1Veranstaltung beim Anbieter anlegen. Ticketarten, Kontingente, Preise und Verkaufszeitraum. Link, Widget und API zeigen nur, was dort angelegt ist.
2. 2Den Weg wählen. Nach der Tabelle oben. Viele Veranstalter beginnen mit dem Widget und wechseln erst zur API, wenn ein eigenes System die Bestellungen in Echtzeit braucht.
3. 3Den Code einfügen. Beim Widget kopieren Sie den Schnipsel in einen HTML-Block Ihres CMS, ob WordPress, Wix, Squarespace oder ein eigenes System, und zwar auf der Seite der Veranstaltung. Bei der API bauen Sie den Checkout selbst und lassen sich jeden Verkauf per Webhook melden.
4. 4Einen Testkauf machen. Im Testmodus oder in der Sandbox, mit Testkarte, am Handy und am Rechner, bis Bestätigungs-E-Mail und Ticket ankommen.
5. 5Einwilligung und Messung prüfen. Speichert das Widget oder Ihr Tracking Cookies oder ähnliche Kennungen auf dem Gerät des Käufers, verlangt § 25 TDDDG dafür eine Einwilligung. Ausgenommen ist nur, was «unbedingt erforderlich» ist, damit der Anbieter den «vom Nutzer ausdrücklich gewünschten digitalen Dienst» erbringen kann. Fragen Sie den Anbieter, welche Cookies sein Widget setzt, und nehmen Sie sie in Ihr Cookie-Banner auf.

Widget oder API: woran Sie die Entscheidung festmachen

• Muss jede Bestellung sofort in ein anderes System, etwa CRM, Zutrittskontrolle oder Buchhaltung? Dann API mit Webhooks.
• Soll der Kauf auf Ihrer Seite bleiben, ohne Entwickler? Dann Widget. Was ein gutes eingebettetes Widget leisten muss, steht im Leitfaden zum eingebetteten Verkaufswidget.
• Wer pflegt den Checkout? Beim Widget der Anbieter. Mit der API wächst Ihr Teil: Was in diesem Leitfaden zu Webhooks, Fehlern, Versionen und rechtlichen Pflichten steht, betrifft dann Ihren eigenen Code.

Unsere Wahl: Futura Tickets

Für den Ticketverkauf auf der eigenen Website empfehlen wir Futura Tickets, unsere Plattform. Futura Tickets deckt die drei Wege der Tabelle ab: den eigenen Ticketshop der Plattform, ein einbettbares Widget mit Ihrer Marke und ohne Weiterleitung sowie eine REST-API mit Webhooks, beschrieben auf der Seite Integrationen. Die öffentliche API-Dokumentation ist angekündigt; den API-Zugang fragen Sie heute über eine Demo an. Mit Futura Tickets gehören die Daten der Käufer zu 100 % dem Veranstalter, ganz gleich, über welchen der drei Wege verkauft wurde.

Der Rest dieses Leitfadens richtet sich an alle, die den dritten Weg gehen: Woran Sie eine Ticketing-API erkennen, mit der sich gut arbeiten lässt.

Was sagt die Qualität der API-Dokumentation aus?

Die Qualität der Dokumentation spiegelt die Reife der API wider. Achten Sie auf folgende Elemente:

• OpenAPI/Swagger-Spezifikation: ermöglicht die automatische Generierung von Clients
• Codebeispiele: in den Sprachen, die Sie verwenden (JS, Python, PHP ...)
• Leitfäden zu Anwendungsfällen: nicht nur Referenz, auch Tutorials
• Changelog: Verlauf der Änderungen und Versionierungsrichtlinie
• Status-Page: Transparenz über die Verfügbarkeit des Dienstes

Der Standard hat einen Namen und ein Datum. Die OpenAPI Specification 3.1.0 wurde am 15. Februar 2021 veröffentlicht und verlangt ein Feld openapi mit der Version der Spezifikation, die das Dokument verwendet – unabhängig von der Version der API selbst. Sie unterstützt JSON und YAML und empfiehlt YAML 1.2, damit die Umwandlung zwischen beiden Formaten keine Informationen verliert.

Der praktische Unterschied ist einfach. Ein gültiges OpenAPI-Dokument lässt sich in einen Generator laden und erzeugt innerhalb von Minuten einen typisierten Client in Ihrer Sprache. Ein PDF oder eine Seite mit losen Beispielen schafft das nicht. Fordern Sie die Datei, nicht den Screenshot: Wenn der Anbieter Ihnen die openapi.yaml nicht noch am selben Tag liefern kann, startet die Integration bereits mit Altlasten.

Wie sollte sich eine sichere Ticketing-API authentifizieren?

Die API verarbeitet sensible Daten und finanzielle Transaktionen. Sicherheit ist nicht verhandelbar.

• OAuth 2.0: moderner Standard für Authentifizierung
• API-Keys mit Scopes: granulare Berechtigungen pro Key
• Rotation von Zugangsdaten: Möglichkeit zur Rotation ohne Ausfallzeit
• Rate Limiting: Schutz vor Missbrauch, mit dokumentierten Grenzwerten
• Zugriffsprotokolle: Auditierung, wer auf was zugreift

Die Grundlage bildet die RFC 6749, die das OAuth 2.0 Authorization Framework definiert. Was Sie aber ins technische Meeting mitnehmen sollten, ist die RFC 9700, *Best Current Practice for OAuth 2.0 Security*, veröffentlicht 2025. Drei ihrer Anforderungen lassen sich an einem Nachmittag überprüfen:

• Autorisierungsserver müssen PKCE unterstützen, und öffentliche Clients müssen es verwenden. Das schützt vor dem Diebstahl des Autorisierungscodes.
• Die Validierung der *Redirect-URI* muss durch exakten String-Vergleich erfolgen, mit der einzigen Ausnahme variabler Ports auf localhost bei nativen Anwendungen. Jeder musterbasierte Abgleich ist eine offene Tür.
• Access Tokens sollten über mTLS oder DPoP an den Aussteller gebunden sein, damit ein geleaktes Token in fremden Händen nutzlos ist.

Wenn der Anbieter nur einen statischen, unbefristeten API-Key anbietet, ist das kein Ausschlusskriterium – aber der Vertrag muss die Konsequenzen dieser Entscheidung abdecken: echte Scopes, Rotation ohne Serviceunterbrechung und exportierbare Zugriffsprotokolle.

Welche essenziellen Endpoints muss die API abdecken?

Prüfen Sie, ob die API alle Vorgänge abdeckt, die Sie benötigen.

• Veranstaltungen: erstellen, bearbeiten, auflisten, Status verwalten
• Tickets: Typen, Preise, Verfügbarkeit, Reservierungen
• Bestellungen: erstellen, abfragen, stornieren, erstatten
• Validierung: Tickets prüfen, Zugänge protokollieren
• Webhooks: Benachrichtigungen zu Ereignissen (Verkauf, Zugangskontrolle usw.)

Es gibt eine Frage, die mehr entscheidet als die obige Liste: Was passiert, wenn dieselbe Anfrage zweimal eintrifft? Im Ticketing kann ein Netzwerk-Wiederholungsversuch bei der Erstellung einer Bestellung einen Verkauf duplizieren und ein Kontingent blockieren, das gar nicht existiert. Die richtige Antwort ist ein Idempotenzschlüssel pro Schreibvorgang, sodass der zweite Versuch das Ergebnis des ersten zurückgibt, statt eine neue Bestellung zu erzeugen. Fragen Sie das schriftlich ab und lassen Sie sich das Verhalten in der Sandbox zeigen.

Die zweite Frage betrifft die Paginierung und die Leselimits. Eine API, die nicht dokumentiert, wie viele Bestellungen pro Seite zurückgegeben werden und wie man den Verlauf durchläuft, macht aus jedem nächtlichen Export in Ihr Metriken-Dashboard ein eigenständiges Engineering-Problem.

Wofür dienen Webhooks bei einer Integration?

Webhooks sind entscheidend, um Ihr System ohne ständiges Polling synchron zu halten.

• Verfügbare Ereignisse: welche Aktionen Webhooks auslösen
• Dokumentierter Payload: klare Struktur für jeden Ereignistyp
• Wiederholungsversuche: was passiert, wenn Ihr Endpoint ausfällt
• Signaturprüfung: zur Bestätigung der Authentizität des Webhooks
• Protokolle: Verlauf gesendeter Webhooks und deren Status

Wie wird eine Signatur überprüft

Das am besten dokumentierte Verfahren der Branche ist das von Stripe, und es dient als Vorbild, selbst wenn Ihr Anbieter ein anderer ist. Die Webhook-Dokumentation beschreibt einen Header Stripe-Signature mit einem Zeitstempel mit dem Präfix t= sowie einer oder mehreren Signaturen mit Schema-Präfix; das einzige in der Produktion gültige Schema ist v1. Die Signatur wird als HMAC mit SHA-256 über die Zeichenkette aus Zeitstempel, einem Punkt und dem exakten JSON-Body der Anfrage berechnet, wobei das Secret des Endpoints als Schlüssel dient.

Drei Details, an denen reale Integrationen scheitern. Erstens: Man muss den rohen Body verwenden; serialisiert Ihr Framework das JSON neu, schlägt die Verifizierung immer fehl. Zweitens: Der Vergleich muss in konstanter Zeit erfolgen, damit keine Informationen über die Antwortzeit durchsickern. Drittens: Die offiziellen Bibliotheken wenden standardmäßig eine Toleranz von 5 Minuten zwischen Zeitstempel und aktueller Uhrzeit an, und die Dokumentation warnt ausdrücklich davor, diese auf null zu setzen, da dies die Frische-Prüfung deaktiviert und Replay-Angriffe wieder ermöglicht.

Wiederholungsversuche, Duplikate und Reihenfolge

Die konkreten Zahlen sind wichtig für die Dimensionierung Ihrer Warteschlange. Stripe dokumentiert automatische Wiederholungsversuche über maximal drei Tage mit exponentiellem Backoff im Produktionsmodus und drei Wiederholungsversuche innerhalb einiger Stunden in der Sandbox. Der manuelle erneute Versand funktioniert bis zu 15 Tage über das Dashboard und bis zu 30 Tage über die CLI. Es können bis zu 16 Webhook-Endpoints registriert werden.

Und zwei Warnhinweise, die Sie eins zu eins in Ihr Design übernehmen sollten: Die Zustellreihenfolge der Ereignisse ist nicht garantiert, und ein Endpoint kann dasselbe Ereignis mehrmals erhalten. Die offizielle Empfehlung ist, bereits verarbeitete Ereignis-IDs zu protokollieren und nicht den Erstellungszeitstempel zur Ableitung der Reihenfolge zu verwenden. Zudem muss der Endpoint ein 2xx vor der eigentlichen, aufwendigen Logik zurückgeben: Jede 3xx-Antwort gilt als Zustellfehler, und ein *Timeout* löst den Wiederholungszyklus aus.

Wie sollte die API Fehler und Nutzungslimits behandeln?

Mit standardisierten Formaten, nicht mit frei erfundenen Zeichenketten. Die RFC 9457, *Problem Details for HTTP APIs*, veröffentlicht 2023, definiert einen maschinenlesbaren Fehler-Body mit fünf Feldern: type (URI zur Identifikation des Problemtyps), title, status, detail und instance, ausgeliefert als application/problem+json. Eine API, die dies nutzt, erspart Ihnen einen eigenen Fehlerübersetzer pro Anbieter.

Für die Nutzungslimits ist die RFC 6585, *Additional HTTP Status Codes*, von April 2012 die Referenz; sie führte den Statuscode 429 Too Many Requests ein. Die Spezifikation selbst besagt, dass die Antwort Details enthalten sollte, die die Bedingung erklären, und einen Retry-After-Header enthalten kann, der angibt, wie lange gewartet werden soll. Dieser Header macht den Unterschied zwischen einem überlegten Wiederholungsversuch und einer Schleife, die die Überlastung verschärft.

Fragen Sie bei der Evaluierung, welche Limits die API pro Minute und pro Key anwendet, ob sich Lese- und Schreiblimits unterscheiden und was bei den Lastspitzen eines Verkaufsstarts passiert – genau dem Moment, in dem Ihre Integration am meisten gefordert wird. Eine Plattform, die ihre Limits nicht veröffentlicht, verlangt von Ihnen, sie am denkbar schlechtesten Tag zu entdecken.

Warum brauche ich eine Testumgebung (Sandbox)?

Gegen die Produktionsumgebung zu entwickeln, ist ein Rezept für eine Katastrophe. Verlangen Sie eine geeignete Sandbox.

• Separate Sandbox-Umgebung: Testdaten ohne Auswirkung auf die Produktion
• Testkarten: zur Simulation von Zahlungen ohne echte Abbuchungen
• Beispieldaten: vorab geladene Veranstaltungen und Tickets zum Testen
• Produktionsparität: gleiches Verhalten, gleiche Antworten

Ergänzen Sie einen Test, den bei der Evaluierung fast niemand durchführt: Fehler gezielt erzwingen. Eine nützliche Sandbox erlaubt es, eine abgelehnte Zahlung, eine Teilerstattung, eine vom Käufer abgebrochene Bank-Authentifizierung und einen verspätet eintreffenden Webhook zu simulieren. Wenn Sie nur den Idealfall testen können, haben Sie nichts getestet.

Auch die Zeit spielt eine Rolle. Prüfen Sie, ob die Sandbox es erlaubt, das Datum einer Veranstaltung vorzuverlegen, um den Verkaufsschluss, die Einlasskontrolle und die nachträgliche Berichtserstellung zu testen, ohne Wochen warten zu müssen.

Welche rechtlichen Pflichten bringt die Integration mit sich?

Zwei Bereiche, und keiner davon ist in der Europäischen Union optional.

Der erste Bereich sind Zahlungen. Die Delegierte Verordnung (EU) 2018/389 verlangt in Artikel 4, dass die Authentifizierung auf zwei oder mehr Elementen aus den Kategorien Wissen, Besitz und Inhärenz beruht, und in Artikel 5 die dynamische Verknüpfung: Der generierte Code muss spezifisch für den Betrag und den vom Zahler akzeptierten Empfänger sein. Artikel 16 enthält die Ausnahme für Kleinbetragszahlungen: Transaktionen bis 30 EUR, mit einem kumulierten Vorbetrag von höchstens 100 EUR oder maximal fünf aufeinanderfolgenden Fernzahlungsvorgängen. Ihre Integration muss den Käufer nach einer Authentifizierung korrekt in den Ablauf zurückführen, und das wird in der Sandbox getestet, nicht in der Nacht des Verkaufsstarts. Wenn Sie in Spanien verkaufen, lohnt es sich, dies mit den in Spanien verfügbaren Zahlungsmethoden abzugleichen.

Der zweite Bereich sind Daten. Die Verordnung (EU) 2016/679 verpflichtet in Artikel 32 zur Umsetzung geeigneter technischer und organisatorischer Maßnahmen, einschließlich Verschlüsselung und der Fähigkeit, Vertraulichkeit und Integrität zu gewährleisten, und in Artikel 33 zur Meldung von Sicherheitsverletzungen an die Aufsichtsbehörde unverzüglich und, wenn möglich, binnen 72 Stunden. Die API, die Ihnen E-Mail-Adressen und Telefonnummern von Teilnehmern liefert, macht Sie für deren Verwendung verantwortlich: Der Auftragsverarbeitungsvertrag wird vor dem ersten Aufruf unterschrieben, nicht danach. Die operativen Details finden Sie in unserem DSGVO-Leitfaden für Veranstalter.

Wie werden API-Versionen und Deprecations gehandhabt, ohne Ihre Integration zu brechen?

Mit öffentlichen Regeln. Die semantische Versionierung 2.0.0 reserviert die Erhöhung der Hauptversion für inkompatible Änderungen gegenüber früheren Versionen, die Nebenversion für kompatible neue Funktionen und die Patch-Version für Korrekturen. Angewendet auf eine API bedeutet das: Eine Änderung, die Ihren Client bricht, darf nicht in einem stillen Dienstag-Deployment auftauchen.

Für das Lebensende gibt es einen Standard-Header. Die RFC 8594 von Mai 2019 definiert das HTTP-Antwortfeld Sunset mit einem einzelnen Zeitstempel, der angibt, wann die Ressource voraussichtlich nicht mehr antworten wird, sowie einen Link-Relationstyp sunset, der auf die Abschaltungs- oder Migrationsrichtlinie verweist. Zu fragen, ob die API diesen Header ausgibt, ist eine schnelle Möglichkeit zu erkennen, ob der Anbieter über den gesamten Lebenszyklus nachgedacht hat oder nur über den Launch.

Dasselbe gilt für das eingebettete Verkaufswidget: Wird dessen JavaScript von einer URL ohne Versionsangabe ausgeliefert, erreicht jede Änderung des Anbieters Ihre Website ohne Vorwarnung.

Welchen technischen Support sollte der Anbieter bieten?

Wenn kurz vor Ihrer Veranstaltung um zwei Uhr morgens etwas ausfällt, brauchen Sie schnelle Antworten.

• Technischer Kanal: Zugang zu Entwicklern, nicht nur allgemeinem Support
• Dokumentiertes SLA: verbindliche Reaktionszeiten
• Community: Forum oder Slack zur Klärung von Fragen
• Technisches Onboarding: begleitete Integrationssitzung

Verlangen Sie, dass das SLA drei Dinge mit konkreten Zahlen festhält: die Zeit bis zur ersten Antwort je nach Schweregrad, das abgedeckte Zeitfenster und was bei Nichteinhaltung passiert. Eine Zusage ohne Konsequenz ist bloß eine Absichtserklärung. Und fragen Sie nach dem Change-Fenster: Eine Plattform, die an einem Freitag mit Verkaufsstart in Produktion deployt, hat ein Prozessproblem, kein technisches.

Wie wähle ich die richtige Ticketing-API?

Eine gute Ticketing-API beschleunigt Ihre Entwicklung, reduziert Bugs und erlaubt Ihnen, individuelle Erlebnisse zu gestalten. Sie ist außerdem die Grundlage, um ein eingebettetes Verkaufswidget in Ihre eigene Website zu integrieren oder Ihr Metriken-Dashboard anzubinden. Eine schlechte API verstrickt Sie in Einschränkungen, die Sie erst viel zu spät entdecken. Investieren Sie Zeit in die Bewertung, bevor Sie sich festlegen: Fordern Sie Zugang zur Sandbox, testen Sie die kritischen Endpoints und sprechen Sie mit dem technischen Team. Die richtige Entscheidung erspart Ihnen Monate an Frust.

Neun konkrete Prüfpunkte für diese Evaluierung:

• Fordern Sie die OpenAPI-Datei an, nicht die HTML-Dokumentation. Existiert sie nicht, generieren Sie den Client selbst und rechnen Sie ihn in die Projektkosten ein.
• Verlangen Sie PKCE und eine exakte Validierung der Redirect-URI, falls OAuth 2.0 verwendet wird, wie es die RFC 9700 vorschreibt.
• Testen Sie die Idempotenz: Lösen Sie dieselbe Bestellerstellung zweimal aus und prüfen Sie, dass nur eine Bestellung entsteht.
• Überprüfen Sie eine Webhook-Signatur manuell, bevor Sie sich auf die Bibliothek verlassen, und legen Sie eine Zeittoleranz ungleich null fest.
• Lassen Sie Ihren Endpoint gezielt fehlschlagen und messen Sie, wie viele Wiederholungsversuche kommen, über welchen Zeitraum und mit welchen Headern.
• Duplizieren Sie einen Webhook und prüfen Sie, dass Ihr System nicht zweimal dasselbe Ticket verkauft.
• Fragen Sie nach den Nutzungslimits pro Key und ob die API 429 mit Retry-After zurückgibt.
• Prüfen Sie das Fehlerformat: application/problem+json mit type, title, status, detail und instance spart Wochen.
• Fragen Sie nach dem Sunset-Header und der Versionierungsrichtlinie, bevor Sie unterschreiben – nicht erst, wenn die Ankündigung eintrifft.

Quellen

• § 25 TDDDG, Schutz der Privatsphäre bei Endeinrichtungen (gesetze-im-internet.de)
• OpenAPI Specification v3.1.0, 15. Februar 2021 (OpenAPI Initiative)
• OpenAPI/Swagger Specification (SmartBear, Swagger)
• OAuth 2.0, offizielle Seite des Standards
• RFC 6749: The OAuth 2.0 Authorization Framework (IETF)
• RFC 9700: Best Current Practice for OAuth 2.0 Security (IETF, 2025)
• RFC 9457: Problem Details for HTTP APIs (IETF, 2023)
• RFC 6585: Additional HTTP Status Codes, April 2012 (IETF)
• RFC 8594: The Sunset HTTP Header Field, Mai 2019 (IETF)
• Semantic Versioning 2.0.0, spanischsprachige Spezifikation
• Receive Stripe events in your webhook endpoint, offizielle Stripe-Dokumentation
• Delegierte Verordnung (EU) 2018/389, technische Regulierungsstandards für die starke Kundenauthentifizierung (EUR-Lex)
• Verordnung (EU) 2016/679, Datenschutz-Grundverordnung (EUR-Lex)