No-Code SaaS Automation Platform  ·  View 08 of 21  ·  Structure

Interface Catalogue

Everything coming in, everything going out — and the outbound side grouped by whether a retry is safe.

Editable source SVG draw.io All views
Trigger sources Provider change push 20%, poll 80% Schedule Catch-hook and mail public endpoint Platform Connector runtime and quota governor 40,000 actions Effects out, by replay safety Idempotent actions provider honours key Checkable actions read-back possible Unsafe actions no key, no read-back ingested clock anything effect key verify first author decides Interface Catalogue — Triggers In, Effects Out External / third party Security / platform Interface / broker Application we own synchronous failure / alternate Cataloguing by replay safety rather than by vendor is the choice that makes Section 5 enforceable. v 1.0 · owner Integration Platform Architecture · date 2026-10

Decisions

  • The catalogue is organised by replay safety rather than by vendor. A vendor list is an inventory; this grouping is the thing every execution guarantee downstream is derived from.
  • An action cannot be published without its class (view 16 makes that a release gate), so the third column can never be silently empty.
  • Catch-hooks and platform-hosted mail addresses are first-class inbound interfaces, which means they are public endpoints with per-connection secrets and their own rate limits.

Assumptions

  • 40,000 published actions and triggers across 8,000 connectors.
  • The unsafe class is a material fraction, not an edge case — 'post this message' and 'send this email' are among the most-used actions in the product.

Open

  • Core Architecture Question 3: whether the unsafe-class behaviour is one platform-wide policy or an authored per-action product decision. This view assumes the latter, which is why the class is a manifest field.