Authentifizierung und API-Schlüssel
API-Schlüssel für REST-API und MCP-Server erstellen, Zugriffsebenen Lesen, Schreiben und Ausführen festlegen und widerrufen.
Sowohl die REST-API als auch der MCP-Server verwenden dieselben Anmeldedaten: einen API-Schlüssel, der auf der Entwicklerseite innerhalb der App erstellt wurde.
Basis-URL
Alle Anfragen richten Sie bitte an:
https://shopify.workflow-transactional-email.appJeder der unten aufgeführten Endpunkte bezieht sich auf diesen Host, sodass der vollständige Pfad für den Index https://shopify.workflow-transactional-email.app/api/v1 lautet.
Einen Schlüssel erstellen
Öffnen Sie „Developer“ in der App, wählen Sie eine Zugriffsebene aus und erstellen Sie den Schlüssel. Der vollständige Wert wird einmalig bei der Erstellung angezeigt. Kopieren Sie ihn anschließend und speichern Sie ihn in Ihrem Passwort-Manager oder einem Shop für vertrauliche Daten - er kann später nicht mehr abgerufen werden, da lediglich ein SHA-256-Hash davon gespeichert wird.
Schlüssel beginnen stets mit fak_, wodurch sie in einem Geheimnis-Scanner leicht zu erkennen sind.
Senden Sie es als Inhaber-Token:
GET /api/v1/me HTTP/1.1
Host: shopify.workflow-transactional-email.app
Authorization: Bearer fak_your_key_hereGET /api/v1/me Dies ist der schnellste Weg, um zu überprüfen, ob ein Schlüssel funktioniert, und um festzustellen, welche Berechtigungsstufe er besitzt.
Zugriffsebenen
Die Ebenen sind hierarchisch angeordnet und kumulativ: Jede Ebene umfasst alle darunter liegenden Ebenen.
| Stufe | Was es bietet |
|---|---|
| Nur Lesen | E-Mail-Layouts, E-Mail-Absender, geheime Namen, hochgeladene Dateien, HTTP-Anfragen, Verlauf und Statistiken auslesen |
| Lesen und Schreiben | HTTP-Anfragen erstellen, bearbeiten und löschen sowie nicht verwendete hochgeladene Dateien löschen |
| Lesen, Schreiben und Ausführen | Führen Sie eine HTTP-Anfrage an das eigentliche Ziel aus |
Beachten Sie, wie schmal die beiden oberen Ebenen sind. Alle Daten, die mit E-Mails zu tun haben, sind lesbar, aber auf keiner Ebene beschreibbar - siehe unten.
Warum „execute“ separat steht
Durch das Ausführen einer HTTP-Anfrage wird eine echte Anfrage an ein echtes System eines Drittanbieters gesendet. Indem dies auf einer separaten Ebene gehalten wird, wird sichergestellt, dass ein Schlüssel, den Sie einem Skript - oder einem KI-Assistenten - zum Lesen und Bearbeiten der Konfiguration übergeben, keine Anfragen an Ihre Live-Integrationen auslösen kann.
Vergeben Sie standardmäßig Lesezugriffsrechte. Fügen Sie Schreib- oder Ausführungsrechte nur hinzu, wenn ein bestimmter Auftrag diese benötigt.
Einen Schlüssel widerrufen
Löschen Sie den Schlüssel auf der Seite „Entwickler“. Die Sperrung wird bei der nächsten Anfrage wirksam - es muss nicht auf die Bereinigung des Caches gewartet werden.
Entziehen Sie den Schlüssel und stellen Sie ihn erneut aus, falls er in ein Repository eingecheckt, in ein gemeinsam genutztes Dokument eingefügt oder einem Auftragnehmer übergeben wurde, der ihn nicht mehr benötigt.
Gute Gewohnheiten
- Verwenden Sie in Ihren HTTP-Anfragen die Anmeldedaten als
{{ secrets.KEY }}, anstatt sie in einen Header oder den Textkörper einzufügen. Unverschlüsselte Anmeldedaten werden in API-Antworten maskiert, doch die Verwendung eines Secrets ist vorzuziehen. - Verwenden Sie einen Schlüssel pro Verbraucher, damit Sie eine einzelne Integration widerrufen können, ohne die anderen zu beeinträchtigen.
- Bewahren Sie Ausführungsschlüssel nicht auf den Laptops der Entwickler auf und nehmen Sie sie nicht in die Konfigurationen der KI-Assistenten auf, es sei denn, Sie möchten ausdrücklich, dass der Assistent Live-Anfragen auslösen kann.
