> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usecustory.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Integrations

> Connect the tools your team already uses so Custory can stay tied to delivery, communication, knowledge, and AI-assisted operating workflows.

Custory integrations connect the tools that hold customer evidence and the tools where work gets done.

Customer signals come in from analytics, billing, docs, and chat. You review that evidence in the journey, decide what matters, then send updates or follow-up work back out to delivery tools, communication channels, and [AI clients](/mcp-server).

The goal is not to connect everything. Connect the few systems that already shape how your team learns, decides, and ships.

## How the pieces fit

Think about integrations in four plain jobs:

1. evidence sources
2. the journey in Custory
3. delivery tools
4. communication tools and AI clients

That keeps each integration tied to a real task instead of turning the page into a feature list.

```mermaid theme={null}
flowchart LR
    S1["Evidence sources<br/>Analytics, billing, chat, docs"] --> J["Journey in Custory<br/>Where the team decides what matters"]
    S2["Knowledge sources<br/>Notion and research notes"] --> J
    J --> E1["Delivery tools<br/>GitHub, Jira, Linear, Notion"]
    J --> E2["Communication tools<br/>Slack, Discord, notifications"]
    J --> E3["AI clients<br/>MCP and workspace AI"]
    E1 --> R["Shipped changes and new context"]
    E2 --> R
    E3 --> R
    R --> J
```

## What to connect first

For most founder-led and product-led teams, the best order is:

1. One communication tool
2. One delivery tool
3. One knowledge or context source
4. Analytics or revenue signals if they shape roadmap decisions often

That usually means something like:

* Slack or Discord
* GitHub, Jira, or Linear
* Notion
* PostHog or Stripe

## What is available now

Open **Manage Integrations** to see the current integration directory for your workspace.

Some tools can be connected immediately. Others may appear with a **Coming soon** state so your team can see where they fit before they are ready to add.

For a practical first setup, start with tools your workspace can connect and use today:

* **Communication:** Slack or Discord
* **Delivery:** GitHub, Jira, or Linear
* **Knowledge:** Notion
* **Analytics and revenue:** PostHog or Stripe
* **AI clients:** MCP server access

If the tool you need is not available yet, use **Request integration** from **Manage Integrations**, describe the workflow you want, and submit it with **Submit request**.

## Signal sources

Signal-source integrations bring raw customer evidence into the system before your team turns it into [items](/items).

### PostHog and Stripe

Use [PostHog and Stripe](/posthog-and-stripe) when product usage, conversion, billing, churn, or recovery movement should shape how the team interprets the journey.

### Notion and knowledge sources

Use Notion when research notes, docs, or structured background material already hold the best version of the customer story.

Google Drive may appear in the integration directory as **Coming soon**. Treat it as requestable planning context until your workspace can connect it.

### Figma and Miro

Figma and Miro are useful when visual flow context, prototypes, or workshop material should help shape the journey.

If they appear as **Coming soon**, use **Request integration** to tell the team which design or workshop workflow matters most.

### Intercom and customer feedback surfaces

Use feedback sources when recurring customer pain, objections, or questions need to survive beyond the original conversation.

Intercom may appear as **Coming soon**. Until it can be connected in your workspace, capture the pattern manually as an [insight](/items#insights) or [opportunity](/items#opportunities) instead of letting it stay buried in support history.

## Delivery tools

Delivery-tool integrations help your team move from a prioritized opportunity to real delivery work.

### GitHub

Use GitHub when journey context should stay connected to issues, pull requests, and shipping activity.

See [GitHub integration](/github-integration).

### Jira and Linear

Use Jira or Linear when [opportunities](/items#opportunities) and [solutions](/items#solutions) need structured execution follow-up in your team's delivery system.

### Notion as linked work

Notion can also support lighter-weight follow-up where a full engineering issue is not the right artifact.

See [External tasks and issues](/external-tasks).

## Communication channels

Communication integrations keep the journey visible without forcing the team to live in Custory all day.

See [Notifications](/notifications) when you want to control how those updates are delivered.

### Slack

Use Slack to:

* send automation updates to channels
* link personal identities for direct-message [notifications](/notifications)
* work with Custory [AI](/ai-workspace-member) from collaboration threads

### Discord

Use Discord to:

* send updates into channels and threads
* link personal identities for direct-message [notifications](/notifications)
* work with Custory [AI](/ai-workspace-member) in conversation-heavy workflows

See [Slack/Discord threads](/slack-discord-ai-threads).

## AI clients and developer access

AI-related integrations matter because they let outside tools work from the same [journey context](/how-custory-works) instead of from isolated prompts.

### MCP

Use [MCP](/mcp-server) when external AI clients or developer workflows should read from Custory context safely.

That is useful for:

* Reading journey state from Cursor, Claude, or another MCP-compatible client
* Creating or editing journeys from an external AI workflow
* Creating or updating journey items and reusable building blocks
* Pulling Custory context into implementation work without copying notes between tools

For in-app AI workflows, use [AI journey imports](/ai-journey-imports), [AI as a workspace member](/ai-workspace-member), or [automation templates](/automation-templates) instead.

## Integration management

Open **Manage Integrations** in a workspace to:

* Connect tools
* Reconnect expired integrations
* Review connection state
* Add manual credentials where required
* Request unsupported integrations

## Good integration hygiene

### Connect only the tools that remove real friction

More integrations are not automatically better.

### Set journey defaults where relevant

If one journey always routes work to the same repo, team, or project, set that default once instead of relying on memory in [journey settings](/journey-settings).

### Keep delivery links close to item context

The integration is most valuable when it keeps the reason for the work visible, not just the task itself.

## Next step

Read [GitHub integration](/github-integration) if delivery handoff is your next use case. Read [Notifications](/notifications) if you want Slack or Discord delivery set up cleanly. Read [Security and privacy](/security-and-privacy) before granting broad integration or MCP access.