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

​
FHIR (EHR) connector

The fhir integration reads FHIR R4 resources from your own EHR. It is read-only: there is no create or update operation, so nothing built on it writes back to the EHR. Because every EHR response is PHI, reads run only for an organization on a paid plan with an active BAA — workflow steps and agent tools alike; sandbox previews use synthetic resources and are unaffected. Connect it in Settings → Integrations → FHIR (EHR):
  1. Generate a client key (ES384 or RS384) — or upload your own PEM private key. The page shows the key’s public JWK; the private key is write-only and never shown again.
  2. Register the public JWK with your EHR as a SMART Backend Services (system-level, private_key_jwt) client. Your EHR issues a client ID and decides which resources the client may read.
  3. Enter the FHIR base URL and client ID. The token endpoint is discovered from the server’s .well-known/smart-configuration; set it explicitly if your server does not publish one. The default scope is system/*.read.
For a FHIR server that does not support SMART Backend Services, choose Bearer token and paste a static token instead. The connection is health-checked by minting a token and reading the server’s /metadata.
Patient identifiers are sent to your EHR unredacted on this connection. HASP removes PHI from what every other integration sends out. It does not on this one, because a FHIR read finds records by patient identifiers — a name, a birth date, a record number — and the EHR it sends them to is your own system of record, which already holds them. This applies only because the connection:
  • only reads — it has no operation that writes to the EHR;
  • reaches only the server and credentials you register;
  • runs only for an organization on a paid plan with an active BAA, and refuses every request before it is sent otherwise;
  • records every request on the audit chain.
Everything the connection reads is PHI. The settings page states this, and you must confirm it each time you save the connection.
The EHR is your own third-party system, reached with credentials you register: HASP orchestrates, gates, and audits each call, and the EHR vendor’s billing stays between you and them. The access token is only ever sent to the FHIR server’s own origin, and page_url / status_url must point back at it. SMART access tokens are cached for their lifetime, so paging and status polling don’t request a new token every time. Each response is capped at 10 MB, including a single Bulk Data output file. Use _type and _since to keep export files under that size. Every call is an integration call like any other — rate-limited and recorded on the audit chain — except that its request is not PHI-redacted (see above). Agents reach the same connector through the fhir.read and fhir.search tools, which require PHI read access. To start an app from EHR data, use the EHR Records (FHIR) template — FHIR-shaped Patients, Practitioners, Appointments and Coverages, plus an Import from EHR workflow whose fhir.import steps upsert records by FHIR id. A fhir.import search follows the server’s next links up to max_pages (default 20, at most 100); if the cap stops it early, the step output’s next_page_url is set.

​
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. The fhir integration’s mock responses are schema-valid FHIR R4 resources (Patient, Practitioner, Appointment, Coverage, DocumentReference), so a workflow that reads from the EHR previews end to end before any EHR is connected. 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 (a provider’s own test keys or sandbox accounts) are not used. Edge-sandboxing is the sandbox behavior for every integration.

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