Ein governed Pfad.
Jeder Connector.
Connector-Aufrufe laufen serverseitig über ein governed Invocation-Framework — Idempotency Keys, Retries, SSRF-geschützter Egress und Capability Gates. Slack ist heute der Referenz-Connector; ein breiterer Katalog ist auf demselben Framework geplant.
Connectoren sind governed Calls.
Keine eingefügten API-Keys.
Jede Connector-Invocation läuft über denselben serverseitigen Pfad. Nichts wird aus dem Browser aufgerufen, und kein Credential erreicht jemals User-Code.
Invocations laufen über einen queued Worker mit Idempotency Keys und Retries — doppelte Sendungen sind strukturell ausgeschlossen.
Ausgehende Aufrufe durchlaufen SSRF-geschützte Egress-Validierung. Connectoren erreichen, was sie deklarieren — sonst nichts.
Apps brauchen eine explizite Capability, um einen Connector aufzurufen. Keine Capability, kein Call — erzwungen bei Publish und zur Laufzeit.
Ein kleines governed Set.
Kein Marktplatz.
PostgreSQL und Slack sind heute live. Datenbank-, API- und Custom-Source-Konnektoren sind auf demselben governed Framework geplant — Qualität vor Anzahl.
Dedizierte Datenbank pro Org mit serverseitiger SQL-Ausführung.
Referenz-Connector — governed Nachrichten mit idempotenter Zustellung.
Externer Datenbank-Connector auf dem governed Framework.
Document-Store-Connector auf dem governed Framework.
Generischer HTTP-Connector mit deklarierten Egress-Zielen.
Typisierter API-Connector mit capability-scoped Queries.
Schluss mit eingefügten API-Keys.
Anfangen mit governed Calls.
Connector-Credentials bleiben serverseitig. Invocations sind queued, idempotent und auditiert. Gebaut für Teams, die Drittanbieter-Aufrufe als Produktionsverkehr behandeln.
Offene Beta · Slack-Connector live · Katalog geplant
Serverseitige Ausführung · Secret References · Capability Gates · Auditierte Invocations