> For the complete documentation index, see [llms.txt](https://docs.ebbot.ai/ebbot-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ebbot.ai/ebbot-docs/integrations/automations-integrations/integration-setup-guides/hubspot-integration-in-automations/connection-setup.md).

# Connect HubSpot

Use a dedicated HubSpot connection for the portal and environment your workflow should access. The documented connection uses a HubSpot private-app access token; it does not provide an interactive OAuth sign-in flow.

## Credentials and connection fields

| Field                                           | Required                                   | Value                                                           |
| ----------------------------------------------- | ------------------------------------------ | --------------------------------------------------------------- |
| HubSpot Access Token (`hubspot_access_token`)   | Yes                                        | Access token for the HubSpot app used by this connection        |
| HubSpot Client Secret (`hubspot_client_secret`) | For ticket webhooks and resolution buttons | The app's client secret, used to validate signed requests/links |
| HubSpot API Base URL (`base_url`)               | Default supplied                           | `https://api.hubapi.com`; change only when instructed           |

The access token and client secret are different values. Keep them in the connection's secret fields, not in prompts, ordinary node inputs or shared documentation.

## Supported app type

The HubSpot integration currently supports legacy private apps.

## Permissions

The integration's setup baseline for core ticket workflows is:

| Scope                       | Capability used by this integration                |
| --------------------------- | -------------------------------------------------- |
| `tickets`                   | Ticket reads/updates and related ticket operations |
| `conversations.read`        | Read threads, messages and channel context         |
| `conversations.write`       | Post public or internal messages to Conversations  |
| `crm.objects.contacts.read` | Contact lookups, including recipient email         |
| `crm.objects.owners.read`   | Owner and sender selectors                         |

Additional catalog operations use `crm.objects.companies.read`, `crm.objects.deals.read` and `settings.users.teams.read`. Generic CRM operations also depend on the selected object type and requested read/write operation. Grant the scopes needed for your chosen workflow, and check HubSpot's response if an operation requires additional access. A scope is not a substitute for the sending actor's access to a conversation channel.

## Create and check the connection

1. Open **Integrations** in Automations and select the HubSpot integration.
2. Create a connection for the intended portal and enter the fields above.
3. Complete connection validation. This makes a small ticket-read request; it does not prove every action, sender or webhook is configured correctly.
4. Use **Get Ticket** on a known test ticket. Check `exists`, ticket ID and required properties.
5. If using events, follow [Incoming HubSpot Ticket Webhook](/ebbot-docs/integrations/automations-integrations/integration-setup-guides/hubspot-integration-in-automations/incoming-hubspot-ticket-webhook.md) to install a trigger and configure its callback in HubSpot.
6. Add public send/update actions only after the input and routing checks behave as intended in your test scope.

## Record the installed configuration

Keep the portal, app name/ID, connection name, trigger ID, callback URL, enabled subscriptions, granted scopes, credential owner and last successful test together in your solution documentation. Store references to secure credential storage rather than the values themselves.

Each installed trigger has a callback target. A legacy app has one target URL for its subscriptions; multiple event types can go to that target. If your design needs distinct targets, plan separate app/connection setups or a single receiving flow that routes the events. Do not overwrite another flow's callback to install a second one.

When credentials change, update the relevant connection and test the read path and any signed trigger/button path that uses them. Previously generated resolution links depend on the secret used to sign them.