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 judges from a different vendor, Gemini and GPT, run fact-check, novelty against the ranking pages, 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, 51% of drafts passed every check first time; the rest were revised or rejected. Pro-tier judges are stricter: 25% first-pass, 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 at the full rate. 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.