Webhooks

I use blogr.ai to write and publish articles for my website. blogr.ai can deliver every published article to a webhook on my site: blog posts, and the site pages it designs from its topical map (pricing, comparisons, services, locations). Build that webhook receiver in this project. Match the language, framework, and conventions this project already uses.

How blogr.ai delivers:
- An HTTP POST with a JSON body, sent to a public https URL that I will configure in blogr.ai.
- Every request carries my access token in an "Authorization: Bearer" header. Read the expected token from an environment variable or secret store, never hardcode it. I will copy the token from the Webhooks card in blogr.ai.
- Test deliveries carry "test": true with a sample article. Real deliveries carry "test": false.

The JSON body:

{
  "event": "article.published (a blog post) or page.published (a site page)",
  "test": false,
  "article": {
    "id": 123,
    "type": "post or page",
    "title": "Article title",
    "slug": "article-title",
    "path": "null for a post; the site path for a page, e.g. /compare/acme-alternatives/",
    "content_markdown": "Markdown body, no H1...",
    "content_html": "<p>HTML body, no H1...</p>",
    "layout": "article, or sections for a page built as a designed layout",
    "blocks": null,
    "page_html": null,
    "page_css": null,
    "seo": {
      "title": "SEO title, or null",
      "meta_description": "Meta description, or null"
    },
    "og_image_url": "https://... social image, or null",
    "og_image_alt": "Image alt text, or null",
    "target_keyword": "keyword, or null",
    "categories": ["Category"],
    "tags": ["tag"],
    "published_at": "2026-01-01T00:00:00+00:00"
  },
  "website": {
    "domain": "example.com"
  }
}

What the receiver must do:
1. Compare the bearer token against my stored token and respond 401 on a mismatch.
2. Respond 200 to test deliveries ("test": true) without saving anything.
3. For real deliveries, create or update the content on my site from the payload. Match on "article.id" so a repeat delivery updates the existing item instead of duplicating it. When nothing is stored under that id yet, match a post on "article.slug" and a page on "article.path", never a page on its slug: a page's slug is only the last segment of its path, so /services/seo/ and /industries/seo/ share it.
4. A "type" of "post" is a blog post: publish it in the blog as the site already does. A "type" of "page" is a site page: serve it at "path" exactly, outside the blog ("/pricing/" at /pricing, "/compare/acme-alternatives/" at /compare/acme-alternatives), never list it among blog posts, and never overwrite a hand-built route that already exists at that path. Skip the page and respond 200 with the existing URL instead.
5. Give every post and page its SEO tags in the served HTML: the <title> from "seo.title" (fall back to "title"), the meta description from "seo.meta_description", og:image from "og_image_url" with "og_image_alt", and JSON-LD structured data: Article for a post, WebPage for a page.
6. Respond with a 2xx status on success. A JSON response body of {"url": "..."} is optional; when present, blogr.ai saves it as the live URL: https://my-site.com/blog/article-title for a post, https://my-site.com followed by "path" for a page.
7. Respond within 15 seconds: blogr.ai stops waiting after that and treats a timeout, like any non-2xx response, as a failed delivery. Save the content and respond; anything slow (such as rebuilding a large sitemap) must not hold up the response. Only error out when something really failed.

"content_html" is ready to render as-is. "content_markdown" is the same body in Markdown, in case my site renders Markdown itself. Neither contains an H1: the body starts with the introduction and uses H2s for sections, so render "article.title" as the page's <h1> above the body: exactly one H1 per page, and never the title twice.

Section layouts:
- "layout" is "article" for every post and for pages written as one body: render "content_html" as described. It is "sections" for a page built as a designed landing page (pricing, comparison, service pages). Then "blocks" holds its sections, "page_html" the same sections rendered to HTML, and "page_css" the stylesheet for that HTML; all three are null otherwise. Older deliveries may not carry these four fields at all: treat a missing "layout" as "article" and missing "blocks", "page_html", and "page_css" as null, so the same code handles both.
- Render a "sections" page from "blocks.sections", in order, with this project's own templates or components, under the title as the page's only <h1>. Section headings are <h2>, item titles <h3>. Keep "content_html" only as the fallback for search and feeds.
- "blocks" looks like {"version": 1, "sections": [{"type": "hero", "heading": "Pricing", "body": "Plans for every team size.", "items": [], "table": {"columns": [], "rows": []}, "cta": {"label": "Start now", "href": "https://example.com/signup/"}, "secondary_cta": null, "image": null}]}. Every section has those same fields. "body" fields (on the section and on its items) are Markdown; every other field is plain text. "items" entries have title, body, value, and source_url. "cta" and "secondary_cta" are {label, href} or null; "image" is {url, alt} or null.
- By type: hero is the page lead (heading is a short kicker above the lead, never a second <h1>; body is the lead paragraph; cta and secondary_cta are buttons). features is a card grid of items. steps is a numbered sequence of items. stats shows each item's value as a big number, title as its label, body as a note, and links source_url. comparison is a table whose first column holds the criteria and whose second column is this business. pricing is plan cards (title the plan, value the price, body what it includes) with the section's cta under them. proof is quotes (body the quote, title the person, value their role). faq is an accordion (title the question, body the answer). text is a heading with Markdown prose. cta is a closing band with heading, body, and the cta button. Any section may carry an image: show it below the section's content. Skip a section type you do not recognize.
- If building components for this is not practical, output "page_html" as-is below the <h1> and add "page_css" to that page: every rule in it is scoped under .blogr-page, so it never affects the rest of the site.

Make every page reachable. A page nothing links to is one visitors never find and search engines rank poorly, so no page may be reachable only by typing its URL:
1. Directory pages: the parent path of every page must answer (/compare/ for /compare/acme-alternatives/). When blogr.ai delivered a page at that path, it is the hub: render it, then list the pages under it below its body, each as its title linking to its path. When no page sits there yet, serve a generated index at that path listing the pages under it, titled from the path segment ("Compare"). A hub that arrives later takes over the generated index. Leave a hand-built route at a directory path alone.
2. Navigation: link each top-level directory once from the footer or main navigation ("Compare" to /compare/, "Services" to /services/), and single pages such as /pricing/ directly. Build it from the stored content, so a newly delivered page shows up without a code change.
3. Breadcrumbs: show them on every page, built from its path (Home / Compare / Acme alternatives), each crumb linking to the directory page above, with BreadcrumbList JSON-LD.
4. Sitemap: add every post, page, and directory page to the site's sitemap.xml with the time of its latest delivery as the last-modified date, updated on each delivery. If the site has no sitemap, create one at /sitemap.xml and reference it from robots.txt.
5. Links inside the body point at other posts and pages on this site: keep them as they are. blogr.ai re-delivers an older article when it adds a link to a page that went live later, so a repeat delivery must replace the stored body.

When you are done, tell me:
1. The full public URL of the webhook, so I can paste it into the Webhooks card in blogr.ai.
2. Where I paste my access token (the environment variable or secret name).
3. Where pages appear in the navigation, and the URL of the sitemap.