Bloggable can POST a signed JSON payload to any HTTPS endpoint when something happens — a post publishes, autopilot finishes a batch, credits run low. That's enough to drive almost any automation: queue a social post, add a row to a sheet, open a ticket, notify a system that isn't Slack.

An honest note first. Bloggable doesn't have a published app in Zapier's or Make's directory yet, so you won't find us by searching there. You connect with a generic webhook trigger, which takes about a minute and works today.

Setting it up in Bloggable

Same three steps whichever platform you use:

1. Create the webhook on their side and copy the URL it gives you (instructions per platform below).
2. In Bloggable, Integrations → Webhooks in the main nav, press Connect on your platform's row, and paste the URL.
3. Tick the events you want, press Connect, then press Test on the new row.

On connect, Bloggable shows you a signing secret once. Copy it if you plan to verify signatures — you can read it again later from the endpoint's settings, but it never appears in an email or a log.

Zapier

1. Create a new Zap and pick Webhooks by Zapier as the trigger.
2. Choose the Catch Hook event.
3. Zapier shows you a Custom Webhook URL — copy it.
4. Paste it into Bloggable and press Connect, then Test.
5. Back in Zapier, click Test trigger. Your test event appears and Zapier learns the field names.
6. Build the rest of the Zap and publish it.

Watch out for test URLs. Zapier's catch hook URL is live once the Zap is published, but an unpublished Zap can stop accepting requests. If deliveries start failing with 404 after they were working, check the Zap is still on.

Make (formerly Integromat)

1. Create a new scenario and add the Webhooks → Custom webhook module.
2. Click Add, name it, and Save. Make gives you an address — copy it.
3. Paste it into Bloggable, Connect, then Test.
4. In Make, the module should show "Successfully determined." — it has now learned the data structure.
5. Add the modules that do the work, and switch the scenario on.

Make must be listening when you test. The Custom webhook module only captures a structure while it's waiting for data. Press Bloggable's Test while Make shows "Waiting for data".

n8n

1. Add a Webhook node to a new workflow.
2. Set the method to POST and copy the Production URL — not the Test URL.
3. Paste it into Bloggable, Connect, Test.
4. Activate the workflow.

Use the production URL. n8n's test URL only accepts a request while the editor is open and listening, and it expires when you close it. That's the single most common reason a working n8n connection appears to break a day later — Bloggable will tell you it got a 404 and suggest exactly this.

Anything else

Pipedream, a Cloudflare Worker, a Lambda, or fifty lines in your own app. All Bloggable needs is an HTTPS URL that accepts a POST and answers with a 2xx. Non-public addresses are rejected when you add the endpoint — the URL has to be reachable from the internet.

What arrives

A JSON body, flat rather than nested per event, so a Zap or an n8n node can map fields by path without a branch per event type:

{
  "event": "post.published",
  "occurredAt": "2026-01-14T09:03:22.114Z",
  "account": { "id": "…", "name": "Acme" },
  "blog": { "id": "…", "name": "The Acme Blog", "url": "https://blog.acme.com" },
  "post": {
    "id": "…",
    "title": "How we cut onboarding in half",
    "slug": "how-we-cut-onboarding-in-half",
    "url": "https://blog.acme.com/how-we-cut-onboarding-in-half",
    "excerpt": "…",
    "status": "published",
    "publishedAt": "2026-01-14T09:03:21.000Z",
    "tags": ["onboarding", "product"]
  }
}

blog is absent on account-level events like credits.low; post is absent on anything that isn't about one post. Autopilot events carry counts in a data object instead — drafted, scheduled, needsReview.

Headers

Verifying the signature

Optional — Zapier and Make can't easily check it, and plenty of workflows don't need to. Worth doing if the automation writes somewhere it matters.

The signed string is {timestamp}.{raw body}, not the body on its own. That's deliberate: a signature over the body alone stays valid forever, so anyone who captures one request could replay it indefinitely.

const crypto = require('crypto')

function verify(rawBody, headers, secret) {
  const ts = headers['x-bloggable-timestamp']
  // Reject anything older than five minutes — this is what stops replays.
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false

  const expected =
    'sha256=' +
    crypto.createHmac('sha256', secret).update(`${ts}.${rawBody}`, 'utf8').digest('hex')

  return crypto.timingSafeEqual(
    Buffer.from(expected),
    Buffer.from(headers['x-bloggable-signature'] || ''),
  )
}

Two things that quietly break this: verifying a re-serialised object instead of the raw body you received, and comparing with ===, which leaks the expected signature to a patient attacker one byte at a time.

Account-wide or one blog?

An endpoint added in Integrations → Webhooks fires for every blog on the account, now and in future. One added from a blog's settings → Notifications for this blog fires only for that blog. Account-wide endpoints show up on the blog page as read-only rows marked All blogs, so you can see what's already listening before adding another.

Troubleshooting

404 on every delivery. Almost always an expired test URL — n8n's Test URL, or a Zap that isn't published. Use the production URL and re-enable the endpoint.

"Endpoint redirected". Bloggable never follows redirects on a signed delivery, because a redirect would replay the signature against whatever origin it named. Point the endpoint at the final URL.

"Timed out after 5 seconds". Your endpoint has five seconds to answer. Acknowledge with a 200 first and do the work afterwards — most platforms have an async or queued mode for exactly this.

"Stopped after 20 failures". Twenty consecutive failures and Bloggable stops trying, so a dead endpoint doesn't cost every publish five seconds. Fix it, then toggle the row off and on to reset the counter.

Duplicates. Dedupe on X-Bloggable-Idempotency-Key, which stays the same across retries of the same event.

Removing it

Delete the endpoint's row. Deliveries stop immediately, and the signing secret goes with it — reconnecting later issues a new one.