Connecting a custom webhook to Goji

A custom webhook is the escape hatch. Instead of publishing to somebody else's network, Goji sends each new article as JSON to a URL you control — your own application, an internal tool, or an automation platform such as Make or n8n. If a channel you need does not exist here yet, this is how you build it yourself.

What connecting a webhook gives you

• The whole article, as data. Title, summary, link, picture, tags and timestamps arrive as JSON you can use however you like.
• A signature you can verify. Each request is signed, so your endpoint can prove it came from Goji and not from someone who guessed the URL.
• Any platform. Make, n8n, a Lambda function, a script on your own server — anything that can receive an HTTP POST.
• Retries. A failed delivery is retried rather than silently dropped.

Before you start

You need a URL that accepts a POST request over HTTPS. It must be reachable from the public internet — an address on your own machine, or one behind a VPN, cannot be reached. For local development, a tunnelling tool that gives you a temporary public address works well.

Your endpoint should answer quickly with a 2xx status. Do the real work afterwards rather than while Goji is waiting: a slow endpoint looks like a failed one, and will be retried.

How to connect it

1. Open Channels from the sidebar and choose Custom Webhooks.
2. Paste your endpoint URL.
3. Give the connection a name you will recognise later — worthwhile as soon as you have more than one.
4. Save.

Connect as many as you like; each is a separate channel and can be enabled or disabled on its own, so a broken internal tool never blocks the rest of your publishing.

What arrives at your endpoint

Each delivery is a POST with a JSON body describing one article: its title, summary, canonical link on your own site, image URL, tags and the time it was published. The picture is a URL rather than an upload, so your endpoint fetches it if it needs the bytes.

Treat the payload as data from the network, not as trusted input: validate it, and escape it before rendering it anywhere. The same applies to the image URL — fetch it with a timeout and a size limit.

Verifying the signature

Every request carries a signature header derived from the body and a secret shared with your workspace. Your endpoint should recompute it and compare the two before acting. Two details matter and are easy to get wrong:

• Compute the signature over the raw body, exactly as received — not over a re-encoded version of the parsed JSON, which will differ by whitespace and key order.
• Compare with a timing-safe comparison function, not with a plain equality check.

An endpoint that skips verification will accept anything anyone sends it, which rather defeats the purpose of having the signature.

If something goes wrong

• Nothing arrives. Confirm the URL is publicly reachable over HTTPS and that the channel is included in your publishing rules.
• Deliveries are retried repeatedly. Your endpoint is not answering 2xx quickly enough. Acknowledge first, process afterwards.
• The signature never matches. Almost always because the body was parsed and re-encoded before signing. Capture the raw body.
• It worked and then stopped. Check for an expired certificate on your endpoint — an HTTPS failure looks like an unreachable host.

Common questions

How is this different from Zapier? Zapier is a Catch Hook with Zapier's tooling behind it. This sends to any URL you control and is signed for verification.

Can I use it with Make or n8n? Yes — paste their incoming webhook URL.

Does it send old articles when I connect? No. Delivery starts with the next article your rules pick up.

Can I test it? Point it at any request-inspection service first to see a real payload before writing code against it.