WebinarSuite

API – Entwickler-Dokumentation

Mit der WebinarSuite API kannst du Daten aus deinem WebinarSuite-Account automatisiert abrufen und in eigenen Anwendungen, CRM-Systemen, Datenbanken oder Automatisierungen weiterverarbeiten.

api api dokumentation entwickler

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:

  1. JavaScript auf deiner Webseite
  2. öffentlich zugänglichem Frontend-Code
  3. GitHub-Repositories
  4. öffentlich sichtbaren Dateien
  5. 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:

  1. ob der API-Key gültig ist,
  2. mit welchem Account du verbunden bist,
  3. welchen Namen der API-Key besitzt,
  4. 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.

Text hier eingeben...

War dieser Artikel hilfreich?