Choose an integration surface
Use the API for application logic, webhooks for events, and MCP for assistants.
Three interfaces, one operating model
| Interface | Use it for | Design around |
|---|---|---|
| API | Reading records and invoking supported operations from your software. | Identity, authorization, revisions, and explicit results. |
| Webhooks | Notifying another system when a relevant event occurs. | Authenticity, duplicates, ordering, and recovery. |
| MCP | Giving compatible AI clients access to context and permitted tools. | Client identity, task scope, disclosure, and action authority. |
Start with the operational contract
Name the system that owns each record and decision. Define how identities map, which revisions apply, and what evidence must exist before a consequential action can proceed. An integration should not depend on copying a display label or directly editing a lifecycle status.
- Separate sandbox and production identities, credentials, and event destinations.
- Keep source identifiers alongside Helix record identities.
- Define responsibility for retries, reconciliation, and exceptions.
- Test denied and uncertain outcomes alongside successful operations.
Use the contract for your workspace
These guides explain the Helix integration model and recommended implementation patterns. Obtain your workspace’s supported endpoints, authentication configuration, MCP capabilities, event catalog, and limits before implementation.
The examples here are conceptual. They do not establish an endpoint, SDK method, event name, or production service-level commitment. Integration access and supported operations should be verified against your deployment.