Plugins-API

Mit der Plugins-API kannst du jedes Plugin in deiner Claude Enterprise-Organisation erfassen, Plugins und neue Versionen aus deinen eigenen Pipelines veröffentlichen, festlegen, welche Version Mitgliedern bereitgestellt wird, bestimmen, wer welches Plugin nutzen kann, Plugin-Dateien zur Prüfung herunterladen und einen Git-Marketplace prüfen, bevor du ihn verbindest.

Berichte zur Nutzung von Plugins (welche Plugins und Skills Mitglieder nutzen und wie oft) findest du unter Analytics-APIs.

Endpunkte

Die API stellt 18 Endpunkte für fünf Ressourcen bereit:

Dieses Release umfasst keine eigenständigen Skills (Skills, die ein Mitglied im Skills-Editor schreibt oder als einzelnen Skill in claude.ai hochlädt). Sie erscheinen nicht im Bestand und können hier nicht erstellt werden. Plugins, die Anthropic veröffentlicht, werden ebenfalls nicht erfasst; ihre Nutzung wird von den Analytics-APIs gemeldet. Marketplaces werden in claude.ai erstellt, mit Repositories verbunden und gelöscht, nicht über diese API.

Voraussetzungen

• Deine Organisation muss einen Claude Enterprise-Plan haben.
• Dein Primary Owner erstellt unter claude.ai > Organisationseinstellungen > API einen Admin-API-Key mit dem Scope read:plugins, dem Scope write:plugins oder beiden. Siehe Admin-API-Key erstellen.
• Jede Anfrage enthält drei Header: x-api-key, anthropic-version: 2023-06-01 und anthropic-beta: ce-plugins-2026-09-01.

Die SDKs für Python, TypeScript, C#, Go, Java, PHP und Ruby stellen diese Endpunkte unter client.beta.organization bereit, und die ant CLI unter ant beta:organization; sie senden die Header anthropic-version und anthropic-beta für dich. Die Beispiele auf dieser Seite verwenden den Standard-Client des jeweiligen SDK, der, wie die CLI, den Admin-API-Key aus der Umgebungsvariable ANTHROPIC_API_KEY liest; die curl-Beispiele lesen den Key aus derselben Variable und übergeben ihn im Header x-api-key. In den Listen-Beispielen für Python, TypeScript, C#, Go, Java und Ruby sowie in der CLI ruft das SDK beim Iterieren weitere Seiten ab, sodass limit die Seitengröße festlegt, nicht die Gesamtzahl; die PHP- und curl-Beispiele geben eine Seite zurück (siehe Paginierung).

API-Keys gehören der Organisation und funktionieren weiter, nachdem die Person, die sie erstellt hat, die Organisation verlässt. Teile sie nicht und checke sie nicht in die Versionskontrolle ein.

Schnellstart

Liste die Plugins in den eigenen Marketplaces deiner Organisation auf, die neuesten zuerst:

client = anthropic.Anthropic()

plugins = client.beta.organization.plugins.list(owner_type="organization", limit=20)

# Ruft bei Bedarf automatisch weitere Seiten ab.
for plugin in plugins:
    print(f"{plugin.id}: {plugin.name}")

{
  "data": [
    {
      "type": "plugin",
      "id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
      "name": "sales-toolkit",
      "display_name": "Sales Toolkit",
      "description": "Account research and call prep for the sales team.",
      "served_version_id": "pluginver_01Km7tL4pR9xF5sU2zV3jP6q",
      "served_version_pinned": true,
      "latest_version_id": "pluginver_01Jd5sK2nQ8wE4rT6yU1iO3p",
      "manifest_version": "1.4.0",
      "owner": { "type": "organization" },
      "marketplace_id": "marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r",
      "created_by": { "type": "api_actor", "api_key_id": "apikey_01Nq9vN6rT2zH7uW4bX5mR8s" },
      "organization_installation_preference": "available",
      "organization_installation_preference_inherited": true,
      "content_scan": { "status": "completed", "assessment": "pass", "reason": null },
      "components": [
        {
          "type": "skill",
          "name": "account-research",
          "description": "Researches a customer account before a call."
        },
        { "type": "mcp_server", "name": "crm", "description": null }
      ],
      "reach": "remote",
      "created_at": "2026-09-01T17:04:11Z",
      "updated_at": "2026-09-15T14:12:30Z"
    }
  ],
  "next_page": "page_xK9f2LqT7vNw3pRzBd8sHy"
}

In diesem Beispiel ist das Plugin auf eine frühere Version festgelegt: Eine neuere Version (latest_version_id) ist gespeichert, wird aber noch nicht bereitgestellt.

Scopes

Ein Key kann mehrere Scopes haben. Eine Integration, die ein Plugin hochlädt und es anschließend wieder liest, benötigt sowohl read:plugins als auch write:plugins. Überall dort, wo diese Seite angibt, dass ein Endpunkt den Scope read:plugins erfordert, funktioniert auch ein Key mit read:org_audit oder read:compliance_org_data.

Zugriff auf die Plugin-Dateien von Mitgliedern

Jeder dieser Lese-Scopes (read:plugins, read:org_audit und read:compliance_org_data) kann die Dateien von Plugins in den persönlichen Marketplaces von Mitgliedern herunterladen, einschließlich Dateien, die die Admin-Einstellungen von claude.ai nicht anzeigen, und ein an deine übergeordnete Organisation gebundener Key mit read:org_audit oder read:compliance_org_data kann dies in jeder darunterliegenden Organisation tun, die Zugriff auf diese API hat, indem er organization_id übergibt (siehe Eine andere Organisation unter derselben übergeordneten Organisation lesen). Jeder solche Download erzeugt ein claude_plugin_archive_accessed-Ereignis im Activity Feed der Compliance-API, das den Key, das Plugin, die Version und das Mitglied identifiziert (siehe Activity-Feed-Ereignisse). Downloads von Plugins der Organisation werden nicht erfasst.

Eine andere Organisation unter derselben übergeordneten Organisation lesen

Keys mit read:plugins und write:plugins lesen und schreiben nur in der Organisation, in der sie erstellt wurden. Wenn dein Unternehmen mehrere Claude-Organisationen hat, die unter einer übergeordneten Organisation verknüpft sind, kann ein Key mit read:org_audit oder read:compliance_org_data, den der Primary Owner der übergeordneten Organisation für alle verknüpften Organisationen erstellt hat (siehe Admin-API-Key erstellen), auch jede von ihnen lesen, die Zugriff auf diese API hat: Übergib die ID dieser Organisation im Query-Parameter organization_id bei einem beliebigen GET-Endpunkt auf dieser Seite. Die ID ist die Organisations-UUID, die in den Einstellungen von claude.ai angezeigt wird (ihre Form mit dem Präfix org_ wird ebenfalls akzeptiert). Ohne den Parameter liest der Key die Organisation, in der er erstellt wurde. Ein 404 bedeutet, dass die angegebene Organisation nicht unter der übergeordneten Organisation des Keys liegt oder die API für sie nicht verfügbar ist; ein Wert, der weder eine UUID noch eine org_-ID ist, gibt 400 zurück. Jeder andere Key, der eine andere Organisation als seine eigene angibt, erhält 404. Schreibvorgänge akzeptieren organization_id nicht.

Wichtige Konzepte

Plugins und Komponenten

Ein Plugin ist ein Paket, das Claude für die Mitglieder deiner Organisation erweitert. Es enthält eine beliebige Kombination dieser Komponenten:

Jedes Plugin hat ein Manifest unter .claude-plugin/plugin.json. Der name des Manifests wird zum name des Plugins: ein kleingeschriebener Bezeichner, der innerhalb seines Marketplace eindeutig ist.

Marketplaces

Ein Marketplace ist ein Container für Plugins. Jeder Marketplace hat einen Eigentümer und eine Quelle.

• Eigentümer. Die Organisation besitzt ihre Marketplaces. Jedes Mitglied kann außerdem persönliche Marketplaces haben.
• Quelle. manual bedeutet, dass Plugins hochgeladen werden, in claude.ai oder, bei einem Marketplace der Organisation, über diese API. github, gitlab und public_git bedeuten, dass Plugins aus einem Git-Repository synchronisiert werden, das der Eigentümer verbunden hat. In einen synchronisierten Marketplace kann nichts hochgeladen werden, und diese API kann seine Plugins nicht löschen, weil die nächste Synchronisierung jede dieser Änderungen rückgängig machen würde. Ändere stattdessen das Repository.

Der „library marketplace" (Bibliotheks-Marketplace) deiner Organisation ist der manual-Marketplace der Organisation, in den Uploads gehen, wenn du keinen Marketplace angibst. Er wird erstellt, wenn zum ersten Mal etwas in ihn hochgeladen wird.

Plugins der Organisation und Plugins von Mitgliedern

Das Feld owner.type eines Plugins gibt an, in wessen Marketplace es sich befindet:

• organization: Du kannst es über diese API verwalten, mit der Ausnahme, dass ein Plugin in einem aus Git synchronisierten Marketplace hier keine Uploads erhalten und nicht gelöscht werden kann.
• user: Es befindet sich im persönlichen Marketplace eines Mitglieds. Du kannst seine Details lesen und seine Dateien herunterladen und es löschen, wenn sein Marketplace manual ist. Das Hochladen von Versionen und das Wählen der bereitgestellten Version geben 403 zurück. Freigaben werden ausschließlich vom Mitglied in claude.ai verwaltet.

Das Entfernen eines Mitglieds aus der Organisation entfernt seine Plugins nicht. Sie bleiben unter der user_id des Mitglieds im Bestand, und der Filter owner_user_id findet sie weiterhin, sodass du die Inhalte eines ausgeschiedenen Mitglieds prüfen und entfernen kannst. Sie werden gelöscht, wenn das Konto des Mitglieds gelöscht wird.

Versionen und die bereitgestellte Version

Jeder Upload erzeugt eine neue, unveränderliche Version, unabhängig davon, ob er über diese API, über claude.ai oder durch eine Git-Synchronisierung erfolgt. Ein Plugin hat zwei Zeiger auf seine Versionen:

• latest_version_id: die neueste Version.
• served_version_id: die „served version" (bereitgestellte Version), also die Version, die Mitgliedern bereitgestellt wird.

Standardmäßig ist served_version_pinned false: Die bereitgestellte Version folgt der neuesten, und jede neue Version wird bereitgestellt, sobald sie gespeichert ist.

Das Wählen einer Version mit POST /v1/organizations/plugins/{plugin_id} pinnt das Plugin (served_version_pinned: true). Dasselbe gilt, wenn ein Administrator in claude.ai eine Version wählt oder die Anfrage eines Mitglieds annimmt, in das Plugin zu veröffentlichen. Ab dann werden neue Uploads gespeichert und setzen latest_version_id weiter, aber Mitglieder behalten die gepinnte Version, bis du served_version_id auf eine andere Version setzt. Bei einem Plugin, dessen zwei Zeiger sich unterscheiden, gibt es eine gespeicherte Version, die nicht bereitgestellt wird.

So kann eine Release-Pipeline jeden Build hochladen, testen und anschließend promoten. Damit deine Pipeline entscheidet, wann jeder Build bereitgestellt wird, pinne das Plugin einmalig, indem du served_version_id auf seine aktuelle Version setzt; promote ab dann jeden Build, der bereitgestellt werden soll. Bei aktiviertem Content-Scanning gibt dieses erste Pinnen 409 scan_pending zurück, bis der Scan der aktuellen Version abgeschlossen ist, und 400 scan_failed, wenn der Scan mit fail oder unknown abgeschlossen wurde oder fehlgeschlagen ist (warn wird akzeptiert). Ein gepinntes Plugin kann derzeit nicht wieder entpinnt werden, weder hier noch in claude.ai.

Für ein Rollback setzt du served_version_id auf eine frühere Version. Ein Roll-forward funktioniert auf dieselbe Weise.

Diese Regeln beschreiben Plugins der Organisation. Die bereitgestellte Version eines Plugins eines Mitglieds wird von dessen Eigentümer in claude.ai gesteuert.

Installationseinstellungen

„Installation settings" (Installationseinstellungen) legen fest, wer ein Plugin der Organisation nutzen kann. Jede Einstellung hat einen von vier Werten, die in den Feldern mit dem Namen installation_preference (und, bei den Plugin- und Marketplace-Objekten, organization_installation_preference und default_installation_preference) übertragen werden:

Ein Plugin kann eine organisationsweite Einstellung und eine Einstellung pro Gruppe haben (die Gruppen der rollenbasierten Zugriffskontrolle, die in der Benutzerverwaltung verwaltet werden). Ein Mitglied erhält einen Wert nach diesen Regeln:

1. Der organisationsweite Wert ist die eigene organisationsweite Einstellung des Plugins, falls vorhanden, andernfalls der Standard seines Marketplace, andernfalls not_available. Das Plugin meldet diesen Wert in organization_installation_preference, mit organization_installation_preference_inherited: true, solange er aus dem Marketplace-Standard stammt.
2. Ein Mitglied, das keiner Gruppe mit einer Einstellung für das Plugin angehört, erhält den organisationsweiten Wert.
3. Ein Mitglied, das einer oder mehreren Gruppen mit einer Einstellung angehört, erhält stattdessen die freizügigste Einstellung dieser Gruppen, in der Rangfolge required, auto_install, available, not_available.

Die Einstellung einer Gruppe ersetzt den organisationsweiten Wert für ihre Mitglieder; sie ergänzt ihn nicht. Wenn der organisationsweite Wert beispielsweise required ist und die Gruppe Pilot available hat, erhalten Pilot-Mitglieder available. Wenn du ein Plugin von einer Pilotgruppe auf die gesamte Organisation ausweitest, lege den organisationsweiten Wert fest und entferne dann die Einstellung der Gruppe (das Festlegen des organisationsweiten Werts verhindert dauerhaft, dass das Plugin den Standard seines Marketplace erbt, wie unter Installationseinstellung festlegen erklärt).

Ein über diese API erstelltes Plugin hat anfangs keine eigenen Einstellungen und erbt daher den Standard seines Marketplace: not_available, sofern niemand einen Standard festgelegt hat. Das Löschen einer Gruppe entfernt ihre Einstellungen aus allen Plugins.

Freigaben

„Shares" (Freigaben) legen fest, wer ein Plugin eines Mitglieds nutzen kann. Der Eigentümer gibt es in claude.ai für alle Mitglieder, für eine Gruppe oder für namentlich genannte Mitglieder frei. Diese API listet Freigaben auf, kann sie aber nicht ändern.

Wenn deine Organisation eine Art der Freigabe in ihren claude.ai-Einstellungen deaktiviert hat, erscheinen Freigaben dieser Art weiterhin in der Liste, gewähren aber niemandem Zugriff, solange diese Einstellung deaktiviert ist; die Liste selbst zeigt nicht an, ob das der Fall ist.

Content-Scanning

„Content scanning" (Inhaltsprüfung) ist eine Organisationseinstellung in claude.ai. Wenn sie aktiviert ist, werden neu gespeicherte Versionen gescannt (claude.ai nimmt einige davon aus), und das Ergebnis wird in content_scan gemeldet; eine Version, die nicht gescannt wurde, zum Beispiel eine, die vor dem Aktivieren des Scannings gespeichert wurde, hat content_scan: null. Scanning wird Organisationen, die kundenverwaltete Verschlüsselungsschlüssel oder Zero Data Retention verwenden, nicht angeboten.

Solange Scanning aktiviert ist, wird Mitgliedern ein Plugin nur bereitgestellt, wenn der Scan seiner bereitgestellten Version completed mit pass oder warn ist. Während der Scan läuft oder nachdem er fehlschlägt, einen Fehler hat oder zu keinem Ergebnis kommt, wird das Plugin Mitgliedern vorenthalten, und es wird keine frühere Version an seiner Stelle bereitgestellt. Eine Version, die nie gescannt wurde (content_scan: null), wird normal bereitgestellt.

Bei einem nicht gepinnten Plugin wird jeder Upload sofort zur bereitgestellten Version. Mitglieder verlieren das Plugin, bis der Scan der neuen Version bestanden ist, und bleiben ohne es, wenn der Scan fehlschlägt. Wenn Mitglieder die aktuelle Version behalten sollen, während eine neue gescannt wird, pinne das Plugin zuerst (siehe Versionen und die bereitgestellte Version).

Nach einem Upload ist content_scan.status processing, und das Ergebnis kommt asynchron. Lies die Version, um es zu sehen; das Plugin-Objekt zeigt nur den Scan seiner bereitgestellten Version. Das Ändern der bereitgestellten Version auf eine Version, deren Scan noch läuft, gibt 409 scan_pending zurück; auf eine, deren Scan fehlgeschlagen ist, 400 scan_failed.

Reichweite

reach („reach", Reichweite) fasst in einem Wert zusammen, wie weit eine Version auf den Rechnern der Mitglieder und darüber hinaus reicht:

reach berücksichtigt alles, was die Version deklariert, einschließlich Monitoren, LSP-Servern und App-Einstellungen, die components nicht auflistet, sodass eine Version mit einer leeren components-Liste trotzdem privileged sein kann. Der Wert ist null für eine Version, die gespeichert wurde, bevor Komponenten erfasst wurden, und für eine Version, deren Reichweite nicht bestimmt werden konnte, weil eine ihrer Skill- oder Command-Dateien nicht gelesen werden konnte; behandle null als nicht klassifiziert.

Anforderungen an Uploads

Uploads folgen denselben Regeln wie Plugin-Uploads in claude.ai, sodass an beiden Stellen dieselben Archive akzeptiert werden.

• Der Upload ist entweder ein einzelnes .zip- oder .plugin-Archiv oder eine Menge einzelner Dateien. Ein Archiv darf alles in einen einzigen Ordner auf oberster Ebene einschließen.
• Er muss genau ein Manifest unter .claude-plugin/plugin.json enthalten, das einen name deklarieren muss. Eine einzelne SKILL.md ohne Manifest wird abgelehnt.
• Eine SKILL.md auf oberster Ebene, deren Frontmatter Plugin-Komponenten deklariert, wird mit dem Manifest zusammengeführt; plugin.json hat Vorrang, wo beide einen Wert festlegen.
• name darf Kleinbuchstaben (aus jedem Alphabet), Ziffern und Bindestriche enthalten, bis zu 64 Zeichen. Großbuchstaben, Leerzeichen, Unterstriche und andere Satzzeichen werden abgelehnt.
• displayName hat höchstens 64 Zeichen und description höchstens 500.
• Jede SKILL.md benötigt gültiges YAML-Frontmatter mit name und description, von denen keines XML-Tags wie <example> enthalten darf. Zwei Skills oder zwei Commands dürfen nicht denselben Namen haben.
• Keine Datei darf sich in einem bin/-Verzeichnis auf oberster Ebene befinden.
• Keine verschachtelten .zip-Dateien. Paketierte MCP-Server (.mcpb, .dxt) sind erlaubt.
• Dateipfade müssen relativ sein, dürfen kein .. enthalten und nur Buchstaben, Ziffern, Leerzeichen und _ . - / ( ) , verwenden.
• Der Request-Body und das entpackte Archiv dürfen jeweils höchstens 200 MB groß sein; ein Request-Body über dem Limit gibt 413 (request_too_large) statt 400 zurück. Ein Upload hat höchstens 5.000 Dateien, eine Pfadtiefe von 12, Pfade mit 472 Zeichen und Datei- oder Ordnernamen mit 255 Zeichen.
• ZIP-Archive müssen DEFLATE- oder STORE-Komprimierung verwenden und dürfen weder verschlüsselt sein noch symbolische Links enthalten.
• Ein Marketplace enthält höchstens 500 Elemente, wobei seine Plugins und alle eigenständigen Skills, die Mitglieder darin aufbewahren, mitgezählt werden. Dieses Limit und das Limit von 5.000 Dateien sind aktuelle Werte, die erhöht werden können.

Beispiel-Workflows

Jeden Build aus einer Release-Pipeline veröffentlichen

Lade jeden getaggten Build aus der CI hoch und lass die Pipeline entscheiden, wann ein Build bereitgestellt wird.

1. Finde den Marketplace, in den hochgeladen werden soll, mit GET /v1/organizations/plugin_marketplaces?owner_type=organization, oder lass marketplace_id weg, um den Bibliotheks-Marketplace zu verwenden.
2. Beim ersten Release erstellst du das Plugin mit POST /v1/organizations/plugins. Bei jedem späteren Release notierst du die latest_version_id des Plugins und lädst dann eine Version hoch mit POST /v1/organizations/plugins/{plugin_id}/versions. Wenn die Antwort auf den Upload verloren geht, lies das Plugin und wiederhole den Upload nur, wenn latest_version_id unverändert ist (siehe Uploads wiederholen).
3. Damit Mitglieder die aktuelle Version behalten, während jeder neue Build geprüft wird, pinne das Plugin einmalig, indem du served_version_id auf seine aktuelle Version setzt. Ab dann wird jeder Upload gespeichert, ohne bereitgestellt zu werden, und das Pinnen kann nicht rückgängig gemacht werden: Jeder Build, der bereitgestellt werden soll, benötigt Schritt 5.
4. Wenn Content-Scanning aktiviert ist, frage GET /v1/organizations/plugins/{plugin_id}/versions/{version} ab, bis content_scan.status nicht mehr processing ist, und promote nur, wenn der Status completed mit pass oder warn ist.
5. Promote den Build mit POST /v1/organizations/plugins/{plugin_id} und {"served_version_id": "<the new version's ID>"}. Für ein Rollback sendest du auf dieselbe Weise die ID der vorherigen Version.

Ein Plugin zuerst für eine Pilotgruppe und dann für alle ausrollen

1. Ermittle die ID der Pilotgruppe mit GET /v1/organizations/rbac_groups. Dieser Aufruf benötigt den Scope read:rbac_groups, der einen für alle verknüpften Organisationen erstellten Key erfordert (siehe Benutzerverwaltung). Die nächsten Schritte benötigen write:plugins, der nur in der Organisation wirkt, in der sein Key erstellt wurde. Erstelle daher in einem Unternehmen mit mehreren verknüpften Organisationen diesen Key in der Organisation, die das Plugin enthält, und gib ihm beide Scopes, oder verwende für diese Schritte einen zweiten, dort erstellten Key.

2. Gib der Gruppe eine eigene Einstellung, zum Beispiel auto_install, mit POST /v1/organizations/plugins/{plugin_id}/installation_settings/{target}, wobei {target} die rbac_group_-ID der Gruppe ist, während der organisationsweite Wert not_available bleibt. Nur die Mitglieder der Gruppe erhalten das Plugin.

3. Wenn der Pilot endet, lege den organisationsweiten Wert fest (dies verhindert dauerhaft, dass das Plugin den Standard seines Marketplace erbt, wie unter Installationseinstellung festlegen erklärt), und entferne dann die Einstellung der Gruppe, damit die Gruppe wieder der Organisation folgt:

   cURLCLIPythonTypeScriptC#GoJavaPHPRuby

   

   client = anthropic.Anthropic()
   
   setting = client.beta.organization.plugins.installation_settings.set(
       "organization",
       plugin_id="plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
       installation_preference="required",
   )
   
   print(f"plugin_id: {setting.plugin_id}")
   print(f"installation_preference: {setting.installation_preference}")

   Entferne dann die Einstellung der Gruppe mit DELETE /v1/organizations/plugins/{plugin_id}/installation_settings/{target}, wobei {target} die ID der Gruppe ist. Die Einstellung einer Gruppe ersetzt den organisationsweiten Wert für ihre Mitglieder, statt ihn zu ergänzen, sodass eine verbliebene Gruppeneinstellung available diese Mitglieder auf available halten würde.

Einen Sicherheitsbestand synchron halten

Führe einen nächtlichen Job aus, der Plugins markiert, die über die Sitzung des Mitglieds hinausreichen oder ihren Content-Scan nicht bestehen.

1. Blättere durch GET /v1/organizations/plugins?limit=100, bis next_page null ist, und übergib dabei das next_page jeder Seite selbst als page, statt einen Listen-Iterator des SDK zu verwenden, der bei dieser Liste vorzeitig anhalten kann (siehe Paginierung). Lies bei jedem Durchlauf reach und content_scan jedes Plugins aus dieser Liste: Ein später eintreffendes Scan-Ergebnis ändert updated_at nicht. updated_at zeigt dir, welche Plugins seit dem letzten Durchlauf neue Inhalte oder eine neue bereitgestellte Version haben (ein erneuter Archiv-Download lohnt sich); das vollständige erneute Auflisten erfasst außerdem Entfernungen, denn ein Plugin, das durch eine Git-Synchronisierung oder eine Kontolöschung entfernt wurde, verschwindet ohne Ereignis.
2. Markiere jedes Plugin, dessen reach remote ist (es deklariert einen MCP-Server oder eine CLI) oder dessen content_scan.assessment fail oder unknown ist.
3. Lade für jedes markierte Plugin das Archiv der bereitgestellten Version zur Prüfung mit GET /v1/organizations/plugins/{plugin_id}/versions/{served_version_id}/content herunter (siehe Dateien einer Version herunterladen).
4. Um Mitgliedern ein Plugin während der Prüfung zu entziehen, findest du unter Plugin löschen die umkehrbare (für Plugins der Organisation) und die dauerhafte Option.

Plugins

Das Plugin-Objekt beschreibt ein Plugin in einem der Marketplaces deiner Organisation oder im persönlichen Marketplace eines Mitglieds (die Antwort im Schnellstart zeigt ein vollständiges Objekt). Seine Felder display_name, description, manifest_version, content_scan, components und reach beschreiben seine bereitgestellte Version, sodass ein einziger Listenaufruf zeigt, was Mitgliedern bereitgestellt wird.

Das content_scan-Objekt:

Eine plugin_id ohne das Präfix plugin_ gibt 400 zurück. Eine plugin_id, die das Präfix trägt, aber nicht aufgelöst werden kann, zu einer anderen Organisation gehört oder auf einen eigenständigen Skill verweist, gibt 404 zurück.

Plugins auflisten

GET /v1/organizations/plugins listet jedes Plugin in deiner Organisation auf, in den Marketplaces der Organisation und in den persönlichen Marketplaces der Mitglieder, absteigend sortiert nach created_at. Filtere nach owner_type (organization oder user), owner_user_id (mit dem Präfix user_; die Plugins eines Mitglieds, auch nachdem das Mitglied die Organisation verlassen hat), marketplace_id sowie created_at[gte], created_at[gt], created_at[lte], created_at[lt] (RFC-3339-Zeitstempel). Filter werden mit UND kombiniert. Eine marketplace_id oder owner_user_id, die in deiner Organisation nichts findet, gibt eine leere Seite zurück, keinen Fehler. Die Antwort hat die im Schnellstart gezeigte Form. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

plugins = client.beta.organization.plugins.list(owner_type="organization", limit=20)

# Ruft bei Bedarf automatisch weitere Seiten ab.
for plugin in plugins:
    print(f"{plugin.id}: {plugin.name}")

Plugin erstellen

POST /v1/organizations/plugins erstellt in einem Aufruf ein organisationseigenes Plugin und seine erste Version; diese Version wird zur ausgelieferten Version. Der Body ist multipart/form-data: files[] ist entweder ein einzelnes .zip- oder .plugin-Archiv oder ein Teil pro Datei, wobei der Dateiname jedes Teils der Pfad der Datei innerhalb des Plugins ist (zum Beispiel .claude-plugin/plugin.json). Optionale Felder sind marketplace_id (ein organisationseigener manual-Marketplace; standardmäßig dein Bibliotheks-Marketplace, der bei der ersten Verwendung erstellt wird) und release_notes (bis zu 5.000 Zeichen, im Versionsverlauf von claude.ai angezeigt und mit der Version zurückgegeben). name, display_name, description und manifest_version des Plugins stammen aus dem hochgeladenen Manifest, und der Upload muss die Upload-Anforderungen erfüllen. Wenn die Inhaltsprüfung aktiviert ist, ist content_scan.status in der Antwort processing, und das Ergebnis trifft asynchron ein. Gibt das Plugin zurück. Erfordert den Scope write:plugins.

Ein Archiv hochladen:

client = anthropic.Anthropic()

with open("dist/sales-toolkit.zip", "rb") as archive:
    plugin = client.beta.organization.plugins.create(
        files=[archive],
        release_notes="First release",
    )

print(f"id: {plugin.id}")
print(f"served_version_id: {plugin.served_version_id}")

{
  "type": "plugin",
  "id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
  "name": "sales-toolkit",
  "display_name": "Sales Toolkit",
  "description": "Account research and call prep for the sales team.",
  "served_version_id": "pluginver_01Km7tL4pR9xF5sU2zV3jP6q",
  "served_version_pinned": false,
  "latest_version_id": "pluginver_01Km7tL4pR9xF5sU2zV3jP6q",
  "manifest_version": "1.4.0",
  "owner": { "type": "organization" },
  "marketplace_id": "marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r",
  "created_by": { "type": "api_actor", "api_key_id": "apikey_01Nq9vN6rT2zH7uW4bX5mR8s" },
  "organization_installation_preference": "available",
  "organization_installation_preference_inherited": true,
  "content_scan": { "status": "processing", "assessment": null, "reason": null },
  "components": [
    {
      "type": "skill",
      "name": "account-research",
      "description": "Researches a customer account before a call."
    },
    { "type": "mcp_server", "name": "crm", "description": null }
  ],
  "reach": "remote",
  "created_at": "2026-09-01T17:04:11Z",
  "updated_at": "2026-09-01T17:04:11Z"
}

Einzelne Dateien in einen bestimmten Marketplace hochladen. Hänge jede Datei unter ihrem Pfad innerhalb des Plugins an (das Suffix ;filename= im cURL-Beispiel, die Dateinamen-Argumente in den SDK-Beispielen); wird eine Datei nur unter ihrem Basisnamen gesendet, wird das Manifest nicht gefunden. Die TypeScript- und Java-SDKs sowie die ant-CLI können Dateien noch nicht unter einem Pfad anhängen, daher laden diese Beispiele das Plugin stattdessen als ein einzelnes Archiv in den Marketplace hoch:

client = anthropic.Anthropic()

# Ein (filename, file)-Tupel behält den Pfad jeder Datei im Plugin bei;
# ein reines Dateiobjekt würde nur unter seinem Basisnamen gesendet.
with (
    open(".claude-plugin/plugin.json", "rb") as manifest,
    open("skills/account-research/SKILL.md", "rb") as skill_md,
):
    plugin = client.beta.organization.plugins.create(
        files=[
            (".claude-plugin/plugin.json", manifest),
            ("skills/account-research/SKILL.md", skill_md),
        ],
        marketplace_id="marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r",
    )

print(f"id: {plugin.id}")
print(f"served_version_id: {plugin.served_version_id}")

Neben einem 400 für einen Upload, der gegen die Upload-Anforderungen verstößt (413 für einen Request-Body über 200 MB), und den gemeinsamen Antworten (ein 403, wenn marketplace_id der persönliche Marketplace eines Mitglieds ist; siehe Fehlerantworten) kann das Erstellen fehlschlagen mit:

Plugin abrufen

GET /v1/organizations/plugins/{plugin_id} gibt ein Plugin zurück. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

plugin = client.beta.organization.plugins.retrieve("plugin_01Hq3vX8kZcN2mB7pR4tY9wL")

print(f"id: {plugin.id}")
print(f"name: {plugin.name}")

Ausgelieferte Version ändern

POST /v1/organizations/plugins/{plugin_id} ändert, welche Version eines organisationseigenen Plugins an Mitglieder ausgeliefert wird. Übergib eine frühere Version, um zurückzurollen, oder eine neuere, um einen Build freizugeben, der gespeichert, aber nicht ausgeliefert wurde. Dadurch wird das Plugin fixiert, und ein fixiertes Plugin kann derzeit weder hier noch in claude.ai wieder gelöst werden (siehe Versionen und die ausgelieferte Version). Das einzige aktualisierbare Feld ist served_version_id, und es ist erforderlich. Die Änderung erreicht die Mitglieder, bevor die Antwort zurückkommt, und erstellt keine Version. Wenn die Inhaltsprüfung aktiviert ist, muss die Version eine sein, die an Mitglieder ausgeliefert werden darf (siehe Inhaltsprüfung). Die Übergabe der bereits ausgelieferten Version bei einem fixierten Plugin ändert nichts; bei einem nicht fixierten Plugin fixiert sie es auf dieser Version, sodass spätere Uploads nicht mehr automatisch ausgeliefert werden. Gibt das Plugin zurück. Erfordert den Scope write:plugins.

client = anthropic.Anthropic()

plugin = client.beta.organization.plugins.update(
    "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
    served_version_id="pluginver_01Jd5sK2nQ8wE4rT6yU1iO3p",
)

print(f"id: {plugin.id}")
print(f"served_version_id: {plugin.served_version_id}")

{
  "type": "plugin",
  "id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
  "name": "sales-toolkit",
  "display_name": "Sales Toolkit",
  "description": "Account research and call prep for the sales team.",
  "served_version_id": "pluginver_01Jd5sK2nQ8wE4rT6yU1iO3p",
  "served_version_pinned": true,
  "latest_version_id": "pluginver_01Jd5sK2nQ8wE4rT6yU1iO3p",
  "manifest_version": "1.5.0",
  "owner": { "type": "organization" },
  "marketplace_id": "marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r",
  "created_by": { "type": "api_actor", "api_key_id": "apikey_01Nq9vN6rT2zH7uW4bX5mR8s" },
  "organization_installation_preference": "available",
  "organization_installation_preference_inherited": true,
  "content_scan": { "status": "completed", "assessment": "pass", "reason": null },
  "components": [
    {
      "type": "skill",
      "name": "account-research",
      "description": "Researches a customer account before a call."
    },
    { "type": "mcp_server", "name": "crm", "description": null },
    {
      "type": "command",
      "name": "call-prep",
      "description": "Builds a one-page brief for an upcoming call."
    }
  ],
  "reach": "remote",
  "created_at": "2026-09-01T17:04:11Z",
  "updated_at": "2026-09-16T10:02:45Z"
}

Neben den gemeinsamen Antworten (ein 403 für ein mitgliedseigenes Plugin sowie 409 scan_pending oder 400 scan_failed für eine Version, die nicht an Mitglieder ausgeliefert werden darf; siehe Fehlerantworten) kann die Anfrage fehlschlagen mit:

Plugin löschen

DELETE /v1/organizations/plugins/{plugin_id} löscht ein Plugin und alle seine Versionen dauerhaft, genau wie das Löschen durch einen Administrator in claude.ai. Es funktioniert für jedes Plugin in einem manual-Marketplace, einschließlich des Plugins eines Mitglieds, selbst wenn dieses Mitglied die Organisation inzwischen verlassen hat. Wenn das Löschen zurückkehrt, sind das Plugin, seine Versionen und deren Dateien aus allen Lesezugriffen verschwunden, und es wird nicht mehr an Mitglieder ausgeliefert. Die Installationseinstellungen eines organisationseigenen Plugins werden mit ihm entfernt; die Freigaben eines mitgliedseigenen Plugins werden zurückgezogen, und es verschwindet auch für seinen Eigentümer. Ein Plugin in einem aus Git synchronisierten Marketplace gibt 400 zurück: Entferne es aus dem Repository oder entferne den Marketplace in claude.ai. Erfordert den Scope write:plugins.

Das Löschen kann nicht rückgängig gemacht werden, und es gibt kein Löschen einzelner Versionen. Um ein organisationseigenes Plugin stattdessen umkehrbar zurückzuhalten, setze seine organisationsweite Installationseinstellung auf not_available (ein Plugin, das bisher den Standard seines Marketplace geerbt hat, behält ab dann eine eigene Einstellung) und entferne jede Gruppeneinstellung, die GET /v1/organizations/plugins/{plugin_id}/installation_settings auflistet (oder setze sie auf not_available), denn die Einstellung einer Gruppe überschreibt für deren Mitglieder den organisationsweiten Wert. Sende diese Schreibvorgänge nacheinander, nicht parallel (siehe Installationseinstellung festlegen). Ein mitgliedseigenes Plugin kann über diese API nur durch Löschen zurückgehalten werden, und das nur, wenn sein Marketplace manual ist.

client = anthropic.Anthropic()

deleted_plugin = client.beta.organization.plugins.delete(
    "plugin_01Hq3vX8kZcN2mB7pR4tY9wL"
)

print(f"id: {deleted_plugin.id}")

{ "type": "plugin_deleted", "id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL" }

Plugin-Versionen

Eine Plugin-Version ist ein unveränderlicher Snapshot der Dateien eines Plugins aus einem Upload (die Antwort von Version erstellen zeigt ein vollständiges Objekt). Ihre Felder spiegeln die Felder der ausgelieferten Version des Plugins (display_name, description, manifest_version, content_scan, components, reach) für diese Version wider, ergänzt um release_notes (wie beim Upload angegeben; im Versionsverlauf von claude.ai angezeigt) und created_by (wer sie hochgeladen hat).

Eine {version} ohne das Präfix pluginver_ gibt 400 zurück (außer dem Literal latest, wo angegeben). Eine, die das Präfix trägt, aber keine Version dieses Plugins bezeichnet, gibt 404 zurück.

Versionen eines Plugins auflisten

GET /v1/organizations/plugins/{plugin_id}/versions listet die Versionen eines Plugins auf, absteigend nach created_at sortiert; das erste Element ist die Version, die latest_version_id bezeichnet. limit liegt zwischen 1 und 1.000. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

versions = client.beta.organization.plugins.versions.list(
    "plugin_01Hq3vX8kZcN2mB7pR4tY9wL", limit=50
)

# Ruft bei Bedarf automatisch weitere Seiten ab.
for version in versions:
    print(f"{version.id}: {version.manifest_version}")

Version erstellen

POST /v1/organizations/plugins/{plugin_id}/versions fügt einem organisationseigenen Plugin in einem manual-Marketplace eine Version hinzu. Der Body ist multipart/form-data, mit denselben Feldern files[] und release_notes, denselben Upload-Anforderungen sowie denselben Datei-, Manifest-, Archiv- und Größenfehlern wie bei Plugin erstellen. Der hochgeladene Name (der name des Manifests) muss dem name des Plugins entsprechen. Ist das Plugin nicht fixiert, wird die neue Version ausgeliefert, sobald sie gespeichert ist; ist es fixiert, wird die Version gespeichert, aber erst ausgeliefert, wenn du die ausgelieferte Version auf sie änderst. Vergleiche zur Prüfung die id der Antwort mit der served_version_id des Plugins. Gibt die Version zurück. Erfordert den Scope write:plugins.

client = anthropic.Anthropic()

with open("dist/sales-toolkit.zip", "rb") as archive:
    version = client.beta.organization.plugins.versions.create(
        "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
        files=[archive],
        release_notes="Adds the call-prep command.",
    )

print(f"id: {version.id}")
print(f"manifest_version: {version.manifest_version}")

{
  "type": "plugin_version",
  "id": "pluginver_01Jd5sK2nQ8wE4rT6yU1iO3p",
  "plugin_id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
  "display_name": "Sales Toolkit",
  "description": "Account research and call prep for the sales team.",
  "manifest_version": "1.5.0",
  "release_notes": "Adds the call-prep command.",
  "created_by": { "type": "api_actor", "api_key_id": "apikey_01Nq9vN6rT2zH7uW4bX5mR8s" },
  "content_scan": { "status": "processing", "assessment": null, "reason": null },
  "components": [
    {
      "type": "skill",
      "name": "account-research",
      "description": "Researches a customer account before a call."
    },
    { "type": "mcp_server", "name": "crm", "description": null },
    {
      "type": "command",
      "name": "call-prep",
      "description": "Builds a one-page brief for an upcoming call."
    }
  ],
  "reach": "remote",
  "created_at": "2026-09-15T14:12:30Z"
}

Neben einem 400 für einen Upload, der gegen die Upload-Anforderungen verstößt (413 für einen Request-Body über 200 MB), und den gemeinsamen Antworten (ein 403 für ein mitgliedseigenes Plugin; siehe Fehlerantworten) kann die Anfrage fehlschlagen mit:

Version abrufen

GET /v1/organizations/plugins/{plugin_id}/versions/{version} gibt eine Version zurück. {version} ist eine Versions-ID oder latest für die Version, die latest_version_id zum Zeitpunkt der Anfrage bezeichnet. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

version = client.beta.organization.plugins.versions.retrieve(
    "latest",
    plugin_id="plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
)

print(f"id: {version.id}")
print(f"manifest_version: {version.manifest_version}")

Dateien einer Version herunterladen

GET /v1/organizations/plugins/{plugin_id}/versions/{version}/content lädt die Dateien einer Version als gespeichertes .zip-Archiv herunter (Content-Type: application/zip). Das Archiv wird unabhängig vom Ergebnis der Inhaltsprüfung zurückgegeben, sodass du auch Versionen untersuchen kannst, die Mitgliedern vorenthalten werden. Es wird genau so ausgeliefert, wie es gespeichert ist, sodass du es bei einem organisationseigenen Plugin in einem manual-Marketplace unverändert als neue Version erneut hochladen kannst, sofern es die aktuellen Upload-Anforderungen erfüllt. {version} muss eine Versions-ID sein, nicht latest: Lies zuerst served_version_id oder latest_version_id des Plugins aus oder löse latest mit GET /v1/organizations/plugins/{plugin_id}/versions/latest auf. Der Dateiname in Content-Disposition wird aus dem Namen des Plugins abgeleitet und ist nicht eindeutig; benenne gespeicherte Dateien nach Plugin- und Versions-ID. Erfordert den Scope read:plugins.

Das Herunterladen des Archivs eines mitgliedseigenen Plugins erzeugt ein claude_plugin_archive_accessed-Ereignis im Activity Feed der Compliance API, das den Key (als api_actor), das Plugin und seinen Marketplace, die Version und das besitzende Mitglied per ID identifiziert; es enthält keine Namen. Das Herunterladen des Archivs eines organisationseigenen Plugins erzeugt keinen Eintrag.

client = anthropic.Anthropic()

plugin_id = "plugin_01Hq3vX8kZcN2mB7pR4tY9wL"
version_id = "pluginver_01Km7tL4pR9xF5sU2zV3jP6q"

with client.beta.organization.plugins.versions.with_streaming_response.download(
    version_id,
    plugin_id=plugin_id,
) as response:
    response.stream_to_file(f"{plugin_id}_{version_id}.zip")

Plugin-Installationseinstellungen

Diese Endpunkte gelten für organisationseigene Plugins. Für ein mitgliedseigenes Plugin, das stattdessen Freigaben hat, geben sie 404 zurück. {target} ist das Literal organization für die organisationsweite Einstellung des Plugins oder die rbac_group_-ID einer Gruppe für die Einstellung dieser Gruppe; jeder andere Wert gibt 400 zurück. Gruppen-IDs stammen aus GET /v1/organizations/rbac_groups (Scope read:rbac_groups; siehe Benutzerverwaltung). Eine Einstellung hat keine eigene id: Sie wird über (plugin_id, target) adressiert, und es wird kein Akteur an ihr gespeichert (der Akteur steht im zugehörigen Activity-Ereignis plugin_installation_preference_updated).

Installationseinstellungen eines Plugins auflisten

GET /v1/organizations/plugins/{plugin_id}/installation_settings listet die Einstellungen eines organisationseigenen Plugins auf, absteigend nach created_at sortiert: seine eigene organisationsweite Einstellung (fehlt, solange es den Standard seines Marketplace erbt) und die Einstellung jeder Gruppe. Filtere nach target_type (organization oder rbac_group). Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

settings = client.beta.organization.plugins.installation_settings.list(
    "plugin_01Hq3vX8kZcN2mB7pR4tY9wL"
)

# Ruft bei Bedarf automatisch weitere Seiten ab.
for setting in settings:
    print(f"{setting.plugin_id}: {setting.installation_preference}")

Installationseinstellung festlegen

POST /v1/organizations/plugins/{plugin_id}/installation_settings/{target} legt die Installationseinstellung eines Ziels für ein organisationseigenes Plugin fest, indem sie erstellt oder ihr bestehender Wert geändert wird. Das einzige Feld im Body ist installation_preference (required, auto_install, available oder not_available), und es ist erforderlich. Das Setzen des Werts, den das Ziel bereits hat, ändert nichts. Das Setzen des Ziels organization beendet die Vererbung des Marketplace-Standards für das Plugin (organization_installation_preference_inherited wird false), selbst wenn der Wert dem Standard entspricht; dies kann nicht rückgängig gemacht werden, da die organisationsweite Einstellung nicht entfernt werden kann, sodass das Plugin späteren Änderungen am Marketplace-Standard nicht mehr folgt. Ein Gruppenziel muss eine Gruppe sein, die deine Organisation in GET /v1/organizations/rbac_groups sehen kann, andernfalls gibt die Anfrage 404 zurück. Die Änderung verändert updated_at des Plugins nicht; sie wird im Activity Feed erfasst. Gibt die Einstellung zurück. Erfordert den Scope write:plugins.

Sende die Schreibvorgänge für Installationseinstellungen eines Plugins einzeln nacheinander. Treffen mehrere Schreibvorgänge für dasselbe Plugin gleichzeitig ein, verarbeitet der Server sie nacheinander und kann einige davon mit 503 beantworten, statt sie anzuwenden. Dieses 503 enthält x-should-retry: true, und der Schreibvorgang kann gefahrlos wiederholt werden: Warte ein bis zwei Sekunden und sende ihn dann erneut.

client = anthropic.Anthropic()

setting = client.beta.organization.plugins.installation_settings.set(
    "rbac_group_01F3xQqQzXyWvUtSrQpOnMlK",
    plugin_id="plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
    installation_preference="available",
)

print(f"plugin_id: {setting.plugin_id}")
print(f"installation_preference: {setting.installation_preference}")

{
  "type": "plugin_installation_setting",
  "plugin_id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
  "target": { "type": "rbac_group", "rbac_group_id": "rbac_group_01F3xQqQzXyWvUtSrQpOnMlK" },
  "installation_preference": "available",
  "created_at": "2026-09-02T10:00:00Z",
  "updated_at": "2026-09-02T10:00:00Z"
}

Installationseinstellung einer Gruppe entfernen

DELETE /v1/organizations/plugins/{plugin_id}/installation_settings/{target} entfernt die Einstellung einer Gruppe für ein organisationseigenes Plugin. Für die Mitglieder dieser Gruppe gilt dann wieder der organisationsweite Wert oder die Einstellung einer anderen ihrer Gruppen. Die organisationsweite Einstellung kann, einmal gesetzt, nicht entfernt werden, genau wie in claude.ai ({target} mit organization gibt 400 zurück); ändere stattdessen ihren Wert. Eine Gruppe ohne Einstellung für dieses Plugin gibt 404 zurück. Die Antwort enthält anstelle einer id den zusammengesetzten Schlüssel. Erfordert den Scope write:plugins.

client = anthropic.Anthropic()

removed_setting = client.beta.organization.plugins.installation_settings.remove(
    "rbac_group_01F3xQqQzXyWvUtSrQpOnMlK",
    plugin_id="plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
)

print(f"plugin_id: {removed_setting.plugin_id}")

{
  "type": "plugin_installation_setting_deleted",
  "plugin_id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL",
  "target": { "type": "rbac_group", "rbac_group_id": "rbac_group_01F3xQqQzXyWvUtSrQpOnMlK" }
}

Plugin-Freigaben

Freigaben gibt es nur bei mitgliedseigenen Plugins, und sie sind in dieser API schreibgeschützt (siehe Freigaben).

Freigaben eines Plugins auflisten

GET /v1/organizations/plugins/{plugin_id}/shares listet auf, für wen der Eigentümer eines mitgliedseigenen Plugins es freigegeben hat, absteigend nach granted_at sortiert: alle Mitglieder (organization), eine Gruppe (rbac_group) oder ein namentlich genanntes Mitglied (organization_member). Filtere nach target_type. Ein Plugin, das sein Eigentümer nicht freigegeben hat, gibt eine leere Liste zurück; ein organisationseigenes Plugin gibt 404 zurück. Freigaben sind in dieser API schreibgeschützt, und eine aufgelistete Freigabe gewährt nur Zugriff, solange diese Art der Freigabe für deine Organisation in claude.ai aktiviert ist (siehe Freigaben). granted_at ist der Zeitpunkt, zu dem die Freigabe erteilt wurde; ändert der Eigentümer die Freigabe später in claude.ai, ist es der Zeitpunkt dieser Änderung. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

shares = client.beta.organization.plugins.shares.list("plugin_01Mr2wP7sU3aJ8vX5cY6nS9t")

# Ruft bei Bedarf automatisch weitere Seiten ab.
for share in shares:
    print(f"plugin_id: {share.plugin_id}")

{
  "data": [
    {
      "type": "plugin_share",
      "plugin_id": "plugin_01Mr2wP7sU3aJ8vX5cY6nS9t",
      "target": { "type": "organization_member", "user_id": "user_01WCz9BvGLdMYRUMmcAxMWvW" },
      "granted_at": "2026-08-20T15:12:00Z"
    }
  ],
  "next_page": null
}

Plugin-Marketplaces

Diese API liest Marketplaces und legt die Standard-Installationseinstellung eines Organisations-Marketplace fest; die Marketplaces selbst werden in claude.ai erstellt, mit einem Repository verbunden und gelöscht.

{
  "type": "plugin_marketplace",
  "id": "marketplace_01VbNcMxZaSdFgHjKlQwErTy",
  "name": "engineering-tools",
  "owner": { "type": "organization" },
  "source": "github",
  "sync_status": "success",
  "last_sync_ended_at": "2026-09-10T22:15:03Z",
  "last_sync_read_sha": "9fceb02d0ae598e95dc970b74767f19372d61af8",
  "default_installation_preference": "available",
  "created_at": "2026-06-12T08:45:00Z"
}

Eine marketplace_id ohne das Präfix marketplace_ gibt 400 zurück. Eine, die das Präfix trägt, aber nicht aufgelöst werden kann oder zu einer anderen Organisation gehört, gibt 404 zurück.

Marketplaces auflisten

GET /v1/organizations/plugin_marketplaces listet die Marketplaces deiner Organisation und die persönlichen Marketplaces der Mitglieder auf, absteigend nach created_at sortiert. Verwende diesen Endpunkt, um die ID eines Marketplace zu ermitteln, damit du die Plugin-Liste danach filtern oder in ihn hochladen kannst, noch bevor er ein Plugin enthält. Der Bibliotheks-Marketplace erscheint, sobald darin erstmals etwas erstellt wurde, in claude.ai oder über diese API. Filtere nach owner_type (organization oder user) und source. limit liegt zwischen 1 und 1.000. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

marketplaces = client.beta.organization.plugin_marketplaces.list(
    owner_type="organization"
)

# Ruft bei Bedarf automatisch weitere Seiten ab.
for marketplace in marketplaces:
    print(f"{marketplace.id}: {marketplace.name}")

Marketplace abrufen

GET /v1/organizations/plugin_marketplaces/{marketplace_id} gibt einen Marketplace zurück. Erfordert den Scope read:plugins.

client = anthropic.Anthropic()

marketplace = client.beta.organization.plugin_marketplaces.retrieve(
    "marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r"
)

print(f"id: {marketplace.id}")
print(f"name: {marketplace.name}")

Standard-Installationseinstellung eines Marketplace festlegen

POST /v1/organizations/plugin_marketplaces/{marketplace_id} legt die Standard-Installationseinstellung eines organisationseigenen Marketplace fest. Jedes Plugin im Marketplace ohne eigene organisationsweite Einstellung meldet diesen Standard als seine organization_installation_preference, einschließlich später hinzugefügter Plugins. Dies funktioniert für manual- und synchronisierte Marketplaces; der persönliche Marketplace eines Mitglieds gibt 403 zurück. Das einzige aktualisierbare Feld ist default_installation_preference, und es ist erforderlich. Es kann nicht wieder auf null gesetzt werden: Sobald ein Marketplace einen Standard hat, behält er einen, wie in claude.ai. Eine Änderung wird als ein einzelnes marketplace_updated-Ereignis ohne Ereignisse pro Plugin erfasst und verändert updated_at keines Plugins. Das Setzen des bereits gesetzten Werts ändert nichts, mit einer Ausnahme: Ein Marketplace, dessen Standard nie gesetzt wurde, meldet not_available, hat aber keine Einstellung, sodass sein erster Schreibvorgang (selbst not_available) als Änderung zählt. Gibt den Marketplace zurück. Erfordert den Scope write:plugins.

client = anthropic.Anthropic()

marketplace = client.beta.organization.plugin_marketplaces.update(
    "marketplace_01Lp8uM5qS1yG6tV3aW4kQ7r",
    default_installation_preference="available",
)

print(f"id: {marketplace.id}")
print(f"default_installation_preference: {marketplace.default_installation_preference}")

Marketplace-Inhalte validieren

Zwei Endpunkte melden, was eine Synchronisierung der angegebenen Marketplace-Inhalte bewirken würde, ohne etwas zu verbinden oder zu speichern: POST /v1/organizations/plugin_marketplaces/validate_repository liest ein öffentliches GitHub-Repository, und POST /v1/organizations/plugin_marketplaces/validate_archive liest eine von dir hochgeladene .zip-Datei des Marketplace-Verzeichnisses. Beide geben denselben Bericht zurück: ob marketplace.json wohlgeformt ist, welche Plugins übersprungen würden und warum, und welche Plugins synchronisiert würden, wobei einige Inhalte ausgelassen würden. Die Prüfungen sind dieselben, die eine echte Synchronisierung durchführt. Probleme mit den Inhalten werden im Bericht zurückgegeben, nicht als HTTP-Fehler: Die Anfrage ist mit valid: false erfolgreich, selbst wenn das Repository oder Archiv überhaupt nicht gelesen werden kann. Eine Validierung zählt als Lesezugriff, und die beiden Endpunkte sind zusammen zusätzlich auf 10 Validierungen pro Minute pro Organisation begrenzt (siehe Ratenlimits); sie erzeugen keine Einträge im Activity Feed. Eine Validierung kann bis zu 120 Sekunden dauern, bevor sie zurückkehrt, setze das Timeout deines Clients also höher. Beide Endpunkte erfordern den Scope read:plugins oder write:plugins (read:org_audit und read:compliance_org_data gewähren diese nicht).

Das Repository und alle Plugin-Quellen außerhalb davon auf GitHub werden anonym gelesen, sodass ein privates Repository oder eine private Plugin-Quelle als nicht gefunden gemeldet wird. Plugin-Quellen auf anderen Hosts als GitHub werden nicht abgerufen; ein solches Plugin erhält normalerweise eine Warnung marketplace_validate_source_not_checked und wird geprüft, wenn der Marketplace tatsächlich synchronisiert wird. Ist das Repository ein Marketplace, den Anthropic in jede Organisation synchronisiert, oder benennt das Archiv einen solchen, gelten strengere Regeln: Jede Plugin-Quelle außerhalb des Marketplace muss auf einen vollständigen Commit-SHA fixiert sein, nicht fixierte Quellen oder Quellen auf nicht unterstützten Hosts werden als Plugin-Fehler gemeldet, und der gelesene Branch ist standardmäßig derjenige, aus dem dieser Marketplace synchronisiert wird.

validate_repository nimmt einen JSON-Body mit zwei Feldern entgegen: repository_url, die https://-URL eines öffentlichen Repositorys auf github.com (erforderlich), und ref, ein Branch-Name oder ein vollständiger 40-stelliger Commit-SHA (optional; wenn weggelassen oder null, der Branch, den eine Synchronisierung lesen würde, in der Regel der Standard-Branch des Repositorys). validate_archive nimmt multipart/form-data mit genau einem Teil entgegen, archive, gesendet als Datei-Teil mit einem Dateinamen: eine .zip-Datei des Marketplace-Verzeichnisses, höchstens 32 MB groß, mit ihrem Inhalt im Stammverzeichnis oder in einem einzelnen Ordner verpackt (wie es der Download eines Git-Hosts erzeugt), nur mit DEFLATE- oder STORE-Komprimierung. Kein anderes Formularfeld wird akzeptiert.

Ein öffentliches Repository auf einem Branch validieren:

client = anthropic.Anthropic()

report = client.beta.organization.plugin_marketplaces.validate_repository(
    repository_url="https://github.com/example-org/claude-plugins",
    ref="release-candidate",
)

print(f"valid: {str(report.valid).lower()}")
print(f"total_plugin_count: {report.total_plugin_count}")

{
  "type": "plugin_marketplace_validation_report",
  "valid": false,
  "ref": "release-candidate",
  "commit_sha": "9fceb02d0ae598e95dc970b74767f19372d61af8",
  "total_plugin_count": 3,
  "manifest_error": null,
  "manifest_error_code": null,
  "plugin_errors": [
    {
      "name": "deploy-helper",
      "error": "The plugin has a top-level bin/ directory.",
      "error_code": "marketplace_sync_bin_directory_not_allowed"
    }
  ],
  "plugin_warnings": [
    {
      "name": "release-notes",
      "warnings": [
        {
          "message": "plugin.json has unrecognized top-level keys: owners",
          "error_code": "marketplace_sync_plugin_unrecognized_keys"
        }
      ]
    }
  ]
}

Validiere stattdessen eine lokale Kopie des Marketplace-Verzeichnisses als .zip; die Antwort ist derselbe Bericht:

client = anthropic.Anthropic()

with open("marketplace.zip", "rb") as archive:
    report = client.beta.organization.plugin_marketplaces.validate_archive(
        archive=archive
    )

print(f"valid: {str(report.valid).lower()}")
print(f"total_plugin_count: {report.total_plugin_count}")

Probleme mit den Inhalten lassen die Anfrage nie fehlschlagen. Abgesehen von den Antworten, die alle Endpunkte gemeinsam haben (ein 403 für einen Key, der nur read:org_audit oder read:compliance_org_data hat; siehe Fehlerantworten und Ratenlimits), kann die Anfrage selbst fehlschlagen mit:

Berichtscodes

Jeder Befund in einem Bericht hat einen stabilen Code: manifest_error_code, wenn nichts validiert werden konnte, error_code bei jedem Eintrag in plugin_errors und error_code bei jeder Warnung. Hat ein Plugin mehrere Probleme, ist error_code der Code des ersten, und error fasst ihre Meldungen zusammen. Neue Codes können hinzukommen; ein unbekannter manifest_error_code bedeutet trotzdem, dass die Inhalte nicht validiert werden konnten, ein unbekannter Code bei einem plugin_errors-Eintrag bedeutet trotzdem, dass das Plugin übersprungen würde, und ein unbekannter Code bei einer Warnung bedeutet trotzdem, dass das Plugin synchronisiert würde. Diese Codes weisen auf vorübergehende Zustände hin, sodass dieselbe Anfrage später erfolgreich sein kann: marketplace_host_rate_limited, marketplace_host_server_error, marketplace_host_timeout, marketplace_host_unreachable, marketplace_repo_access_denied, marketplace_sync_transient_fetch_budget_exhausted, marketplace_validate_network_error und in der Regel marketplace_validate_deadline_exceeded.

Unbekannte Werte

Jeder String-Wert auf dieser Seite (Komponententypen, reach, Scan-Felder, Marketplace-source, Fehlercodes) kann jederzeit neue Werte erhalten. Behandle einen Wert, den du nicht kennst, wie jeden anderen unbekannten String, statt einen Fehler auszulösen.

Ratenlimits

Leseanfragen (jeder GET-Endpunkt auf dieser Seite) teilen sich ein Limit von 300 Anfragen pro Minute pro Organisation, und Schreibanfragen (Erstellen eines Plugins oder einer Version, Ändern der ausgelieferten Version, Löschen, Festlegen oder Entfernen einer Installationseinstellung und Aktualisieren eines Marketplace) teilen sich ein Limit von 60 Anfragen pro Minute pro Organisation. Eine Marketplace-Validierung (über einen der beiden Endpunkte) zählt als Lesezugriff, und Validierungen sind zusätzlich auf 10 pro Minute pro Organisation über beide Endpunkte hinweg begrenzt; beide Limits werden geprüft, bevor der Request-Body gelesen wird. Diese Limits werden über alle Keys deiner Organisation hinweg gezählt und sind von den übrigen Admin-API-Limits deiner Organisation getrennt. Anfragen über einem Limit geben 429 Too Many Requests mit einem retry-after-Header zurück. Antworten enthalten anthropic-ratelimit-requests-*-Header für das jeweils geltende Limit (bei der Marketplace-Validierung deren Limit von 10 pro Minute; bei einem 429 das Limit, das die Anfrage abgelehnt hat).

Ein Upload, eine Änderung der ausgelieferten Version oder eine Validierung kann außerdem 429 mit retry-after zurückgeben, wenn der Dienst kurzzeitig keine Kapazität für einen weiteren Vorgang hat, und ein Upload gibt 429 zurück, wenn deine Organisation ihre Rate für die Inhaltsprüfung überschritten hat. Behandle all diese Fälle gleich: Warte die in retry-after angegebene Zeit ab und versuche es dann erneut. Unabhängig von diesen Limits solltest du Schreibvorgänge für Installationseinstellungen desselben Plugins einzeln nacheinander senden: Treffen mehrere gleichzeitig ein, können einige mit 503 und x-should-retry: true beantwortet werden, und diese können nach ein bis zwei Sekunden gefahrlos erneut gesendet werden (siehe Installationseinstellung festlegen).

Paginierung

Listen-Endpunkte verwenden einen opaken Cursor. Die erste Anfrage gibt bis zu limit Zeilen sowie einen next_page-Cursor zurück; übergib den Cursor unverändert als Parameter page bei der nächsten Anfrage und wiederhole dies, bis next_page null ist. Behandle den Cursor-String als opak: Parse, verändere oder konstruiere ihn nicht selbst. Plugins auflisten kann eine Seite mit weniger als limit Plugins oder ganz ohne Plugins zurückgeben, während next_page noch gesetzt ist; fordere also weiter Seiten an, bis next_page null ist. Die Listen-Iteratoren der SDKs rufen beim Iterieren weitere Seiten ab, halten aber bei der ersten leeren Seite an, sodass sie bei der Plugin-Liste vorzeitig enden können; wenn du jedes Plugin benötigst, wie im Workflow für das Sicherheitsinventar, fordere jede Seite selbst an und übergib ihr next_page als page.

limit ist standardmäßig 20 und hat ein Minimum von 1. Das Maximum beträgt 100 für Plugins, Installationseinstellungen und Freigaben sowie 1.000 für Versionen und Marketplaces. Jede Liste ist mit den neuesten Einträgen zuerst sortiert.

Fehlerantworten

Fehlerantworten folgen der Standardstruktur, die unter Fehler dokumentiert ist. Gib die request_id aus dem Antworttext an, wenn du dich an den Support wendest.

Wenn ein Status mehrere Ursachen hat, die du unterschiedlich behandeln würdest, enthält der Fehler zusätzlich error.details.error_code sowie error.details.plugin_id oder error.details.plugin_version_id, wenn die Ursache eines davon betrifft:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "...",
    "details": {
      "error_code": "plugin_name_taken",
      "plugin_id": "plugin_01Hq3vX8kZcN2mB7pR4tY9wL"
    }
  },
  "request_id": "req_018EeWyXxfu5pfWkrYcMdjWG"
}

Es können neue Codes hinzukommen. Behandle einen Code, den du nicht kennst, so wie seinen Status.

Uploads wiederholen

Kein Endpunkt akzeptiert einen Idempotency-Key. Das Ändern der bereitgestellten Version, das Festlegen einer Installationseinstellung und das Festlegen eines Marketplace-Standards können gefahrlos wiederholt werden. Ein wiederholtes Löschen oder ein wiederholtes Entfernen der Installationseinstellung einer Gruppe gibt 404 zurück.

Ein Upload, der einen Fehler zurückgibt, hat nichts gespeichert, mit einer Ausnahme: 503 mit error_code: "registration_pending". Nach dem Speichern der Dateien eines Uploads registriert der Server die Skills der neuen Version bei claude.ai, wodurch sie für Mitglieder nutzbar werden; registration_pending bedeutet, dass die Dateien gespeichert wurden, dieser letzte Schritt aber nicht abgeschlossen wurde. Ein erneuter Upload derselben Dateien schließt ihn ab (und speichert eine weitere, identische Version):

• Bei POST /v1/organizations/plugins wurde das Plugin erstellt, und die Antwort enthält x-should-retry: false: Sende die Erstellung nicht erneut (ein erneutes Senden gibt 409 plugin_name_taken zurück); lade stattdessen dieselben Dateien als Version von details.plugin_id hoch.
• Bei POST /v1/organizations/plugins/{plugin_id}/versions wurde die Version gespeichert (details.plugin_version_id); sende dieselbe Anfrage erneut, wenn die Antwort x-should-retry: true enthält, und nicht, wenn sie false enthält.

Wenn die Antwort einer Erstellung verloren geht, wiederhole sie: Die Wiederholung gibt 409 plugin_name_taken mit der ID des Plugins in details.plugin_id zurück, und du fährst mit diesem Plugin fort. Das Wiederholen einer Versionserstellung, deren Antwort verloren gegangen ist, speichert eine zweite, identische Version. Um das zu vermeiden, notiere vor jedem Upload die latest_version_id des Plugins; wenn eine Antwort verloren geht, lies das Plugin aus und wiederhole die Anfrage nur, wenn latest_version_id unverändert ist.

Activity Feed-Ereignisse

Jeder Schreibvorgang über diese API wird im Compliance API Activity Feed deiner Organisation erfasst und dem API-Key als api_actor mit dessen apikey_-ID zugeordnet. Derselbe Akteur erscheint in created_by bei den Plugins und Versionen, die der Key erstellt.

Die Plugin-, Versions- und Marketplace-IDs in diesen Ereignissen sind dieselben IDs, die diese API zurückgibt. plugin_installation_preference_updated identifiziert das Plugin anhand seines name und seiner marketplace_id statt anhand seiner id.

Das Ändern des Standards eines Marketplace erfasst ein einzelnes marketplace_updated-Ereignis und keine Ereignisse pro Plugin, obwohl es den Wert jedes Plugins ändert, das den Standard erbt. Lesevorgänge werden nicht erfasst, mit Ausnahme von Downloads des Archivs eines Plugins, das einem Mitglied gehört. Ein Schreibvorgang, der nichts ändert, erfasst nichts.

In claude.ai erteilte oder entzogene Freigaben erscheinen im Feed als role_assignment_granted- und role_assignment_revoked-Ereignisse. Diese API meldet keine Löschungen: Ein gelöschtes Plugin fehlt einfach in der nächsten Liste. Ein Plugin, das durch eine Git-Synchronisierung, durch das Löschen seines Marketplace (ein einzelnes marketplace_deleted-Ereignis) oder durch das Löschen des Kontos eines Mitglieds oder der Organisation entfernt wird, löst kein Ereignis pro Plugin aus. Rufe daher regelmäßig den vollständigen Bestand erneut ab, um Entfernungen zu erkennen.

Kundenverwaltete Verschlüsselungsschlüssel

Wenn deine Organisation einen „customer-managed encryption key" (kundenverwalteten Verschlüsselungsschlüssel) verwendet, werden description, release_notes, components und die Dateien einer Version damit verschlüsselt. Solange der Schlüssel nicht verfügbar ist:

• Lese- und Listenvorgänge sind weiterhin erfolgreich, wobei description, release_notes und components als null zurückgegeben werden.
• Archiv-Downloads, Erstellungen, Versionserstellungen und Änderungen der bereitgestellten Version geben 400 mit cmek_key_disabled oder cmek_key_network_blocked zurück.
• Das Löschen eines Plugins im Bibliotheks-Marketplace gibt 400 cmek_key_disabled zurück und löscht nichts, da seine Skills zuerst aus claude.ai zurückgezogen werden müssen und dafür der Schlüssel benötigt wird. Andere Löschvorgänge, Installationseinstellungen und Marketplace-Standards funktionieren normal.

Die Wiederherstellung des Schlüssels hebt all diese Einschränkungen auf.

Siehe auch