HubSpot package v1.0.0

A HubSpot private app access token, 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 super admin creates the private app in the HubSpot account (Development > Legacy apps > Create legacy app > Private), chooses its scopes, and copies the token from the app's Auth tab; the executor performs no token lifecycle itself and injects the stored value verbatim.

Least privilege: HubSpot scopes are per-object and per-operation for most CRM objects (for example crm.objects.contacts.read versus.write), but tickets are the documented exception: HubSpot's scope list documents the ticket-read scope as 'tickets' (which includes access to tickets) — tickets do not follow the crm.objects.<object>.read pattern, and no crm.objects.tickets.read scope exists — so grant crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read and tickets for the reads, plus crm.objects.contacts.write for the create capability — and nothing more.

Expiry and revocation: private app access tokens do not expire on their own; rotation is manual from the app's Auth tab — 'Rotate and expire now' invalidates the original token immediately, while 'Rotate and expire later' leaves it valid for 7 days — and deleting the private app permanently revokes its token.

Because the token is the credential (no separate tokens are issued from it), rotation or deletion revokes exactly this value; HubSpot recommends rotating every six months and emails super admins when a token has gone unrotated for 180 days.

Renewal ownership sits with an external deployment process.

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.

Every endpoint here is on api.hubapi.com, the shared HubSpot API host named in HubSpot's own private-app documentation, so there is no per-customer host to substitute; HubSpot responses also reference the api.hubspot.com alias, which this pack deliberately does not allowlist — one authority per capability, exactly as registered. This pack registers only endpoints the official HubSpot developer documentation describes: the CRM v3 objects collection reads for contacts, companies, deals and tickets, and single-record contact creation.

All read capabilities cover the collection read only (GET /crm/v3/objects/{object}): single-record reads (GET /crm/v3/objects/{object}/{recordId}), batch reads, search and association navigation endpoints are not registered by this pack.

Documented exclusions: this pack does not register record update or delete (PATCH/DELETE /crm/v3/objects/{object}/{recordId}), batch create/update/archive operations, the standalone association-write endpoints (contact creation can itself establish associations to existing records through the associations object in the same POST — that is part of the registered create capability, and what is excluded is the standalone association-write surface), company, deal or ticket creation, engagements (notes, calls, meetings, tasks), and any email-sending surface (marketing email send, transactional single-send): a send capability would carry the send action at the minimum R3 tier, and this pack registers none.

Data-class rationale: contacts and tickets identify individuals and carry their messages, so both are classified as pii (personal data); deals carry amounts, stages and close dates — the account's revenue pipeline — and are registered financial for the same reason the Salesforce pack classes opportunity data financial; companies describe organizations rather than individuals and are registered internal, and a deployment whose company records carry personal or regulated data should raise the class before enabling.

Tiering: reads sit at R0 (the read floor) and contact creation at R2 (the create floor); the shipped pack registers at the minimum and policy can raise a tier for a specific actor, scope or resource.

The endpoints are verified against the provider documents named in the review block, and the credential-custody review was completed on 2026-09-21 against this pack's custody model (a private app access token held in the customer's vault), with these findings, one per gated property.

Issuance authority and delegation: a super admin creates the private app in the HubSpot account (Development > Legacy apps > Create legacy app > Private), chooses its scopes and copies the token from the app's Auth tab, so issuance authority sits with the account's own super admin.

Scope: scopes are chosen at app creation and are per-object and per-operation for most CRM objects, with tickets the documented exception (the ticket-read scope is 'tickets', and no crm.objects.tickets.read exists); the least-privilege grant is crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read and tickets for the reads, plus crm.objects.contacts.write for the create capability — and nothing more.

Audience: no audience mechanism is documented — the bearer value authorizes against api.hubapi.com, and audience binding beyond that is not established. TTL: private app access tokens do not expire on their own; HubSpot recommends rotating every six months and emails super admins when a token has gone unrotated for 180 days.

Refresh ownership: there is no refresh — rotation is a manual action from the app's Auth tab ('Rotate and expire now' invalidates the original token immediately, 'Rotate and expire later' leaves it valid for 7 days), renewal ownership sits with an external deployment process, and the executor injects the stored value verbatim and performs no token lifecycle itself.

Revocation: deleting the private app permanently revokes its token, and because the token is the credential (no separate tokens are issued from it), rotation or deletion revokes exactly this value. Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable with no TTL bound until rotated or deleted, and HubSpot's 180-day unrotated-token reminder is the vendor's mitigation.

Alternate access paths: the HubSpot UI and other apps or OAuth integrations retain access outside this pack, and deleting this app or rotating its token closes only this path. The credential review is complete. Assign accountable owners before deployment.