> ## Documentation Index > Fetch the complete documentation index at: https://www.courier.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Migrate from Intercom > Move transactional and marketing messages from Intercom (now Fin) to Courier. Concept mapping, event-triggered sends to the send API, and a phased plan. This guide helps you plan a migration from Intercom to Courier. It maps Intercom concepts to their Courier equivalents, covers both transactional and marketing sends, and lays out a phased plan. It says "Intercom" throughout, since that is still what the product surfaces and the API call themselves. Intercom is a support platform, and it is committing harder to that. The company renamed itself Fin in May 2026 after its AI support agent, and Salesforce has signed a definitive agreement to acquire it and fold that agent technology into Agentforce. Outbound messaging sits beside that focus rather than at the center of it, and the API shows where the investment went: sends are modeled as support conversations owned by an agent seat, push and SMS have no send endpoint at all, and campaign definitions can be exported but never created in code. Those are reasonable tradeoffs for a help desk and poor ones for the messages your product sends. A password reset, a receipt, a usage alert, or an onboarding sequence needs a send API, per-channel routing, provider failover, preference enforcement, and delivery logs. Threading a conversation between a customer and an agent needs almost none of that. So here's the split most teams land on. Intercom keeps the help desk: Messenger, the Intercom Inbox, tickets, Help Center, and Fin. Courier takes over what your product sends. The rebuild is also less work than it used to be, because Courier's UI and API are at full parity: every template, journey, audience, and preference topic can be created programmatically, so a coding agent with access to [Courier's MCP server](/docs/tools/mcp) can do most of the mechanical translation. There's a [ready-made prompt](#migrating-with-an-ai-agent) for that below. ## Mapping Intercom Concepts to Courier | Intercom | Courier | | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- | | [Series](https://www.intercom.com/help/en/collections/2091449-outbound) | [Journeys](/docs/platform/journeys/journeys-overview) | | Event-triggered outbound messages | [Send API](/docs/platform/sending/send-message) or [journey triggers](/docs/platform/journeys/invocation) | | [`POST /events`](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/data-events) as a send trigger | Direct [send](/docs/api-reference/send/send-a-message) or [journey invoke](/docs/platform/journeys/invocation) | | [`POST /messages`](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/messages) | [Send API](/docs/platform/sending/send-message) with a template | | One-off email or post to a segment | [Broadcasts](/docs/platform/broadcasts/broadcasts-overview) | | Message composer and content blocks | [Design Studio](/docs/platform/content/design-studio/design-studio-overview) | | Contacts and custom attributes | [User profiles](/docs/platform/users/users-overview) (nested JSON) | | Segments | [Audiences](/docs/platform/users/audiences) | | [Subscription Types](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/subscription-types) | [Preference topics](/docs/platform/preferences/preferences-overview) | | Mobile Push | Push channel through [your providers](/docs/external-integrations/integrations-overview) | | SMS and WhatsApp | SMS and chat channels through [your providers](/docs/external-integrations/integrations-overview) | | Posts, News items | [Courier Inbox](/docs/platform/inbox/inbox-overview) | | Banners | Your own UI over [Courier Inbox](/docs/platform/inbox/inbox-overview) data today, in-app banners on the roadmap | | Message frequency rules | [Send limits](/docs/platform/sending/send-limits) and [throttle nodes](/docs/platform/journeys/nodes/throttle) | | Access tokens | [API keys](/docs/reference/api-overview#authentication) | | Messenger, Intercom Inbox, tickets, Workflows, Help Center, Fin | Stays in Intercom | ### Series and Journeys Intercom [Series](https://www.intercom.com/help/en/collections/2091449-outbound) is the multi-step campaign builder: contacts enter on a rule or an event, then move through waits, splits, and sends. It requires the Proactive Support Plus add-on. Courier [Journeys](/docs/platform/journeys/journeys-overview) fill the same role, with [four trigger types](/docs/platform/journeys/invocation): API invoke, inbound webhook, Segment event, and audience membership. | Series element | Courier equivalent | | ------------------------------------- | -------------------------------------------------------------------------------------------------- | | Message node (email, push, chat, SMS) | [Send node](/docs/platform/journeys/nodes/send) (references a template) | | Wait or delay | [Delay node](/docs/platform/journeys/nodes/delay) | | Rules branch | [Branch node](/docs/platform/journeys/nodes/branch) | | Exit rules | [Cancel node](/docs/platform/journeys/nodes/cancel) + [cancellation API](/docs/platform/journeys/invocation) | | A/B content test | [Experiments](/docs/platform/journeys/experiments) on send nodes | | Tag or attribute update | [Profile updates via API](/docs/api-reference/user-profiles/update-a-profile) | Two capabilities have no Series equivalent: * **[Batch](/docs/platform/journeys/nodes/batch) and [digest](/docs/platform/journeys/nodes/digest) nodes** collapse many events into one message. In Intercom, roll-up messages have to be precomputed in your own backend before you fire the triggering event. * **[Fetch data nodes](/docs/platform/journeys/nodes/fetch-data)** call an external API mid-journey and use the response in later steps. Journeys are also [buildable through the API](/docs/platform/journeys/building-journeys-via-api). Intercom has no Series endpoint, so a Series exists only in the UI. The one [workflow endpoint](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/workflows) is `GET /export/workflows/{id}`, which is read-only, documented as an EU Data Act compliance export, and covers Workflows rather than Series. Either way, campaign definitions can't be versioned as code. ### Event-Triggered Messages and the Send API This is the biggest change in the migration. Plan it first. Intercom's `POST /messages` endpoint accepts `message_type` values of `in_app`, `email`, or `whatsapp`. There is no push or SMS send endpoint, and its `template` field is a message style (`plain` or `personal`), not a reference to content you built in the composer. So the way you send a designed message from your backend is indirect: post an event, and let a message you configured in the UI match on it. ```bash theme={null} # Intercom: fire an event and let a pre-configured rule match it curl -X POST https://api.intercom.io/events \ -H "Authorization: Bearer $INTERCOM_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "event_name": "password_reset_requested", "created_at": 1755500000, "user_id": "user_123", "metadata": { "reset_url": "https://app.example.com/r/abc123" } }' ``` That returns `202 Accepted` with an empty body. Your code learns that the event was accepted, not that a message was created, and Intercom exposes no delivery status endpoint for email, push, or in-app. In Courier, the same send is explicit. You name the template, the recipient, and the data, and the response carries a `requestId`: ```bash theme={null} curl -X POST https://api.courier.com/send \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "message": { "to": { "user_id": "user_123" }, "template": "password-reset", "data": { "reset_url": "https://app.example.com/r/abc123" } } }' ``` For a single-recipient send like this one, that `requestId` is also the message's ID. Use it to [get the message](/docs/api-reference/messages/get-message), [read its delivery history](/docs/api-reference/messages/get-message-history), or [cancel it](/docs/api-reference/messages/cancel-message). Sends to a list or audience derive a separate ID per recipient, which you look up through the [Messages API](/docs/api-reference/messages/list-messages). Several Intercom event constraints disappear with the switch. Check each one against your current setup: * Intercom caps a workspace at **120 active event names**, and each event can drive at most **50 live proactive support messages**. Courier templates are addressed by ID, so there is no shared namespace to run out of. * Intercom events are **flat**; its API docs state that nested JSON structures are not supported. Courier `data` and [user profiles](/docs/platform/users/users-overview) both take arbitrary nested JSON, so an order with line items goes through as-is. * Intercom **de-duplicates** events on workspace, contact, event name, and `created_at` at second granularity, and drops duplicates with a `202`. Two legitimate identical sends in the same second collapse into one. Courier treats every send request as its own message. * New Intercom event metadata can take **up to 24 hours** to become available in the message composer and filters. Courier templates reference variables directly, so a new field is usable on the next send. * An Intercom outbound message can carry **only one event-based rule**, and event-triggered messages are not eligible for re-notification. ### Transactional Sending Intercom supports transactional messaging on email, in-product messages, and push, and transactional email can reach unsubscribed contacts. Two things about it usually drive the migration: **It is an add-on, not a mode.** Transactional and event-triggered messaging require the Proactive Support Plus add-on. In Courier, there is no transactional subsystem to enable. Every send goes through the same pipeline, and you control preference enforcement per topic by marking a [preference topic](/docs/platform/preferences/preferences-overview) as required. **Sending is on shared infrastructure.** Intercom's docs state that [dedicated IP addresses aren't available](https://www.intercom.com/help/en/articles/9744849-connect-your-email-support-channel) and that all email is sent over shared IPs, and there is no option to send through your own email provider. It also documents activity-based sending restrictions that, when triggered, limit email to contacts seen, heard from, or engaged within the last 180 days, and notes that event-driven email is usually delivered in seconds but can be delayed up to 30 minutes under load. Courier sends through [your own provider accounts](/docs/external-integrations/integrations-overview). Your SendGrid, SES, Postmark, Twilio, or FCM credentials, your domains, your reputation, your dedicated IP if you have one. Courier adds the orchestration layer on top: [channel routing](/docs/platform/sending/channel-priority), [provider failover](/docs/platform/sending/failover), and [error handling](/docs/platform/sending/handling-responses-and-errors). If a provider degrades, you swap it in Courier without redeploying. ### Contacts, Custom Attributes, and User Profiles Intercom contacts carry standard fields plus custom attributes defined through [data attributes](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/data-attributes). Courier [user profiles](/docs/platform/users/users-overview) are JSON documents keyed by `user_id`. The translation is direct: the contact's `external_id` becomes the Courier `user_id`, channel addresses (`email`, `phone_number`, push tokens) become profile addresses, and custom attributes become profile attributes. Because profiles accept nested JSON, attribute structures you had to flatten for Intercom can keep their shape. Load contacts with the [bulk API](/docs/api-reference/bulk/create-a-bulk-job), or create them inline: sending to an unknown `user_id` with profile data creates the user. Intercom segments become [audiences](/docs/platform/users/audiences), which recalculate automatically as profile attributes change. Push tokens are the one item to plan around. Intercom collects device tokens through its mobile SDK, so they live inside Intercom rather than in your data. Register tokens with Courier's [device token API](/docs/api-reference/device-tokens/add-multiple-tokens-to-user) from your app and let the two run in parallel until coverage is high enough to cut over. ### Keeping Intercom for Support Nothing about this migration touches the help desk. Messenger, the Intercom Inbox, tickets, [Workflows](https://www.intercom.com/help/en/articles/7836459-workflows-explained), Help Center, and Fin all stay where they are. One sync keeps the two in step: 1. **Your application is the source of truth** for who the user is and what they did. 2. **Into Courier**: upsert [profiles](/docs/api-reference/user-profiles/update-a-profile) with identifiers, channel addresses, and the attributes you segment or personalize on. 3. **Into Intercom**: keep sending the contact updates and events your support team relies on for context in the Intercom Inbox. Events you were firing only to trigger outbound messages can stop. Events your agents read in the contact timeline should keep going. ### Subscription Types and Preferences Intercom [Subscription Types](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/subscription-types) support opt-in and opt-out consent, and their `content_types` field accepts `email` or `sms_message`, so consent is tracked for those two channels. Courier [preference topics](/docs/platform/preferences/preferences-overview) cover every channel, including push and in-app, and Courier enforces them at send time. Each topic can be opt-in or opt-out, required, or channel-specific, so a user can keep receipts on email while turning off push for the same topic. Map each Subscription Type to a preference topic and import the opt-out state before your first send. Note that Intercom's `GET /contacts/{id}/subscriptions` only returns subscriptions the contact explicitly set, so contacts sitting on a default are absent from the response. Decide the default for each topic in Courier deliberately rather than inferring it from the export. You get a [hosted preference page](/docs/platform/preferences/hosted-page) out of the box, or [embeddable components](/docs/platform/preferences/embedding-preferences) to build the preference center into your product. ### Frequency Capping Intercom controls volume per message: you set how often a message can send and cap total occurrences per contact. Courier has two mechanisms that work across messages. [Send limits](/docs/platform/sending/send-limits) cap volume globally, per user, per subscription topic, or per tenant over an hour, day, week, month, or billing period, with a `THROTTLED` status in the logs when a message is blocked. [Throttle nodes](/docs/platform/journeys/nodes/throttle) cap how many times a user or the whole population passes a point in a journey. ### In-Product Messages Intercom's in-product surfaces (Posts, Banners, Carousels, Tooltips, Checklists, News items) are rendered by the Intercom Messenger, and coverage varies by surface. Banners, for example, run on desktop and mobile web but are not supported inside iOS and Android apps. The closest Courier equivalent is [Courier Inbox](/docs/platform/inbox/inbox-overview), a notification feed with read and unread state, [tabs](/docs/platform/inbox/organize-with-tabs), and [toasts](/docs/platform/inbox/notify-with-toasts), available as components for [React](/docs/platform/inbox/web/react-sdk), [JavaScript](/docs/platform/inbox/web/javascript-sdk), and mobile. It is a notification feed rather than a Messenger replacement, so the mapping is not one to one: * **Posts and News items** map cleanly to Courier Inbox messages. * **Banners** are on the Courier roadmap as a first-class in-app surface. Until they ship, either keep banners in Intercom or render one in your own UI over Courier Inbox data. If banners are load-bearing for you, scope them separately from the rest of the migration rather than blocking the cutover on them. * **Tooltips, Checklists, Product Tours, and Carousels** are in-product guidance and onboarding UI. Those stay in Intercom or move to a product-adoption tool. Courier does not replace them. The billing works differently here too. Intercom meters Posts, Mobile Push, Product Tours, Carousels, and Surveys under a single "Messages Sent" metric with an allowance included in the Proactive Support Plus add-on, so in-product messages and push draw down the same pool. ### Personalization and Localization Intercom personalizes with attribute insertion and fallbacks in the composer, and event metadata for event-triggered messages, limited to the first metadata keys on the event. The attribute has to exist on the contact, or the value has to arrive as flat event metadata. Courier templates use [variables](/docs/platform/content/variables/inserting-variables) in single curly brackets, and they resolve from four sources rather than one: | Source | Use it for | | --------- | --------------------------------------------------------------------------------------- | | `data` | Values you pass on the send call, like `{order.total}` | | `profile` | Attributes stored on the user, like `{profile.firstName}` | | `tenant` | Attributes stored on the account or workspace the user belongs to, like `{tenant.name}` | | `brand` | Themed values, like `{brand.colors.primary}` | Anything not prefixed resolves against `data`, so `{orderId}` and `{data.orderId}` are the same. Nested paths work, so `{order.shipping.carrier}` renders without flattening the payload first. The `tenant` source has no Intercom equivalent. If you send on behalf of customer accounts, per-account values like company name, support address, or logo live on the [tenant](/docs/platform/tenants/tenants-overview) instead of being copied onto every user profile or passed on every send. For localization, Intercom's documented pattern is to duplicate a message per language and target it with an audience rule on the contact's language. Courier keeps locales on a single template: set `locale` on the profile or the send request, and Courier renders the matching version. Translations are managed through [Design Studio](/docs/platform/content/design-studio/ai-translations) or the [translations API](/docs/api-reference/translations/update-translations-by-locale). ### Authentication Intercom authenticates with a workspace access token, rate limited to 10,000 API calls per minute per app and 25,000 per workspace, enforced in ten-second buckets. Courier uses [API key authentication](/docs/reference/api-overview#authentication): a bearer token per workspace, with separate keys for test and production. Client-side surfaces like Courier Inbox use short-lived [JWTs](/docs/tutorials/inbox/how-to-send-jwt) scoped to a single user. ## Migration Plan Do transactional first. Those sends are already API-driven, they carry the most risk if they break, and they are the ones Intercom's shared sending and 30-minute delay ceiling serve least well. Marketing sends are less urgent and take longer to rebuild. ### Phase 1: Inventory 1. **List every live outbound message and Series.** Note the trigger, channels, and audience for each. No endpoint returns Series definitions, so take these from the Outbound list filtered to live messages. For per-message volume, [`POST /export/content/data`](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/data-export) exports delivery and engagement data for outbound content, Series included, over a date range. One active job per workspace. 2. **Split the list into transactional, marketing, and in-product.** Transactional is anything a user action must produce: password resets, receipts, confirmations, alerts. In-product is banners, tours, tooltips, and checklists, which stay in Intercom or move elsewhere. 3. **List the events you fire.** Mark which ones exist only to trigger a message and which ones your support team reads in the Intercom Inbox. The first group retires; the second stays. ### Phase 2: Transactional 4. **Connect your providers.** Add your email, SMS, and push provider credentials in Courier and verify your sending domains. You are moving off shared IPs, so check domain authentication before the first production send. 5. **Set up the profile sync.** Upsert `user_id`, channel addresses, and the attributes your templates need. Start registering push tokens with Courier from your app now, in parallel with the Intercom SDK, so tokens accumulate ahead of the push cutover. 6. **Rebuild the highest-volume transactional templates** in [Design Studio](/docs/platform/content/design-studio/design-studio-overview), with content for each channel the message sends on. 7. **Replace event posts with send calls.** Each `POST /events` that existed only to trigger a message becomes a `POST /send` naming the template and passing `data`. This is usually a small diff and it removes an indirection: the call now returns an ID you can trace to delivery status. 8. **Run in parallel and compare.** Send to a test audience through both systems, diff the rendered output, then cut over one message type at a time. Watch the [logs](/docs/api-reference/messages/list-messages) rather than the calendar. ### Phase 3: Preferences 9. **Map Subscription Types to preference topics**, decide the default for each, and import opt-outs before any marketing send. Do this before Phase 4, not during it. ### Phase 4: Marketing 10. **Rebuild Series as journeys**, starting with onboarding. Recreate the trigger, then the nodes. Where a Series precomputed a roll-up in your backend, replace that with a [batch](/docs/platform/journeys/nodes/batch) or [digest](/docs/platform/journeys/nodes/digest) node. 11. **Convert segments to audiences.** Segment rules become audience filters on profile attributes, and membership updates on its own as profiles change. 12. **Move one-off sends to [broadcasts](/docs/platform/broadcasts/broadcasts-overview)**: pick a template, pick an audience, send now or schedule it. 13. **Add frequency caps.** Per-message rules in Intercom become [send limits](/docs/platform/sending/send-limits) that hold across every journey and broadcast. ### Phase 5: Decommission 14. **Pause the Intercom message, don't delete it,** once its Courier replacement has run clean for a full cycle. 15. **Drop the Proactive Support Plus add-on** when no live message needs it, and stop firing the events that existed only to trigger sends. ## Migrating with an AI Agent Most of this migration is mechanical: read a message definition, create the equivalent template, rewrite the call site. That suits a coding agent well. Three things to set up first: * **[Courier Skills](/docs/tools/courier-skills)** teaches the agent Courier's real APIs and patterns so it stops guessing at endpoints: ```bash theme={null} npx skills add trycourier/courier-skills ``` In Claude Code you can install it as a plugin instead, which self-updates and ships the Courier docs MCP server. * **[Courier's MCP server](/docs/tools/mcp)** gives the agent direct access to your workspace, so it can create templates, build journeys, upsert users, and read send logs as it works. See [Build with AI](/docs/tools/ai-onboarding) for setup in Claude Code, Cursor, Codex, and VS Code. * **Docs for agents.** Point it at [llms-full.txt](https://www.courier.com/docs/llms-full.txt) when it needs API detail beyond this page. Then start it with a prompt like this one. Fill in the bracketed parts. ```text theme={null} Help me migrate our notification sending from Intercom to Courier. Read first: - https://www.courier.com/docs/tutorials/migrate/from-intercom (concept mapping, constraints, and the phased plan you should follow) - https://www.courier.com/docs/llms-full.txt (full Courier docs, for API detail as you need it) Our setup: - Codebase: [path] - Intercom access token: [env var] - Courier: connected through the Courier MCP server Work in this order. Stop after step 3 and wait for my review before you create anything in Courier. 0. Setup. Install Courier Skills so you build against Courier's real APIs and patterns rather than guessing: npx skills add trycourier/courier-skills Then confirm the Courier MCP server is connected. If either one is missing, stop and tell me before going further. 1. Inventory. Intercom has no endpoint that lists Series or outbound messages, so I will paste in the list from the Outbound screen. For each item, record: name, trigger (manual, rule, or event), channels, audience, and the event name if it is event-triggered. If you need per-message volume, use POST /export/content/data. 2. Classify each item as: - transactional (a user action must produce it) - marketing (campaign or lifecycle) - in-product guidance (banner, tooltip, tour, checklist, carousel) The third group does not move to Courier. Flag it and leave it. 3. Find the send sites. Grep the codebase for Intercom POST /events and POST /messages calls. For each event call, decide whether it exists to trigger a message or only to give support agents context in the Intercom Inbox. Only the first group becomes a Courier send. Report the inventory, the classification, and the send-site list. Then wait. 4. Transactional first. For each transactional item: create the Courier template with the channels it needs, then rewrite its call site from an Intercom event post to a Courier /send that names the template and passes data. Leave the Intercom call in place behind a flag so we can run both and compare output. 5. Journeys. Recreate each Series through the Courier journeys API. Waits become delay nodes, rules branches become branch nodes, messages become send nodes, exit rules become cancel nodes. Where the Series depended on our backend precomputing a roll-up, use a batch or digest node instead. Rules: - Never send to a real user. Use a test profile for every verification send. - Never pause, unpublish, or delete anything in Intercom. That is my call. - If an Intercom message relies on something Courier does not have, say so in your report rather than approximating it. ``` Review the classification in step 2 closely. Whether a message counts as transactional decides whether its preference topic is marked required, and getting that backwards means either a receipt users can unsubscribe from or a marketing email they can't. ## FAQ No, and most teams don't. Intercom keeps the help desk: Messenger, the Intercom Inbox, tickets, Help Center, Workflows, and Fin. Courier takes over the notifications your product sends. Keep sending Intercom the contact updates and events your agents read for context, and retire only the events that existed to trigger outbound messages. [Journeys](/docs/platform/journeys/journeys-overview). Entry rules become [triggers](/docs/platform/journeys/invocation) (API invoke, inbound webhook, Segment event, or audience membership), and Series nodes map across: waits to [delay](/docs/platform/journeys/nodes/delay), rules branches to [branch](/docs/platform/journeys/nodes/branch), messages to [send nodes](/docs/platform/journeys/nodes/send). Journeys add [batch](/docs/platform/journeys/nodes/batch), [digest](/docs/platform/journeys/nodes/digest), [throttle](/docs/platform/journeys/nodes/throttle), and [fetch data](/docs/platform/journeys/nodes/fetch-data) nodes, and they can be [built through the API](/docs/platform/journeys/building-journeys-via-api). Call the [send API](/docs/platform/sending/send-message) with the template and recipient. Intercom has no push send endpoint, so if you were triggering push from code you were posting an event and matching it against a message configured in the UI. In Courier the send is explicit and returns an ID you can trace through to [delivery history](/docs/api-reference/messages/get-message-history). Tokens collected by Intercom's mobile SDK live in Intercom. Start registering tokens with Courier's [device token API](/docs/api-reference/device-tokens/add-multiple-tokens-to-user) from your app while Intercom is still live, let coverage build across a release cycle or two, then cut push over. Plan this early, since it moves at the speed of app adoption rather than your backend deploys. You improve your control over it. Intercom sends over shared IPs and does not support bringing your own email provider. Courier sends through [your own provider accounts](/docs/external-integrations/integrations-overview), so your domains, reputation, and dedicated IP if you have one carry over. Authenticate your sending domain with your provider before the first production send. The help desk (Messenger, the Intercom Inbox, tickets, Workflows), the Help Center and Articles, Fin and the AI agent surfaces, and in-product guidance UI such as Tooltips, Product Tours, Checklists, and Carousels. In-app banners are on the Courier roadmap. Courier replaces message delivery and orchestration: transactional sends, campaigns, journeys, templates, preferences, and the in-app notification feed.