n8n-flow

Generic HubSpot webhook handler in n8n

Difficulty

intermediate

Setup time

45min

For

revops · gtm-engineer

RevOps

Stack

A single n8n workflow that takes every HubSpot Workflows webhook your portal fires, verifies the HMAC v3 signature, deduplicates against a Postgres ledger, routes by event type, and acks fast enough that HubSpot never retries. One handler, one URL, every event your team cares about — replacing the folder of one-off Zaps that nobody trusts and nobody owns.

The architectural centerpiece is not the routing. It is the dedupe ledger. HubSpot retries every 5xx response for up to 24 hours, your handler will go down at some point, and the same event will arrive two or three times. Without a ledger keyed on HubSpot’s eventId, you double-fire Slack notifications, double-create records in your downstream system, and corrupt your pipeline metrics. With a ledger, the second delivery returns zero rows on insert and the flow short-circuits to a 200 OK ack. The bundle at apps/web/public/artifacts/webhook-handler-hubspot-n8n/webhook-handler-hubspot-n8n.json is built around that property; everything else is fan-out wiring.

When to use

You have three or more downstream systems that need to react to HubSpot events (Slack, your warehouse, an internal service, a sync to Zendesk or Salesforce), the events overlap (deal stage changes also create tickets, contact creation also triggers Slack), and you currently have a Zap or HubSpot Operations Hub custom code action per (event × destination) pair. That matrix grows multiplicatively and nobody refactors it. One handler with a Switch node and shared infrastructure (signature verification, dedupe, error capture, replay) cuts the matrix down to one path per event type. You also want this when your downstream systems have rate limits or quotas you need to centrally throttle, because n8n’s per-node retry and queue mode is the right place to put that logic — not spread across ten Zaps.

When NOT to use

If you only have one downstream consumer of HubSpot events, skip n8n entirely and use HubSpot Operations Hub’s custom code action — it runs inside HubSpot’s own retry framework and you don’t have to operate a webhook receiver. If you have strict latency budgets (sub-100ms ack required) and a high-volume use case (>100 events per second sustained), n8n’s webhook node fronted by a single Postgres connection pool will become a bottleneck; reach for AWS Lambda + API Gateway + DynamoDB instead, where the dedupe table is millisecond-latency and the compute is per-request. If your team has zero appetite for operating a small Postgres database, this workflow is a bad fit — the ledger is non-negotiable, and “we’ll just use n8n’s static data” or an in-memory cache will not survive a restart and will silently double-fire events. Finally, if your HubSpot tier is Marketing Hub Free / Sales Hub Starter, you do not have Workflows webhooks at all; the prerequisite is Operations Hub Professional or Enterprise.

Setup

Provision a Postgres instance (or use an existing one). Run the two CREATE TABLE statements from apps/web/public/artifacts/webhook-handler-hubspot-n8n/_README.md — hubspot_event_ledger is the dedupe table; hubspot_unhandled_events parks events with subscription types your Switch doesn’t yet handle.
In your HubSpot developer account, find or create the app whose client secret will sign outbound webhooks. The client secret is the HMAC key — Workflows webhook signing uses it directly. Note the value once; HubSpot will not show it again.
On the n8n instance, set two environment variables: HUBSPOT_CLIENT_SECRET (the value from step 2) and N8N_WEBHOOK_PUBLIC_BASE_URL (the public origin of your n8n install, e.g. https://n8n.example.com — no trailing slash). The Code node reconstructs the signing string against this exact origin, so a mismatch breaks every signature.
Import apps/web/public/artifacts/webhook-handler-hubspot-n8n/webhook-handler-hubspot-n8n.json via Workflows → Import from File. Bind credentials to the two placeholders: Postgres — hubspot-ledger (a Postgres credential pointing at the database from step 1) and Slack — bot token (an httpHeaderAuth credential with Authorization: Bearer xoxb-...).
Activate the workflow. Copy the production webhook URL from the Webhook node and register it on the HubSpot app’s webhook subscriptions page. Subscribe to the specific event types you route on (deal.propertyChange, contact.creation, ticket.propertyChange are the bundled branches; add or remove to match your portal).
Run the four verification cases from the bundle’s _README.md (valid happy-path, invalid signature reject, duplicate event-id skip, unknown subscription type fallback) before any production HubSpot Workflow points at the URL.

What the flow does

The Webhook node accepts POST /webhook/hubspot/events with rawBody: true. The raw bytes are mandatory because HubSpot’s v3 signature is computed over the exact request body — n8n’s default JSON parsing would re-serialize the payload and any whitespace difference would invalidate the signature.

Verify HMAC + Parse is a Code node that does four things in order: rejects requests where the timestamp header is more than 5 minutes off wall-clock (this is the replay window), reconstructs the signing string POST + URI + RAW_BODY + TIMESTAMP, computes HMAC-SHA256(client_secret, signing_string) and base64-encodes it, and compares the result to x-hubspot-signature-v3 in constant time using crypto.timingSafeEqual. On failure it emits a single item flagged __valid: false with a reason string; on success it parses the body and emits one item per event in HubSpot’s batch (HubSpot batches up to 100 events per delivery).

Dedupe Ledger Insert is the idempotency keystone. Every event hits INSERT INTO hubspot_event_ledger (...) VALUES (...) ON CONFLICT (event_id) DO NOTHING RETURNING event_id. A first-time event returns its event_id and proceeds. A duplicate (HubSpot retry, replay attack that somehow passed signature, or your own mis-import of the workflow) returns zero rows. If New Event checks for that empty result and short-circuits to Respond 200 OK without re-firing the downstream branch.

Switch — Event Type keys on subscriptionType. The bundled branches are illustrative — deal.propertyChange posts a Slack message, contact.creation POSTs to an internal API, ticket.propertyChange syncs to a placeholder Zendesk URL. Replace these with your real destinations. The fallback output writes to hubspot_unhandled_events so a HubSpot-side schema change (new event type added to a subscription, new property added to an event payload) parks the event for human review instead of failing the whole flow.

Respond 200 OK is the explicit Respond-to-Webhook node — responseMode: "responseNode" on the Webhook node means we control exactly when the ack goes back. We ack after the ledger insert succeeds, not after the downstream branch completes. That trade-off is deliberate: HubSpot considers the event delivered as soon as the ledger has it, and any branch failure is recovered out-of-band by the Error Trigger sub-flow that posts to #alerts-revops plus your own replay tooling reading from hubspot_event_ledger. The alternative (ack only after the branch completes) means a slow downstream API stalls HubSpot’s queue and triggers retries that you then have to dedupe anyway.

Cost reality

n8n self-hosted on a single small VM (2 vCPU / 4GB, ~$20-30/month on Hetzner / DigitalOcean) handles tens of thousands of events per day from one HubSpot portal without breaking a sweat. n8n Cloud’s Starter tier is $24/month for 2,500 executions and gets expensive fast at this volume — if you expect more than ~10k webhook deliveries/month, self-hosted is meaningfully cheaper. Add a small managed Postgres ($15-25/month on Supabase, RDS, or Neon) for the ledger.

The dedupe ledger row size is roughly 2-4KB depending on raw payload size (HubSpot payloads are small — typically ~500 bytes, JSONB compresses well). At 30k events/month with 30-day retention, the table stays under 100MB. At 1M events/month with 30-day retention, you’re at roughly 3-4GB — still trivial for any managed Postgres. The pruning job (one DELETE per day, indexed on received_at) costs nothing measurable.

The hidden cost is downstream API quotas. A schema-drift event that floods your switch fallback can be a surprise; a misconfigured HubSpot Workflow that fires 10,000 events in an hour will burn through any Slack rate limit and most internal API quotas in minutes. Budget for both: per-branch retry caps (the bundle ships tryCount: 5, waitBetweenTries: 1000-2000ms) and a circuit-breaker mindset where your downstream APIs reject 429s back to n8n cleanly so the event stays in the queue rather than being lost.

Success metric

End-to-end latency from HubSpot fire to downstream side-effect under 2 seconds at p95, measured by comparing occurred_at (HubSpot’s timestamp on the event) to your downstream system’s create/update timestamp. A second metric: zero double-fires per quarter, measured as count(*) GROUP BY event_id HAVING count(*) > 1 against your downstream system’s audit log. If you can hit both, the handler is doing its job and you can stop staring at it.

vs alternatives

Versus HubSpot Operations Hub custom code: HubSpot’s custom code actions run in HubSpot’s own retry framework with no infrastructure for you to operate, which is a real win when you have one or two simple destinations. They become painful at three or more destinations because each Workflow has its own custom code copy of your signing/dedupe/routing logic, and you cannot share infrastructure (no shared Postgres ledger, no shared Slack credential rotation, no central error handling). The break-even is roughly 3 destinations or any need for cross-event correlation. Pick HubSpot custom code first; migrate to this n8n handler when you outgrow it.

Versus AWS Lambda + API Gateway + DynamoDB: this is the more scalable architecture (DynamoDB conditional writes are millisecond-latency idempotency, Lambda scales horizontally automatically, API Gateway gives you per-route throttling for free) but it costs you a deployment pipeline, IaC, observability stack, and a team that can debug Lambda cold starts. For a revops team running 10-100k events/month, n8n is simpler to operate, easier to modify (Switch + branch nodes vs. code + redeploy), and the ledger lives in the same Postgres your other ops automations probably already use. Pick Lambda when you cross 100 events/second sustained or when latency matters in single-digit milliseconds.

Versus the Zap-per-event status quo: this is the alternative everyone is actually replacing. Zaps double-fire on retry (Zapier’s dedupe is best-effort and not user-controlled), have no shared signature verification (anyone with a Zap webhook URL can fire fake events), and become impossible to refactor when there are twenty of them. The argument for this n8n workflow is the same argument for any centralized infrastructure: one place to fix the bug, one place to rotate the secret, one place to read the audit log.

Watch-outs

HMAC signature mismatches that pass locally and fail in production. The signing string includes the URI, and the URI must match exactly what HubSpot POSTed to. Set N8N_WEBHOOK_PUBLIC_BASE_URL precisely (no trailing slash, correct scheme, correct port) — the most common production failure is a Cloudflare/load-balancer in front of n8n changing the URL HubSpot sees vs. the URL n8n thinks it has. Guard: log the reconstructed signing string at debug level and compare against HubSpot’s request log when the first signature fails; never enable that log in production beyond debugging.
Replay attacks within the 5-minute window. Signature verification is necessary but not sufficient — a captured signed request can be replayed within the timestamp window. Guard: the dedupe ledger’s event_id PRIMARY KEY makes this a no-op (a replay returns zero rows on insert and short-circuits to ack), but only if event_id is actually a stable, unique identifier per event. Verify with the duplicate-event test case in the README before going live.
Downstream API quota exhaustion under burst. A misconfigured HubSpot Workflow can fire thousands of events per minute. Slack’s chat.postMessage allows roughly 1 message per second per channel; many internal APIs have 100 req/min per token quotas. Guard: per-branch retry caps in the workflow (tryCount: 5, waitBetweenTries) plus n8n queue mode so events back up in the queue rather than failing fast and being lost. For genuinely high-volume branches, swap the direct HTTP node for an SQS/Redis queue write and let a separate consumer drain at quota-respecting speed.
Schema drift on HubSpot’s side. HubSpot adds fields to event payloads and occasionally introduces new subscription types. Guard: the Switch node’s fallback output parks unknown types in hubspot_unhandled_events instead of erroring; downstream branches read propertyName/propertyValue defensively rather than asserting on shape.
n8n worker crashing mid-execution. If the worker dies after the ledger insert but before Respond 200 OK, HubSpot retries because it never got an ack, the second delivery hits the ledger constraint and returns zero rows, and the downstream branch never re-fires. Guard: enable saveExecutionProgress: true (already set in the bundle) and treat the ledger as the source of truth — replay tooling reads hubspot_event_ledger and re-runs branches against parked event payloads, not against HubSpot’s API.

Stack

HubSpot Workflows — event source. Operations Hub Professional or Enterprise required for the webhook action.
n8n (self-hosted recommended) — webhook receiver, signature verifier, router, fan-out. Queue mode strongly recommended for production.
Postgres — dedupe ledger and unhandled-event parking. Any managed Postgres works (Supabase, Neon, RDS, Cloud SQL).
Slack — failure alerts and the example deal-stage branch. Bot token with chat:write.
Downstream systems — your internal APIs, Salesforce, Zendesk, warehouse, whatever the events fan out to.

Edit this page on GitHub

Files in this artifact

Download all (.zip)

# HubSpot webhook handler (n8n)

A single n8n workflow that receives every HubSpot Workflows webhook your portal fires, verifies the HMAC v3 signature against your app's client secret, deduplicates against a Postgres ledger keyed on HubSpot's `eventId`, routes by `subscriptionType`, and acknowledges with a fast `200` so HubSpot stops retrying.

Bundle layout:

```
webhook-handler-hubspot-n8n/
├── webhook-handler-hubspot-n8n.json # n8n workflow export
└── _README.md # this file
```

## What this flow does

The Webhook node accepts `POST /webhook/hubspot/events` with `rawBody` capture enabled — HubSpot Signature v3 signs the exact request bytes, so any re-serialization of the JSON body breaks the comparison.

`Verify HMAC + Parse` is a Code node that reconstructs HubSpot's signing string (`METHOD + URI + RAW_BODY + TIMESTAMP`), HMAC-SHA256s it with your app's client secret from `$env.HUBSPOT_CLIENT_SECRET`, and compares to the `x-hubspot-signature-v3` header in constant time. Requests with stale timestamps (older than 5 minutes) are rejected before any signature math runs, which kills replay attacks. On success it parses the body and emits one item per event in the batch.

`Dedupe Ledger Insert` writes each event's `eventId` into `hubspot_event_ledger` with `INSERT ... ON CONFLICT (event_id) DO NOTHING RETURNING event_id`. A duplicate delivery (HubSpot retries every 5xx for 24 hours, and your handler will have downtime) returns zero rows. `If New Event` then short-circuits the duplicate path straight to a `200 OK` ack — the downstream side effect already ran the first time.

`Switch — Event Type` fans out to one branch per `subscriptionType`. The bundle ships three concrete branches (`deal.propertyChange` → Slack, `contact.creation` → internal API, `ticket.propertyChange` → sync) plus a fallback that parks unknown types in `hubspot_unhandled_events` instead of crashing. Replace the example URLs with your own.

`Respond 200 OK` is a Respond-to-Webhook node — the handler always acks after the ledger insert succeeds, so HubSpot considers the event delivered even if a downstream branch fails. The Error Trigger sub-flow catches branch failures and posts to Slack so you replay them out-of-band, not by stalling HubSpot's queue.

## Import

1. In n8n, open **Workflows** → **Import from File** and select `webhook-handler-hubspot-n8n.json`.
2. Open the workflow's **Settings**. Confirm `Timezone` is set (default `America/New_York` — change to match your business calendar) and `Save execution progress` is on (the partial state is what you replay against on a retry).
3. On the n8n instance, set two environment variables and restart the worker:
- `HUBSPOT_CLIENT_SECRET` — your HubSpot app's client secret (used as the HMAC key).
- `N8N_WEBHOOK_PUBLIC_BASE_URL` — the public origin of the n8n webhook URL, e.g. `https://n8n.example.com`. The signing string is reconstructed against this exact origin; if it differs, every signature fails.
4. Bind credentials to the placeholder IDs (next section), then activate the workflow.
5. In your HubSpot app's webhook settings, register the production URL n8n shows for the Webhook node and subscribe to the event types you actually route on.

## Credentials

### Postgres — hubspot-ledger

Used by `Dedupe Ledger Insert` and `Branch — Unknown Type → Park`.

Required schema (run once before activation):

```sql
CREATE TABLE IF NOT EXISTS hubspot_event_ledger (
event_id TEXT PRIMARY KEY,
subscription_type TEXT NOT NULL,
object_id BIGINT,
portal_id BIGINT,
occurred_at TIMESTAMPTZ,
raw_payload JSONB NOT NULL,
received_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX IF NOT EXISTS hubspot_event_ledger_received_at_idx
ON hubspot_event_ledger (received_at);

CREATE TABLE IF NOT EXISTS hubspot_unhandled_events (
event_id TEXT PRIMARY KEY,
subscription_type TEXT NOT NULL,
raw_payload JSONB NOT NULL,
received_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
```

The `event_id` PRIMARY KEY is the idempotency contract — the entire flow's correctness depends on it being a real unique constraint, not just an index. Plan to prune rows older than your replay window (HubSpot's is 24 hours; we recommend retaining 30 days for audit). A daily `DELETE FROM hubspot_event_ledger WHERE received_at < now() - interval '30 days'` keeps the table well under a gigabyte for typical mid-market portal volume.

### Slack — bot token

Used by `Branch — Deal Stage → Slack` and `Slack — Failure Alert`.

n8n credential type `httpHeaderAuth`. Header name `Authorization`, header value `Bearer xoxb-...`. The token needs `chat:write` and the bot must be invited to the channels named in the JSON bodies (`#revops-pipeline` and `#alerts-revops` by default — rename to your channels).

## First-run verification

The flow's correctness rests on three behaviors. Verify each one before pointing real HubSpot traffic at it.

### 1. Valid signature happy-path

Use HubSpot's built-in **Test** button on the webhook action in your Workflows UI — it sends a real signed payload from HubSpot's edge, which is the only way to exercise the v3 signing path end-to-end (a curl from your laptop won't have the right signing key).

Expected: `200 OK` response, one new row in `hubspot_event_ledger` with the test event's `eventId`, and one message in `#revops-pipeline` (or whichever branch matches the test event type).

### 2. Invalid signature reject

From a shell:

```bash
curl -i -X POST https://n8n.example.com/webhook/hubspot/events \
-H 'content-type: application/json' \
-H 'x-hubspot-signature-v3: AAAAinvalidsignature==' \
-H "x-hubspot-request-timestamp: $(date +%s000)" \
-d '{"eventId":"test-1","subscriptionType":"deal.propertyChange","objectId":1,"portalId":1,"occurredAt":1000}'
```

Expected: `401` with `{"ok":false,"reason":"hmac-mismatch"}`. No row in `hubspot_event_ledger`. No Slack message. If you get a `200`, your signing string reconstruction is wrong — most commonly because `N8N_WEBHOOK_PUBLIC_BASE_URL` doesn't match the URL HubSpot is actually POSTing to (check for `http` vs `https`, trailing slashes, port differences).

### 3. Duplicate event-id skip

Send the same valid signed payload twice (re-trigger the HubSpot test, or replay a captured request through a tool that preserves headers and body bytes exactly).

Expected: both responses are `200 OK`, but `hubspot_event_ledger` shows exactly one row, and the downstream branch (Slack message, internal API call, etc.) fired exactly once. If the side effect ran twice, the ledger insert is not actually constraining on `event_id` — verify the PRIMARY KEY exists and that the Code node is emitting a stable `eventId` value (HubSpot uses the field literally named `eventId` on each event in the array).

### 4. Schema drift fallback

Construct a payload with `subscriptionType: "company.propertyChange"` (or any type your switch doesn't handle) and send it through the HubSpot test path. Expected: `200 OK`, one row in `hubspot_unhandled_events`, no error in the execution log. The flow should never crash on an unknown event type — if it does, the Switch node's fallback wiring is broken.

{
  "name": "HubSpot webhook handler",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "hubspot/events",
        "responseMode": "responseNode",
        "responseCode": 200,
        "options": {
          "rawBody": true,
          "responseHeaders": {
            "entries": [
              { "name": "content-type", "value": "application/json" }
            ]
          }
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000001",
      "name": "Webhook — HubSpot Inbound",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "position": [240, 360],
      "webhookId": "hubspot-events-prod",
      "notesInFlow": true,
      "notes": "POST /hubspot/events. responseMode=responseNode so we ack only after dedupe ledger insert succeeds. rawBody=true is REQUIRED — HMAC v3 signs the exact bytes HubSpot sent, not a re-serialized JSON."
    },
    {
      "parameters": {
        "jsCode": "// HubSpot Signature v3 verification.\n// Reference: https://developers.hubspot.com/docs/api/webhooks/validating-requests\n//\n// v3 signs: METHOD + URI + RAW_BODY + TIMESTAMP\n// Algo: HMAC-SHA256, key = app client secret, output = base64\n// Reject if timestamp is older than 5 minutes (replay window).\n\nconst crypto = require('crypto');\n\nconst clientSecret = $env.HUBSPOT_CLIENT_SECRET;\nif (!clientSecret) {\n  throw new Error('HUBSPOT_CLIENT_SECRET env var not set on the n8n instance');\n}\n\nconst headers = $json.headers || {};\nconst sig = headers['x-hubspot-signature-v3'];\nconst tsHeader = headers['x-hubspot-request-timestamp'];\nconst rawBody = $json.body && typeof $json.body === 'string'\n  ? $json.body\n  : JSON.stringify($json.body || {});\n\nif (!sig || !tsHeader) {\n  return [{ json: { __valid: false, __reason: 'missing-signature-headers', __status: 401 } }];\n}\n\nconst tsMs = Number(tsHeader);\nif (!Number.isFinite(tsMs) || Math.abs(Date.now() - tsMs) > 5 * 60 * 1000) {\n  return [{ json: { __valid: false, __reason: 'timestamp-out-of-window', __status: 401 } }];\n}\n\n// HubSpot Workflows webhooks POST to a fixed path; reconstruct full URL exactly as HubSpot saw it.\nconst publicBaseUrl = $env.N8N_WEBHOOK_PUBLIC_BASE_URL; // e.g. https://n8n.example.com\nconst path = '/webhook/hubspot/events';\nconst uri = `${publicBaseUrl}${path}`;\nconst payload = `POST${uri}${rawBody}${tsHeader}`;\n\nconst expected = crypto\n  .createHmac('sha256', clientSecret)\n  .update(payload, 'utf8')\n  .digest('base64');\n\n// Constant-time compare.\nconst a = Buffer.from(sig);\nconst b = Buffer.from(expected);\nconst valid = a.length === b.length && crypto.timingSafeEqual(a, b);\n\nif (!valid) {\n  return [{ json: { __valid: false, __reason: 'hmac-mismatch', __status: 401 } }];\n}\n\n// Parse the body now that the signature is verified.\nlet parsed;\ntry {\n  parsed = JSON.parse(rawBody);\n} catch (e) {\n  return [{ json: { __valid: false, __reason: 'invalid-json', __status: 400 } }];\n}\n\n// HubSpot batches events; emit one item per event so downstream can route per-event.\nconst events = Array.isArray(parsed) ? parsed : [parsed];\nreturn events.map(ev => ({\n  json: {\n    __valid: true,\n    eventId: String(ev.eventId ?? ev.subscriptionId ?? ''),\n    subscriptionType: ev.subscriptionType,\n    objectId: ev.objectId,\n    portalId: ev.portalId,\n    occurredAt: ev.occurredAt,\n    propertyName: ev.propertyName,\n    propertyValue: ev.propertyValue,\n    changeSource: ev.changeSource,\n    raw: ev,\n  }\n}));\n"
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000002",
      "name": "Verify HMAC + Parse",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [460, 360],
      "notesInFlow": true,
      "notes": "HubSpot Signature v3. Constant-time compare. Rejects timestamps >5min old. rawBody must be the exact bytes HubSpot sent — set rawBody=true on the Webhook node."
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "typeValidation": "strict"
          },
          "conditions": [
            {
              "id": "valid-only",
              "leftValue": "={{ $json.__valid }}",
              "rightValue": true,
              "operator": { "type": "boolean", "operation": "equal" }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000003",
      "name": "If Signature Valid",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [680, 360]
    },
    {
      "parameters": {
        "operation": "executeQuery",
        "query": "INSERT INTO hubspot_event_ledger (event_id, subscription_type, object_id, portal_id, occurred_at, raw_payload, received_at)\nVALUES ($1, $2, $3, $4, to_timestamp($5 / 1000.0), $6::jsonb, now())\nON CONFLICT (event_id) DO NOTHING\nRETURNING event_id;",
        "options": {
          "queryReplacement": "={{ $json.eventId }},{{ $json.subscriptionType }},{{ $json.objectId }},{{ $json.portalId }},{{ $json.occurredAt }},{{ JSON.stringify($json.raw) }}"
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000004",
      "name": "Dedupe Ledger Insert",
      "type": "n8n-nodes-base.postgres",
      "typeVersion": 2.4,
      "position": [900, 280],
      "credentials": {
        "postgres": {
          "id": "PLACEHOLDER_POSTGRES_CRED_ID",
          "name": "Postgres — hubspot-ledger"
        }
      },
      "notesInFlow": true,
      "notes": "Idempotency keystone. UNIQUE INDEX on event_id + ON CONFLICT DO NOTHING means duplicate deliveries return zero rows and skip the rest of the branch."
    },
    {
      "parameters": {
        "conditions": {
          "options": { "typeValidation": "strict" },
          "conditions": [
            {
              "id": "first-time-only",
              "leftValue": "={{ $json.event_id }}",
              "rightValue": "",
              "operator": { "type": "string", "operation": "exists" }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000005",
      "name": "If New Event",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [1120, 280],
      "notesInFlow": true,
      "notes": "Empty result from INSERT means duplicate — short-circuit to OK ack."
    },
    {
      "parameters": {
        "rules": {
          "values": [
            { "conditions": { "options": { "typeValidation": "strict" }, "conditions": [{ "id": "r1", "leftValue": "={{ $('Verify HMAC + Parse').item.json.subscriptionType }}", "rightValue": "deal.propertyChange", "operator": { "type": "string", "operation": "equals" } }], "combinator": "and" }, "outputKey": "deal-stage" },
            { "conditions": { "options": { "typeValidation": "strict" }, "conditions": [{ "id": "r2", "leftValue": "={{ $('Verify HMAC + Parse').item.json.subscriptionType }}", "rightValue": "contact.creation", "operator": { "type": "string", "operation": "equals" } }], "combinator": "and" }, "outputKey": "contact-created" },
            { "conditions": { "options": { "typeValidation": "strict" }, "conditions": [{ "id": "r3", "leftValue": "={{ $('Verify HMAC + Parse').item.json.subscriptionType }}", "rightValue": "ticket.propertyChange", "operator": { "type": "string", "operation": "equals" } }], "combinator": "and" }, "outputKey": "ticket-update" }
          ]
        },
        "options": { "fallbackOutput": "extra" }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000006",
      "name": "Switch — Event Type",
      "type": "n8n-nodes-base.switch",
      "typeVersion": 3.2,
      "position": [1340, 280]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://slack.com/api/chat.postMessage",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "httpHeaderAuth",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "content-type", "value": "application/json" }
          ]
        },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"channel\": \"#revops-pipeline\",\n  \"text\": \"Deal stage change: {{ $('Verify HMAC + Parse').item.json.objectId }} → {{ $('Verify HMAC + Parse').item.json.propertyValue }}\"\n}",
        "options": {
          "retry": { "tryCount": 5, "waitBetweenTries": 1000 }
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000007",
      "name": "Branch — Deal Stage → Slack",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [1560, 160],
      "credentials": {
        "httpHeaderAuth": {
          "id": "PLACEHOLDER_SLACK_CRED_ID",
          "name": "Slack — bot token"
        }
      }
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://hooks.example-internal.com/contacts/created",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "content-type", "value": "application/json" }
          ]
        },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"hubspot_event_id\": \"{{ $('Verify HMAC + Parse').item.json.eventId }}\",\n  \"contact_id\": {{ $('Verify HMAC + Parse').item.json.objectId }},\n  \"portal_id\": {{ $('Verify HMAC + Parse').item.json.portalId }},\n  \"occurred_at\": {{ $('Verify HMAC + Parse').item.json.occurredAt }}\n}",
        "options": {
          "retry": { "tryCount": 5, "waitBetweenTries": 2000 }
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000008",
      "name": "Branch — Contact Created → Internal API",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [1560, 280]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://api.example-zendesk.com/v2/tickets/sync",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "content-type", "value": "application/json" }
          ]
        },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"hubspot_event_id\": \"{{ $('Verify HMAC + Parse').item.json.eventId }}\",\n  \"ticket_id\": {{ $('Verify HMAC + Parse').item.json.objectId }},\n  \"property\": \"{{ $('Verify HMAC + Parse').item.json.propertyName }}\",\n  \"value\": \"{{ $('Verify HMAC + Parse').item.json.propertyValue }}\"\n}",
        "options": {
          "retry": { "tryCount": 5, "waitBetweenTries": 2000 }
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-000000000009",
      "name": "Branch — Ticket Update → Sync",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [1560, 400]
    },
    {
      "parameters": {
        "operation": "executeQuery",
        "query": "INSERT INTO hubspot_unhandled_events (event_id, subscription_type, raw_payload, received_at)\nVALUES ($1, $2, $3::jsonb, now())\nON CONFLICT (event_id) DO NOTHING;",
        "options": {
          "queryReplacement": "={{ $('Verify HMAC + Parse').item.json.eventId }},{{ $('Verify HMAC + Parse').item.json.subscriptionType }},{{ JSON.stringify($('Verify HMAC + Parse').item.json.raw) }}"
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-00000000000a",
      "name": "Branch — Unknown Type → Park",
      "type": "n8n-nodes-base.postgres",
      "typeVersion": 2.4,
      "position": [1560, 520],
      "credentials": {
        "postgres": {
          "id": "PLACEHOLDER_POSTGRES_CRED_ID",
          "name": "Postgres — hubspot-ledger"
        }
      },
      "notesInFlow": true,
      "notes": "Schema-drift guard: park unknown subscription types in a separate table for human review instead of crashing."
    },
    {
      "parameters": {
        "respondWith": "json",
        "responseBody": "={\n  \"ok\": true,\n  \"eventId\": \"{{ $('Verify HMAC + Parse').item.json.eventId }}\"\n}",
        "options": {
          "responseCode": 200
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-00000000000b",
      "name": "Respond 200 OK",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [1780, 360]
    },
    {
      "parameters": {
        "respondWith": "json",
        "responseBody": "={\n  \"ok\": false,\n  \"reason\": \"{{ $json.__reason }}\"\n}",
        "options": {
          "responseCode": "={{ $json.__status || 401 }}"
        }
      },
      "id": "2d2d2d2d-0001-0000-0000-00000000000c",
      "name": "Respond 401 Reject",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [900, 480]
    },
    {
      "parameters": {},
      "id": "2d2d2d2d-0001-0000-0000-00000000000d",
      "name": "On Error",
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [240, 760]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "=https://slack.com/api/chat.postMessage",
        "authentication": "predefinedCredentialType",
        "nodeCredentialType": "httpHeaderAuth",
        "sendHeaders": true,
        "headerParameters": {
          "parameters": [
            { "name": "content-type", "value": "application/json" }
          ]
        },
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={\n  \"channel\": \"#alerts-revops\",\n  \"text\": \":rotating_light: HubSpot webhook handler failure\\n*workflow*: {{ $json.workflow.name }}\\n*node*: {{ $json.execution.lastNodeExecuted }}\\n*error*: {{ $json.execution.error.message }}\\n*executionId*: {{ $json.execution.id }}\"\n}",
        "options": {}
      },
      "id": "2d2d2d2d-0001-0000-0000-00000000000e",
      "name": "Slack — Failure Alert",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [460, 760],
      "credentials": {
        "httpHeaderAuth": {
          "id": "PLACEHOLDER_SLACK_CRED_ID",
          "name": "Slack — bot token"
        }
      }
    }
  ],
  "connections": {
    "Webhook — HubSpot Inbound": {
      "main": [
        [{ "node": "Verify HMAC + Parse", "type": "main", "index": 0 }]
      ]
    },
    "Verify HMAC + Parse": {
      "main": [
        [{ "node": "If Signature Valid", "type": "main", "index": 0 }]
      ]
    },
    "If Signature Valid": {
      "main": [
        [{ "node": "Dedupe Ledger Insert", "type": "main", "index": 0 }],
        [{ "node": "Respond 401 Reject", "type": "main", "index": 0 }]
      ]
    },
    "Dedupe Ledger Insert": {
      "main": [
        [{ "node": "If New Event", "type": "main", "index": 0 }]
      ]
    },
    "If New Event": {
      "main": [
        [{ "node": "Switch — Event Type", "type": "main", "index": 0 }],
        [{ "node": "Respond 200 OK", "type": "main", "index": 0 }]
      ]
    },
    "Switch — Event Type": {
      "main": [
        [{ "node": "Branch — Deal Stage → Slack", "type": "main", "index": 0 }],
        [{ "node": "Branch — Contact Created → Internal API", "type": "main", "index": 0 }],
        [{ "node": "Branch — Ticket Update → Sync", "type": "main", "index": 0 }],
        [{ "node": "Branch — Unknown Type → Park", "type": "main", "index": 0 }]
      ]
    },
    "Branch — Deal Stage → Slack": {
      "main": [
        [{ "node": "Respond 200 OK", "type": "main", "index": 0 }]
      ]
    },
    "Branch — Contact Created → Internal API": {
      "main": [
        [{ "node": "Respond 200 OK", "type": "main", "index": 0 }]
      ]
    },
    "Branch — Ticket Update → Sync": {
      "main": [
        [{ "node": "Respond 200 OK", "type": "main", "index": 0 }]
      ]
    },
    "Branch — Unknown Type → Park": {
      "main": [
        [{ "node": "Respond 200 OK", "type": "main", "index": 0 }]
      ]
    },
    "On Error": {
      "main": [
        [{ "node": "Slack — Failure Alert", "type": "main", "index": 0 }]
      ]
    }
  },
  "active": false,
  "settings": {
    "executionOrder": "v1",
    "timezone": "America/New_York",
    "saveExecutionProgress": true,
    "saveManualExecutions": true,
    "errorWorkflow": ""
  },
  "versionId": "2d2d2d2d-0001-0000-0000-0000000000ff",
  "meta": {
    "templateCreatedBy": "ooligo",
    "instanceId": "ooligo-pilot"
  },
  "id": "webhook-handler-hubspot",
  "tags": [
    { "name": "revops" },
    { "name": "webhook" },
    { "name": "hubspot" }
  ]
}