Your stack, your database, your URLs. Hoxigen sends each article as one signed JSON request and your endpoint decides what to do with it.
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 connector holds the full receiver 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.
The same steps the connect screen walks you through, so you can see the whole of it before you sign up for anything.
Hoxigen issues a signing secret and shows it once. Copy it then — afterwards it is masked and cannot be shown again.
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.
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.
A Version 1 receiver publishes new articles. Version 2 adds lookup and update, which is what makes refreshes possible. The connector shows which one you have and the instructions for the other.
Field by field, so nothing arrives as a surprise.
content_html and content_markdown, so a Markdown-based site does not have to parse HTML back out.
id, title, slug, meta_description, focus_keyword, featured_image_url, tags, author and published_at.
Deterministic Article and Organization schema as a json_ld string, keeping any FAQ block the article generated. Put it in the page head.
X-Hoxigen-Signature (sha256 of the raw body), X-Hoxigen-Event, X-Hoxigen-Timestamp, and X-Hoxigen-Contract on Version 2 requests.
Off by default. When on, the delivered body carries small tracking markup in both HTML and Markdown so Hoxigen can estimate article views.
Only on a Version 2 receiver — and then in place, at the same URL.
A Version 2 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 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. It is rolling out to accounts gradually; publishing new articles is not gated on it.
You would find these out in week two anyway. Here they are in week zero.
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.
A Version 1 receiver publishes new articles only. Implementing lookup and update — including the conflict case — is what unlocks refresh-in-place.
HTTP or HTTPS, no redirects on updates, a response inside thirty seconds, and a body under a megabyte. Localhost and VPN-only hosts cannot be delivered to.
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.
Drafts land in your queue with their images, meta description, FAQ schema and internal links. You can edit, approve or reject each one. Ignore the queue and it publishes on schedule anyway — that is the point of an autopilot.
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.
Each connector verifies its credentials against the real API — a signed test request, a token exchange, a collection read — before Hoxigen saves anything. A connector that cannot publish says so on the day you connect it, not on the day you expected an article.
Connectors are probed on their own schedule. An expired token, a revoked scope or a key that no longer does what publishing needs flips the connector to Reconnect and tells the seats that asked for alerts.
Our own plugin turns your site into a signed receiver. Articles arrive as posts and refresh at the same permalink.
Publishes to your store's blog through the Admin API, on your own domain, with the product-adjacent content Shopify stores rarely get around to writing.
Publishes to your Wix blog with an API key you generate, converting each article into Wix's own rich content format.
Publishes live CMS items into the blog collection you choose, mapping your existing fields instead of demanding new ones.
Connect Any site, by signed webhook when you like what you read — nothing publishes before that.