Wenn du in Provedly einen Account-API-Schlüssel erstellst, triffst du eine Entscheidung: Read only oder Read and write. Es ist eine kleine Wahl, die festlegt, wie viel ein KI-Assistent oder ein Skript mit deinem Konto tun kann, und es lohnt sich, sie am ersten Tag richtig zu treffen statt erst, nachdem etwas Überraschendes passiert ist.
Was jede Stufe erlaubt
| Aktion | Read only | Read and write |
|---|---|---|
| Plan, Limits und Verbrauch sehen | Ja | Ja |
| Websites, Widgets und Leisten auflisten | Ja | Ja |
| Statistiken lesen (Impressionen, Klicks, Bestellungen) | Ja | Ja |
| Das Installations-Snippet abrufen | Ja | Ja |
| Ein Widget pausieren oder fortsetzen | Nein | Ja |
| Eine Leiste anlegen, bearbeiten, pausieren oder fortsetzen | Nein | Ja |
| Einen Eintrag hinzufügen | Nein | Ja |
| Einen Eintrag als verifiziert markieren | Nein | Nein |
Die letzte Zeile ist kein Tippfehler. Kein Schlüssel kann irgendetwas als verifiziert markieren, auf keiner Stufe. Die Verifizierung kommt nur von signierten Webhooks von Stripe, Shopify und WooCommerce, und die API bietet keinen Weg daran vorbei. Mit einem Schreibschlüssel hinzugefügte Einträge behalten die Quelle API, tragen im Widget ein sichtbares „Imported“-Label und zeigen nie die Kennzeichnung „Verifiziert“. Warum dein Assistent keinen Kauf verifizieren kann erklärt die Überlegung dahinter.
Dieselbe Tabelle gilt, egal ob der Schlüssel über die REST-API oder den MCP-Server verwendet wird. Ein Tool-Aufruf ist ein API-Aufruf mit freundlicherer Oberfläche.
Welche du wählst
Eine einfache Regel: Gib einem Schlüssel das Minimum, das er für seine Aufgabe braucht, und erstelle einen zweiten Schlüssel, wenn eine zweite Aufgabe dazukommt.
Berichte und Fragen. Ein wöchentlicher Statistik-Check, ein Dashboard-Skript, ein Assistent, den du fragst „wie lief die letzte Woche?“: Read only. Nichts davon muss etwas ändern, und ein geleakter Lese-Schlüssel lässt einen Fremden deine Zahlen lesen, aber nicht deine Website anfassen.
Kampagnen aus dem Chat steuern. Willst du „pausiere die Black-Friday-Leiste“ oder „erstelle den Launch-Countdown“ sagen und es soll passieren, braucht der Assistent Read and write. Genau darum geht es im Workflow Black Friday aus dem Chat.
Backends, die Käufe hinzufügen. Ein Server, der Einträge sendet, braucht Read and write. Gib ihm einen eigenen Schlüssel, benannt nach dem Dienst, damit du ihn rotieren kannst, ohne etwas anderes anzufassen.
Freelancer und Agenturen. Ein Schlüssel pro Person, benannt mit ihrem Namen. Endet die Zusammenarbeit, widerrufe ihn. Die Agenturseite davon steht in viele Kundenseiten verwalten.
Schutzmechanismen, die für jeden Schlüssel gelten
Auch ein Schlüssel mit Lese- und Schreibzugriff arbeitet innerhalb derselben Regeln wie das Dashboard, und das begrenzt den Schaden durch Fehler.
- Plan-Limits gelten. Ein Widget fortzusetzen oder eine Leiste zu aktivieren, über das Limit deines Plans hinaus, wird abgelehnt.
- Neue Leisten starten pausiert. Eine über die API oder MCP angelegte Leiste wird Besuchern nicht gezeigt, bis jemand sie in einem zweiten Schritt einschaltet. Ein missverstandener Prompt oder ein fehlerhaftes Skript erzeugt einen pausierten Entwurf, kein Live-Banner.
- Nichts wird verifiziert. Siehe oben.
- Widerruf wirkt sofort. Widerrufe einen Schlüssel in den Settings, und die nächste Anfrage damit schlägt fehl.
Umgang mit Schlüsseln
Schlüssel beginnen mit provedly_ und werden einmal angezeigt, bei der Erstellung. Provedly zeigt sie nicht noch einmal an, es gibt also nichts wiederherzustellen; ein verlorener Schlüssel wird widerrufen und ersetzt.
Die meisten Probleme entstehen dort, wo Schlüssel landen. Ein paar Stellen, auf die du achten solltest:
Konfigurationsdateien von MCP-Clients. Claude Code und Cursor speichern Server-Einstellungen in Konfigurationsdateien. Fügst du den Server auf Projektebene hinzu und liegt das Projekt in Git, prüf das vor dem Commit. Die Anleitung für Claude Code und die Anleitung für Cursor zeigen beide, wo der Schlüssel gespeichert wird.
Shell-History. Leg den Schlüssel in eine Umgebungsvariable oder einen Secrets-Manager, statt ihn in einen curl-Befehl einzufügen, den du später in der History wiederfindest.
Browser-Code. Ein Schlüssel in clientseitigem JavaScript ist öffentlich. Die API ist für Server, Terminals und KI-Tools, nie für ein Skript, das in deinem Shop-Frontend läuft. Das Widget-Skript selbst braucht keinen Schlüssel.
Chatverläufe. Füge den Schlüssel nicht in den Chat mit deinem Assistenten ein. Er gehört in den Authorization-Header der Server-Konfiguration, wo der Client ihn sendet, ohne dass das Modell ihn sehen muss.
Wenn ein Schlüssel leakt
Widerrufe ihn in den Settings, erstelle dann einen neuen und aktualisiere ihn überall, wo der alte verwendet wurde. Schau dir danach an, was sich geändert hat: Deine Liste der Leisten und Widgets zeigt den aktuellen Zustand, und alle über die API hinzugefügten Einträge zeigen im Data-Tab des Widgets die Quelle API, sie sind also leicht zu finden und zu entfernen. Weil API-Einträge nie verifiziert werden können, kann ein geleakter Schlüssel keine falschen verifizierten Käufe auf deine Verifizierungsseite bringen.
Häufige Fragen
Kann ich einen Schlüssel von Read only auf Read and write umstellen?
Erstelle einen neuen Schlüssel mit der gewünschten Stufe und widerrufe den alten. Wenn die Stufe pro Schlüssel fest bleibt, ist offensichtlich, was jeder einzelne kann.
Sollten sich mehrere Tools einen Schlüssel teilen?
Das funktioniert, aber getrennte Schlüssel sind im Alltag einfacher. Mit einem Schlüssel pro Tool oder Person zeigt dir die Übersicht der API-Schlüssel, wer Zugriff hat, und der Widerruf eines Schlüssels legt den Rest nicht lahm.
Nutzt das Widget auf meiner Website einen dieser Schlüssel?
Nein. Das Script-Tag auf deinen Seiten nutzt einen öffentlichen Widget-Token und braucht kein Secret. Account-API-Schlüssel sind nur für die REST-API und den MCP-Server.
Schlüssel gibt es in jedem Plan, auch im Free-Plan. Erstelle ein Konto, um deinen ersten anzulegen.