Integrations
TWL Tool integrations let an installed app connect to external services without storing provider credentials in its manifest. A connection belongs to the account that authorized it; workflows refer to catalog nodes and connection inputs at run time.
What the platform handles
| Capability | What it provides |
|---|---|
| Authorization | OAuth 1, OAuth 2, API keys, bearer tokens, basic auth, and provider-specific connection flows |
| Credential lifecycle | Encrypted storage, token refresh, reconnect flows, and connection status |
| Authenticated requests | Credential injection, provider base URLs, request forwarding, retries, and rate-limit handling |
| Actions | Typed, on-demand reads and writes that appear in the workflow node catalog |
| Data movement | Scheduled or incremental sync functions when enabled for an integration |
| Events | Signed incoming webhooks and provider events routed into workflow triggers |
| App DSL | Integration actions can be composed with any workflow node; durable triggers can be shipped as app resources |
Catalog versus account availability
The integration catalog lists every connector type the platform can support. A connector becomes usable in an account only after an administrator configures and enables it and a user authorizes a connection. The actions, inputs, and provider events available on a particular server are returned by that server's live catalogs.
This distinction keeps manifests portable. Do not hard-code a connection ID or assume that every account has enabled the same actions.
Typical flow
- Choose a connector from the catalog.
- Authorize an account from TWL Tool's connection UI.
- Query the target server's platform schema and action catalog.
- Add the selected catalog node to a workflow with
nodes.call(). - Add a native or provider-event trigger when the workflow should start automatically.
- Validate, plan, and deploy the app with the CLI.
Continue with Configuration and DSL for authoring examples or Triggers for the complete trigger model.