Integrations

Integrations is the installer. It's separate from Actions on purpose: Actions is the runtime surface (what operators can do right now), Integrations is the setup surface (how new actions get there).

The catalog lives at /integrations. Pick a provider, click Install, do the OAuth dance or paste an API key, and you're done — the integration's actions register into the flat Actions list automatically.

Three flavours

1. HTTP integrations (first-party / curated)

REST APIs Guilde has wrapped: HubSpot, Stripe, Linear, GitHub (the HTTP variant), Brevo, Mercury, etc. Most use OAuth, a few use API keys.

2. MCP integrations

MCP servers — remote tool catalogs over the open Model Context Protocol. Install one MCP server and you get dozens or hundreds of actions at once (the GitHub MCP server adds 90+).

3. Built-in

Browser, Canvas, Knowledge, Work Items, Vault — first-party providers that don't need installation; they're always on. They show up in the Actions list under the Built-in filter.

Installing an integration

Common path:

1. Find it — search the catalog, or pick from a category (CRM, Payments, Code, Comms, Drive, Calendar, Analytics, Ads, Cloud, Database).
2. Install — most integrations are one OAuth click. A few paste an API key or service-account JSON.
3. Scope — pick which actions are enabled (you don't have to enable everything; the OAuth scope and the action allowlist are independent).
4. Wire to operators — by default no operator has access; grant per-operator or per-role from the Actions page.

User vs guild ownership

An integration belongs to you (the user who installed it). To use it in a guild, attach it from the guild's integrations page. This separation matters because the OAuth grant lives at the user level; the guild attachment is the policy layer.

For org-level shared integrations (where multiple guilds in an org should all use the same provider credentials), use the org settings → Connectors tab. Org-level integrations are inherited by every guild in the org.

OAuth vs API key vs service account

Most modern providers use OAuth — the scoped, revocable, modern path.

A few legacy services (SMTP, custom internal APIs) need a manual API key. Paste it in the install dialog; it's stored encrypted at rest.

A handful (Google Cloud, AWS) support service-account JSON when OAuth isn't a fit. Same encrypted storage.

The integration page tells you which method it needs.

Refreshing & revoking

OAuth tokens auto-refresh while they're valid. If a refresh fails (you revoked from the SaaS side, scope change, etc.) the integration's status flips to expired and operators using its actions surface an error in the conversation. Re-authenticate from the integration row's Reconnect.

To revoke entirely: integration row → Revoke. Guilde deletes its tokens. The third-party still remembers the grant — revoke from their side too if you're being thorough.

What's next

• Actions — where installed actions appear
• MCP servers — the long-tail flavour of integrations
• Skills — named recipes on top of actions
• Connect a CRM tutorial — hands-on walk-through