How do I connect HubSpot workflows to Zapier, Make or n8n?
Outbound is native. The Trigger a webhook action posts a payload to any URL, and it needs Operations Hub Professional, now sold as Data Hub. Inbound is not: there is no incoming webhook enrollment trigger on the workflow canvas, so Zapier, Make or n8n receives the external event and writes a property or fires a custom event, and the workflow triggers on that. The trap is that nothing retries a failed call, in either direction.
The 11 specs, in build order
Each spec states its minimum tier. Free ones open in full; the others show their public preview and the date their full spec lands.
What a spec looks like
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
What breaks, and how the specs prevent it
A workflow enrolls on records, lists and property changes, not on an HTTP request arriving. The billing signal spec documents the only two buildable paths: middleware writes a property through a private app and the workflow triggers on that property change, or middleware calls the Custom Events API and the workflow enrolls on the custom event. Zapier, Make and n8n exist in these specs to be that middleware, not to replace the workflow.
A failed push stays failed. The project tool sync spec says it plainly: a rotated API key breaks every future run and the status property tells you it is broken now, it will not replay what already failed. Worse, an endpoint that answers 200 and then rejects the payload in its own response body reads as success unless the code checks the body too. The enrichment spec carries a retry-once variant because a single retry has to be built, not assumed.
It does not wait for an answer a later step can branch on. The external routing spec is built around that fact: webhook out, delay fifteen minutes, then check whether the owner was actually set, with a fallback rotation when it was not. If you need the answer inside the same run, that is a custom coded action reading its own response, not the native action.
What this bundle builds
The moment someone asks to connect a HubSpot workflow to a tool outside the portal, they are really asking two questions that have different answers. Pushing data out is native, gated behind one tier. Pulling an event in is not native at all, and that is where Zapier, Make and n8n earn their place.
These eleven specs cover both halves. The outbound ones page an on call engineer when an SLA breaches, update a card in the project tool the delivery team actually works in, create a customer Slack channel on closed won, pull a usage score from a product API on a schedule, and hand a routing decision to an external service when native rotation runs out of road. The inbound ones start from a property that something outside HubSpot wrote: a failed payment, a first product login, a fresh usage sync, a new session source.
It fits an operations owner with Data Hub who wants the portal to stop being an island, and an agency that keeps rebuilding the same push and the same middleware bridge on every client. Two specs need more than Professional: the multi step enrichment chain and the multi touch attribution one, which sits on Marketing Hub Enterprise.
How the pieces fit together
Build an outbound spec first, and point it at a request inspection endpoint rather than the real vendor. The paging spec and the project tool sync both tell you to do this, and it is the fastest way to see your own payload before anything downstream can reject it. Once the payload is right, swap in the real URL.
The secret comes next, because every spec after the first needs one. Store the key as a workflow secret, not in the code body, then check in settings who can view and edit those secrets. That list is usually wider than the credential deserves.
Chaining comes third. The enrichment spec puts a native webhook and a coded action in one workflow, so build it after each shape has worked alone. Inbound work comes last, because it depends on middleware you have to stand up and monitor separately, and on a property whose name you get to choose. The integration health alert closes the loop: without it, a dead connection is indistinguishable from a quiet week.
What you get
- 11 specs, each with outcome, prerequisites, enrollment, steps, known pitfalls, a test plan and variants
- Each spec ships as PDF and Markdown
- Properties JSON, 30 properties across contacts, companies, deals and tickets, plus one custom object
- Workflow JSON for all 11, in Automation API format, switched off on import
- 7 custom coded actions as JavaScript files, with inputs, outputs and secret names in the header
- The payload field list per spec, so the middleware mapping is written before you open Zapier, Make or n8n
- A test plan per spec, each starting at a request inspection endpoint rather than the live vendor
- Install in one click for Full and Agency buyers
Who it is for, and who should skip it
Take this if you have Operations Hub Professional or Enterprise and something outside the portal needs to hear about a record change, or if a vendor keeps pushing events at you and you have nowhere to put them. The paging and project tool specs pay for themselves in the first hour.
Skip it if you are on Service or Sales Hub Professional alone. The native webhook action is not in your action picker and no spec here works around that. Skip it too if a maintained native connector already exists for your tool, which the project tool spec says outright: a connector someone else keeps current usually beats a custom push you now own forever.
Questions admins ask
Does sending a webhook from a HubSpot workflow need Operations Hub Professional?
Yes, and this is the tier boundary people get wrong most often. The SLA paging spec calls it out: an outbound webhook is an Operations Hub Professional capability, now sold as Data Hub, and Service Hub Professional alone does not include it. The same tier unlocks the custom code action, which is the fallback whenever the native action cannot set the headers a vendor requires. Chaining a webhook and a coded action in one workflow may need Enterprise, which the enrichment spec flags to verify on your own portal.
Can an incoming webhook trigger a HubSpot workflow?
Not directly. Point the external system at Zapier, Make, n8n or a small serverless function instead, and have that write a property on the contact or company through a private app. The workflow then enrolls on that property change like any other. The billing signal spec documents this path end to end, including the alternative of calling the Custom Events API and enrolling on a custom behavioral event.
Do you ship Zapier or n8n templates with these specs?
No. Every spec here documents the HubSpot side: the trigger, the payload fields, the properties, the guard against duplicates and the failure branch. The middleware scenario is described in words, with the field mapping it needs, and you build it in whichever tool you already pay for. An n8n template is planned as a companion download. Nothing for Zapier or Make is planned yet.
Does HubSpot retry a webhook that fails?
Do not count on it. Every spec in this collection treats a failure as something you detect and route, not something the platform repairs. Each one writes a sync status property and branches to a task or an internal notification on error, so a broken integration is visible on the record instead of buried in workflow history. The usage API spec adds the other half of the discipline: watch the last synced timestamp, because a stalled sync leaves the old value sitting there looking current.
Why can my custom code action not read the webhook response?
This is a known complaint on the developer forums: webhook properties show as unavailable inside a custom code action, and the usual fix is to insert a Format data step between the two so the value becomes selectable. Treat it as behaviour to confirm on your portal before you design a two-step chain around it. The enrichment spec sidesteps the question by branching on the webhook result first, then handing the parsing to code.