Veeting Rooms REST APIs

Übersicht

Mit der Veeting REST API erstellen Sie aus Ihrer eigenen Software heraus Konten, planen Meetings im Namen Ihrer User und verwalten diese Meetings über den ganzen Lebenszyklus. Es ist eine ganz normale JSON-API über HTTPS, Sie können also jeden HTTP-Client einsetzen. Die Beispiele unten verwenden curl.

Basis-URL: https://<DOMAIN-NAME>/api/v6

<DOMAIN-NAME> ist Ihre eigene Meeting-Domain. Einen gemeinsamen oder globalen Host gibt es nicht: Nehmen Sie die Domain, unter der Ihre Instanz läuft.

Authentifizierung: ein X-API-KEY-Header bei jedem Aufruf.

Content-Type: application/json bei jedem POST und PUT.

Verwendung mit einem KI-Assistenten

Wenn Sie mit einem KI-Coding-Assistenten arbeiten, können Sie den folgenden Text in Ihren Assistenten kopieren und mit einem Satz ergänzen, der beschreibt, was Sie programmieren möchten.

Der Prompt verweist auf unsere Entwicklerdokumentation, die wir für Coding-Assistenten in einer separaten, token-optimierten KI-Version ausliefern.

Lies zuerst diese Seite, bevor Du Code schreibst:
https://www.veeting.com/de/developer-documentation/api-usage

Sie dokumentiert die Veeting Rooms REST API. Halte Dich an diese
sechs Regeln:

1. Frage mich nach meiner Veeting-Domain und meinem API-Key,
   bevor Du Code schreibst, ausser ich habe sie Dir schon
   genannt. Rate weder das eine noch das andere.
2. Der API-Key ist ein serverseitiges Geheimnis. Halte ihn in
   einer Umgebungsvariable, nie fest im Quellcode. Frage ich
   nach einer Browser-Integration, dann baue stattdessen ein
   Backend dafür und sage mir warum.
3. Ein Aufruf war nur dann erfolgreich, wenn der HTTP-Status 200
   ist UND der Body responseCode 0 enthält. Prüfe beides.
4. Ein Meeting hat zwei IDs. Verwende die 24 Zeichen lange «id» in
   API-Aufrufen und die «meetingId» mit den Bindestrichen im
   Meeting-Link. Vertausche sie nie.
5. Frage mich, ob mein API-Key auf Kontoebene oder auf
   Instanzebene liegt. Das ändert, welche Endpunkte und Header
   gelten.
6. Die Listen-Endpunkte kennen kein Paging und keine Sortierung,
   sortiere das Array also selbst. /meeting/past ohne startDate
   und endDate liefert jedes Meeting, das das Konto je hatte,
   nicht nur vergangene.

Was ich bauen möchte:

Regeln für jeden Aufruf

Diese vier Regeln gelten für jeden Endpunkt auf dieser Seite. Regel 2 überrascht die meisten Integratoren: Lesen Sie diese Regel auch dann, wenn Sie den Rest überspringen.

1. Der API-Key ist ein serverseitiges Geheimnis. Wer ihn hat, steuert Ihre ganze Meeting-Plattform. Legen Sie ihn deshalb nie in Browser-JavaScript, in ein Mobile-App-Bundle oder in ein öffentliches Repository. Wollen Sie Meetings aus dem Browser heraus starten, dann rufen Sie die API von Ihrem eigenen Backend aus auf und geben nur das Ergebnis an die Seite weiter.

2. Ein erfolgreicher Aufruf liefert HTTP 200 und responseCode: 0. Die meisten Endpunkte antworten auch dann mit HTTP 200, wenn der Aufruf fehlgeschlagen ist. Das tatsächliche Ergebnis steht in einem negativen responseCode. Wer nur den HTTP-Status prüft, hält Fehler für Erfolge. Prüfen Sie immer beides.

3. Die Payload liegt immer unter data. Lesen Sie Ihre Werte aus data, nie von der obersten Ebene. Eine Fehlerantwort enthält gar kein data-Feld.

4. Alle Zeitstempel sind ISO 8601 in UTC, mit einem Z am Ende. Das Feld timezone eines Meetings steuert nur, wie Einladungen die Zeiten anzeigen. Es verschiebt weder startTime noch endTime.

Den richtigen API-Key wählen

Es gibt zwei Arten von API-Keys. Welche Sie haben, entscheidet darüber, was Sie tun können.

Hinweis: Geben Sie Keys auf Instanzebene nie an Kunden weiter. Wer einen solchen Key hat, kann Konten erstellen und für jeden User der Instanz handeln.

Ein Key auf Kontoebene ist immer auf die Meeting-Endpunkte beschränkt, ganz gleich, welche Berechtigungen Sie ihm sonst noch geben. Die Plattform erzwingt diese Grenze selbst, sie ist keine blosse Konvention. Einen Key auf Kontoebene können Sie deshalb gefahrlos einem Integrator geben, der nur Meetings planen muss.

Ausserdem muss auf der White-Label-Instanz die Funktion accountLevelApiKeys eingeschaltet sein. Ist sie aus, weist die Plattform jeden Aufruf mit einem Key auf Kontoebene ab.

Im Namen eines Users handeln

Standardmässig handelt ein Key als synthetischer API-User, der zu keiner Person gehört. Wollen Sie stattdessen als echter Meeting-Organisator handeln, senden Sie einen dieser Header:

X-USER-ID: <USER-ID>
X-USER-EMAIL: <USER-EMAIL>

Senden Sie beide, gewinnt X-USER-ID und die Plattform ignoriert X-USER-EMAIL. Senden Sie deshalb nur einen davon.

Das funktioniert mit beiden Key-Arten. Ein Key auf Instanzebene kann als jeder beliebige User der Instanz handeln, ein Key auf Kontoebene nur als Organisator im eigenen Konto. Jedes andere Ziel weist die Plattform ab.

Die IDs

Ein Meeting hat zwei IDs, und die beiden sind nicht austauschbar. Wer sie verwechselt, macht den häufigsten Fehler im Umgang mit dieser API.

Faustregel: Was Bindestriche hat, ist für Menschen. Was 24 hexadezimale Zeichen lang ist, ist für die API. Kein Endpunkt nimmt die meetingId mit Bindestrichen an, auch PUT /meeting nicht. Nehmen Sie deshalb überall data.id.

Drei weitere IDs erscheinen in Antworten:

Konto erstellen

Mit diesem Aufruf erstellen Sie ein Konto und dessen ersten Administrator in einem Schritt. Nur mit Keys auf Instanzebene.

curl 'https://<DOMAIN-NAME>/api/v6/account' \
  -X POST \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'content-type: application/json' \
  --data-binary '{"sendPassword":true,"accountType":"trial","adminFirstname":"Test","adminLastname":"User","adminEmail":"test-user@example.com","adminPreferredLanguage":"en","paidUntil":"2026-12-31T23:59:59.000Z"}'

{
  "responseCode": 0,
  "data": {
    "id": "5e9459c5b863b82cefdddf4f",
    "name": "test-user@example.com",
    "accountType": "trial",
    "numberOfMeetingRooms": 1,
    "paidUntil": "2026-09-21T09:00:00.000Z",
    "accountRooms": []
  }
}

data.id ist die Konto-ID. Merken Sie sich den Wert, der nächste Aufruf braucht ihn.

Die Antwort beschreibt das Konto, nicht den soeben erstellten Administrator. Die User-ID des Administrators fehlt darin. Die holen Sie mit dem nächsten Aufruf.

Kontoadministrator abrufen

Dieser Aufruf liefert die Administratoren eines Kontos. Nur mit Keys auf Instanzebene. So kommen Sie an die User-ID des Administrators, den POST /account erstellt hat.

curl 'https://<DOMAIN-NAME>/api/v6/account/admin/<ACCOUNT-ID>' \
  -X GET \
  -H 'X-API-KEY: <API-KEY>'

{
  "responseCode": 0,
  "data": [
    {
      "id": "5e9459c5b863b82cefdddf4e",
      "email": "test-user@example.com",
      "firstName": "Test",
      "lastName": "User",
      "preferredLanguage": "en",
      "timezone": "Europe/Zurich"
    }
  ]
}

data ist ein Array. Bei einem frisch erstellten Konto steht darin ein Eintrag, ein Konto im laufenden Betrieb kann mehrere haben. Suchen Sie deshalb den Eintrag mit der erwarteten E-Mail-Adresse, statt blind data[0] zu nehmen.

Meeting erstellen

Pflicht sind nur zwei Felder, alles Übrige ist optional. Was Sie weglassen, füllt die Plattform mit den Vorgaben des Kontos. Das Beispiel unten sendet trotzdem alle Felder, und meistens wollen Sie genau das: Ein Meeting ohne endTime und ohne duration dauert 60 Minuten, was selten so gemeint ist.

Mit einem Key auf Instanzebene ergänzen Sie X-USER-ID oder X-USER-EMAIL, um im Namen des betreffenden Users zu planen.

curl 'https://<DOMAIN-NAME>/api/v6/meeting' \
  -X POST \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-ID: <USER-ID>' \
  -H 'content-type: application/json' \
  --data-binary '{"topic":"My Meeting Topic","startTime":"2026-09-07T09:00:00.000Z","endTime":"2026-09-07T10:00:00.000Z","duration":60,"type":"standard","isRecurring":false,"isRecorded":false,"isDialin":false,"invitedParticipants":[],"recurring":{}}'

{
  "responseCode": 0,
  "data": {
    "id": "5e945c36b863b82cefdddf54",
    "meetingId": "9974-7653-8886-0485",
    "topic": "My Meeting Topic",
    "startTime": "2026-09-07T09:00:00.000Z",
    "endTime": "2026-09-07T10:00:00.000Z",
    "type": "standard",
    "roomId": "5e9459c5b863b82cefdddf50",
    "isActive": true,
    "isOpen": false,
    "isClosed": false,
    "accountId": "5e9459c5b863b82cefdddf4f",
    "addedByUserId": "5e9459c5b863b82cefdddf4e",
    "timezone": "Europe/Zurich"
  }
}

So lesen Sie die Antwort:

• data.id brauchen Sie in jedem späteren Aufruf.
• data.meetingId zeigen Sie Ihren Usern, und sie gehört in den Meeting-Link.
• isClosed steht bei einem soeben erstellten Meeting auf true. Das ist normal. Es heisst nur, dass noch niemand beitreten kann. Für Moderatoren öffnet ein Meeting rund eine Stunde vor Beginn (isPreOpen), für alle anderen rund 15 Minuten vorher (isOpen). Werten Sie das nicht als fehlgeschlagenen Aufruf und wiederholen Sie ihn nicht.

Teilnehmer einladen

Jeder Eintrag in invitedParticipants ist ein Objekt:

"invitedParticipants": [
  { "email": "anna@example.com", "name": "Anna Meier", "sendInvite": true }
]

Setzen Sie sendInvite beim Testen auf false, aus demselben Grund wie sendPassword beim Anlegen eines Kontos: Es ist der Unterschied zwischen einem Testlauf und einer E-Mail an eine echte Person.

Das recurring-Objekt

Steht isRecurring auf false, senden Sie {}. Steht es auf true, gelten diese Felder:

weekDays erwartet MO, nicht Monday. Ein unbekannter Eintrag neben gültigen Codes wird bloss ignoriert. Steht in der Liste kein einziger gültiger Code, erstellt die Plattform die Serie ohne Fehlermeldung, aber ohne Termine: Sie erscheint in keiner Meeting-Liste und öffnet nie. Nichts schlägt fehl, es lohnt sich also, das gleich richtig zu treffen.

Ein wöchentliches Standup, jeden Montag, 12-mal:

{
  "isRecurring": true,
  "recurring": {
    "frequencyType": "weekly",
    "frequency": 1,
    "weekDays": ["MO"],
    "endsType": "after",
    "endsAfter": 12
  }
}

Der Meeting-Link

Die API liefert keinen Link zurück. Bauen Sie ihn selbst aus der meetingId mit den Bindestrichen zusammen:

https://<DOMAIN-NAME>/meeting/<data.meetingId>

Für das Beispiel oben ist das https://<DOMAIN-NAME>/meeting/9974-7653-8886-0485.

Es ist derselbe Link, den Veeting in seine Einladungs-E-Mails und Kalendereinträge schreibt. Zwei Dinge dazu:

• Er verwendet die meetingId mit den Bindestrichen. Die 24 Zeichen lange id funktioniert hier nicht.
• Der Host ist die Domain, unter der Ihre User den Meetingraum öffnen. Auf den meisten Instanzen ist das dieselbe <DOMAIN-NAME>, unter der Sie die API aufrufen. Eine White-Label-Instanz kann aber eine andere Domain hinterlegt haben. Lesen Sie den Wert deshalb aus Ihrer eigenen Konfiguration, statt ihn zu raten.

Ist das Meeting passwortgeschützt und steht includeMeetingPasswordInMeetingLink auf true (am Meeting selbst oder als Vorgabe des Kontos), enthält der Einladungslink zusätzlich den Passwort-Hash. Sonst ist data.passwordHash null, und der Link hat keinen Hash. Mit dem Hash muss der Empfänger das Passwort nicht eintippen:

https://<DOMAIN-NAME>/meeting/<data.meetingId>?meetingAccessHash=<data.passwordHash>

An einen Meeting-Link hängen Sie zusätzlich Query-Parameter an. Damit geben Sie den Teilnehmernamen vor, überspringen den Gerätetest, wählen ein Layout und einiges mehr.

Ein Meeting abrufen

curl 'https://<DOMAIN-NAME>/api/v6/meeting/5e945c36b863b82cefdddf54' \
  -X GET \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>'

Liefert das gespeicherte Meeting ohne die berechneten Statusfelder: isActive, isOpen, isClosed, isPreOpen und isPasswordProtected fehlen. Erwartet ausschliesslich die 24 Zeichen lange id. Ist die ID gültig, das Meeting aber nicht vorhanden oder für Sie nicht lesbar, kommt kein Fehler zurück, sondern responseCode: 0 mit data: null.

Sie brauchen das öfter, als Sie denken. Vor einem PUT lesen Sie das Meeting, ändern die gewünschten Felder und senden es vollständig zurück, denn ein PUT ohne invitedParticipants oder password entfernt die Teilnehmer beziehungsweise das Passwort. Damit gleichen Sie auch den Stand eines Meetings ab, wenn Ihnen ein Webhook entgangen sein könnte: die Zustellung wird genau einmal versucht, ohne Wiederholung.

Der Aufrufer muss Organisator des Kontos sein, dem das Meeting gehört, oder in den invitedParticipants des Meetings stehen.

Meetings auflisten

Drei Endpunkte liefern Listen von Meetings. Ein GET /meeting gibt es nicht, ebenso wenig /meeting/list, /meetings oder /history. Diese drei sind alles.

Zukünftige Meetings

Alle Meetings ab 00:00:00 UTC des laufenden Tages.

Ohne geplante Meetings liefert der Endpunkt [].

curl 'https://<DOMAIN-NAME>/api/v6/meeting/upcoming' \
  -X GET \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>'

{
  "responseCode": 0,
  "data": [
    {
      "id": "5e945c36b863b82cefdddf54",
      "meetingId": "9974-7653-8886-0485",
      "topic": "My Meeting Topic",
      "startTime": "2026-09-07T09:00:00.000Z",
      "endTime": "2026-09-07T10:00:00.000Z",
      "type": "standard",
      "roomId": "5e9459c5b863b82cefdddf50",
      "isActive": true,
      "isOpen": false,
      "isClosed": false,
      "accountId": "5e9459c5b863b82cefdddf4f",
      "addedByUserId": "5e9459c5b863b82cefdddf4e",
      "timezone": "Europe/Zurich"
    }
  ]
}

Vergangene Meetings

Meetings, die bereits beendet sind, innerhalb des angefragten Zeitraums. Ob ein Meeting in den Zeitraum fällt, entscheidet sein Ende: bei einem vorzeitig geschlossenen Meeting der Zeitpunkt des Schliessens, sonst die endTime. Ein Zeitraum in der Zukunft liefert [].

curl 'https://<DOMAIN-NAME>/api/v6/meeting/past?startDate=2026-08-01T00:00:00Z&endDate=2026-08-31T23:59:59Z' \
  -X GET \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>'

Der Endpunkt kennt diese optionalen Query-Parameter. Ohne startDate und endDate liefert er jedes Meeting, das das Konto je hatte, nicht nur vergangene:

Meetings in einem beliebigen Zeitraum

Das Gegenstück für beliebige Zeiträume. Gleiche Form des Ergebnisses, frei wählbares Fenster.

GET /api/v6/meeting/<START>/<END>

Beide Pfadsegmente sind Pflicht. Übergeben Sie die literale Zeichenkette null in einem Segment, bleibt dieses Ende offen. Ein Segment, das die Plattform nicht interpretieren kann, verhält sich genau wie null. Mit null in beiden Segmenten erhalten Sie aber nicht alles: Ohne gesetzte Grenze liefert der Endpunkt ein leeres Array.

Anders als /meeting/past schränkt dieser Endpunkt das Ergebnis nicht auf beendete Meetings ein. Er liefert, was ins Fenster fällt, vergangen oder künftig. Massgeblich ist die endTime, ein gerade laufendes Meeting ist also dabei.

curl 'https://<DOMAIN-NAME>/api/v6/meeting/2026-08-01T00:00:00Z/null' \
  -X GET \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>'

Meeting aktualisieren

PUT /api/v6/meeting/<MEETING-ID>/<SEND-UPDATE-TO-PARTICIPANTS>

Das zweite Pfadsegment ist ein Boolean und nicht optional:

• true schickt allen unter invitedParticipants eine aktualisierte Einladung.
• false ändert das Meeting stillschweigend.

Der Body braucht ein id-Feld mit der Meeting-ID, und sie muss mit der ID im Pfad übereinstimmen. Die meisten Felder, die Sie weglassen oder als null senden, behalten ihren bisherigen Wert. Drei Ausnahmen:

• Fehlt invitedParticipants, entfernt die Plattform alle eingeladenen Teilnehmer.
• Fehlt password oder ist es leer, entfernt die Plattform das Passwort. Das Meeting ist dann nicht mehr passwortgeschützt.
• Senden Sie meetingPermissionId oder meetingRegistrationFormId als null oder "", entfernt die Plattform die Berechtigungen bzw. das Registrierungsformular vom Meeting. Fehlt das Feld, bleibt der bisherige Wert.

Um meetingPermissionId oder meetingRegistrationFormId zu leeren, senden Sie "". Mit null bleibt der bisherige Wert.

Am sichersten rufen Sie das Meeting deshalb zuerst ab, ändern, was Sie brauchen, und senden es vollständig zurück.

curl 'https://<DOMAIN-NAME>/api/v6/meeting/5e945c36b863b82cefdddf54/false' \
  -X PUT \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>' \
  -H 'content-type: application/json' \
  --data-binary '{"id":"5e945c36b863b82cefdddf54","topic":"My Updated Meeting Topic","startTime":"2026-09-07T09:30:00.000Z","endTime":"2026-09-07T10:30:00.000Z","duration":60,"type":"standard","isRecurring":false,"isRecorded":false,"isDialin":false,"invitedParticipants":[],"recurring":{}}'

Ein Meeting vorzeitig schliessen

Meetings schliessen sich von selbst, sobald sie zu Ende sind. Wollen Sie eines sofort beenden, schliessen Sie es vorzeitig. Die Plattform entfernt dann alle, die noch im Raum sind.

Schliessen ist nicht Löschen: Der Meeting-Datensatz bleibt bestehen.

curl 'https://<DOMAIN-NAME>/api/v6/meeting/close' \
  -X POST \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>' \
  -H 'content-type: application/json' \
  --data-binary '{"meetingId":"5e945c36b863b82cefdddf54"}'

Hinweis: Trotz seines Namens erwartet das Feld meetingId in diesem Body die 24 Zeichen lange data.id, nicht die data.meetingId mit den Bindestrichen.

Meetings löschen

curl 'https://<DOMAIN-NAME>/api/v6/meeting/5e945c36b863b82cefdddf54' \
  -X DELETE \
  -H 'X-API-KEY: <API-KEY>' \
  -H 'X-USER-EMAIL: <USER-EMAIL>'

Mehrere Meetings löschen Sie in einem Aufruf, indem Sie die IDs mit Kommas trennen:

DELETE /api/v6/meeting/<ID-1>,<ID-2>,<ID-3>

Im Body senden Sie optional eine cancellationMessage mit. Der Text erscheint in der Absage an die eingeladenen Teilnehmer.

Fehler

Eine Fehlerantwort enthält einen negativen responseCode und eine responseMessage, aber kein data-Feld. Denken Sie daran: Der HTTP-Status lautet meistens trotzdem 200.

{
  "responseCode": -44,
  "responseMessage": "Input validation errors"
}

Pro IP-Adresse dürfen Sie 50 Aufrufe pro Sekunde senden, mit einer kurzen Reserve für Spitzen. Darüber antwortet die Plattform mit HTTP 429 statt mit einem responseCode.

Häufige Fehler

• HTTP 200 als Erfolg werten, ohne responseCode zu prüfen.
• Die meetingId mit den Bindestrichen dort übergeben, wo die 24 Zeichen lange id gefragt ist.
• Den Meeting-Link mit id statt mit meetingId zusammenbauen.
• X-USER-ID zusammen mit X-USER-EMAIL senden und erwarten, dass die Plattform die E-Mail-Adresse nimmt.
• POST /account mit einem Key auf Kontoebene aufrufen.
• duration und endTime zusammen senden und erwarten, dass endTime erhalten bleibt. duration überschreibt sie.
• Lokale Zeiten ohne das Z am Ende senden.
• isOpen: false bei einem soeben erstellten Meeting als Fehler deuten.
• An PUT /meeting nur die geänderten Felder senden. Das entfernt die eingeladenen Teilnehmer und das Passwort.
• Den API-Key in clientseitigen Code legen.
• Von den Listen-Endpunkten Paging oder eine stabile Reihenfolge erwarten.
• /meeting/past ohne startDate und endDate aufrufen und nur vergangene Meetings erwarten.
• Ein blosses Datum wie 2026-08-01 senden und Mitternacht UTC erwarten.
• Ein Datum mit dem Tag zuerst senden, etwa 01.08.2026.
• Eine id aus einer Liste für eindeutig halten, obwohl eine Serie sie pro Termin wiederholt.
• /meeting/null/null aufrufen, um alle Meetings zu holen.
• Mit einem Key auf Instanzebene X-USER-ID und X-USER-EMAIL auf den Listen-Endpunkten weglassen.

Der komplette Ablauf

So richten Sie mit einem Key auf Instanzebene einen Kunden ein und planen dessen erstes Meeting:

POST   /account                       -> data.id           Konto-ID
GET    /account/admin/<ACCOUNT-ID>    -> data[0].id        User-ID
POST   /meeting  + X-USER-ID          -> data.id           für API-Aufrufe
                                         data.meetingId    für den Meeting-Link
GET    /meeting/upcoming              -> data[]            ab heute, unsortiert
GET    /meeting/past  + Zeitraum      -> data[]            beendete Meetings
PUT    /meeting/<ID>/<true|false>     aktualisieren
POST   /meeting/close                 vorzeitig schliessen
DELETE /meeting/<ID>                  entfernen

Mit einem Key auf Kontoebene überspringen Sie die ersten beiden Schritte und senden direkt an /meeting.