API – Entwickler-Dokumentation

Die API eignet sich zum Beispiel für eigene Software, interne Dashboards, Reporting-Lösungen oder Integrationen mit Make, Zapier, n8n und anderen Systemen.

Die aktuelle API-Version v1 ist ausschließlich lesend. Daten können über die API abgerufen, aber nicht erstellt, geändert oder gelöscht werden.

1. Voraussetzungen

Für den Zugriff benötigst du einen API-Key aus deinem WebinarSuite-Account.

Du findest die Verwaltung unter:

API-Verwaltung → Meine eigene API

Dort kannst du einen neuen API-Key erstellen und festlegen, auf welche Daten dieser Key zugreifen darf.

Je nach gewählten Berechtigungen stehen folgende Bereiche zur Verfügung:

Plain text

webinare:read

landingpages:read

anmeldungen:read

teilnahmen:read

Wir empfehlen, für jedes angebundene System einen eigenen API-Key anzulegen. So kannst du einzelne Integrationen später unabhängig voneinander deaktivieren.

2. Wichtiger Sicherheitshinweis

Dein API-Key ist ein Zugangsschlüssel zu deinen WebinarSuite-Daten.

Er gehört deshalb ausschließlich auf deinen Server oder in die sichere Secret-Verwaltung deiner Automatisierungsplattform.

Verwende den API-Key niemals direkt in:

JavaScript auf deiner Webseite
öffentlich zugänglichem Frontend-Code
GitHub-Repositories
öffentlich sichtbaren Dateien
Browser-Erweiterungen, in denen der Key ausgelesen werden kann

Die WebinarSuite API ist für Server-zu-Server-Kommunikation vorgesehen.

Direkte API-Aufrufe aus Webseiten bzw. Browser-JavaScript werden nicht unterstützt.

3. Basis-URL

Alle Endpunkte der aktuellen Version befinden sich unter:

https://my.webinarsuite.me/api/v1

Beispiel:

https://my.webinarsuite.me/api/v1/me

Die Versionsnummer /v1 ist Bestandteil der API.

4. Authentifizierung

Bei jedem Request muss dein API-Key im HTTP-Header Authorization übertragen werden.

Format:

http

Authorization: Bearer DEIN_API_KEY

Ein WebinarSuite API-Key beginnt beispielsweise mit:

Plain text

ws_live_

Beispiel mit cURL:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/me

Der API-Key darf nicht als URL-Parameter übertragen werden.

Falsch wäre beispielsweise:

Plain text
/api/v1/me?api_key=ws_live_...

5. Verbindung testen

Der einfachste Verbindungstest ist:

http

GET /api/v1/me

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/me

Eine erfolgreiche Antwort sieht grundsätzlich so aus:

JSON

{

"data": {

"account_id": "acc_7f3k9m2q",

"account_name": "Muster GmbH",

"key_name": "Make",

"scopes": [

"anmeldungen:read",

"teilnahmen:read"

]

}

Damit kannst du gleichzeitig prüfen:

ob der API-Key gültig ist,
mit welchem Account du verbunden bist,
welchen Namen der API-Key besitzt,
welche Berechtigungen der Key besitzt.

6. Verfügbare Endpunkte

Die API v1 stellt folgende Endpunkte bereit:

7. Öffentliche IDs

Die API verwendet bewusst keine internen Datenbank-IDs.

Webinare besitzen beispielsweise eine öffentliche Kennung wie:

Plain text

web_xxxxxxxxxxxx

Landingpages:

Plain text

lp_xxxxxxxxxxxx

Accounts:

Plain text

acc_xxxxxxxxxxxx

Für Anmeldungen wird der tkey verwendet.

Nutze ausschließlich diese öffentlichen Kennungen.

Eine interne oder numerische ID wie:

Plain text

123

ist kein gültiger Ersatz für eine Webinar- oder Landingpage-ID.

Beispiel:

http

GET /api/v1/webinare/web_xxxxxxxxxxxx

Nicht:

http

GET /api/v1/webinare/123

8. Webinare abrufen

Alle Webinare:

http

GET /api/v1/webinare

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/webinare

Ein bestimmtes Webinar:

http

GET /api/v1/webinare/:webinar_id

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/webinare/web_xxxxxxxxxxxx

Dafür benötigt dein API-Key die Berechtigung:

Plain text

webinare:read

9. Landingpages abrufen

Alle Landingpages:

http

GET /api/v1/landingpages

Einzelne Landingpage:

http

GET /api/v1/landingpages/:landingpage_id

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/landingpages/lp_xxxxxxxxxxxx

Dafür benötigt dein API-Key:

Plain text

landingpages:read

10. Anmeldungen abrufen

Alle Anmeldungen werden über folgenden Endpunkt abgerufen:

http

GET /api/v1/anmeldungen

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

"https://my.webinarsuite.me/api/v1/anmeldungen?limit=50"

Dafür benötigt dein Key:

Plain text

anmeldungen:read

Eine einzelne Anmeldung kannst du über ihren tkey abrufen:

http

GET /api/v1/anmeldungen/:tkey

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

https://my.webinarsuite.me/api/v1/anmeldungen/DEIN_TKEY

Der tkey ist die stabile öffentliche Kennung einer Anmeldung und eignet sich deshalb auch hervorragend als eindeutiger Schlüssel in deiner eigenen Datenbank.

11. Teilnahmen abrufen

Teilnahmedaten werden über folgenden Endpunkt abgerufen:

http

GET /api/v1/teilnahmen

Beispiel:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

"https://my.webinarsuite.me/api/v1/teilnahmen?limit=50"

Dafür benötigt dein API-Key:

Plain text

teilnahmen:read

Über diesen Bereich können unter anderem Teilnahmesessions mit Daten wie Wiedergabedauer sowie Join- und Endzeitpunkt abgerufen werden.

12. Listen und Pagination

Listen werden nicht unbegrenzt in einer einzigen Antwort ausgegeben.

Standardmäßig liefert ein Request maximal:

Plain text

50 Datensätze

Mit dem Parameter limit kannst du die Anzahl verändern.

Beispiel:

Plain text

?limit=100

Der maximale Wert beträgt:

Plain text

200

Eine Listen-Antwort enthält zusätzlich Informationen zur Pagination:

JSON

{

"data": [

...

"pagination": {

"next_cursor": "...",

"has_more": true

}

Wenn:

JSON

"has_more": true

zurückgegeben wird, existiert mindestens eine weitere Seite.

Verwende anschließend den zurückgegebenen next_cursor für den nächsten Request.

Beispiel:

Plain text

/api/v1/anmeldungen?limit=100&cursor=DEIN_CURSOR

Wichtig:

Verändere oder dekodiere den Cursor nicht für deine Programmlogik.

Der Cursor ist für deinen Client ein undurchsichtiger Wert. Übernimm ihn exakt so, wie die API ihn zurückgibt.

13. Beispiel: alle Anmeldungen durchlaufen

Das Prinzip sieht folgendermaßen aus:

Plain text

1. GET /anmeldungen?limit=200

2. data verarbeiten

3. pagination.has_more prüfen

4. Falls true:

GET /anmeldungen?limit=200&cursor=NEXT_CURSOR

5. Wiederholen, bis has_more = false

Eine Integration sollte sich niemals darauf verlassen, dass alle Daten mit einem einzigen Request zurückgegeben werden.

14. Nur neue oder geänderte Daten abrufen

Für regelmäßige Synchronisationen solltest du nicht jedes Mal sämtliche Datensätze neu abrufen.

Dafür gibt es den Parameter:

Plain text

seit

Beispiel:

Plain text

/api/v1/anmeldungen?seit=2026-08-15T10:00:00Z

Der Zeitwert wird im ISO-8601-Format übergeben.

Beispiel mit cURL:

Bash

curl \

-H "Authorization: Bearer ws_live_DEIN_API_KEY" \

"https://my.webinarsuite.me/api/v1/anmeldungen?seit=2026-08-15T10:00:00Z&limit=200"

seit und cursor können gemeinsam verwendet werden.

Der seit-Wert definiert dabei das Zeitfenster und der Cursor blättert durch die darin gefundenen Datensätze.

15. Empfohlene Synchronisationsstrategie

Für eine zuverlässige Integration empfehlen wir folgende Vorgehensweise:

Speichere nach einem erfolgreichen Synchronisationslauf den zuletzt verarbeiteten updated_at-Zeitpunkt.

Beim nächsten Lauf verwendest du diesen Wert wieder als seit-Parameter.

Ziehe dabei eine kleine Sicherheitsüberlappung ab, beispielsweise eine Minute.

Beispiel:

Letzter erfolgreich verarbeiteter Zeitpunkt:

Plain text

2026-08-15T12:30:00Z

Nächster Abruf:

Plain text

seit=2026-08-15T12:29:00Z

Durch diese kleine Überlappung vermeidest du, dass Änderungen an einer zeitlichen Grenze verloren gehen.

16. Warum Datensätze doppelt auftreten können

Während du mehrere Seiten abrufst, können sich Daten in WebinarSuite gleichzeitig ändern.

Wird ein bereits gelieferter Datensatz aktualisiert, kann sich dessen Position innerhalb der Sortierung verändern.

Dadurch kann derselbe Datensatz während eines Synchronisationslaufs unter Umständen ein zweites Mal erscheinen.

Das ist beabsichtigt.

Die API priorisiert:

Kein Datensatz soll verloren gehen.

Deine Integration sollte deshalb sogenannte idempotente Verarbeitung verwenden.

Bei Anmeldungen bedeutet das:

Verwende den tkey als eindeutigen Schlüssel und führe ein Upsert durch.

Vereinfacht:

Plain text

Existiert tkey bereits?

→ Datensatz aktualisieren

Existiert tkey noch nicht?

→ Datensatz anlegen

Vermeide deshalb eine Logik wie:

Plain text

Jeder API-Datensatz = neue Datenbankzeile

Sonst erzeugst du bei einer erneuten Lieferung Duplikate.

17. Zeitstempel

Zeitangaben der API werden in UTC und im ISO-8601-Format ausgegeben.

Beispiel:

Plain text

2026-08-15T10:00:00Z

Wenn du die Zeiten einem Benutzer anzeigen möchtest, solltest du sie anschließend in dessen lokale Zeitzone umrechnen.

Für Webinar-Termine solltest du den von der API gelieferten UTC-Terminwert verwenden.

18. Rate Limit

Die API ist gegen übermäßig viele Requests geschützt.

Der aktuelle Ausgangswert liegt bei:

Plain text

120 Requests pro Minute und API-Key

Die tatsächlichen Informationen findest du in den Response-Headern:

http

RateLimit-Limit

RateLimit-Remaining

RateLimit-Reset

Diese Werte sollte deine Anwendung auswerten.

Wird das Limit überschritten, antwortet die API mit:

http

429 Too Many Requests

Zusätzlich wird ein Header zurückgegeben:

http

Retry-After

Deine Anwendung sollte danach nicht sofort erneut anfragen, sondern bis zum angegebenen Zeitpunkt bzw. Zeitraum warten.

Vermeide feste Schleifen wie:

Plain text

solange Fehler → sofort erneut versuchen

Das verschärft das Problem nur.

19. Fehlerformat

Fehler werden einheitlich als JSON zurückgegeben.

Grundstruktur:

JSON

{

"error": {

"code": "invalid_api_key",

"message": "..."

}

Für deine Programmlogik solltest du möglichst den Wert in:

Plain text

error.code

verwenden und nicht versuchen, den Text aus message auszuwerten.

20. Häufige HTTP-Statuscodes

200 – OK

Der Request wurde erfolgreich verarbeitet.

400 – Bad Request

Der Request enthält einen ungültigen Parameter.

Beispiele:

Plain text

invalid_parameter

invalid_cursor

Kontrolliere insbesondere:

Datum und ISO-Format
Cursor
Webinar-ID
Landingpage-ID
Limit

401 – Unauthorized

Es wurde kein oder kein gültiger API-Key übermittelt.

Mögliche Fehler:

Plain text

missing_api_key

invalid_api_key

Prüfe den Header:

http

Authorization: Bearer DEIN_API_KEY

403 – Forbidden

Der API-Key ist gültig, besitzt aber nicht die notwendige Berechtigung.

Beispiel:

Plain text

insufficient_scope

Möchtest du beispielsweise Anmeldungen abrufen, benötigt dein Key:

Plain text

anmeldungen:read

404 – Not Found

Die angeforderte Ressource wurde nicht gefunden.

Das kann beispielsweise bei einer unbekannten Webinar-, Landingpage- oder Anmeldungskennung auftreten.

Aus Sicherheitsgründen unterscheidet die API nicht danach, ob eine Kennung überhaupt nicht existiert oder zu einem anderen WebinarSuite-Account gehört.

429 – Too Many Requests

Das Rate Limit wurde überschritten.

Werte den Header:

http

Retry-After

aus und wiederhole den Request erst danach.

21. Beispiel in JavaScript / Node.js

JavaScript

const API_KEY = process.env.WEBINARSUITE_API_KEY;

async function getAnmeldungen() {

const response = await fetch(

"https://my.webinarsuite.me/api/v1/anmeldungen?limit=100",

{

headers: {

Authorization: `Bearer ${API_KEY}`

}

);

if (!response.ok) {

const error = await response.json();

throw new Error(

`WebinarSuite API: ${response.status} ${error?.error?.code || ""}`

);

}

return response.json();

}

getAnmeldungen()

.then(result => console.log(result))

.catch(error => console.error(error));

Wichtig:

JavaScript

process.env.WEBINARSUITE_API_KEY

ist hier bewusst eine Server-Umgebungsvariable.

Speichere den Key nicht direkt in öffentlich ausgeliefertem JavaScript.

22. Beispiel in PHP

PHP

<?php

$apiKey = getenv('WEBINARSUITE_API_KEY');

$ch = curl_init(

'https://my.webinarsuite.me/api/v1/anmeldungen?limit=100'

);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

curl_setopt($ch, CURLOPT_HTTPHEADER, [

'Authorization: Bearer ' . $apiKey,

'Accept: application/json'

]);

$response = curl_exec($ch);

$status = curl_getinfo($ch, CURLINFO_HTTP_CODE);

curl_close($ch);

if ($status >= 200 && $status < 300) {

$data = json_decode($response, true);

print_r($data);

} else {

echo 'API-Fehler: ' . $status . PHP_EOL;

echo $response;

}

23. Beispiel in Python

Python

import os

import requests

api_key = os.environ["WEBINARSUITE_API_KEY"]

response = requests.get(

"https://my.webinarsuite.me/api/v1/anmeldungen",

params={

"limit": 100

headers={

"Authorization": f"Bearer {api_key}"

}

)

response.raise_for_status()

result = response.json()

print(result)

24. Beispiel für Make, n8n oder vergleichbare Systeme

Bei Automatisierungsplattformen verwendest du normalerweise ein HTTP-Modul.

Konfiguration:

Methode

Plain text

GET

URL

Plain text

https://my.webinarsuite.me/api/v1/anmeldungen

Header

Plain text

Authorization

Wert:

Plain text

Bearer ws_live_DEIN_API_KEY

Als Query-Parameter kannst du beispielsweise setzen:

Plain text

limit = 100

oder für einen regelmäßigen Sync:

Plain text

seit = 2026-08-15T10:00:00Z

Wenn pagination.has_more den Wert true besitzt, muss anschließend mit dem gelieferten next_cursor die nächste Seite abgerufen werden.

25. Empfohlene Architektur einer Integration

Eine produktive Integration sollte ungefähr folgendermaßen arbeiten:

Plain text

WebinarSuite

↓

WebinarSuite API

↓

dein Server / Make / n8n / Zapier

↓

eigene Datenverarbeitung

↓

CRM / Datenbank / BI / anderes System

Nicht empfohlen:

Plain text

Besucher-Browser

↓

WebinarSuite API + sichtbarer API-Key

Der API-Key darf nicht beim Besucher landen.

26. Einen regelmäßigen Sync bauen

Ein robuster Synchronisationsprozess sieht beispielsweise so aus:

Plain text

1. letzten erfolgreichen Sync-Zeitpunkt laden

2. ca. 1 Minute Sicherheitsüberlappung abziehen

3. GET /anmeldungen?seit=...&limit=200 senden

4. erhaltene Datensätze per tkey als Upsert verarbeiten

5. has_more prüfen

6. falls true:

nächsten Request mit next_cursor senden

7. solange wiederholen, bis has_more = false

8. neuen erfolgreichen updated_at-Zeitpunkt speichern

Erst nachdem ein kompletter Lauf erfolgreich abgeschlossen wurde, solltest du deinen gespeicherten Sync-Zeitpunkt fortschreiben.

Damit vermeidest du Datenverluste, wenn beispielsweise dein eigener Server während des Imports ausfällt.

27. API-Key deaktivieren

Wird eine Integration nicht mehr benötigt, solltest du den dazugehörigen API-Key in WebinarSuite entfernen bzw. widerrufen.

Dadurch verliert ausschließlich dieses angebundene System seinen Zugriff.

Das ist einer der Gründe, warum wir empfehlen:

Ein System = ein eigener API-Key.

Verwende nach Möglichkeit nicht denselben Key gleichzeitig für mehrere unabhängige Anwendungen.

28. Unterstützte Daten in API v1

Die aktuelle Version konzentriert sich bewusst auf die wichtigsten Daten für Integrationen:

Webinare
Landingpages
Anmeldungen
Teilnahmen

Nicht Bestandteil von API v1 sind derzeit unter anderem:

Chat-Verläufe, Livestream-Daten, KI-Inhalte und Umfragen.

Ebenfalls nicht vorhanden sind in v1 schreibende API-Endpunkte.

Du kannst deshalb über die API beispielsweise keine neue Anmeldung erzeugen oder Webinar-Daten verändern.

29. Kurzreferenz

Basis-URL:

Plain text

https://my.webinarsuite.me/api/v1

Authentifizierung:

http

Authorization: Bearer ws_live_DEIN_API_KEY

Verbindung testen:

http

GET /me

Webinare:

http

GET /webinare

GET /webinare/:webinar_id

Landingpages:

http

GET /landingpages

GET /landingpages/:landingpage_id

Anmeldungen:

http

GET /anmeldungen

GET /anmeldungen/:tkey

Teilnahmen:

http

GET /teilnahmen

Pagination:

Plain text

limit

cursor

Inkrementelle Synchronisierung:

Plain text

seit

Standard-Limit:

Plain text

Maximales Limit:

Plain text

200

API-Version:

Plain text

30. Checkliste für deine erste Integration

API-Key in WebinarSuite erzeugen
nur die benötigten Berechtigungen auswählen
Key sicher als Secret speichern
/api/v1/me aufrufen
Antwort und Scopes kontrollieren
benötigten Daten-Endpunkt testen
Pagination implementieren
seit für regelmäßige Synchronisation verwenden
Datensätze idempotent verarbeiten
bei Anmeldungen tkey als eindeutigen Schlüssel verwenden
HTTP-Fehler behandeln
Rate-Limit-Header beachten
bei 429 den Retry-After-Header berücksichtigen
API-Key niemals im Browser veröffentlichen

Damit hast du die technische Grundlage, um eine eigene Anwendung oder Integration mit WebinarSuite aufzubauen.