1. Overview
The HubSpot integration uses a customer-managed private app token to read core CRM objects, their properties and associations, owners, schemas, and deal or ticket pipelines.
The HubSpot portal ID is the verified provider account identity. Archived records observed during synchronization are used to remove the matching indexed objects safely.
2. Connection and scope
Seedling verifies the provider account before storing the connection. A personal connection remains actor-owned; a workspace connection is administered for the selected Seedling workspace. Credentials are never inferred from an email address or silently promoted between scopes.
- Private app access token
- A HubSpot Super Admin creates a private app in the target account and grants the required read scopes. An optional account name may be supplied; Seedling always calls HubSpot's API.
- Personal or workspace connection
- The token's HubSpot account and authorizing user are verified before the exact connection is stored.
3. HubSpot 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.
- CRM records
- Contacts, companies, deals, tickets, selected properties, archived state, and associations among core objects.
- Owners and pipelines
- Owners, deal and ticket pipelines, stages, and lifecycle vocabulary used for attribution and operational context.
- Schemas
- Contact, company, and deal property metadata used to interpret configured CRM fields without assuming a universal customer schema.
4. Read-only permission contract
Seedling rejects a private app token that omits a required object or owner read scope. Schema scopes are recommended for richer property context.
- crm.objects.contacts.read, crm.objects.companies.read, and crm.objects.deals.read — read core CRM records.
- tickets — read ticket records used by the current HubSpot API contract.
- crm.objects.owners.read — read CRM owner identity and attribution.
- crm.schemas.contacts.read, crm.schemas.companies.read, and crm.schemas.deals.read — read property definitions and schema context.
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.
- The provider does not expose enough object-level audience evidence for Seedling to reproduce every native permission safely. Workspace content therefore follows the connection's restricted-by-default policy; administrators and stewards receive no raw-content bypass.
- Personal-connection raw content remains visible only to the connecting member in human-facing Seedling surfaces.
- HubSpot scopes are not a per-record ACL. Seedling does not treat token validity, ownership, or administrator status as proof that every workspace member may read every CRM record.
- Generated output cannot bypass Seedling's human review, verification, and approval gates.
6. Retention and deletion
- Connected data
- Synchronized HubSpot records remain while the connection is active and are removed through a durable integration purge after disconnect.
- Credentials
- Stored HubSpot 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.