Connect a headless site

A headless destination keeps your published posts in Kitful, and your site reads them through the Blog API. Use it when your site is your own code: a Next.js app, or an app built with an AI builder. Each site has one headless destination. Any plan can connect it and publish by hand, and scheduled publishing and campaigns need an active paid plan.

Connect

1. Open Integrations inside the site.
2. Click Add on Headless.
3. Enter the Blog URL, where posts will live, such as https://example.com/blog. It must be on your site's domain or one of its subdomains.
4. Optionally enter a Notification URL. Kitful posts a signed notification there after every publish, update and delete, so your site refreshes within seconds. For a Next.js site, it is your site's address followed by /api/kitful/revalidate.
5. Click Connect.
6. Copy the Read token. Kitful shows it only now. Keep it on your server or in your builder's secrets, never in browser code.

Then set up your site:

• Next.js: follow Add a blog to a Next.js site.
• Lovable: follow Add a blog to a Lovable app.
• Any other site: read the Blog API. Its sync section shows how a site that keeps its own copy of the posts stays current.

Publish

Pick the destination when you publish an article, in a scheduled slot, or in a campaign. A post's address is the blog URL plus the article's slug, such as https://example.com/blog/plan-a-crm-migration. Kitful refuses to publish an article whose slug another live post on the site already uses: change the slug and publish again.

Update or remove a post

• Update on site in an article's menu sends the article's current version to your site. The post keeps its slug and address.
• An improvement applied from Optimize updates the post the same way.
• Deleting an article in Kitful removes the post from the API, and Kitful notifies your site when it has a notification URL.

Manage the destination

Click Manage on the destination in Integrations.

• Send test sends a test notification and shows how your site answered. The last result stays under the notification URL.
• New token, confirmed with Replace the token?, makes a new read token and a new notification secret, and stops the old ones at once: your site can't read posts or verify notifications until it has the new token.
• The blog URL stays fixed while any post is live, because your site and search engines already know those addresses.
• Disabling the destination stops new publishing and updates. Your site keeps reading the posts already published, and deleting an article still removes its post. Removing the destination also stops its read token.

Troubleshoot

• The test fails with a redirect: save the final URL the redirect points to.
• The test fails with 401: the site is checking the signature with an old token or secret. Copy the current one.
• A post does not appear: check the read token on your site, then press Send test. Without a notification URL, a cached page refreshes on its own schedule.