Custom Integrations

When to use this

The built-in catalog covers 88 services (see Integrations Guide). For anything else, an internal API, a niche vendor, a provider nobody's built yet, define a custom integration instead of waiting for one to ship. Turn the feature on for your organization from Settings → Custom Integrations; it's off by default.

Importing from a curl command

The fastest path: paste a working curl command straight from the provider's own documentation. The wizard detects the auth shape, headers, and base URL for you, so you review it rather than retype it.

Building it by hand

• Basics: an ID, display name, category, description, and the capabilities it declares, so an agent can reason about when to reach for it.
• Authentication: an API key (as a Bearer token, a custom header, a query parameter, or HTTP Basic) or OAuth 2.0, including PKCE for providers that require it (Twitter/X-style) and extra authorize parameters for providers that gate refresh tokens behind them (Google's access_type=offline).
• Fields: the credentials the connecting member provides. Each field is encrypted at rest by default; marking one as non-secret (a plaintext account ID or region, say) is only allowed for fields that clearly aren't a credential. A field named anything like token, secret, key, password, or credential is blocked from that classification unless explicitly overridden.
• API hosts: the hostnames this integration is allowed to reach, wildcards supported, the same egress model as every built-in integration.
• Verification: an endpoint hit at connect time, to confirm a member's credentials actually work before the integration is considered connected.

Drafts and publishing

A new integration saves as a draft, invisible to every agent, until you publish it. Publishing is what makes it appear under Settings → Integrations for members to connect their own credentials, and what gives bound agents access. Unpublishing hides it again without deleting anything: encrypted credentials already connected are preserved, so republishing restores access rather than starting over.

The same security guarantees

A custom integration inherits everything a built-in one gets: per-row encrypted credentials, the credential broker, egress allow-listing, per-agent binding, and the same audit trail. Defining your own integration doesn't mean stepping outside the platform's security model, it means extending it to one more service.

Related

• Integrations Guide: the 88 built-in integrations this extends
• Security: the boundaries every integration, built-in or custom, operates inside