Skip to main content
An integration is an outbound connection to an external system. Credentials and configuration live at the project level so multiple workflows can share one connection without duplicating credentials or managing per-workflow auth.

​
Adding an integration

Describe what you want to connect:
“Connect to Postmark to send transactional emails.”
or
“I need to call our EHR API when a patient is admitted.”
The system identifies the integration type, prompts for credentials and required configuration (API key, base URL, auth scopes), and creates the integration at the project level. Once created, any workflow in the project can reference it.

​
Available integration types

AI Studio supports connections to:
  • Email — Postmark, SendGrid, Mailgun
  • CRM — HubSpot, Salesforce
  • Billing — Stripe
  • Productivity — Notion, Google Workspace (Docs, Sheets, Calendar), Linear, Slack
  • Communication — Twilio (SMS/voice), Intercom
  • Healthcare — Generic REST EHR adapters (HL7 FHIR, custom endpoint)
  • Custom HTTP — Any REST API with a declared response schema
For integrations not in the list, use Custom HTTP: provide the base URL, auth scheme, and endpoint schema, and the system wraps it as a standard integration adapter.

​
Using integrations in workflows

Reference an integration by name in chat:
“When the intake form is submitted, call the Postmark integration to send a confirmation email to the patient.”
The system compiles a workflow step with:
  • The integration adapter bound to this project’s Postmark credentials
  • Input schema derived from the entity fields you specify
  • Output schema declared by the adapter (for downstream step use)
You never write API call code. The system generates the step contract; the runtime executes it.

​
Sandbox behavior

In sandbox mode, integration calls are edge-sandboxed: the runtime never makes real outbound calls. Instead, each integration adapter declares a response schema; the sandbox produces schema-derived mock responses. Trace view in sandbox shows side-effect markers as “would have sent X” rather than “sent X.” You see the exact payload that would have been sent and a plausible mock response without touching any real external system.
Real provider sandbox credentials (Stripe test keys, HubSpot sandbox accounts, etc.) are a post-V1 capability. The default sandbox behavior is edge-sandboxing for all integrations.

​
Data-change events from integrations

Some integrations expose inbound data-change events — for example, a Notion page updated or a Linear issue moved to a new status. When the integration adapter supports it, these manifest as data-change events on integration-cached entities, and workflows can trigger on them.

​
Credential management

Integration credentials are stored encrypted at the project level. They are:
  • Not exposed to workflow contracts (the contract references the integration by name, not by credential)
  • Accessible only to workflows within the project
  • Audited on every use
To rotate credentials, update the integration configuration in project settings. Existing workflows pick up the new credentials on their next run.

​
Reverse-dependency view

From the integration resource view, you can see which workflows use this connection and which steps make outbound calls. This makes credential rotation and integration changes safe — you know the blast radius before you make a change.