---
title: Custom Integrations
summary: Define your own integration for an internal API or any provider that isn't in the built-in catalog, with the same security guarantees as the 88 that ship by default.
date: 2026-09-17
---

# Custom Integrations

Define your own integration for an internal API or any provider that isn't in the built-in catalog, with the same security guarantees as the 88 that ship by default.

## When to use this

The built-in catalog covers 88 services (see [Integrations Guide](/en/docs/guides/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](/en/docs/guides/integrations-guide): the 88 built-in integrations this extends
- [Security](/en/docs/guides/security): the boundaries every integration, built-in or custom, operates inside