Writing integration code repeatedly means reading API docs, handling auth, defining types, managing rate limits, and updating when APIs change. Capabilities treat external systems as reusable building blocks.
Benefits
- Standardization: A "Send Email" action feels consistent across providers.
- Less boilerplate: Auth headers, retries, and error parsing are handled by the capability.
- Type safety: Built-in schemas give the workflow builder required inputs, optional fields, and expected outputs.
Capability Catalog vs Shared Capabilities
1. Capability Catalog
The Capability Catalog is the public catalog of capability definitions.
- Purpose: Discovery and installation.
- Action: Search for "Salesforce", install it, then provide API credentials.
- Analogy: Installing a package from a registry.
2. Shared Capabilities
Shared Capabilities let teams share configured, authenticated capability without exposing secrets.
- The problem: Central IT owns database credentials; a contractor needs to build a workflow using that database without receiving the password.
- The solution:
- IT Admin installs the "Postgres" capability and configures the connection string securely.
- IT Admin publishes this configured installation to Shared Capabilities.
- Contractor browses Shared Capabilities, sees "IT's Production DB", and requests access.
- Once approved, the contractor can use that capability in workflows.
- Security: The contractor can execute allowed actions but never sees credentials.
- Browse and share: Cross-team or cross-organization collaboration without credential sprawl.
Configuration scope
Capabilities are configured at the Project Level.
- Global config: Set credentials once (e.g., "My Production Database").
- Reuse: Use that connection across many workflows in the same project.
- Overrides: Advanced users can override configuration per step when needed.
Integration into any system
- Known SaaS: Slack, Salesforce, HubSpot, Airtable—install from the Catalog, add credentials, use in workflows.
- Payment providers: Stripe, Flutterwave, Razorpay—capability or Call API for custom endpoints.
- Legacy systems: Old ERP, on-prem database—SQL capability or Call API with basic auth or custom headers.
- Internal tools: Your own backend and microservices—HTTP trigger receives; Call API sends out.
- Unknown third-party: Vendor or partner APIs—Call API with method, URL, headers, body.
- Webhooks from anywhere: Form submissions, IoT devices—HTTP trigger accepts POST/GET; validate and route.
- Proprietary APIs: Industry-specific platforms—Call API with env vars for base URL and secrets.
No capability for a system? Use Call API. Cliodot does not require a pre-built capability for every integration.
Common use cases
- Secure third-party development: Allow an agency to build on your internal API without issuing them a raw API key.
- Legacy modernization: SQL capability to an older database plus an AI capability to summarize data.
- Vendor swapping: Swap a capability node when providers change; keep the workflow structure.
- Rapid prototyping: Start with Google Sheets, then move to Postgres for production.