Any site, by signed webhook

Your stack, your database, your URLs. Hoxigen sends each article as one signed JSON request and your endpoint decides what to do with it.

Start your trial See our pricing Read the webhook reference

What connecting it does

This is the oldest and most exercised path in the product, and the one with no platform in the middle. Each article is a single HTTP POST with a JSON body. You verify one header, store what you were sent, and return 200. Nothing about your stack has to change, and nothing about your publishing has to route through anyone's API but your own.

Every request carries X-Hoxigen-Signature, an HMAC-SHA256 of the raw request body computed with a secret unique to your webhook — not shared with any other customer. Verify the signature over the raw bytes before you parse the JSON and an unsigned request cannot cost you anything.

Delivery is durable rather than fire-and-forget: a failed attempt is retried on a widening schedule of one minute, five, thirty, two hours and six hours, and every request carries the article id so your receiver can deduplicate a retry it already handled.

You do not have to write it from a blank page. The full contract is published at /webhook — every header, every payload field, the exact signature algorithm and a receiver you can paste. The connector itself holds the same spec, a working Next.js endpoint to copy, and a prompt you can paste into Claude Code, Cursor or Copilot to have the receiver built against your own codebase.

What it needs from you

The same steps the connect screen walks you through, so you can see the whole of it before you sign up for anything.

1
Create the webhook in Connectors
Hoxigen issues a signing secret and shows it once. Copy it then — afterwards it is masked and cannot be shown again.
2
Build the receiver
Use the spec, the example endpoint, or the AI agent prompt in the connector. All three are in the product; none of them assume a framework.
3
Point Hoxigen at the endpoint
Enter your endpoint's full public URL. Hoxigen sends a signed test request and tells you what came back, including which contract version your endpoint reports.
4
Optionally upgrade
A Version 1 receiver publishes new articles. Version 2 adds lookup and update, which is what makes refreshes possible. Version 3 also returns each article's public URL, so Hoxigen links the article to its live page. The connector shows which one you have and the instructions to upgrade.

What actually gets published

Field by field, so nothing arrives as a surprise.

The article, in both formats

content_html and content_markdown, so a Markdown-based site does not have to parse HTML back out.

Everything around it

id, title, slug, meta_description, focus_keyword, featured_image_url, tags, author and published_at.

JSON-LD, ready to render

Deterministic Article and Organization schema as a json_ld string, keeping any FAQ block the article generated. Put it in the page head.

Signed headers

X-Hoxigen-Signature (sha256 of the raw body), X-Hoxigen-Event, X-Hoxigen-Timestamp, and X-Hoxigen-Contract on test, lookup and update requests.

An optional view pixel

Off by default. When on, the delivered body carries small tracking markup in both HTML and Markdown so Hoxigen can estimate article views.

What happens when an article is refreshed

Only on a Version 2 or 3 receiver — and then in place, at the same URL.

A Version 2 or 3 receiver answers three events: article.published as before, article.lookup, which returns the article living at a given URL with its current revision, and article.updated, which replaces it.

Every update names the target article, the URL it lives at, and the exact revision it was drafted against. A receiver whose article has changed since then answers 409 and Hoxigen treats it as a conflict rather than retrying — a stale base revision never becomes fresh, and retrying would only lock up the draft.

Nothing about updates switches on because a page said so. Hoxigen sends a signed capability test first, and only a receiver that reports Version 2 or 3 with all three capabilities is ever sent a lookup or an update. A Version 1 endpoint keeps publishing new articles, unbothered, until you upgrade it.

Refreshing an article rather than writing a new one is how a page that used to rank keeps ranking.

What it cannot do

You would find these out in week two anyway. Here they are in week zero.

You build and run the receiver

This connector is an interface, not a plugin. Roughly an afternoon by hand, less with the agent prompt, and after that it is code you own and maintain.

Refreshes need Version 2 or later

A Version 1 receiver publishes new articles only. Implementing lookup and update — including the conflict case — is what unlocks refresh-in-place.

Your endpoint has to be publicly reachable

HTTP or HTTPS. Article deliveries must answer within thirty seconds, the connection test and lookup within fifteen; those two and updates refuse redirects. Keep your response under a megabyte. Localhost and VPN-only hosts cannot be delivered to.

Secrets are shown once

The signing secret is masked after connection. Lose it and you reconnect, which issues a new one and means updating it on your side.

Everything on this page describes what the connector does today. Found something that does not match what you see in the product? hello@hoxigen.app — we will correct the page.

How publishing works, whichever you pick

Everything queues before it publishes

Drafts land in your queue with their images, meta description and internal links, plus a short FAQ where readers need one. You can edit, approve or reject each one. Ignore the queue and it publishes on schedule anyway — that is the point of an autopilot. Prefer to sign off first? Set the connector to Approve first.

Every connected destination gets its own article

Connect two blogs and each gets its own article per publishing slot, written for it. Hoxigen does not syndicate one body to several sites and hope search engines pick a winner.

The connection is tested before it is stored

Each connector verifies access against the real API before you save its publishing destination. OAuth sign-in stores the login first; choosing a collection and saving finishes the connection.

A broken credential shows up where you look

A publish that fails keeps the reason on the article and tries again, up to three times. If it still fails, it stops and tells you, so you can reconnect the site and retry it.

Publishing somewhere else

Give it your URL. See what it drafts.

Connect Any site, by signed webhook when you like what you read — nothing publishes before that.

Start your trial