---
name: intercom-oauth-app
description: Creates or signs in to an Intercom development workspace and registers an Intercom app in the Developer Hub to obtain OAuth2 client ID and client secret — enabling OAuth on the app, adding every HTTPS redirect URL, selecting the per-app permission scopes, handling US/EU/AU regional hosting, pinning the API version, and a safe credential handoff. Use when asked to get Intercom OAuth credentials, create an Intercom app or development workspace, add a redirect URL or scope to an Intercom app, submit an Intercom app for review or App Store listing, or fix an Intercom OAuth failure such as `Unauthorized Code`, a customer landing on the wrong region, or a 401 on every API call after install. For any other vendor's developer portal, use that vendor's skill instead.
---

# Intercom OAuth2 App Registration

Get a working Intercom OAuth2 client — a development workspace, an app in the Developer Hub with **Use OAuth** ticked,
HTTPS redirect URLs, the permission checkboxes, and a client ID and secret — for a platform that connects many
customers' Intercom workspaces.

Intercom departs from the usual OAuth shape in three ways that cost real time if you assume otherwise. **Scopes are
selected per app in the Developer Hub, not requested per authorization** — the authorize URL takes only `client_id`
and `state`, so there is no "just add a scope to the URL" fix; a scope change is an app change, and on an approved app
it is a re-review. **Intercom has three regional workspaces (US, EU, AU) with three authorization hosts and three API
hosts**, and sending an EU customer to the US host costs them an extra region-selection step — or hard-fails if they
sign in with Google. And **the API version is pinned on the app**, retroactively, for every token ever issued by it.

The fourth thing to know before you start: **a public app must be developed in a development workspace, and
development workspaces exist only in the US region** (§2). That is a constraint on where you build, not on who can
install.

## Inputs to collect before you start

Ask in one batch. Never invent.

| Input | Notes |
| --- | --- |
| **App name**, description, logo | Shown on the consent screen and, if listed, in the App Store |
| **Which workspace owns the app** | An existing development workspace, or a new one (§2) |
| **Is this public (customers' workspaces) or private (your own)?** | Private apps skip OAuth entirely — use an access token (§2) |
| **Redirect URLs** | Every callback host your platform serves, HTTPS only (§4) |
| **Permission set** | Intercom's checkbox labels, not scope strings (§5) |
| **Which customer regions you serve** | US / EU / AU — decides §6 |
| **API version to pin** | Affects every existing customer token (§8) |
| **Listed in the App Store, or unlisted?** | Both need review; listing needs much more (§9) |
| **Intercom teammate account with Developer Hub access** | Only a human can sign up, verify email and accept terms |

## Quick Start

1. Confirm a **new app** is needed — a new client ID orphans every existing customer connection (§1).
2. Sign in to, or create, the **development workspace** that will own the app (§2).
3. Create the app in the Developer Hub, then tick **Use OAuth** on its Authentication page (§3).
4. Add **every** redirect URL, HTTPS only, first one is the default (§4).
5. Tick the permission checkboxes the connector actually needs — these are the scopes (§5).
6. Decide the regional story: authorization host per customer, API host per workspace (§6).
7. Copy client ID and client secret from **Basic Information** (§7).
8. Pin the API version deliberately, knowing it applies to tokens already issued (§8).
9. Choose listed vs unlisted and submit for review — both require it (§9).
10. Verify with a real authorize → callback → token → `/me` round trip against a *second* workspace (§10).
11. Hand the credentials over — never commit them (§11).

## Platform state (verified 2026-09-20 — re-verify before trusting)

- **OAuth is off until you turn it on.** A new app has no OAuth at all. You tick **Use OAuth** on the app's
  Authentication page in the Developer Hub, which then reveals the Redirect URLs and Permissions sections. Until that
  tick, there is no client secret to find and the authorize URL will not work.
- **Scopes are per app, not per authorize request.** The documented authorize URL carries only `client_id` and
  `state`. Permissions are checkboxes in the Developer Hub, reviewed at approval. A connector cannot narrow or widen
  what it asks for at connect time.
- **Public apps must be built in a development workspace**, which is free, unlimited in number, **US region only**,
  capped at 20 users/leads, cannot be converted to production, and watermarks the Messenger.
- **Three regions, three hosts.** API: `https://api.intercom.io`, `https://api.eu.intercom.io`,
  `https://api.au.intercom.io`. Authorization: `https://app.intercom.com/oauth`, `https://app.eu.intercom.com/oauth`,
  `https://app.au.intercom.com/oauth`. Calling `api.intercom.io` for any workspace is documented to attempt routing to
  the right region; the authorization host is *not* forgiving in the same way for Google sign-in.
- **The token response has no `expires_in` and no `refresh_token`** — it returns `token_type`, `token` and
  `access_token`, and the docs document no refresh endpoint. See §7 for what this does and does not let you conclude.
- **Every public app needs review — listed or unlisted.** Up to **seven business days**. On approval the app becomes
  *public unlisted*; listing in the App Store is a separate switch. Changes to an approved app (including redirect
  URLs and permissions) need re-approval.
- **Rate limits**: 10,000 API calls per minute per app and 25,000 per minute per workspace, distributed into 10-second
  windows.

If the Developer Hub does not look like this, stop and report what you actually see rather than clicking on.

## 1. Decide: reuse the existing app, or register a new one

A new app means a **new client ID, and every existing customer token belongs to the old one**. Intercom tokens are not
portable between apps; every customer would reinstall and re-authorize.

Reuse the existing app for: adding a redirect URL, adding or removing a permission, rotating credentials, changing the
pinned API version, or diagnosing a failing authorization. On an **approved** app all of those are re-review events
(§9) — they are not free, but they are far cheaper than a new client ID.

Create a **new** app only when the user explicitly wants one: a separate product, a staging app kept apart from
production (Intercom itself recommends a `[Staging]` twin), or a deliberate replacement for a compromised app. Say
which path you are taking before you touch anything.

## 2. Workspaces: which one owns the app

Intercom apps are owned by a **workspace**, and which kind of workspace you pick is a decision you cannot undo later.

- **Public app (this is the multi-customer connector case)** — you **must** create a new **development workspace**:
  `https://app.intercom.com/admins/sign_up/developer`. Free, create as many as you like, intended for development
  only. Limits that bite: **US region only**, **cannot be converted into a production workspace**, maximum 20
  users/leads (older ones are archived automatically), no outbound email or push, Help Center can never go live,
  watermarked Messenger.
- **Private app (your own workspace's data only)** — you do not need OAuth at all. Sign in at
  `https://app.intercom.io/admins/sign_in`, create the app on your paid workspace, and use the access token from its
  Authentication page. If someone is asking for OAuth credentials to read *their own* workspace, say so — it saves the
  whole review cycle. Intercom's terms forbid asking customers for their access tokens in place of OAuth.
- **If your own paid workspace is in EU or AU**, Intercom explicitly advises against developing a private app in a
  development workspace, because you will not be able to install a development-workspace app into your paid workspace.
  Develop in the paid workspace instead.
- **Test workspace** (a toggle on a paid workspace, Settings → Workspace → General) is a different thing from a
  development workspace: it inherits your plan and teammates, and is available on the **Advanced or Expert** plans.
  Useful as the *second* workspace for end-to-end verification (§10).

Hand control back to the user for anything only a human can do: signing up, verifying the email, accepting terms, 2FA,
and anything that requires being a teammate on the workspace. Do not retry a blocked step in a loop.

**If this session has no browser automation** (the usual case for a CLI or cloud run), do not pretend to click. Hand
the user an exact, ordered click path with the literal values to paste — the redirect URLs from §4 and the permission
labels from §5 — then continue once they report back with the client ID.

## 3. Create the app and turn OAuth on

1. Developer Hub → **Your apps** → **New App**: `https://app.intercom.com/a/apps/_/developer-hub`.
2. In the modal, enter the app name and **select the workspace** it belongs to (you can create a development workspace
   from this dropdown). Creating the app **pre-installs it** into that workspace and issues an access token for it —
   that token is for your own workspace's data and is not what customers will use.
3. Open the app's **Authentication** page and tick **Use OAuth**. Two sections appear: **Redirect URLs** (§4) and
   **Permissions** (§5). Nothing about OAuth exists before this tick.
4. Fill in Basic Information — name, description, logo. This is what a customer sees on the consent screen and, if
   listed, in the App Store.

If the app will use **Canvas Kit** (Messenger or Inbox surfaces), four permissions are selected automatically and
**cannot be deselected**: *Read and list users and companies*, *Read conversations*, *Read admins*, *Gather App data*.
A pure REST connector that does not use Canvas Kit avoids that floor — worth knowing before a reviewer asks why you
request them.

## 4. Redirect URLs

The redirect URL is where Intercom sends the authorization code. Register **every** callback host your platform
serves. For Unified.to these are one per data center; confirm the current list with the platform owner rather than
assuming:

```
https://api.unified.to/oauth/code          # us (default)
https://api-eu.unified.to/oauth/code       # eu
https://api-au.unified.to/oauth/code       # au
https://api-dev.unified.to/oauth/code      # dev
```

Notes that decide whether this works:

- **HTTPS is mandatory.** Intercom will not accept an `http://` redirect — TLS/SSL only. No localhost exception is
  documented, which is why a dev/staging host belongs in this list rather than a loopback URL.
- **Multiple URLs are supported** via *Add redirect URL*. **The first is always the default** — the one used when you
  do not pass `redirect_uri`. Put production first unless you have a reason not to.
- Intercom's guidance is that after approval you select among the registered URLs with the `redirect_uri` parameter,
  which is how one app covers testing and production.
- On an approved app, editing this list is a **re-review** (§9). Register every host you will plausibly need now — a
  fourth data center added later is a review cycle, not a config change.

## 5. Permissions (these are the scopes)

Intercom calls them **Permissions**, presents them as checkboxes on the app's Authentication page, and reviews them at
approval. There is no scope parameter in the authorize URL — **whatever is ticked is what every customer grants**.

The consequences are worth stating plainly before you tick anything:

- You cannot ask a given customer for less. Every install carries the full ticked set.
- **Over-privileged scopes are the most common reason apps are initially rejected** in review, per Intercom's own
  guidance. Tick only what the connector calls.
- Adding a permission later changes the consent screen and triggers re-review. Customers who authorized before the
  change did not consent to the new permission — plan on re-authorization when you widen the set, and verify the
  behavior before promising otherwise.
- **Webhook topics are gated on the matching permission.** If you want a webhook topic, the corresponding permission
  must be ticked — e.g. user/lead-created topics require *Read and write users*.

The checkbox labels are the identifiers here — copy them verbatim into the Developer Hub. Labels relevant to a
CRM/ticketing/help-center connector, as Intercom spells them:

| Group | Label |
| --- | --- |
| People & conversation data | `Read and list users and companies`, `Read one user and one company`, `Read and write users`, `Write users and companies` |
| People & conversation data | `Read conversations`, `Write conversations`, `Read tickets`, `Write tickets` |
| People & conversation data | `Read tags`, `Write tags`, `Read events`, `Write events`, `Read counts`, `Write data attributes` |
| People & conversation data | `Read and write custom object instances`, `Read status of jobs`, `Read content data` |
| Workspace data | `Read admins`, `Read one admin`, `Update admins`, `Read admin activity logs` |
| Workspace data | `Read and List articles`, `Read and Write Articles` |
| Workspace data | `Read and List news items and newsfeeds`, `Read and Write news items and newsfeeds` |
| Workspace data | `Read data when entered into the app`, `Read and write AI content`, `Read data connectors` |

**Product fact — as of 2026-09-20, Unified.to's Intercom connector requests this permission set**: *Read admins*,
*Read one admin*, *Read and list users and companies*, *Write users and companies*, *Read and List Articles*, *Read
conversations*, *Read tickets*, and *Write tickets* — covering messaging, ticketing, HRIS (admins and teams),
knowledge-base articles and collections, and ticket attachments. Reads dominate; the only writes are contacts/companies
and tickets. **Confirm the current set with the connector's owner before ticking boxes** — a set captured on a date is
a starting point, not an authority, and shipping a permission the connector does not use is exactly what review
rejects.

## 6. Regions: US, EU and AU

This section matters more than it looks for a connector serving customers in more than one region.

**Two different host families, both regional:**

| Region | Authorization host (browser) | API host (server) |
| --- | --- | --- |
| US | `https://app.intercom.com/oauth` | `https://api.intercom.io` |
| EU | `https://app.eu.intercom.com/oauth` | `https://api.eu.intercom.io` |
| Australia | `https://app.au.intercom.com/oauth` | `https://api.au.intercom.io` |

(A bare `GET` to an authorization host without `client_id` returns 400 — that is the endpoint working, not a
misconfiguration.)

What the docs say about getting it wrong:

- **Authorization host.** Send each customer to the host matching their workspace's region. If you use the US host for
  an EU or AU customer, they are asked to check their credentials and pick the correct region from a dropdown on the
  sign-in page before continuing — an extra step, not a failure. **The exception: if the customer signs in with
  Google, the wrong regional host fails rather than prompting.** So "US host for everyone" is not broken-for-everyone;
  it is broken for the subset of customers using Google sign-in, which is the worst kind of bug to diagnose from a
  support ticket.
- **API host.** Calling `api.intercom.io` is documented to attempt routing the request to the correct region, but the
  regional hosts exist so you can be explicit. Be explicit: store the workspace's region at connect time. The `/me`
  response includes the workspace's `region`, which is the cheapest way to learn it right after the token exchange.
- **The token exchange** is documented against `https://api.intercom.io/auth/eagle/token`. If you exchange against a
  regional host instead, verify it rather than assuming symmetry — this is the one place where the three-host pattern
  is not spelled out in the docs.

**One app or three?** Development workspaces are US-only, so a public app is built in the US regardless. The
documented model is one public app whose customers authorize on their own regional host. The docs do *not* state this
in one sentence, so if the user's plan depends on a single app serving EU and AU customers, verify it against a real
EU or AU workspace during §10 rather than taking it on faith.

Also worth knowing when a customer asks: regional data hosting is available to **new** workspaces on Advanced/Expert
contract plans, and a workspace cannot be migrated between regions — they create a new workspace and move data.

**Product fact — as of 2026-09-20, Unified.to's Intercom connector** offers the customer a choice of US, Europe or
Australia, pairs each with the matching regional API base and a **region-specific token endpoint**, and — worth
flagging — **points all three at the US authorization host**. Per the region note above, that is tolerable for
password sign-in and a failure mode for Google sign-in. It also ships **no shared Intercom credentials**, so each
deployment brings its own client ID and secret; sends only `client_id` and `state` on authorize, with no scope
parameter and no PKCE; and exchanges the code by POSTing JSON containing `client_id`, `client_secret` and `code`.
Confirm all of this with the connector's owner before designing around it.

## 7. Capture the credentials

Client ID and client secret live on the app's **Basic Information** page in the Developer Hub. They appear only after
OAuth is enabled (§3).

Capture:

- **Client ID** and **client secret**
- The authorization host(s) you will use (§6), and the token endpoint `https://api.intercom.io/auth/eagle/token`
- Which workspace owns the app, and whether it is a development or paid workspace
- The app's pinned API version (§8)

**The token response, and what it does not contain.** A successful exchange returns `token_type` (always `Bearer`),
`token`, and `access_token` — a duplicate of the same value. There is **no `expires_in` and no `refresh_token`**, and
the docs document no refresh or renewal endpoint. What the docs *do* document is how a token ends: the customer
uninstalls the app, you regenerate a private app's token in the Developer Hub, or someone `POST`s to
`https://api.intercom.io/auth/uninstall` with the token to deauthorize it. **Intercom's own documentation does not
state in words that OAuth tokens never expire** — that is a widely repeated claim this skill could not verify at an
official source on 2026-09-20. Treat the token as long-lived but revocable: build for "401 means the customer must
re-authorize", never for a refresh flow, and if a contractual maximum lifetime matters, ask Intercom directly.

**Know when a customer disconnects.** Because there is no refresh cycle to fail, an uninstall is otherwise invisible
until the next API call 401s. Intercom lets you register a URL that receives a `POST` with `{"app_id": "..."}` when
someone uninstalls or revokes — wire it up if the platform can consume it.

**`Unauthorized Code` on exchange.** The `code` in the redirect may end with `=`, and it must be included. A truncated
or over-trimmed code is the documented cause of a 401 with that message at the token step.

Rotating the client secret invalidates the old one. Never rotate without explicit go-ahead and a cutover plan. Report
the secret once so the user can paste it into their secret store, say plainly that it is now in the transcript and can
be rotated, then move on.

## 8. The API version is pinned on the app

Each app carries an API version, set in the Developer Hub (**API Version** → *Change version*), and an
`Intercom-Version` request header overrides it per call.

The part that surprises people: **for OAuth apps, the app's version setting governs every access token the app has
ever granted, including tokens issued before the change.** Bumping the version in the Developer Hub is a
production-wide behavior change for all installed customers at once, not a staged rollout. Intercom's own advice is to
ship the header first (so code and version change together), confirm it in production, and only then move the app
setting.

Two more consequences worth carrying:

- **Webhook topics can conflict across versions.** When you change version, topics unavailable in the new version show
  as *Off* and must be deleted before you can proceed.
- **Rollback is supported** — you can switch back to an older version if something breaks.

Before changing it, ask whether the platform pins a version per request. A connector that sends `Intercom-Version` on
every call is insulated from the app setting; one that does not is not. **Product fact — as of 2026-09-20,
Unified.to's Intercom connector sends an explicit `Intercom-Version` header (2.11) on every list, get, create, update
and delete call**, so the app-level setting is not what determines its behavior. Confirm with the connector's owner,
and note that Intercom's current version was **2.15** as of this check — a pinned 2.11 is a deliberate lag, not
necessarily a bug.

## 9. Listing, review, and the unlisted path

**Private apps** — your own workspace only, access token, no OAuth, **no review**. Stop here if that is the case.

**Every public app needs review**, whether or not you list it:

| | Listed | Unlisted |
| --- | --- | --- |
| Discoverable in the App Store | Yes | No |
| Requires review | Yes | Yes |
| App Store listing + Start guide pages | Required | Not required |
| App Partner Program form | Required | — |
| Installation status section | Required | Not required |
| Install path | App Store and/or your site | Your product or site only |

Mechanics that change what you build:

- On approval the app becomes **public unlisted**. Listing is a separate **List in App store** action, so you can beta
  with real customers before going live.
- For listed apps you provide a **Direct installation URL** — a URL *you* host that starts the OAuth flow and then
  redirects to Intercom's authorize endpoint. On success redirect to
  `https://app.intercom.com/appstore/redirect?install_success=true`; on failure to the same path with
  `install_success=false&error_message=<your message>`.
- **If the app uses any Canvas Kit capability, installation from the App Store listing is mandatory.**
- Review takes **up to seven business days**, and submission requires an **end-to-end video** showing install with
  OAuth working, the app's functionality, and uninstall — plus test-account credentials or setup instructions if your
  service needs an account. Notifications go to the teammates who created the app and who submitted the review.
- **Changes to an approved app need re-approval**, including redirect URLs and permissions. The live app keeps working
  with its current configuration while the change is pending; a *Review changes* tab shows the diff.

Everything in the App Partner Program form — company details, target use cases, points of contact, co-marketing — and
anything the review asks about compliance, data handling or volume is a business decision. Collect it from the user;
do not compose it (see **Stop and ask**).

## 10. Verify end-to-end

Authorizing in the workspace that owns the app proves little — the app is pre-installed there. Test the customer path:

1. Authorize from a **second workspace** (a test workspace on a paid plan, or another development workspace) through
   your platform's real connect flow.
2. Confirm the redirect arrives with `code` and `state`, that `state` matches what you sent, and that the **trailing
   `=` on `code`, if present, survives** into the exchange.
3. Exchange, then call `GET https://api.intercom.io/me` with `Authorization: Bearer <token>`. Read the workspace
   `region` out of the response and store it.
4. Re-issue that same call against the **regional** API host for that workspace and confirm it behaves identically.
5. If you serve EU or AU customers, repeat the whole flow against a workspace in that region using **its**
   authorization host — including, if you can, a Google sign-in account (§6).
6. Uninstall the app from the second workspace and confirm your platform notices — via the uninstall notification URL
   if configured, or by a 401 on the next call.

| Symptom | Cause |
| --- | --- |
| Authorize page errors, or the app is not found | **Use OAuth** was never ticked on the Authentication page (§3) |
| 400 from the authorization host | Missing `client_id` / `state` — or a bare `GET` with no parameters |
| Customer is asked to "check credentials" and pick a region | Sent to the US authorization host for an EU/AU workspace (§6) |
| Google sign-in customers cannot authorize at all; password users can | Wrong regional authorization host — Google fails instead of prompting (§6) |
| Redirect never happens / URL rejected at save | Redirect URL is not HTTPS, or not registered exactly (§4) |
| Lands on the wrong callback host | No `redirect_uri` sent, so Intercom used the **first** registered URL (§4) |
| `401 Unauthorized Code` at the token exchange | The `code`'s trailing `=` was dropped, or a stale/reused code (§7) |
| Auth succeeds, then 403/permission errors on one endpoint | That permission is not ticked on the app — not fixable per connection (§5) |
| Expected webhook topic unavailable | Its matching permission is not ticked (§5) |
| Everything 401s after working for months | Customer uninstalled or revoked; re-authorize — there is no refresh (§7) |
| Response shapes changed for all customers at once | The app's pinned API version moved (§8) |
| 429 with `X-RateLimit-*` headers | 10,000/min per app, 25,000/min per workspace, in 10-second windows |

## 11. Hand off — never commit the secret

- **Do not** write the client secret into source control, a test, a fixture, a committed `.env`, a ticket, a PR body,
  or a chat channel. Values go to the user, for their secret store or console.
- Access tokens are equally sensitive — an Intercom access token is a workspace password. Never ask a customer for
  theirs; Intercom's terms require OAuth instead, and violating that can cost API access.
- If a code change is needed (a callback host, a regional authorization host, a version header), keep it secret-free
  and say what the human must set out of band.
- Close with: app name and the workspace that owns it (development or paid, and its region); client ID; where the
  secret was delivered; the authorization host(s) and token endpoint in use; the exact permission labels ticked and
  why; the pinned API version; listed vs unlisted and current review state; and anything left for the user to do.

## Stop and ask

Hand back to a human rather than guessing when: the permission set is not confirmed by the connector's owner (a
guessed scope is a rejected review); someone wants to change redirect URLs or permissions on an approved app without
understanding it is a re-review and may force customers to re-authorize; a version bump is proposed on an app whose
clients do not send `Intercom-Version` themselves; the plan depends on one app serving EU or AU customers and that has
not been verified against a real workspace in that region; the App Partner Program form, App Store listing copy,
compliance answers, or test-account credentials for the reviewer are needed; someone proposes asking customers for
their access tokens instead of OAuth; a customer's regional workspace or plan eligibility is in question (Advanced /
Expert, contract); or the Developer Hub does not match the **Platform state** section above.

## References

- Authentication overview (access tokens vs OAuth) — https://developers.intercom.com/docs/build-an-integration/learn-more/authentication
- Setting up OAuth (redirect URLs, permissions, regional authorization hosts, token exchange) — https://developers.intercom.com/docs/build-an-integration/learn-more/authentication/setting-up-oauth
- OAuth scopes — https://developers.intercom.com/docs/build-an-integration/learn-more/authentication/oauth-scopes
- Installing and uninstalling apps (install URL, uninstall notifications, `auth/uninstall`) — https://developers.intercom.com/docs/build-an-integration/learn-more/authentication/installing-uninstalling-apps
- Set up a workspace / create an app (development workspace limits) — https://developers.intercom.com/docs/build-an-integration/getting-started
- About our REST API (regional hosting endpoints) — https://developers.intercom.com/docs/build-an-integration/learn-more/rest-apis
- Update your API version — https://developers.intercom.com/docs/build-an-integration/learn-more/rest-apis/update-your-api-version
- API changelog — https://developers.intercom.com/docs/build-an-integration/learn-more/rest-apis/api-changelog
- App review and publishing — https://developers.intercom.com/docs/publish-to-the-app-store/review-publish-your-app
- Listing your app — https://developers.intercom.com/docs/publish-to-the-app-store/listing-your-app
- Setting up webhooks — https://developers.intercom.com/docs/webhooks/setting-up-webhooks
- Rate limiting — https://developers.intercom.com/docs/references/rest-api/errors/rate-limiting
- Intercom developer FAQs (current API version, rate limits) — https://www.intercom.com/help/en/articles/9071694-intercom-developer-faqs
- Regional Data Hosting — https://www.intercom.com/help/en/articles/6124430-regional-data-hosting
- Changes to your EU/AU hosted workspace — https://www.intercom.com/help/en/articles/8699600-changes-to-your-eu-au-hosted-workspace
- Create a test workspace — https://www.intercom.com/help/en/articles/188-create-a-test-workspace-in-intercom
- Developer Hub — https://app.intercom.com/a/apps/_/developer-hub
- Development workspace signup — https://app.intercom.com/admins/sign_up/developer
- Intercom App Store — https://www.intercom.com/app-store
- Technology Partner Program — https://www.intercom.com/technology-partner-program