Hitelesítés és jogosultságok
API-kulcs, MCP-kulcs, OAuth-token: melyik mire való, hogyan készíted el, és mit jelentenek a scope-ok.
Drei Zugangsdaten
| Typ | Präfix | Wo du es nutzt | Woher |
|---|---|---|---|
| API-Schlüssel | psty_… | REST-API und Kommandozeilen-Tool | Einstellungen → Entwickler |
| MCP-Schlüssel | psty_mcp_… | MCP-Server, für Chat-Clients | Einstellungen → Entwickler |
| OAuth-Token | pos_… | Wenn eine App im Namen anderer zugreift | Am Ende des OAuth-Ablaufs |
Der MCP-Server lehnt REST-Schlüssel, die mit psty_ beginnen, absichtlich ab und sagt auch, warum. Wenn ein Chat-Client nicht verbindet, ist das der häufigste Grund.
Der API-Schlüssel
Den Schlüssel erstellst du in Posty, auf der Seite Einstellungen → Entwickler. Du musst uns nicht schreiben, und es gibt keinen Freigabeprozess. Der Schlüssel ist nur einmal sichtbar, im Moment der Erstellung. Danach kannst du ihn nicht mehr abrufen.
Jede Anfrage sendet den Schlüssel im Authorization-Header. Der Schlüssel ist der komplette Wert des Headers:
curl https://api.posty.hu/public/v1/integrations \
-H "Authorization: psty_a_kulcsod"Beim OAuth-Token gibt es dagegen ein Bearer-Präfix:
curl https://api.posty.hu/public/v1/integrations \
-H "Authorization: Bearer pos_a_tokened"Berechtigungen
Den Schlüssel kannst du einschränken: Erlaubt sind nur die Operationen, die wirklich nötig sind. Das sind die Scopes, und die Antwort von https://api.posty.hu/public/v1/status listet sie ebenfalls auf.
| Scope | Was es erlaubt |
|---|---|
posts:read | Kalender und Beiträge lesen. |
posts:draft | Entwürfe erstellen, bearbeiten, löschen. |
posts:publish | Planen und sofort veröffentlichen, und einen Beitrag aus dem Entwurf holen. |
channels:read | Kanäle, Gruppen und Einstellungsschemas lesen. |
channels:write | Das Verbinden eines Kanals starten. |
media:write | In die Mediathek hochladen. |
analytics:read | Statistiken lesen. |
Beim MCP gibt es zwei Scopes: mcp:read und mcp:write.
Ein Agent, der Entwürfe erstellt, braucht nur posts:read und posts:draft. Wenn dann etwas schiefgeht, ist das Schlimmste ein überflüssiger Entwurf, nicht ein Beitrag, der an ein echtes Publikum gegangen ist.
Arbeitsbereich wählen
Wenn ein Schlüssel zu mehreren Arbeitsbereichen gehört, wählt der showorg-Header, auf welchen sich der Aufruf bezieht:
curl https://api.posty.hu/public/v1/integrations \
-H "Authorization: psty_a_kulcsod" \
-H "showorg: <munkaterulet-azonosito>"401 und 403
| Code | Was es bedeutet | Was du tun sollst |
|---|---|---|
| 401 | Die Zugangsdaten fehlen, sind falsch, abgelaufen oder wurden widerrufen. | Prüfe, ob der Schlüssel der komplette Wert des Authorization-Headers ist, ohne Bearer, und ob du ihn inzwischen nicht ersetzt hast. |
| 403 | Die Authentifizierung stimmt, aber die Berechtigung reicht nicht. | Die Antwort nennt den fehlenden Scope und die aktuelle Rolle des Schlüsselbesitzers. Schau dir beides an. |
Die Berechtigung eines Schlüssels folgt der aktuellen Rolle seines Besitzers. Wenn jemand herabgestuft oder aus dem Arbeitsbereich entfernt wird, kann sein Schlüssel sofort nur noch das, was er kann. Wenn ein Schlüssel, der gestern noch funktionierte, heute 403 liefert, ist es fast immer das.
Schlüsselverwaltung
- Leg ihn in eine Umgebungsvariable oder einen Secret-Manager, nicht in den Code und nicht in die Versionskontrolle.
- Wenn er irgendwo gelandet ist, wo er nicht hingehört, ersetze ihn unter Einstellungen → Entwickler. Der Austausch gilt sofort. Der alte Schlüssel bekommt beim nächsten Aufruf 401.
- Für das Kommandozeilen-Tool musst du den Schlüssel gar nicht kopieren:
posty auth:loginspeichert die Zugangsdaten auf deinem Rechner. Siehe die Seite CLI-Authentifizierung. - Schick uns den API-Schlüssel nie per E-Mail. Wir brauchen ihn nicht.