Integrations

The platform integrations catalog covers fourteen providers across productivity, communication, mail and calendar, engineering, and finance. Every integration in the catalog is described with the same four-capability vocabulary and one of three setup patterns.

Audience: IT (the enabler) and builders

How to think about integrations

Capabilities. What an integration does is captured in four canonical words: Read, Write, Triggers, Reply. Every integration shows its lit capabilities the same way in the product and in this documentation. See Capabilities.
Setup patterns. Who can set up an integration depends on the provider. Three patterns cover all of them: self-serve OAuth, admin-enabled OAuth, and admin-only API key. See How connections get set up.
Credentials, bindings, and ownership. A credential is the thing OAuth or an API key produces. A binding is the attachment of a credential to a Project. Builders bind on credentials, even ones they did not create. See Credentials and ownership.

What this section covers

Capabilities. The four canonical capabilities and the visual patterns the product uses.
Catalog. All fourteen providers with their lit capabilities at a glance.
Credentials and ownership. The model in depth.
Sync status and troubleshooting. Operational reference.
Provider setup pages, grouped by setup pattern below.

Providers by setup pattern

The setup pattern determines who does the work. See How connections get set up for the full model.

Self-serve OAuth

No org-level prerequisite. Builders self-serve.

Linear

Admin-enabled OAuth

IT does the one-time foundation. Builders OAuth their own accounts after that.

Admin-only API key

No per-user OAuth. A functional admin (usually Finance) generates a restricted API key.

How connections get set up Capabilities