# API-Tokens

Tokens für die API und den MCP-Server erstellen, verwalten und rotieren.

## API-Tokens

Ein API-Token authentifiziert die REST-API und den MCP-Server. Es handelt an deiner Stelle, innerhalb eines Workspaces. Behandle es wie ein Passwort.

<h2 id="format">Format</h2>
<p>
  Ein Token besteht aus <code>fb_</code> gefolgt von 32 alphanumerischen Zeichen — 35 insgesamt. Sende es als Bearer-Token:
</p>

```
Authorization: Bearer fb_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

<p>
  Derselbe Header funktioniert für <a href="/de/developers/rest-api">die API</a> und den <a href="/de/developers/mcp-server">MCP-Server</a>.
  Gespeichert wird nur ein SHA-256-Hash, ein verlorenes Token lässt sich also nicht wiederherstellen — erstelle ein neues.
</p>

<h2 id="limits">Limits</h2>
<ul>
  <li>
    <strong>10 Tokens</strong> pro Person pro Workspace. Zugriffstoken, die beim Verbinden einer OAuth-App ausgestellt werden (
    <code>fbo_...</code>), stehen auf derselben Seite, zählen aber nicht mit.
  </li>
  <li>
    <strong>Läuft 30 Tage nach der Erstellung ab.</strong> Es gibt keinen Verlängern-Button — erstelle ein neues Token und lösche das alte.
  </li>
  <li>
    <strong>Ein Workspace.</strong> Ein Token ist an den Workspace gebunden, in dem es erstellt wurde. Ein Aufruf, der einen anderen
    Workspace oder ein Formular darin nennt, schlägt mit <code>FORBIDDEN</code> fehl — selbst wenn du Mitglied in beiden bist.
  </li>
  <li>
    <strong>Keine Scopes.</strong> Ein Token kann alles, was du in diesem Workspace kannst. Es gibt kein Nur-Lese-Token.
  </li>
</ul>

> ℹ️ **Jeder Plan hat API-Zugriff**
> <p>
>     Das Erstellen und Verwenden von Tokens ist nicht planabhängig. Einzelne Aufrufe schon — Request-Erinnerungen zu planen braucht zum
>     Beispiel Pro oder Business und antwortet sonst mit <code>UPGRADE_REQUIRED</code>.
>   </p>

<h2 id="create">Token erstellen</h2>

<p>
  Die Liste zeigt danach den Namen, die ersten 11 Zeichen, wann es erstellt wurde und wann es abläuft. Ein abgelaufenes Token ist als{' '}
  <strong>Abgelaufen</strong> markiert und authentifiziert nicht mehr.
</p>

<h2 id="rotate">Token rotieren</h2>

<h2 id="revoke">Ein Token widerrufen</h2>
<p>
  Ein Token zu löschen entfernt es dauerhaft, und es funktioniert ab dem nächsten Aufruf nicht mehr — es gibt keine Übergangsfrist, und
  alles, was es noch verwendet, bekommt ab sofort <code>401 UNAUTHORIZED</code>. Du kannst ein Token außerdem über das Stift-Symbol
  umbenennen (bis zu 64 Zeichen); das Umbenennen ändert seinen Wert nicht.
</p>
<p>
  Nur du siehst deine eigenen Tokens — Workspace-Admins können sie weder auflisten noch löschen. Verlässt du den Workspace oder wirst du
  daraus entfernt, werden deine Tokens automatisch gelöscht.
</p>

> ⚠️ **Ein Token hat vollen Zugriff**
> <p>Wer es besitzt, kann in diesem Workspace als du handeln. Ist eines durchgesickert, lösche es zuerst und untersuche danach.</p>

<h2 id="oauth">OAuth statt Token</h2>
<p>
  Eine Drittanbieter-App, die im Namen einer Person eine Verbindung herstellt, sollte den OAuth-Flow verwenden, statt nach einem Token zu
  fragen. Sie erhält ein <code>fbo_...</code>-Zugriffstoken, gültig eine Stunde und 30 Tage lang erneuerbar, gebunden an den einen
  Workspace, den die Person bei der Zustimmung ausgewählt hat. Die Person sieht diese Apps unter <strong>Verbundene Apps</strong> auf
  derselben Seite und kann sie dort trennen. Siehe <a href="/de/developers/mcp-server#oauth">MCP-Server</a>.
</p>

<h2 id="next-steps">Nächste Schritte</h2>
<div class="not-prose grid gap-3 sm:grid-cols-2">
  - [MCP-Server](/de/developers/mcp-server) — Formstep aus KI-Agenten heraus verwenden
  - [Webhooks-Referenz](/de/developers/webhooks-reference) — Payload-Schema und Signierung
</div>