Integrations

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 Slack so the care team gets notified in #intake.”

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 ships these first-class integration types: For anything not on this list — a billing provider, an EHR, an SMS gateway — use custom_http: provide the base URL, auth scheme, and endpoint schema, and the system wraps it as a standard integration adapter with the same policy, audit, and sandbox behavior as a first-class type. Credentials and bindings for custom_http integrations can also be managed programmatically via the integrations API.

​

Using integrations in workflows

Reference an integration by name in chat:

“When the intake form is submitted, use the email integration to send a confirmation to the patient.”

The system compiles a workflow step with:

• The integration adapter bound to this project’s email 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.

​

Data-change events from integrations

Some integrations expose inbound data-change events — for example, a HubSpot contact updated or a file added to a Drive folder. 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.