Publish engine-written articles on your Next.js site

Install with npm install @itmaster/sdk. Then run npx @itmaster/sdk init, which asks yes or no per feature and writes only new files — the shared client at lib/itmaster.ts, a route file for each feature you picked, middleware.ts, and the webhook route. It detects whether your app lives in app or src/app, skips anything that already exists unless you pass --force, and prints the two snippets it refuses to clobber: the root layout head wiring and the blog pages.

It also ensures the env keys in .env.local and .env.example:

• ITMASTER_API_URL — the engine origin, written for you.
• PUBLISH_SITE — your site slug in the engine, written for you.
• PUBLISH_PULL_KEY — the per-site bearer key, left blank because only you should paste it.
• PUBLISH_PUSH_SECRET — added only if you chose the webhook.

So one value is yours to fill in. The generated client starts with an import of server-only, which is what keeps the pull key out of any client bundle. Pass cache with a number of seconds to createClient if you want ISR instead of the default no-store.

Each feed is a one-line route file. The factory returns a plain async handler that proxies the engine's generated output and answers 404 rather than an empty body when a feed is not available.

• app/robots.txt/route.ts — createRobotsRoute serves the robots policy from your dashboard, including the single AI-crawler toggle that flips GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot and the rest of the managed list between allow and disallow.
• app/sitemap.xml/route.ts — createSitemapRoute serves the engine's sitemap, honouring the changefreq, priority and exclude settings.
• app/rss.xml/route.ts — createRssRoute.
• app/llms.txt/route.ts — createLlmsRoute publishes the llms.txt manifest.
• app/api/indexnow-key/route.ts — createIndexNowKeyRoute.

The IndexNow route is worth a note. The key is derived locally from a SHA-256 of a fixed salt and your site id, using exactly the formula the engine uses when it submits, so ownership verifies with no stored secret and no round trip. A middleware rule rewrites any 32-hex .txt request to that route, which is where search engines look for the proof.

Verification tokens, analytics IDs, the default OG image, the Twitter handle, the favicon and the title template live in the engine's site config, not in your repository. The SDK applies them at request time.

In the root layout, fetch config and pass your base metadata through applyMeta. That returns a Next Metadata object with the Google and Yandex verification fields set, Bing and Pinterest under verification.other, OG and Twitter defaults filled and the title template or suffix applied. Analytics are separate: headTagsFromConfig returns script descriptors for GA4, GTM, Plausible, Clarity and Meta Pixel, which you render with next/script.

On an article page, compose the two — applyMeta over articleMetadata gives you the canonical, description, keywords, OG and Twitter cards for that post under the site's own title rules. articleJsonLd returns the engine's authored JSON-LD when the article carries it, and otherwise builds an Article plus FAQPage graph.

One trap the README calls out: do not try to inject tags through a Fragment with dangerouslySetInnerHTML inside head. A Fragment has no DOM node, so nothing reaches the document. Use the Metadata API and next/script.

If your site registers a push URL and secret, the engine POSTs each publish, update or takedown straight to it. createWebhookRoute reads the raw body, verifies the X-Thoth-Signature header — a hex HMAC-SHA256 of that body, compared in constant time — and answers 401 on a bad signature and 400 on malformed JSON before any of your code runs.

After the check it dispatches. Publish and update events go to onUpsert; unpublish, delete and takedown events go to onDelete, as does any article whose status is already unpublished. Then it calls your revalidate closure, which is where you put revalidatePath for the post and the index. That is the whole path from the engine passing its checks to the page being live.

Prefer polling? listArticlesPage returns a page of articles and a next_since cursor, tombstones included, so a mirror can add, update and delete in one pass. Either way, a takedown removes the article from your site rather than leaving an orphan.

The same signature scheme covers createSeoPatchRoute, which lets the engine propose rewritten titles, meta and JSON-LD for pages you already have.

By the time an article reaches your Next.js app it has been through the whole pipeline. Topics come from measured demand — DataForSEO plus your own Search Console queries. Research reads the competing pages, forums and, where it exists, your first-party data. A Claude model writes it. Then four checks run, none of them by the model that wrote it and each including at least one model from a different vendor: fact-check and novelty against the ranking pages led by Gemini and GPT, plus an E-E-A-T critique and AI-tell detection, with up to three revision rounds; see cross-model validation.

Stated as measured, not promised. Across 186 Standard-tier runs, 21% of drafts cleared every check on the first attempt with no revision, and 51% got there within the three revisions allowed; the rest never published. Pro-tier judges are stricter: 25% cleared every check across a small sample of 16 runs.

You pay per published article from a prepaid balance, with no subscription; a draft that fails the checks is not charged. Current rates are on pricing, and the route recipes above are written out in full in the docs.

Not on Next.js? The same engine serves WordPress through a plugin.

The SDK is a convenience, not a requirement, and there are projects it does not suit.

• You are not on Next.js. The route factories, applyMeta and articleMetadata are shaped for the App Router. The core client is framework-agnostic, but if you are on Astro, Remix, Nuxt or a Go service, the REST pull feed is a plainer contract than a package with a Next peer.
• You already have a CMS that owns content. If editors work in Sanity or Contentful and expect articles to be entries they can edit, take the signed webhook and write them into that CMS instead of rendering our records directly.
• Your build is fully static with no revalidation. Articles arrive continuously. A site that only rebuilds when a human runs a deploy will show stale content, so wire the webhook to trigger a build or accept the lag.
• You cannot keep a secret on the server. The pull key must never reach the browser. The generated client imports server-only on its first line so a client component that touches it fails the build, but a purely client-rendered site has nowhere safe to put the key.
• You want the engine to edit pages you wrote. That is a separate, opt-in route (createSeoPatchRoute) that you mount and your handler governs; it is not what installing the package does.

The package pins nothing about your design. If none of the above applies, the honest summary is that it removes about a day of glue code and one class of bug: the authenticated fetch, the feed proxies, the schema builder and the HMAC check.