intercom v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-intercom-access-token

Custody

customer_vault

Injection

header (Authorization)

An Intercom access token (bearerAuth in the REST API reference), held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'. Token issuance is an external process: a workspace admin creates an app in the Intercom Developer Hub, and the workspace's access token is issued from the app's Authentication section; the executor performs no token lifecycle itself and injects the stored value verbatim. Least privilege: build the app for the exact registered surface — read access to contacts, companies and conversations, plus conversation reply — and no other permission; Intercom scopes app permissions per resource in the Developer Hub. Expiry and revocation: Intercom access tokens do not expire on their own; the token is revoked by deleting or rotating it in the Developer Hub (or by uninstalling the app), and a revoked value fails closed. Because the token IS the credential (no separate tokens are issued from it), deletion revokes exactly this value. Review the workspace's app inventory and token age before enabling. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• intercom-workspace-contacts (api, pii): https://api.intercom.io/contacts
• intercom-workspace-companies (api, internal): https://api.intercom.io/companies
• intercom-workspace-conversations (api, pii): https://api.intercom.io/conversations

Every endpoint here is on api.intercom.io, the shared Intercom production API host named in Intercom's REST API reference, so there is no per-customer host to substitute. Intercom also operates regional hosts (api.eu.intercom.io, api.au.intercom.io); a deployment whose workspace lives in a regional data host must substitute that host in the endpoints, resource locators and egress allowlists — the allowlist matches exactly, so all three move together. Callers must send the Intercom-Version header (the reference documents version 2.16 as current); the version is a request header, not part of the registered endpoint. This pack registers only endpoints the official Intercom REST API reference documents: the contacts, companies and conversations collection reads, and replying to a conversation. All read capabilities cover the COLLECTION read only: single-record reads (GET /contacts/{id}, GET /companies/{id}, GET /conversations/{id}), search, scroll and per-contact sub-resource listings (notes, tags, segments, subscriptions) are not registered by this pack — separate navigation and sub-resource endpoints are not registered unless named. Note on the companies collection read: it is verified against Intercom's retrievecompany reference itself, which documents the collection operation — GET /companies returns a paginated list of all companies, filterable by segment_id or tag_id, and fetches a single company by the name or company_id query parameters on the same path; the retrieval reference does document the general collection listing on this path. The POST /companies/list variant named in older documentation does not appear in the current reference (its page returns not-found), POST /companies is the create-or-update operation (not registered), and the scroll API is deliberately not registered. Effect-level declaration: POST /conversations/{conversation_id}/reply with message_type 'comment' is an admin reply delivered to the contact in the Messenger and by email — the unrestricted effect of the endpoint includes transmitting to the customer, so the capability declares send at the R3 floor alongside create. send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer): a reply cannot be un-delivered once the contact has it. An internal-note-only variant (message_type 'note') is NOT registered: message_type is a request-body property of the same endpoint, and a pack registers an endpoint, not a body value, so nothing in the registration would enforce the note-only restriction. Documented exclusions: this pack does not register contact create/update/delete, contact merge, archive or block, note creation, company create/update/delete, the Messages API (admin-initiated outbound messages, which are send at R3), conversation assignment or snooze, tags, and data-export endpoints — a documented exclusion, not an approximated capability. Data-class rationale: contacts identify individuals (names, emails, phones, custom attributes) and conversations carry their messages, so both are pii; companies describe organizations and are registered internal. The review state is draft, not library: the endpoints are verified against the provider documents named in the review block, but the custody-model review the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates on — issuance authority, scope, audience, TTL, revocation, executor access and bypass paths — is unfinished for this pack.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://developers.intercom.com/docs/references/rest-api/api.intercom.io/contacts/listcontacts (retrieved 2026-09-21)
• https://developers.intercom.com/docs/references/rest-api/api.intercom.io/companies/retrievecompany (retrieved 2026-09-21)
• https://developers.intercom.com/docs/references/rest-api/api.intercom.io/companies/ (retrieved 2026-09-21)
• https://developers.intercom.com/docs/build-an-integration/learn-more/authentication (retrieved 2026-09-21)
• https://developers.intercom.com/docs/references/rest-api/api.intercom.io/conversations/listconversations (retrieved 2026-09-21)
• https://developers.intercom.com/docs/references/rest-api/api.intercom.io/conversations/replyconversation (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.