Authentifizierung

Jede Anfrage trägt ein Bearer-Token:

Authorization: Bearer rw_...

Es gibt zwei Arten von Aufrufern, und sie sind bewusst nicht dasselbe.

API-Schlüssel

Ein Schlüssel gehört einem Workspace, nicht einer Person. Er trägt Berechtigungen und enthält nur, was ihm mitgegeben wurde.

Was ein Schlüssel auch enthält, kein Schlüssel kann:

• API-Schlüssel auflisten, erstellen, ändern, erneut anzeigen, widerrufen oder entfernen, oder das Signaturgeheimnis des Webhooks rotieren oder erneut anzeigen,
• die Schlüssel des Workspaces für KI-Dienste lesen, speichern oder entfernen,
• die Zugangsdaten des Plattform-Connectors eines Kanals setzen oder entfernen (ein Schlüssel liest sie maskiert mit Channels: read und testet sie mit Channels: write),
• ein Testereignis aus dem Testwerkzeug eines eigenen Feeds senden (POST /v1/streams/{id}/test): Ein Schlüssel sendet Ereignisse über POST /v1/stream, mit Custom feeds - Send raw data,
• den Tarif ändern, Kontingent kaufen, behalten oder abgeben, den Speicher aufteilen oder die Rechnungsadresse, Rechnungen und die Affiliate-Provision lesen und schreiben,
• den Workspace umbenennen, seine Branchen wählen oder ihn verlassen,
• jemanden anmelden oder auf Sitzungen einwirken,
• die Plattformseite oder einen anderen Workspace als den eigenen erreichen.

Geheimnisse und Geld sind keine Berechtigungen, die Sie ankreuzen können. Eine Zugangsberechtigung, die eine weitere erzeugen oder ändern kann, was ein Workspace zahlt, kann eine Tür öffnen oder echtes Geld kosten, und beide Entscheidungen gehören einer Person, die sich angemeldet hat und im Audit-Protokoll benannt werden kann. Sie werden in der Auswahl gar nicht angeboten.

Personen sind die eine Ausnahme, und sie verdient einen zweiten Blick. team:write erlaubt einem Schlüssel, Kollegen einzuladen, zu ändern, was jeder darf, und sie zu entfernen, damit ein von einem Assistenten eingerichteter Workspace seine Kollegen auf demselben Weg hinzufügen kann. Einem eingeladenen Kollegen kann die Berechtigung Verwaltung gegeben werden, die API-Schlüssel verwaltet; ein Schlüssel mit team:write ist also ein Zugang zum Workspace und nicht nur eine Möglichkeit, ihn zu lesen. Kreuzen Sie ihn nur für einen Schlüssel an, dessen Aufgabe das Einrichten von Workspaces ist. Aus demselben Grund hat die Verbindung eines KI-Assistenten ihn nie: siehe Die Verbindung eines Assistenten.

Alles andere auf diesen Pfaden gehört zu keinem Berechtigungsbereich, und eine Anfrage eines Schlüssels dorthin wird abgelehnt, statt durch Auslassung erlaubt zu werden: Wird vergessen, einen Endpunkt einzuordnen, schlägt das geschlossen fehl, und das ist die einzige sichere Richtung.

Einen Schlüssel erstellen

Ein Schlüssel kann nur von einer angemeldeten Person mit dem Recht zur Verwaltung von Zugangsdaten erstellt werden, also vom Inhaber und von jedem mit der Berechtigung Verwaltung (admin unter seinen powers). Darum verwendet der folgende Aufruf ein Sitzungstoken.

curl http://localhost:4000/v1/keys \
  -H "Authorization: Bearer rws_your_session_token" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Docs examples",
    "permissions": ["ingest:write", "posts:read", "media:write"],
    "expiresAt": "2026-12-31T23:00:00Z"
  }'

{
  "key": {
    "id": "01M2SRXSGEPAJ7VY8W8M3EXHT0",
    "name": "Docs examples",
    "hint": "rw_0...0000",
    "permissions": ["ingest:write", "posts:read", "media:write"],
    "expiresAt": "2026-12-31T23:00:00.000Z",
    "remindExpiry": false
  },
  "secret": "rw_0000000000000000000000000000000000"
}

201, mit secret darin. Jede Anfrage wird allein gegen den Hash des Schlüssels geprüft. Der Schlüssel wird zusätzlich verschlüsselt aufbewahrt, damit eine Person, die Schlüssel erstellen darf, ihn hinter ihrem eigenen Passwort wieder ansehen kann (siehe Einen Schlüssel erneut anzeigen), aber kein Skript kann ihn zurückverlangen: Legen Sie ihn in dem Moment, in dem Sie ihn erstellen, in Ihrem Secret-Manager ab. Der Inhaber und wer den Schlüssel erstellt hat, erhalten eine E-Mail, dass er existiert; die E-Mail nennt den Schlüssel und enthält nie sein Geheimnis.

name hat bis zu 80 Zeichen und ist standardmäßig „API key“. permissions braucht mindestens eine, und jeder Eintrag wird gegen den Katalog geprüft: Eine unbekannte Zeichenfolge würde auf der Seite wie eine Berechtigung aussehen und nichts gewähren, und das ist die schlimmste Art von falsch. GET /v1/keys/permissions liefert diesen Katalog mit fertigen Voreinstellungen, sodass ein Client die Liste nie fest einprogrammiert. expiresAt ist optional: ein Zeitpunkt in der Zukunft (ISO 8601, mit Offset), oder null bzw. weggelassen für einen Schlüssel, der nie abläuft. remindExpiry: true schickt dem Inhaber und allen mit Verwaltung eine Woche und einen Tag vor dem Ablauf eine E-Mail; es braucht ein expiresAt, und PATCH /v1/keys/{keyId} ändert es wie den Rest.

Ein Workspace hat eine begrenzte Zahl von Schlüsseln, die noch funktionieren, 25, sofern Reelwire sie nicht auf Anfrage erhöht hat. Darüber hinaus ist das Erstellen eines Schlüssels ein 409 conflict, der das sagt; ein widerrufener oder abgelaufener Schlüssel zählt nicht mit, das Widerrufen schafft also Platz. Auch die Verbindung eines KI-Assistenten ist ein Schlüssel und zählt genauso. Ein Workspace, dessen Abonnement gekündigt wurde, erstellt keine neuen Schlüssel (409), bis er wieder abonniert, in jedem Tarif, auch in Free.

Zwei Berechtigungen werden nur von jemandem vergeben, der besitzt, was sie öffnen: approvals:write von einer Person mit der Berechtigung Freigaben und plan:read vom Inhaber. Sie anderweitig zu verlangen ist ein 403, der sie nennt, bei POST /v1/keys und bei PATCH /v1/keys/{keyId}, wo ein Schlüssel eine behält, die er schon hat. GET /v1/keys/permissions kennzeichnet sie mit withheld ("read" oder "write") und withheldWhy und lässt sie aus den Voreinstellungen weg.

Sie können kein eigenes Geheimnis mitbringen. Bei einem anderswo gewählten Wert kann Reelwire nichts zusagen, er kommt in einem Anfragetext und in Logs auf dem Weg hierher vor, und die Wahl eines Kunden könnte mit der eines anderen kollidieren.

Auflisten und Widerrufen

curl http://localhost:4000/v1/keys \
  -H "Authorization: Bearer rws_your_session_token"

{
  "keys": [
    {
      "id": "01M2SRXSGEPAJ7VY8W8M3EXHT0",
      "name": "Docs examples",
      "hint": "rw_0...0000",
      "permissions": ["ingest:write", "posts:read", "media:write"],
      "enabled": true,
      "lastUsedAt": "2026-09-18T08:08:07.898Z",
      "expiresAt": "2026-12-31T23:00:00.000Z",
      "remindExpiry": false,
      "expired": false,
      "state": "ACTIVE",
      "connection": false,
      "revealable": true,
      "createdAt": "2026-09-18T08:08:01.807Z"
    }
  ]
}

revealable sagt, ob der Schlüssel aufbewahrt wurde, um erneut angezeigt zu werden: true bei einem Schlüssel, der erstellt wurde, seit Schlüssel aufbewahrt werden, false bei einem früheren (von ihm gibt es nur den Hash) und bei der Verbindung eines Assistenten.

POST /v1/keys/{keyId}/revoke stoppt einen Schlüssel sofort und antwortet mit { "revoked": true, "id": "..." }. Die Zeile bleibt in der Liste mit lastUsedAt, denn das ist der Nachweis, den Sie beim Widerrufen haben wollten. POST /v1/keys/{keyId}/remove löscht danach die Zeile eines widerrufenen oder abgelaufenen Schlüssels und antwortet mit { "removed": true, "id": "..." }; seine letzte Verwendung bleibt im Audit-Protokoll erhalten. Ein Schlüssel, der noch funktioniert, ist ein 409: Widerrufen Sie ihn zuerst.

Ein Schlüssel mit expiresAt funktioniert ab diesem Zeitpunkt nicht mehr, genau wie ein widerrufener: Eine Anfrage mit ihm erhält 401. Auch seine Zeile bleibt, und state unterscheidet die beiden: REVOKED, wenn jemand ihn abgeschaltet hat, EXPIRED, wenn seine eigene Zeit abgelaufen ist, sonst ACTIVE. Ein widerrufener oder abgelaufener Schlüssel kann weder geändert noch zurückgeholt werden (409); erstellen Sie einen neuen. connection: true kennzeichnet die Verbindung eines KI-Assistenten über MCP, die ihr eigenes Token erneuert und kein Ablaufdatum zeigt: siehe unten Die Verbindung eines Assistenten.

PATCH /v1/keys/{keyId} benennt einen Schlüssel um, ändert, was er darf, oder setzt, verschiebt oder entfernt sein expiresAt (null für nie) und sein remindExpiry, ohne ein neues Geheimnis auszugeben, und antwortet mit { "key": { ... } }. Einen Schlüssel zu rotieren bedeutet, jedes System anzufassen, das ihn hält; ihn einzuengen oder zu erweitern muss daher auch für sich möglich sein.

Einen Schlüssel erneut anzeigen

curl http://localhost:4000/v1/keys/01M2SRXSGEPAJ7VY8W8M3EXHT0/reveal \
  -H "Authorization: Bearer rws_your_session_token" \
  -H "Content-Type: application/json" \
  -d '{"password":"..."}'

{
  "key": { "id": "01M2SRXSGEPAJ7VY8W8M3EXHT0", "name": "Docs examples", "hint": "rw_0...0000" },
  "secret": "rw_0000000000000000000000000000000000"
}

POST /v1/keys/{keyId}/reveal gibt einen Schlüssel an die anfragende Person zurück, sobald das Passwort stimmt, mit dem sie sich anmeldet. Es erfordert dasselbe Recht wie das Erstellen eines Schlüssels, das des Inhabers oder der Verwaltung, und eine Sitzung: Ein Schlüssel kann nie einen anderen Schlüssel lesen. Ein falsches Passwort ist ein 403 und kein 401, weil die Sitzung selbst in Ordnung ist, und die Versuche unterliegen dem Limit der Anmeldung, 10 pro Minute von einer Adresse, sodass ein Passwort hier nicht schneller erraten werden kann als bei der Anmeldung. Jeder angezeigte Schlüssel wird mit dem Namen des Anfragenden in das Audit-Protokoll des Workspaces geschrieben (key.reveal), denn ein zurückgelesener Schlüssel ist einer, der jetzt anderswo sein könnte.

Nur ein Schlüssel, der noch funktioniert und aufbewahrt wurde: Ein widerrufener oder abgelaufener Schlüssel ist ein 409, ebenso ein Schlüssel mit revealable: false, von dem nur der Hash existiert. Erstellen Sie einen neuen Schlüssel, setzen Sie ihn dort ein, wo der alte verwendet wird, und widerrufen Sie dann den alten. Das Signaturgeheimnis des Webhooks wird auf dieselbe Weise erneut angezeigt, mit POST /v1/webhook/secret/reveal, demselben Text und denselben Regeln: siehe Webhooks.

Die Verbindung eines Assistenten

Ein KI-Assistent, der sich mit dem MCP-Server von Reelwire durch Anmelden (OAuth) statt mit einem eingefügten Schlüssel verbindet, erhält einen eigenen gewöhnlichen rw_-Schlüssel. Er ist an diesen einen MCP-Server gebunden, den resource bei /v1/whoami nennt, lebt eine Stunde und wird vom Assistenten an Ort und Stelle erneuert; eine Verbindung ist also eine Zeile in GET /v1/keys, mit connection: true und ohne expiresAt (ein dafür gesendetes expiresAt wird ignoriert). Was er darf, ist die Voreinstellung Read only oder Run the whole workspace, je nachdem, was die Person erlaubt hat, abzüglich der beiden oben genannten Berechtigungen, die diese Person einem Schlüssel nicht geben darf. Eine Verbindung, die handeln darf, hat nie Team: write oder Webhook: write und Posts - Approvals: write nur dort, wo die Person das ebenfalls eingeschaltet hat. Das wird bei jeder Erneuerung neu berechnet; wer Freigaben verliert, nimmt sie also innerhalb der Stunde seinem Assistenten. Das Verbinden erfordert dasselbe Recht wie das Erstellen eines Schlüssels von Hand. Das Widerrufen der Zeile beendet die Verbindung, und das anschließende Entfernen beendet sie endgültig. Die Zustimmungsseite finden Sie unter Ihren Assistenten verbinden.

Sein Token funktioniert nur über den MCP-Server von Reelwire: Direkt an die API gesendet, von irgendwo außerhalb von Reelwire, wird es mit einem 401 abgelehnt, der das sagt; so wird verhindert, dass ein aus einem Assistenten kopiertes Token zum Schlüssel für die ganze API wird. Ein Erneuerungstoken, das ein zweites Mal vorgelegt wird, eine Minute oder mehr nach seiner Verwendung, beendet die Verbindung, ebenso ein zweimal eingelöster Anmeldecode: Einer der beiden, die ihn halten, ist nicht der Assistent. Eine zweite Verwendung innerhalb dieser Minute wird nur abgelehnt, denn ein Assistent, der die Antwort auf seine eigene Erneuerung verloren hat und erneut fragt, ist weit häufiger als ein so schneller Dieb.

Die Anmeldung von Reelwire folgt den Standards, die ein gängiger Client erwartet, sodass ihm nichts über Reelwire beigebracht werden muss: der Autorisierungscode mit PKCE (nur S256), Antworten, die den Server nennen (iss, RFC 9207), die Loopback-Adresse eines Assistenten auf jedem Port akzeptiert, das eigene Adressschema einer App akzeptiert (etwa das cursor://, auf das ein Editor ausweicht, wenn sein lokaler Port belegt ist), und ein Assistent, der sich mit der Adresse eines Dokuments über sich selbst benennt (ein Client ID Metadata Document), wird akzeptiert, statt sich zu registrieren.

Welchen Schlüssel halte ich

GET /v1/whoami ist der eine Aufruf, den jeder Schlüssel machen darf, was auch immer seine Berechtigungen sind. Ihn zu verweigern hieße, dass ein Schlüssel seine eigenen Berechtigungen nicht prüfen könnte, und das ist das Erste, was ein gut geschriebener Client tut. /v1/health, /v1/ready, /v1/version, /v1/_meta und /v1/_routes brauchen gar kein Token, und ein Schlüssel, der an sie gesendet wird, wird ebenfalls nicht abgelehnt. /v1/version antwortet mit { "version": "...", "commit": "..." }, dem Release und dem Commit, die das System betreiben; /v1/_meta trägt dieselben beiden neben contractSha, apiVersion, startedAt und catalogueVersion; /v1/_routes listet jede Route mit der Berechtigung, die ein Schlüssel dafür braucht, und daraus wird Jeder Endpunkt erstellt.

curl http://localhost:4000/v1/whoami \
  -H "Authorization: Bearer rw_your_key_here"

{
  "accountId": "01M1VFRWE3A35H892VAAEKKDA6",
  "accountName": "Enterprise 2",
  "scopes": ["ingest:write", "posts:read", "media:write"],
  "permissions": [
    { "scope": "ingest:write", "label": "Custom feeds - Send raw data: write" },
    { "scope": "posts:read", "label": "Posts: read" },
    { "scope": "media:write", "label": "Media: write" }
  ],
  "kind": "apikey",
  "resource": null
}

kind ist apikey oder session. permissions nennt bei einem Schlüssel jede seiner Berechtigungen in den Worten, die die Schlüsselauswahl und jede Ablehnung verwenden. resource nennt den MCP-Server, für den ein Schlüssel ausgestellt wurde, wenn ihn die Verbindung eines KI-Assistenten erzeugt hat, und ist null bei einem von Hand erstellten Schlüssel.

Sitzungen

Eine angemeldete Person erhält ein Sitzungstoken, rws_..., das die Dashboards verwenden und die wenigen nur für Personen bestimmten Routen verlangen. Eine Sitzung trägt, was die Rolle dieser Person erlaubt, statt Berechtigungen je Bereich, und enthält nie das Senden von Rohdaten (ingest:write): Das ist die Aufgabe eines Schlüssels, damit eine gestohlene Dashboard-Sitzung keine Daten einspielen kann und ein durchgesickerter Produzentenschlüssel nichts liest, was ihm nicht gegeben wurde.

curl http://localhost:4000/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com","password":"...","takeOver":true}'

{
  "status": "signed-in",
  "token": "rws_...",
  "expiresAt": "2026-09-18T19:44:11.500Z",
  "expiresAtEpoch": 1789760651,
  "verified": true,
  "user": {
    "id": "01M1VFRWEN9BM7GW2YVJNMZAZK",
    "email": "you@example.com",
    "displayName": "Alex Fischer",
    "optionalMail": true,
    "role": "OWNER",
    "scope": "TENANT",
    "powers": ["operate", "approve", "admin"],
    "tenantId": "01M1VFRWE3A35H892VAAEKKDA6"
  }
}

Reelwire erlaubt eine aktive Sitzung pro Person. Eine Anmeldung an anderer Stelle beendet die erste, und der ersten wird gesagt, warum. Mit takeOver: true sagen Sie, dass Sie das beabsichtigen. Ohne es ist die Antwort, solange die andere Sitzung in den letzten 15 Minuten verwendet wurde, eine Frage statt einer Sitzung: { "status": "in-use", "lastSeenAt": "...", "minutes": 15 }, und kein Token, bis Sie dieselbe Anmeldung erneut mit takeOver: true senden. Darum ist ein Sitzungstoken das Falsche für ein Skript: Zwei Skripte, die sich ein Konto teilen, melden sich abwechselnd gegenseitig ab. Verwenden Sie einen Schlüssel.

Auf reelwire.io sind das Anmelden, das Registrieren und die Anforderung eines Passwort-Resets außerdem für einen Browser gedacht: Jede trägt ein reCAPTCHA-Token, das die Seite erzeugt, und eine Anfrage ohne eines wird mit 403 „We could not verify that this came from a browser“ abgelehnt. Ein weiterer Grund, warum ein Skript einen Schlüssel hält.

Eine falsche Adresse oder ein falsches Passwort ist ein 401, „Invalid email or password“, für beide absichtlich gleich.

Bei eingeschalteter Zwei-Faktor-Anmeldung (jede Person schaltet sie unter Mein Konto ein) bringt ein richtiges Passwort ein Ticket statt einer Sitzung: { "status": "two-factor", "ticket": "...", "expiresAt": "...", "minutes": 5 }. Senden Sie das Ticket mit dem Code, den die Authenticator-App der Person zeigt, oder einem ihrer Wiederherstellungscodes an POST /v1/auth/login/two-factor, mit takeOver wie oben; die Antwort ist die Sitzung oder die Frage „in Benutzung“, gestellt, bevor der Code verbraucht wird:

curl http://localhost:4000/v1/auth/login/two-factor \
  -H "Content-Type: application/json" \
  -d '{"ticket":"...","code":"123456","takeOver":true}'

Das Ticket gilt fünf Minuten und wird ungültig, wenn sich das Passwort inzwischen ändert. Ein falscher Code ist ein 401; zehn falsche Codes innerhalb einer Viertelstunde lassen diese Person fünfzehn Minuten warten. Ein Code wird einmal akzeptiert. Die Zwei-Faktor-Anmeldung ein- und auszuschalten und neue Wiederherstellungscodes zu erstellen ist allein Sache einer angemeldeten Person: POST /v1/auth/two-factor/setup, /enable, /disable und /recovery-codes.

GET /v1/auth/session beschreibt die Sitzung, die Sie halten, einschließlich des Tarifs und seiner Funktionen. Eine Sitzung dauert 12 Stunden und endet früher nach einer Stunde, in der niemand etwas getan hat: POST /v1/auth/heartbeat sagt, dass noch jemand da ist, und antwortet mit der neuen Frist (idleUntil); die Sitzungsantwort sagt, wie lange sie untätig sein darf und wie oft einer zu senden ist (idle.minutes, idle.heartbeatSeconds). POST /v1/auth/logout mit dem Token beendet diese Sitzung.

Wie eine Ablehnung aussieht

Ein fehlendes und ein ungültiges Token sind beide 401, und die Meldung sagt, welches:

{
  "error": {
    "type": "https://reelwire.io/errors/unauthenticated",
    "code": "unauthenticated",
    "message": "Provide a bearer token",
    "requestId": "01M2SR17V1VCT4R68VQXE5PXGH",
    "details": []
  }
}

{
  "error": {
    "type": "https://reelwire.io/errors/unauthenticated",
    "code": "unauthenticated",
    "message": "Invalid credentials",
    "requestId": "01M2SR17SJRFQ844N1FX9FFSKJ",
    "details": []
  }
}

„Invalid credentials“ ist dieselbe Antwort, ob der Schlüssel nie existiert hat, widerrufen wurde, abgelaufen ist oder zu einem anderen Workspace gehört, und zwar absichtlich: Sie zu unterscheiden verriete einem Angreifer, welche Versuche nah dran waren. Der eine 401 mit mehr Inhalt ist das Token eines KI-Assistenten, das direkt an die API gesendet wird: „This token belongs to an assistant's connection and works only through Reelwire's MCP server.“

Eine gültige Zugangsberechtigung, der die Anfrage nicht erlaubt ist, ist ein 403, und diese Meldung ist so konkret, wie es sicher möglich ist, denn sie ist für Sie und nicht für einen Fremden:

{
  "error": {
    "type": "https://reelwire.io/errors/forbidden",
    "code": "forbidden",
    "message": "This key may not read here. Give it the \"Team: read\" permission, or use a key that has it.",
    "requestId": "01M2SR17R25EKN6DM1H9DVDS0D",
    "details": []
  }
}

Ein Schlüssel, der eine Route erreicht, die einer angemeldeten Person gehört, erhält einen anderen Satz:

{
  "error": {
    "type": "https://reelwire.io/errors/forbidden",
    "code": "forbidden",
    "message": "Sign in to do this. Secrets and money are for a signed-in person: an API key cannot mint a credential, change what a workspace pays, or buy allowance. Nor can it rename this workspace or leave it, because a key holds no role and is nobody's membership.",
    "requestId": "01M2SQPYK8ZC7G18BEQ4PHAQB8",
    "details": []
  }
}

Eine Route in keinem Berechtigungsbereich antwortet einem Schlüssel „An API key cannot use this endpoint“, und eine Änderung in einem Bereich, den ein Schlüssel nur lesen darf, etwa POST /v1/licence unter Tarif, sagt, dass dieser Bereich „is read-only for an API key“. Beides ist ein 403, und keine Berechtigung ändert eine der beiden Antworten.

Einige Routen prüfen vor allem anderen ein bestimmtes Recht und antworten in älteren Worten: „This credential lacks the credentials:write scope“ beim Auflisten, Erstellen, Ändern, Anzeigen, Widerrufen oder Entfernen eines Schlüssels und bei den Routen des Webhook-Geheimnisses, an jeden Schlüssel und an eine Person ohne Verwaltung, und „This credential lacks the team:write scope“ beim Einladen, Ändern oder Entfernen eines Kollegen, an einen Schlüssel ohne Team: write und an eine Person ohne Verwaltung. Sie bedeuten, was die obigen Sätze bedeuten.

Den ganzen Umschlag finden Sie unter Fehler.

Ratenlimits

429 ist ein Ratenlimit. Jede Anfrage mit einem Schlüssel oder einer Sitzung zählt gegen diese eine Zugangsberechtigung, 600 pro Minute, egal welche Route sie aufruft, sodass eine ausgelastete Integration das Budget einer anderen nicht aufbrauchen kann. Einige Routen fügen ein engeres eigenes Limit hinzu, gezählt je Adresse:

Route	Limit
Anmelden, Registrieren, Bestätigen einer Adresse, beide Schritte des Passwort-Resets	10 pro Minute
Einen Schlüssel oder das Signaturgeheimnis des Webhooks erneut anzeigen	10 pro Minute, wie bei der Anmeldung
Eine Nachricht an den KI-Assistenten senden oder einen Chat mit ihm starten (POST /v1/ai/generate)	30 pro Minute
Eine Datei für den KI-Assistenten anhängen (POST /v1/ai/attachments)	120 pro Minute
Eine Syndikations-Test-E-Mail senden (POST /v1/syndication/sender/test)	10 pro Minute

Das 429 eines Ratenlimits trägt retryAfterSeconds und einen Retry-After-Header. Jede Antwort, die gegen ein Limit gezählt wurde, sagt auch, wo es steht, in x-ratelimit-limit, x-ratelimit-remaining und x-ratelimit-reset (Sekunden, bis es sich wieder füllt); bei einer Route mit eigenem Limit beschreiben sie dieses Limit.