Incoming HubSpot Ticket Webhook

Trigger identifier: incoming_hubspot_ticket_webhook.

Starts a workflow from HubSpot ticket events. HubSpot sends events to the callback of an installed trigger; the connector verifies the request, applies the event-type filter and dispatches each matching event separately.

Install the trigger

1. Create a HubSpot connection, including its client secret.

2. Create an instance of this trigger in Automations and select the connection.

3. Set the event-type filter described below and note the installed trigger's callback URL.

4. Open the matching HubSpot app's Webhooks settings and set its target URL to your trigger's callback URL. See Callback URL and subscription ID below for the exact URL format and which ID to use.

5. Enable the required HubSpot ticket subscriptions. For property-change subscriptions, select the properties your workflow needs.

6. Send a test event or perform a controlled ticket operation. Verify a run with the expected ticket ID and event fields. Merely saving the URL does not create an event.

Multiple event subscriptions can share the app's target URL. Configure both sides: the HubSpot subscription controls what is sent; the trigger option controls what is dispatched to the workflow.

Callback URL and subscription ID

Example target URL, using a fictitious subscription ID:

https://hubspot.wf.ebbot.eu/hubspot-ticket-events/12345678-1234-4123-8123-123456789abc

The URL consists of:

Part	Meaning
https://hubspot.wf.ebbot.eu	The HubSpot Workflow Server address
/hubspot-ticket-events/	The endpoint that receives HubSpot ticket webhooks
12345678-1234-4123-8123-123456789abc	An example Ebbot trigger subscription ID

The server calls the final path parameter subscriptionId. Use the subscription ID shown after installing your trigger in Automations. It identifies the installed Ebbot trigger subscription whose connection settings and event filter the server uses, and to which it dispatches matching events.

HubSpot also calls its event registrations subscriptions. Their IDs are separate from the Ebbot subscription ID in this URL. The URL does not take a HubSpot ticket ID or an Automations workflow ID.

For your setup, use:

https://hubspot.wf.ebbot.eu/hubspot-ticket-events/<YOUR-EBBOT-TRIGGER-SUBSCRIPTION-ID>

Replace the final placeholder with your installed trigger's subscription ID; do not reuse the example UUID. Use the callback host provided for your environment if it differs from the address above.

Trigger option

Field	Default	Accepted configuration values
event_type / Event Type Filter	Empty string	ticket.creation, ticket.propertyChange, ticket.deletion, ticket.associationChange, or empty

A non-empty filter dispatches only exact matches. Empty disables event-type filtering for the receiving subscription. Use explicit downstream eligibility checks rather than assuming that an empty filter protects against unrelated events.

This option does not filter by property name, property value, source or owner. Add those conditions in the workflow.

Output

Field	Type	Meaning
id	string	Ticket object ID, converted from HubSpot's objectId
event_type	string	HubSpot subscriptionType
property_name	string	propertyName, or empty if absent
property_value	string	propertyValue, or empty if absent
change_source	string	changeSource, or empty if absent
source_id	string	sourceId, or empty if absent

The dispatched output does not expose the raw occurredAt, event ID, retry attempt or portal ID. A subsequent Get Ticket reads the current record; it may already differ from the value carried by this event.

Illustrative output, using synthetic identifiers:

{
  "id": "123456",
  "event_type": "ticket.propertyChange",
  "property_name": "hs_pipeline_stage",
  "property_value": "YOUR_STAGE_ID",
  "change_source": "CONVERSATIONS",
  "source_id": ""
}

Do not reuse the example stage value. Read actual values in the connected portal.

Prevent a flow from reacting to its own writes

One ticket operation can produce several property-change events. A flow that writes status can generate events that would otherwise start the same logic again.

Put eligibility conditions before expensive classification and writes:

1. Check the relevant event_type and property_name.

2. Check change_source and, when justified by observed events, source_id.

3. Read the ticket and check the solution's ownership/state convention.

4. Identify the actual message or change being acted on.

5. Perform the intended action only when all conditions hold.

For example, a solution following conversation-originated status changes might require property_name = hs_pipeline_stage and change_source = CONVERSATIONS, then its automation-owner check. These values describe an example business design, not a universal HubSpot rule. CONVERSATIONS identifies a source subsystem, not proof that a particular end customer authored the event.

A run ending without action can be expected. These conditions do not deduplicate qualifying events or provide exactly-once execution. See Workflow patterns.

Request validation and delivery limits

The endpoint requires X-HubSpot-Signature-v3 and X-HubSpot-Request-Timestamp. It verifies the signature with the connection's client secret and the public callback URL. It rejects stale timestamps; the documented implementation permits a five-minute age window with a small clock-skew tolerance.

Missing/invalid signature headers or a rejected timestamp return 401. Missing configured client secret is a server-configuration error. Invalid JSON or a body that is not an array returns 400.

Events arrive in a batch. Matching events are dispatched separately; filtered events are counted as ignored. The acknowledgement contains status, dispatched and ignored. A batch acknowledgement is not proof that each workflow completed: malformed entries can be skipped and dispatch failures are logged while the batch still receives an acknowledgement. Verify the individual Automations run when diagnosing missing work.

See Troubleshooting for callback, authentication and repeated-event checks.