Build on the sales operating system
HELM sits above your customers' entire stack. Connect any system today with self-serve tools, or follow the architecture to build a certified connector.
Connect anything, self-serve
Every one of these ships in the product now. Bring your own system and HELM makes it part of the operating system.
- Custom REST APILive
Point HELM at any REST endpoint. Base URL, auth, and the actions you want. HELM classifies each and gates the writes.
- OpenAPI / SwaggerLive
Paste a spec URL or the JSON/YAML. HELM imports the operations and maps them to capabilities.
- Postman collectionLive
Import a collection export. Credentials are stripped server-side and never imported.
- GraphQLLive
HELM introspects the schema. Queries read; mutations always ask first.
- Outbound webhooksLive
Send data from HELM to any system. Always requires approval.
- MCP serversLive
Any Model Context Protocol server becomes a connector. Streamable HTTP and legacy SSE supported.
A few lines to connect
Illustrative developer examples of the self-serve connect flows. Auth is held server-side and every write is approval-gated.
POST /connect/custom
{
"name": "Acme Orders",
"base_url": "https://api.acme.com/v1",
"auth": { "type": "api_key", "header": "X-Api-Key" },
"actions": [
{ "name": "list_orders", "method": "GET", "path": "/orders", "risk": "read" },
{ "name": "create_order", "method": "POST", "path": "/orders", "risk": "write" }
]
}
# writes are approval-gated automaticallyOAuth and secrets
- OAuth 2.0 with PKCE is the standard for hosted connectors. One guided sign-in, revocable any time.
- Tokens and secrets are held server-side and never reach the browser.
- Connections are workspace-scoped and isolated by database row-level security.
- Disconnecting revokes access immediately.
Sandbox and approval
- Actions are classified by risk on the server, not the client.
- Every write runs through the approval gate before anything happens.
- Destructive actions are double-gated and never enabled by default.
- Test a connector's health and mapped tools before you approve them.
The Connector Contract
Every connector, first-party or custom, is described by the same contract. Build to it and HELM knows how to use your connector without any change to the user experience.
Identity
Name, category, icon, description.
Auth
OAuth 2.0, API key, or none. Held server-side.
Capabilities
The business capabilities this connector provides.
Permissions
Read only or read and write, per action.
Actions
What HELM can do, each classified by risk.
Triggers
The events HELM can react to.
Health
A reachability and status check.
Sync
Cursor, cadence, and conflict handling.
Rate + retry
Limits, backoff, and safe retries.
Recovery
How a failed run resumes where it stopped.
Memory
Facts a connector contributes, in HELM memory.
Events
Usage recorded for observability.
Relationships
How its records link to your graph.
Agent access
Which tools each agent may call, allowlisted.
A connector never owns storage. Its facts live in HELM memory, its events in observability, its relationships in your graph. One model, one source of truth.
From custom to certified
How a connector moves from your workspace to the marketplace.
Self-serve custom connectors are live today. A public submission and review programme, downloadable SDKs, and OAuth app registration are on the roadmap. Product names belong to their owners; a badge describes HELM's verification, never a vendor's endorsement.