Intercom API 2.17 adds draft, version and connector controls for customer operations

What Intercom released

Intercom's official API changelog lists version 2.17 for October 12, 2026. The release adds Data Connectors API endpoints to create, update, delete and list connectors, plus access to connector execution history. New connectors begin in a draft state, and the API supports audience targeting. The same release adds article draft operations, article version history, unified Knowledge Hub content search, Office Hours endpoints, markdown article bodies and more granular conversation-priority levels.

Those capabilities do not form one undifferentiated automation feature. They expose at least two operating lifecycles: data connectors that fetch or synchronize context, and knowledge articles that move from a staged change to a published customer-facing source. RevOps should govern each lifecycle with its own evidence, authority and recovery path while retaining a link between the connector run and the content or decision that consumed its output.

• Record API version 2.17 and the October 12 source date.
• Inventory the exact endpoints and scopes enabled.
• Keep connector and knowledge-release ownership separate.

Sources: Intercom API changelog

Draft is a control state, not a backlog label

Intercom says article drafts can be created, updated, retrieved and published while the live article remains unchanged until publication. That separation gives content operations a usable control boundary. A draft can be reviewed for factual accuracy, audience, links and escalation language without altering the source that an agent or customer currently reads.

Model the states explicitly: live version, draft version, review decision, release request, publish response and read-back of the newly live article. Do not collapse saved, approved and published into one status. A successful draft write proves only that the proposed content exists. A publish response still needs a destination read-back because policy, permissions or a later automation can change the result.

• Preserve the live version before editing.
• Name the approver and release criterion.
• Read the published article after the API call.

Version history makes rollback testable

The version-history endpoints allow an operator to inspect prior article versions instead of relying on a separate copy pasted into a ticket. Use that history to build a release receipt containing article identity, previous version, draft version, acting identity, approval, publish timestamp and verified current version. The receipt should be understandable without reopening the automation conversation that produced it.

A rollback plan must still be defined by the team. The existence of history does not prove that restoring a prior version is permitted, safe or complete. Test the supported recovery path on a low-risk article, then verify search, agent retrieval and linked content after the correction. Retain the incident version rather than deleting the evidence that explains what customers may have seen.

• Link each release to previous and current versions.
• Test the supported correction path.
• Recheck retrieval after rollback or republish.

Connector execution history belongs in the decision trace

A connector definition describes intended access; execution history describes what actually ran. Preserve both. For each production connector, store the owner, audience, authentication identity, source system, permitted data classes, schedule or trigger, configuration version and the relevant execution result. A healthy connector record should not be treated as proof that every expected object was fetched.

Define an eligible population and reconcile it where the consequence matters. If connector data informs support answers, account routing or lifecycle messages, sample the source records, retrieved content and final customer-facing result. Route missing, stale, denied and ambiguous inputs to separate exception states. A run marked complete can still carry incomplete context.

• Retain configuration and execution evidence.
• Measure eligible records as well as successful runs.
• Route stale or missing context to an owner.

Unified search expands the evidence surface

Unified Knowledge Hub search can simplify retrieval across content types, but a broader search surface increases the need for source labels and freshness. The result shown to an operator or agent should retain content identity, content type, language, publication state, version and retrieval time. Search relevance is not authority to answer a contractual, billing or account-specific question.

Create consequence classes. General how-to guidance may use published knowledge directly. Account access, commercial commitments, security claims and refunds should require the appropriate account or policy source and a named escalation route. Office Hours can help communicate availability, but they should not be used as a substitute for an owned response or service commitment.

• Retain source identity and version in retrieval traces.
• Apply stricter gates to commercial or account-specific answers.
• Keep availability information separate from resolution promises.

The operator takeaway

Intercom API 2.17 gives customer-operations teams more explicit building blocks for controlled automation. Drafts protect the current live article while changes are reviewed. Version history supports reconstruction. Data Connector execution history provides evidence about runs. Unified search provides a common retrieval path. Those are meaningful improvements when the operating model uses them as boundaries rather than shortcuts.

Start with one article family and one connector. Define scope, identity, evidence, approval, final-state verification and recovery before production. Report published content only after read-back, and report connector outcomes only against an eligible population. The win is not simply more API surface; it is customer work that can be released, inspected and corrected without guesswork.

• Pilot one bounded connector and content family.
• Publish a release receipt for every consequential change.
• Review scopes, audiences and stale sources on a cadence.