> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations

> Integrations are outbound connections to external systems — email, Slack, Microsoft 365, HubSpot, object storage, or any REST API. Credentials live at the project level.

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:

| Type               | Description                                  |
| ------------------ | -------------------------------------------- |
| `email_smtp`       | Outbound email over SMTP                     |
| `slack`            | Slack messaging                              |
| `microsoft_365`    | Microsoft 365 (mail, calendar, files)        |
| `google_workspace` | Google Workspace (Gmail, Calendar, Drive)    |
| `hubspot`          | HubSpot CRM                                  |
| `zapier`           | Zapier automation                            |
| `make`             | Make automation                              |
| `aws_s3`           | S3-compatible object storage                 |
| `generic_oauth`    | Any OAuth 2.0 provider                       |
| `custom_http`      | Any REST API with a declared response schema |

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](/ai-api/quickstart).

## 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.

<Note>
  Real provider sandbox credentials (a provider's own test keys or sandbox accounts) are not used. Edge-sandboxing is the sandbox behavior for every integration.
</Note>

## 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.