Skip to main content
Technical Preview

Overview

A client-mode connector for the Intercom REST API that connects plant and product events to customer support. A connected machine that raises an alarm can open a conversation or a ticket for its owner, the support team can be told when it clears, and contact or company custom attributes (firmware, run hours, machines online) stay current from live data. Usage can be recorded as Intercom events so it shows on the customer’s timeline. Every event pins Intercom-Version: 2.16, the latest generally available version (released 2026-07-15), so a change of the app’s default version in the Developer Hub does not change the connector’s behaviour. Topics use crm/intercom/<object>/<verb>; each response is published on <source topic>/response.
The template was checked against Intercom’s published OpenAPI 2.16 and a local mock, and every packaged method and path was probed on api.intercom.io with an invalid token: each answered 401 unauthorized, while an unknown path answers 404 not_found, so all 25 paths exist on the live API. It has not been run against a real Intercom workspace yet, so status stays blocked until an authenticated smoke passes.

Authentication

Create an app in the Intercom Developer Hub and copy its access token from Configure > Authentication in the app (see Intercom authentication). Public apps use an OAuth access token instead; the header is the same. The connector sends Authorization: Bearer <token>, taken from the access_token field of each MQTT payload.
Do not publish the token in retained messages. Store it as a broker secret (for example INTERCOM_ACCESS_TOKEN) and have a LoT action add it to the payload with GET SECRET before publishing to the connector topic.
Workspaces hosted in Europe or Australia use a different host. Change BASE_ADDRESS to https://api.eu.intercom.io or https://api.au.intercom.io.

Payload fields

Events

The three POST .../search events only read data; Intercom uses a JSON body for search queries. No delete, merge, archive, block or redact events are packaged on purpose.

Basic Syntax

Examples

Publish to crm/intercom/conversations/create:
When the alarm clears, publish {"access_token": "...", "id": "<conversation id>", "body": {"message_type": "close", "type": "admin", "admin_id": "<admin id>", "body": "Cleared by the line"}} to crm/intercom/conversations/manage.

Webhooks into the broker

Intercom webhooks (topics such as conversation.user.created or ticket.state.updated) are set up on the app’s Webhooks page in the Developer Hub, not through the API. Intercom then POSTs each notification to your endpoint and signs it with an X-Hub-Signature header (sha1= plus the HMAC-SHA1 of the JSON body, keyed with the app’s client_secret from its Basic Info page). To receive them, run a separate server-mode connector:
The receiver must be reachable from the internet over HTTPS. It is not part of the client template.

Rate limits

By default an app may make 10,000 API calls per minute and a workspace 25,000, spread evenly over 10-second windows. Excess calls get 429 Too Many Requests with X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers. React to events rather than polling searches from fast timers.

Testing

To finish the check, set INTERCOM_ACCESS_TOKEN and run python3 smoke_intercom.py --live from the package, then deploy the connector and publish {"access_token": "..."} to crm/intercom/me/get.
Last modified on October 21, 2026