Workspace- und Creator-API

Die Workspace-API verbindet Turniersysteme, Redaktionswerkzeuge und andere externe Dienste mit deinen gespeicherten sOU-Daten. Ein Dienst kann Teams, Spieler, Wettbewerbe, Maps, Matches, Vetos und Ergebnisse vorbereiten. Verbundene Desktop-Clients erhalten diese Änderungen über ihren bestehenden Abgleich. Für diese Integration ist kein zusätzliches Desktopupdate erforderlich.

Voraussetzungen und Umfang

Du benötigst ein bestätigtes, nicht gesperrtes Konto und Zugriff auf den gewünschten Workspace. Leser dürfen Daten lesen. Bearbeiter und Verwalter können zusätzlich Schreibzugriff vergeben. Ein Workspace-Schlüssel gehört deinem Konto und genau einem Workspace; er verleiht niemals mehr Rechte als deine aktuelle Rolle. Ein persönlicher Schlüssel wird durch die Erstellung nicht für andere Mitglieder sichtbar.

Die API bearbeitet gespeicherte Workspace-Daten. Sie startet keine HUDs, aktiviert kein Match und steuert weder OBS noch CS2, HLAE oder den Observer. Live-GSI, Radar und Killfeed werden nicht zur Cloud übertragen. Persönliche Einstellungen, lokale Pfade und Zugangsdaten sind nicht Bestandteil dieser API. Die lokale HUD-API ist eine eigenständige Schnittstelle.

API-Schlüssel im Konto erstellen

1. Melde dich auf der Website an und öffne unter „Dein Konto“ den Bereich „Workspace- und Creator-API“ und „API-Schlüssel verwalten“.
2. Gib einen nachvollziehbaren Namen an, beispielsweise den Namen deines Turniersystems. Der Name hat höchstens 100 Zeichen.
3. Wähle den Workspace. Die Auswahl enthält ausschließlich Arbeitsbereiche, auf die du aktuell zugreifen darfst; die UUID wird für API-Aufrufe angezeigt.
4. Wähle „Nur lesen“ oder „Lesen und schreiben“. Schreibzugriff ist nur mit der Rolle Bearbeiter oder Verwalter möglich. Er umfasst auch Löschmarkierungen und Bild-Uploads.
5. Lege die Gültigkeit von 1 bis 365 Tagen fest; voreingestellt sind 90 Tage. Wähle „Schlüssel erstellen“.
6. Kopiere den vollständig angezeigten Schlüssel sofort in die vertrauliche Konfiguration deines Dienstes. Nach „Schlüsselanzeige schließen“ oder einem erneuten Seitenaufruf wird er nicht wieder angezeigt.

Die Liste zeigt Name, Workspace, Kennung, Zugriff, Erstellzeit, Ablaufzeit und Status. Zeitangaben sind UTC. Unter einem gültigen Schlüssel kannst du über „Auf nur Lesen begrenzen“ oder „Lesen und Schreiben erlauben“ den Zugriff ändern; dafür gelten erneut deine aktuellen Workspace-Rechte. Die Workspace-Bindung und Ablaufzeit bleiben bestehen. Eine Passwortänderung oder Passwort-Rücksetzung macht bisherige Schlüssel ungültig. Abgelaufene oder durch Passwortänderung ungültige Schlüssel musst du ersetzen.

„Schlüssel unwiderruflich widerrufen“ sperrt weitere authentifizierte Aufrufe. Bereits laufende Aufrufe können noch abgeschlossen werden. Ein Widerruf lässt sich nicht rückgängig machen. Erstelle zum Wechsel einen neuen Schlüssel, stelle deinen Dienst um, prüfe einen Leseaufruf und widerrufe dann den alten Schlüssel. Bei einem offengelegten Schlüssel widerrufe ihn sofort. Insgesamt höchstens 50 nicht widerrufene Workspace- und Creator-Schlüssel je Konto sind zulässig; widerrufe auch abgelaufene Einträge, um Platz zu schaffen.

Adresse und Authentifizierung

Die Basisadresse lautet https://www.getsou.app/api/v1/integration. Sende den vollständigen Schlüssel ausschließlich im Header Authorization: Bearer … über HTTPS. Desktop-Anmeldetokens und Browsercookies ersetzen diesen Schlüssel nicht. Workspace-Schlüssel berechtigen ausschließlich die hier dokumentierten Workspace-Entitäts- und Medienoperationen. Für HUD-Uploads benötigst du den separaten Creator-Schlüssel. Beide Schlüsselarten berechtigen weder Konto-, Mitglieder-, Organisations- noch Plattformverwaltung oder HUD-Freigaben.

Verwende pro Integration einen eigenen Schlüssel und speichere ihn serverseitig in einer Secret-Konfiguration. Veröffentliche ihn weder im Browsercode noch in Git, URLs, Screenshots oder Logs. sOU speichert den vollständigen Schlüssel nicht, sondern einen SHA-256-Prüfwert zusammen mit Kennung, Besitzer, Workspace, Name, Zugriff, Erstell-/Ablaufzeit und gegebenenfalls Widerrufszeit. Änderungen und erfolgreiche Schreibaufrufe werden mit Konto und Schlüsselkennung protokolliert; der Schlüsselinhalt und Entitätsinhalte gehören nicht in diese Protokolle.

OpenAPI herunterladen

Die vollständige maschinenlesbare OpenAPI-Beschreibung herunterladen beschreibt alle 51 Operationen, Parameter, Authentifizierung, typisierten Anfragen und Antworten sowie Grenzen. Importiere die öffentliche Datei in einen API-Client oder verwende sie zur Clientgenerierung. Jede Ressource hat ein eigenes Inhaltsschema sowie konkrete Schreib- und Antwortschemas. Der Ressourcenpfad legt den Typ von data fest; ein generischer Dokumentart-Parameter entfällt. Die Beschreibung ist unabhängig von der lokalen HUD-API versioniert.

Alle Endpunkte

Die folgenden Operationen gelten für jede der zehn Ressourcen: teams, players, competitions, seasons, sections, maps, map-pools, matches, startup-configs, panel-templates. Ersetze {resource} durch einen dieser Pfadnamen.

Bestand lesen und Identitäten erhalten

Ersetze die Workspace-UUID durch den Wert aus der Schlüsselverwaltung. Das folgende Shell-Beispiel setzt den Schlüssel über eine verdeckte Eingabe für diese Sitzung. Verwende für einen dauerhaft laufenden Dienst seine Secret-Verwaltung.

read -r -s -p 'sOU API key: ' SOU_API_KEY
export SOU_API_KEY
export SOU_WORKSPACE='00000000-0000-0000-0000-000000000000'
curl --fail-with-body \
  -H "Authorization: Bearer $SOU_API_KEY" \
  "https://www.getsou.app/api/v1/integration/workspaces/$SOU_WORKSPACE/teams"

Eine Sammlung liefert ein Array typisierter Ressourcen mit id, revision, deleted und data. Eine Einzelabfrage liefert genau eine solche Ressource. Der Gesamtbestand enthält die Felder teams, players, competitions, seasons, sections, maps, mapPools, matches, startupConfigs, panelTemplates. Revisionen zählen pro Entität. Kennungen sind innerhalb des Entitätstyps und Workspace eindeutig, unterscheiden Groß-/Kleinschreibung und enthalten 1 bis 100 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche. Spielern dient ihre 17-stellige SteamID64 als Kennung. Erhalte Kennungen bei Umbenennungen. Der Inhalt muss dieselbe Kennung in data.id; Spieler verwenden data.steamId.

Entitäten schreiben und ersetzen

Bei einer Neuanlage ist expectedRevision gleich 0. Bei Änderungen verwende die zuletzt gelesene Revision. data ersetzt die gesamte Entität; ausgelassene optionale Felder verwenden beim Desktopimport ihre Standardwerte. Lies für eine Feldänderung zuerst den aktuellen Inhalt und erhalte die übrigen Felder. Eine erfolgreiche Antwort liefert die erhöhte Revision und bestätigt die Cloud-Speicherung, nicht die Übernahme in einen laufenden Cast.

curl --fail-with-body -X PUT \
  -H "Authorization: Bearer $SOU_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"expectedRevision":0,"data":{"id":"team-alpha","name":"Team Alpha","shortName":"ALP"}}' \
  "https://www.getsou.app/api/v1/integration/workspaces/$SOU_WORKSPACE/teams/team-alpha"

Unbekannte Ressourcen, nicht vorgesehene Felder, falsche Datentypen, widersprüchliche Identitäten und negative Revisionen werden abgelehnt. Namen dürfen nicht nur Leerraum enthalten. Bildverweise müssen auf bereits hochgeladene Dateien dieses Workspace zeigen. Beziehungen werden am vollständigen Zielbestand geprüft: Ein Match benötigt zwei verschiedene vorhandene Teams. Zum gemeinsamen Anlegen abhängiger Objekte verwende ein Änderungspaket.

Zusammengehörige Änderungen atomar schreiben

{
  "teams": [
    {"id":"team-bravo","expectedRevision":0,
     "data":{"id":"team-bravo","name":"Team Bravo","shortName":"BRV"}}
  ],
  "matches": [
    {"id":"final-2026","expectedRevision":0,
     "data":{"id":"final-2026","name":"Finale","teamA":"team-alpha","teamB":"team-bravo","bestOf":3,"mapIds":[],"vetos":[]}}
  ]
}

Sende dieses Objekt als JSON an POST /workspaces/{workspace}/changes. Mindestens eine nicht leere Sammlung ist nötig; ausgelassene Sammlungen bleiben unverändert. Die Feldnamen entsprechen denen des Gesamtbestands. Jede Kennung darf nur einmal pro Sammlung vorkommen. Alle erwarteten Revisionen müssen passen; andernfalls wird kein Teil gespeichert. Abhängigkeiten müssen im resultierenden Gesamtbestand gültig sein, unabhängig von der Reihenfolge. Eine Löschung enthält id, expectedRevision, deleted:true und ausgelassenes oder data:null. Felder zur automatischen Desktop-Ergebnisquelle werden nicht akzeptiert. Stimme Ergebnisänderungen mit den Cast-Verantwortlichen ab; sie übernehmen keine automatische Ergebnisquelle.

Entitäten und Felder

Die folgende Liste enthält alle zulässigen Hauptfelder. Die OpenAPI-Schemas geben Pflichtfelder, Datentypen und Grenzen an. Zahlen für Zustände sind die hier genannten numerischen Enumwerte, keine übersetzten Bezeichnungen. Listen werden bei der Synchronisierung als ein gemeinsames Feld behandelt.

Ein Veto enthält mapId, type und optional teamId: 0 unbekannte Zuordnung, 1 Pick, 2 Ban, 3 Decider. Picks/Bans benötigen eines der beiden Match-Teams; andere Arten haben kein Team. Bans dürfen nicht in der gespielten Mapreihenfolge stehen, alle anderen Entscheidungen müssen dort stehen. Höchstens ein Decider, keine doppelten Mapentscheidungen. Im BO1 ist kein Team-Pick zulässig. Bei zugeordnetem Mappool müssen alle gespielten und entschiedenen Maps darin enthalten sein.

Ein Mapergebnis enthält mapId, status, scoreA, scoreB: Status 1 ausstehend, 2 laufend, 3 abgeschlossen. Ausstehende Maps haben keine Rundenpunkte. Abgeschlossene Maps benötigen zwei nichtnegative, unterschiedliche Punktzahlen. Höchstens eine Map darf laufen; nach dem entscheidenden Seriensieg darf keine weitere Map Ergebnisdaten haben. Bei vorhandener Ergebnisliste ergibt sich der Serienstand aus abgeschlossenen Maps. Bei mapResults gleich null gelten die gespeicherten Serienwerte. Regeln zur Bedienung stehen unter Maps, Pick/Ban und Ergebnisse.

Löschen und wiederherstellen

Verwende die DELETE-Route mit der zuletzt gelesenen expectedRevision als verpflichtendem Queryparameter. Der Server behält eine Löschmarkierung mit erhöhter Revision und data:null, damit auch zuvor offline arbeitende Clients die Löschung erkennen. Sie bleibt in Sammlungen, Einzelabfragen und Gesamtbestand sichtbar. Entferne abhängige Referenzen im selben Änderungspaket. Zur Wiederherstellung sende per PUT den vollständigen gültigen Inhalt und die Revision der Löschmarkierung. Verwende nicht wieder Revision 0. Das Entfernen eines Bildverweises löscht keine Mediendatei.

Bilder übertragen

Berechne SHA-256 über die unveränderten PNG-, JPEG- oder GIF-Bytes. Der Dateiname besteht aus dem kleingeschriebenen 64-stelligen Hexwert und der Endung. Prüfe vorhandene Namen mit dem Medien-POST-Endpunkt; der Body enthält names, die Antwort missing. Übertrage nur fehlende Dateien per Medien-PUT als Binärdaten, Content-Type application/octet-stream. Danach verwende in der Entität /cast-media/{name}. Fremde URLs und lokale Rechnerpfade ersetzen diesen Upload nicht. Dieselbe Datei muss in jedem verwendeten Workspace vorhanden sein.

Synchronisierung und Konflikte

Ein verbundener Desktop gleicht ungefähr alle 15 Sekunden ab; Offlinezeiten und Netzwerkfehler können die Übernahme verzögern. Läuft eine HUD-Ausgabe, warten fremde Änderungen auf „Jetzt in den Cast übernehmen“ oder das Ende der Ausgabe. Aktive Matchauswahl und manuelle CT/T-Zuordnung bleiben lokal. Der API-Aufruf kann diese Schutzregeln nicht umgehen. Der Dienst erhält keine Bestätigung, wann ein bestimmter Desktop die Daten tatsächlich übernommen hat.

Wenn API und Desktop unterschiedliche Felder ändern, kann der bestehende Dreiwegeabgleich sie zusammenführen. Ändern beide dasselbe Feld unterschiedlich oder steht eine Löschung im Konflikt, entscheidet der Nutzer im Desktop. Arrays, etwa Veto-Reihenfolgen, zählen als ein Feld. Bei HTTP 409 lade den aktuellen Bestand erneut, vergleiche ihn mit deiner ursprünglichen Grundlage und deiner geplanten Änderung und löse die Abweichung bewusst. Setze nicht lediglich die neueste Revision vor unveränderte alte Daten. Nach Timeout oder Verbindungsabbruch kann ein Schreibvorgang bereits angekommen sein; lies vor einer Wiederholung den Bestand und vergleiche die Inhalte. Es gibt keinen separaten Idempotenzschlüssel.

Creator-API: HUDs hochladen und aktualisieren

HUDs gehören einer Organisation. Öffne im Konto die API-Schlüsselverwaltung und dort den Bereich „Creator-API: HUDs hochladen und aktualisieren“. Erstelle einen eigenen Creator-Schlüssel mit Name, Organisation, Lese- oder Lese-/Schreibzugriff und 1 bis 365 Tagen Gültigkeit. Es werden ausschließlich Organisationen angezeigt, für die du das ausdrücklich vergebene Publisher-Recht besitzt. Eigentümer- oder Administratorrolle allein genügt nicht; ein entsprechend berechtigtes normales Mitglied darf ebenfalls Creator-Schlüssel nutzen. Die Organisation ist nach der Erstellung unveränderlich.

Kopiere den Schlüssel sofort; er wird nur einmal angezeigt. Sende ihn ausschließlich im Authorization: Bearer … Header. Creator-Schlüssel beginnen mit sou_hud_, Workspace-Schlüssel mit sou_ws_. Die Schlüsselarten sind getrennt: Workspace-Schlüssel erhalten keinen HUD-Uploadzugriff, Creator-Schlüssel keinen Workspace- oder Desktopzugriff. Konto, Sicherheitsmarkierung nach Passwortänderungen, Ablauf, Widerruf, Organisationsbindung und das aktuelle Publisher-Recht werden bei jedem Aufruf geprüft. Bei Verlust des Organisationszugriffs kannst du deinen eigenen Schlüssel weiterhin im Konto widerrufen. Zugriff ändern, Rotation und die insgesamt 50 nicht widerrufenen Schlüssel gelten wie oben beschrieben.

Für ein neues HUD lege zuerst den Eintrag an. Der JSON-Body enthält name, visibility (private, open oder approval) und optional translations für die unten beschriebenen HUD-Angaben. Der Name darf nicht leer sein und höchstens 100 Zeichen haben. Die Organisation stammt aus dem Pfad und dem Schlüssel, nicht aus frei wählbaren JSON-Feldern. Private HUDs werden nicht gelistet; die anderen Sichtbarkeiten werden gelistet, aber erst freigegebene Pakete können abonniert werden. Speichere die zurückgegebene HUD-Kennung.

read -r -s -p 'sOU Creator API key: ' SOU_CREATOR_KEY
export SOU_CREATOR_KEY
export SOU_ORGANIZATION='00000000-0000-0000-0000-000000000000'
curl --fail-with-body \
  -H "Authorization: Bearer $SOU_CREATOR_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"name":"My HUD","visibility":"private"}' \
  "https://www.getsou.app/api/v1/integration/organizations/$SOU_ORGANIZATION/huds"

Für ein bereits vorhandenes HUD verwende dessen bestehende Kennung; lege für ein Update kein zweites HUD an. Lade das vollständige .souhud Paket als rohe Binärdaten mit application/octet-stream hoch, ohne Multipart-Hülle. Der Upload akzeptiert höchstens 128 MiB komprimierte Bytes und höchstens 128 MiB entpackte Gesamtgröße, 4.096 ZIP-Einträge sowie eine hud.json bis 64.000 Bytes. Unbekannte Bodylängen werden während des Streamings begrenzt. Es gelten dieselben Paketprüfungen wie im Desktop: sichere ZIP-Pfade, API-Version 2, unterstützte Laufzeit, gültiger Einstiegspunkt und stabile Paketkennung. Aufbau und Build stehen unter HUD-Paketformat und HUD-Entwicklung.

export SOU_HUD='00000000-0000-0000-0000-000000000000'
curl --fail-with-body \
  -H "Authorization: Bearer $SOU_CREATOR_KEY" \
  -H 'Content-Type: application/octet-stream' \
  --data-binary @my-hud-1.0.0.souhud \
  "https://www.getsou.app/api/v1/integration/organizations/$SOU_ORGANIZATION/huds/$SOU_HUD/releases"

Die erste Paketversion bindet die Paketkennung an dieses HUD. Weitere Versionen müssen dieselbe Paketkennung verwenden; eine fremde Paketkennung ist nicht erlaubt. Jede Version ist unveränderlich, auch ausstehende oder abgelehnte Uploads. Ein Update benötigt deshalb eine neue gültige Versionsnummer. Vorhandene Pakete und Freigaben bleiben erhalten. Die Antwort enthält id, hudId, version, hash, state und review. Ohne Creator-Vertrauen beginnen neue Uploads mit pending; nach der regulären Prüfung können sie approved oder rejected sein. Besitzt das hochladende Konto Creator-Vertrauen, erhält ein erfolgreich geprüftes neues Paket unmittelbar approved. Nutze eine Leseabfrage für Prüfstatus und Vermerk. Der Schlüssel kann weder Vertrauen vergeben noch Prüfentscheidungen ändern. Uploads ändern keine Workspace-Abos und installieren oder starten keine HUDs. Bestehende Desktop-Update- und Ausgabeschutzregeln bleiben erhalten.

Mehrsprachige HUD-Angaben und Medien

GET /organizations/{organization}/huds/{hud}/details liefert revision und translations. Mit PUT auf denselben Pfad ersetzt du die Texte mit {"revision":0,"translations":[{"language":"en","description":"My HUD","author":"Creator","authorUrl":"https://example.org","imprintUrl":null,"privacyUrl":null}]}. Verwende immer die zuletzt gelesene Revision. Die Anfrage darf höchstens 512 KiB enthalten, bis zu 256 unterschiedliche Sprachcodes. Beschreibung: höchstens 8.000 Zeichen; Autor: 200; jede URL: 2.048. URLs müssen absolute HTTP(S)-Adressen ohne Zugangsdaten sein. Medien bleiben beim Ersetzen der Texte erhalten. Alle Angaben sind vorerst optional; für jedes in einer anderen Sprache ausgefüllte Feld ist Englisch en erforderlich.

Medien lädst du separat mit POST /organizations/{organization}/huds/{hud}/media/{language}/{kind}?expectedRevision=… hoch. kind ist preview, gallery oder demo. Sende rohe Dateibytes mit dem zutreffenden Content-Type image/png, image/jpeg, image/webp oder video/mp4. Für Demo ist zusätzlich Content-Disposition: attachment; filename="demo.mp4" erforderlich. Preview: mindestens 1920 × 900 Pixel und maximal 5.000.000 Bytes; Gallery: gleiche Mindestauflösung und maximal 10.000.000 Bytes je Bild; Demo: nur MP4 und maximal 50.000.000 Bytes. Lade zuerst Englisch für die jeweilige Medienart hoch. Preview/Demo ersetzen die bisherige Datei der Sprache, Gallery ergänzt ein Bild. Die Antwort liefert den aktualisierten Detailstand samt Revision und Medienkennungen.

GET /organizations/{organization}/huds/{hud}/media/{media} liefert die Datei; DELETE auf denselben Pfad mit ?expectedRevision=… entfernt die Referenz. Die letzte englische Datei einer Medienart kann erst entfernt werden, wenn keine anderen Sprachfassungen dieser Art mehr vorhanden sind. Sämtliche Schreiboperationen benötigen einen Schreibschlüssel und aktuelles Publisher-Recht; auch Lesezugriffe bleiben auf die gebundene Organisation begrenzt. Bei 409 neu lesen und abgleichen. Diese Inhalte liegen außerhalb des unveränderlichen HUD-Pakets. Weitere Bedienhinweise und künftige Pflichtangaben stehen unter HUD-Angaben.

Anfragen und direkte Freigaben

GET /organizations/{organization}/huds/{hud}/grants liest alle Zugänge und Anfragen eines eigenen HUDs. GET /organizations/{organization}/huds/{hud}/requests liefert ausschließlich noch offene Anfragen mit requested:true und approved:false. Die Datensätze enthalten hudId, workspaceId, approved, requested und das historische, heute nicht mehr zur Versionsauswahl verwendete selectedReleaseId.

Mit PUT /organizations/{organization}/huds/{hud}/grants/{workspace} und {"approved":true} genehmigst du eine Anfrage oder vergibst direkt Zugriff für einen bestehenden Workspace-Code ohne vorherige Anfrage. {"approved":false} lehnt eine Anfrage ab beziehungsweise entzieht den Zugriff. Jede Entscheidung setzt requested:false; abgelehnte oder entzogene Zugänge erscheinen deshalb nicht erneut in der Anfragenliste. Eine ausdrückliche neue Anfrage des Workspace-Verwalters öffnet sie wieder. Bestehende ältere nicht freigegebene Datensätze werden nicht nachträglich als offene Anfragen interpretiert und bleiben in der vollständigen Zugangsliste sichtbar.

Leseschlüssel können die Listen abfragen. Entscheidungen benötigen einen Schreibschlüssel und das aktuelle ausdrückliche Publisher-Recht der gebundenen Organisation. Die erfolgreiche Änderung liefert 204, ein unbekannter Workspace 404 und ungültige Angaben 400; der JSON-Body ist auf 4.096 Bytes begrenzt. Die Freigabe gilt für das HUD und installiert oder startet kein Paket. Nach einer verlorenen Antwort den gespeicherten Zugang lesen und abgleichen. Manuelle Bedienung ist auch in der Web-Creator-Verwaltung verfügbar.

Vertrauenswürdige Creator

Creator-Vertrauen gilt für ein einzelnes Konto einschließlich seiner Creator-Schlüssel. Es gilt nicht automatisch für andere Mitglieder derselben Organisation. Für die Zielorganisation bleibt das ausdrückliche Publisher-Recht erforderlich.

Vertrauen gilt für neue Uploads. Bereits wartende Uploads benötigen weiterhin eine einzelne Prüfung. Nach einem Entzug durchlaufen neue Uploads wieder die reguläre Prüfung; bestehende Versionen behalten ihren Status. Paketprüfung, Größenlimits und unveränderliche Versionen gelten weiterhin. Creator-Schlüssel können weder Vertrauen vergeben noch Prüfentscheidungen ändern.

Nach einer verlorenen Uploadantwort frage die Versionen ab und vergleiche Versionsnummer und SHA-256-Hash mit deinem Paket, bevor du erneut hochlädst. Ein Konflikt liefert 409. Fehlende eigene HUDs oder Versionen liefern 404; unzureichender Schlüsselzugriff oder verlorene Publisher-Rechte 403, ungültige Schlüssel 401, falscher Upload-Medientyp 415 und zu große Anfragen 413. Für beide Schlüsselarten gelten gemeinsam 120 Aufrufe je Minute und Besitzer; beachte Retry-After.

Grenzen und Fehlerbehebung

Es gelten 120 Aufrufe pro Minute je Schlüsselbesitzer, gemeinsam über dessen Schlüssel. HTTP 429 enthält Retry-After in Sekunden. Schreibpakete enthalten höchstens 5.000 eindeutige Entitätsänderungen; Entitätsanfragen höchstens 8 MiB Body. Ein Entitätsinhalt ist auf 256.000 serialisierte Zeichen begrenzt. Bilder sind höchstens 4 MiB groß. Die Medienprüfung akzeptiert höchstens 5.000 unterschiedliche Namen und 400.000 Bodybytes. Auch Daten ohne vorab bekannte Länge sind begrenzt. Plane kleinere zusammengehörige Pakete und begrenzte Wiederholungen ein.

Weitere Regeln zu Offlinebetrieb, Rollen und laufenden Ausgaben findest du unter Workspaces und Zusammenarbeit. Schlüssel verwaltest du unter API-Schlüssel verwalten. Hinweise zur Datenverarbeitung stehen unter Workspace-API und Datenschutz.