Intercom integration

2. Connection and scope

Seedling verifies the provider account before storing the workspace connection. A current Seedling workspace administrator controls installation and disconnect; account identity is never inferred from an email address or display name.

Seedling-managed OAuth app

A current Seedling workspace administrator authorizes the Seedling Intercom app in the matching US, EU, or AU Intercom region.

Customer-managed OAuth app

Seedling has designed a customer-owned public or unlisted OAuth mode, but it is not enabled until Intercom confirms that operating model in writing.

3. Intercom data Seedling accesses

Seedling uses synchronized information for source-backed search, operating context, verification, and customer-approved workflows. Availability depends on the connected account, selected resources, provider plan, and native permissions.

Support conversations

Conversation lifecycle, assignment, source messages, replies, notes, and events. Intercom returns at most the 500 most recent parts; Seedling marks that boundary as incomplete history.

Customer context

Contacts, companies, stable identifiers, and a bounded set of typed custom attributes used to connect support work to customer context.

Support organization

Teammates and teams used to resolve authors, owners, assignment, and operational handoffs. Team assignment is never treated as a reader permission.

Published knowledge

Published Help Center article locales and hierarchy context. Draft, unpublished, and deleted articles are excluded from member-facing retrieval.

4. Read-only permission contract

Seedling requests only the Intercom read capabilities needed for the implemented data classes and probes each capability before completing a connection.

• Read and list admins, teams, contacts, and companies.
• Read conversations and their available conversation parts.
• Read and list Help Center articles.
• No ticket, message-send, contact-write, company-write, or conversation-write permission is included in this release.

5. Security and access

• Provider credentials and other connection secrets are encrypted in the workspace tenant data plane, never returned to the browser, and excluded from logs and queue payloads.
• Every source, synchronization, secret lookup, audience contribution, disconnect, and purge remains bound to the exact connection that created it.
• OAuth tokens are long-lived according to Intercom's documented response and require reauthorization after revocation or persistent unauthorized responses; Seedling does not invent refresh behavior.
• Every API request pins Intercom REST API version 2.16 and routes to the installed workspace's US, EU, or AU API host.
• Intercom's public APIs do not expose enough evidence to reproduce effective teammate access per conversation. Synchronized objects therefore remain restricted and have no human audience until a workspace administrator explicitly grants Seedling access.
• Signed webhook intake, durable receipt recovery, bounded overlap, and scheduled reconciliation are implemented behind the disabled rollout flag. Provider uninstall authenticity and destructive callback handling remain release gates.
• Generated output cannot bypass Seedling's human review, verification, and approval gates.

6. Retention and deletion

Connected data

Synchronized Intercom records remain while the connection is active and are removed through a durable integration purge after disconnect.

Credentials

Stored Intercom credentials or connection secrets and connection-owned synchronization state are deleted from active Seedling systems as part of the purge.

Backups

Deleted information may remain in encrypted, access-restricted backups until expiry, ordinarily within 35 days after active-system deletion.

7. Installation, help, and removal