Permissions & Security - Hubspot
Updated 15 days ago
/ /
For data security, encryption, and credential storage information that applies across all connectors, see Data & Security - Enterprise Search Connectors.
Our approach to permissions
The connector requests the minimum set of permissions the HubSpot APIs allow for its functionality, and only read-oriented scopes wherever the source APIs permit it.
The connector never writes to or modifies data in HubSpot.
Credentials are stored encrypted and are never exposed in logs, search results, or the Simpplr UI after initial entry.
Where a source API forces a broader or less clear scope than the connector's actual usage, this is called out explicitly in Understanding the credential scope below, together with the guardrails that apply.
Credential scope
Auth type: HubSpot account service key (Bearer token).
The service key you create in HubSpot must be granted the following scopes:
Permission | Why it's needed |
|---|---|
crm.objects.contacts.read | Read contact records and related metadata for indexing |
crm.objects.companies.read | Read company records and related metadata for indexing |
crm.objects.deals.read | Read deal records and related metadata for indexing |
tickets | Read ticket records and related metadata for indexing (HubSpot's legacy-style scope name for tickets — not crm.objects.tickets.read) |
crm.objects.owners.read | Resolve owners (including archived owners for display) during permission sync |
settings.users.read | Sync HubSpot users for identity mapping and permission sync |
settings.users.teams.read | Sync teams for membership context used with permission sync |
sales-email-read (optional) | Required only if CRM emails are enabled for indexing |
A HubSpot Super Admin, or a user with Developer tools access, must create and manage the service key. If you are not an admin, coordinate with one before proceeding to setup.
Understanding the credential scope
Account service key
Why it's required: The connector authenticates every HubSpot REST call with a long-lived Bearer service key. HubSpot documents account service keys as the supported pattern for third-party REST integrations without distributing a marketplace app. Service keys cannot authenticate webhooks; the connector therefore uses scheduled full sync (not webhooks) to detect deletions and silent permission drift.
What the connector actually does with it: Read-only calls to list and search CRM records, read record permissions for contacts/companies/deals/tickets, and sync users, owners, and teams. The connector performs no write, update, or delete operations in HubSpot.
Guardrails: Grant only the read scopes listed above. Store the key as a sensitive credential in Simpplr.
If not granted: The connector cannot authenticate. Sync fails until a valid service key with the required scopes is configured.
Tickets scope name
Why it's required: HubSpot's Tickets API documents the scope name as tickets, not crm.objects.tickets.read.
What the connector actually does with it: Read ticket records for search indexing only.
Guardrails: Read-only usage; no ticket create, update, or delete paths in the connector.
If not granted: Tickets cannot be indexed.
Versions and editions supported
Supported: HubSpot Cloud CRM (API host
https://api.hubapi.com)Not supported: Non-cloud / self-hosted HubSpot deployments (not offered by HubSpot for this API surface)
Professional or Enterprise HubSpot tiers are strongly recommended. Free/Starter rate limits may be too low for document-level permission fetching on larger portals.
Permission design
How permissions work
Permissions from HubSpot are read and enforced in Simpplr Enterprise Search. For contacts, companies, deals, and tickets, users only see records they already have View access to in HubSpot.
User and group sync: HubSpot user identities, owners, and teams are synced by the permission sync. When a user is added to or removed from HubSpot, or team membership changes, the change is reflected in Simpplr after the next permission sync.
Item permission changes (contacts, companies, deals, tickets): The connector reads HubSpot's record View permissions for each indexed record. When a record's permissions change and HubSpot updates the record's last-modified time, the change is picked up by the next incremental sync. Role or team permission changes that do not move a record's last-modified time are reconciled on the next full sync.
Public or shared links: Anonymous or public HubSpot links are not used as an access model. Visibility follows HubSpot View principals for the core four object types, or owner-only for enabled engagements.
Access removal: When a user loses View access to a contact, company, deal, or ticket in HubSpot, that record stops appearing in their Simpplr results after the next sync. Records whose permission fetch fails are not indexed with an empty or open ACL.
Deletes: Deleted HubSpot records are removed from the search index during full sync.
Was this article helpful?
Subscribe to receive updates on this article