Pieces

A piece packages an integration or capability: its actions (things a step can do), its triggers (things that can start a flow), the input schema of each, and how it authenticates.

What ships

• 51 internal pieces, always compiled in: HTTP, Code (sandboxed JavaScript), Branch, Loop, Switch, Filter, Delay/Wait, Approval, Email (SMTP + IMAP trigger), Webhook, Schedule, Form (hosted input page), PostgreSQL / MySQL / MongoDB, Redis, Storage (KV) and Queue, JSON / Text / Math / Date / Crypto helpers, CSV / XML / Spreadsheet / PDF / Image / QR / Compression, GraphQL, RSS, JWT, TOTP, Execute Workflow (run another flow as a step), Error & Run-Finished triggers, and more.
• 582 vendor connectors (Slack, Google Sheets, GitHub, Stripe, …) — 633 pieces total.

Actions declare their blast radius

Every action carries a sideEffects tag — pure, reads_external or writes_external. The editor's test machinery and Keel both honor it: a pure step can be auto-tested silently, but nothing ever "tests" a step that would send a real email or write to a real database without explicit consent. Untagged resolves to writes_external — fail safe.

Versioning

A step records the piece version it was built with, and the executor runs that version — a breaking change to a piece can never silently alter a flow already in production. Pins the current build cannot serve are refused, never substituted; during a rollout the job is handed back to the queue for a worker that can serve it.

Discovering pieces programmatically

The catalog is designed to be read by machines as well as the editor:

• GET /api/pieces?view=index — a compact index (~2.8k tokens for the internal set) with ?q= search and ?category= filtering.
• GET /api/pieces/{id}?view=summary — one piece, summarized.
• GET /api/pieces/{id}/actions/{actionId} — one action's schema, and any field=value pair narrows conditional fields (?auth_type=BASIC shows exactly the fields that apply).

See the Pieces API reference for the full surface.