Lovable / AI agents

Build a blog on your website with Lovable or another AI coding tool, then let outwrite.ai send finished articles to it. You copy three prompts from this page into your tool, and it does the technical work. The result is your own branded blog at /blog, with a permanent page for each article at /blog/{slug}. Available in Simple and Pro.

What this is and who it's for

This guide is for you if your website was built with an AI coding tool such as Lovable, Cursor, Claude Code, Codex or Bolt, and you'd like outwrite.ai articles to appear on it.

In plain words, three things happen:

1. Your AI tool builds the blog pages. It adds a blog list and article pages that match your site's design.
2. Your AI tool builds a private "mailbox" for articles. This is a receiver: a secure web address on your site that accepts articles from outwrite.ai and nothing else. It checks a shared secret on every request.
3. You connect that mailbox in outwrite.ai. You paste its address into the Webhook integration and copy a secret back to your site.

There's no separate Lovable app to install. This is a guided setup for the Webhook integration. You don't need to write code or download files, but you'll paste a few settings into your tool's secure settings screen.

If your site runs on WordPress, Shopify, Wix, Ghost, Webflow or Framer, use that platform's guide instead.

Why it helps

• You get a real blog on your own domain, styled like the rest of your site, with articles that search engines and AI tools can read.
• Articles arrive with their cover image, alt text, tags, search description and language.
• Drafts stay private, and updating an article keeps its web address.
• outwrite.ai confirms each published article by checking its public page, so you know it really went live.

Before you start

• Your website project open in Lovable, Cursor, Claude Code, Codex, Bolt or a similar tool, with access to its backend and deployment (publishing) tools.
• About 30 minutes, most of which is your tool working.
• An active outwrite.ai trial or subscription.
• If you manage several brands, select the right one in outwrite.ai first. Each brand has its own connections and its own workspace ID.

Use the Copy prompt button on each prompt below. It copies the prompt plus the current technical reference, so your tool doesn't need to sign in to outwrite.ai. No account secrets are included.

Set it up

1. Create your blog pages

Open your website project and paste this prompt. Your tool will match your site's design and set up the pages, storage and search information. It should work with your existing site rather than replace it.

Add a production-ready blog to my existing website, powered by outwrite.ai. Preserve the site's design and existing pages. Inspect the framework, router and hosting before making changes; use their native conventions.

Build /blog and /blog/{slug}. Use clean, permanent article URLs. Never create new ?slug= links. If this site already serves /blog?slug= links, keep them working with a 200 response and a canonical link to /blog/{slug}. In a TanStack file-router project, make article pages standalone instead of accidentally nesting them inside the index; do not assume a file naming convention without checking this project's router.

/blog: show published articles newest first with cover images, title, description, tags and publication date. Add accessible pagination when needed and an honest empty state. Link Blog from the site's navigation.

Article pages: use comfortable typography, a readable content width, responsive cover image and alt text, publication and update dates, tags, breadcrumbs, and the complete article. Preserve headings, tables, lists, citations, links and photo attribution. Show author details only when supplied. Use one main page heading. Include a table of contents when useful. Make tables and code readable on phones.

Store published articles separately from private draft revisions and delivery receipts. Public visitors may read published content only and may never write to storage. Do not expose secrets or service credentials in the browser. Preserve an existing live article when a draft update arrives.

Return article content and article-specific title, description, canonical URL, Open Graph/social image and accurate BlogPosting structured data in the initial HTML, using this project's SSR or prerendering. Keep the index and published articles in the sitemap. Keep drafts out of public queries, routes and sitemaps. A missing article must return 404, not a successful empty app shell. Do not create a separate public HTML Edge Function unless this hosting setup actually requires it.

Do not create fake published articles. Use private local fixtures for testing. Next I will give you the outwrite.ai receiver prompt.

2. Create the connection

Paste the next prompt into the same project. Your tool will build and deploy the private receiver and give you its HTTPS address. Until the secret is added, the receiver stays closed and refuses all requests.

Before you paste it, get your workspace ID: in outwrite.ai, open the Webhook card on the integrations page (see step 3 below) and, next to Workspace ID at the bottom, select Copy. You can also find it in the workspace menu at the top of the left sidebar. After pasting the prompt into your tool, replace COPY_WORKSPACE_ID_FROM_OUTWRITE with your workspace ID before sending it. If you forget, your tool will ask you for it.

Connect this blog to outwrite.ai. Build and deploy a server-side POST endpoint named outwrite-webhook using this project's backend. For Supabase, use an Edge Function with verify_jwt=false for this function only, and still require the webhook secret below.

Read the implementation contract at https://outwrite.ai/integrations/ai-agents/contract.md. It includes public reference code you can read directly; do not ask me to download or upload an archive. Adapt it to this project's stack and preserve its storage and delivery guarantees.

Server settings:
- OUTWRITE_WEBHOOK_SECRET: I will copy this from outwrite.ai after saving your endpoint URL. Ask me to enter it through the platform's secure secrets UI, not in chat or frontend code.
- OUTWRITE_BRAND_ID: COPY_WORKSPACE_ID_FROM_OUTWRITE. If this is still a placeholder, ask me to use Copy workspace ID in outwrite.ai's Webhook integration (Auto Blog → Integrations in Pro, or Publishing settings → Connect or manage your website in Simple).
- OUTWRITE_BLOG_URL: this site's real public URL ending in /blog, for example https://mywebsite.com/blog.
Keep the endpoint closed until its required settings exist. Return its deployed HTTPS URL so I can save it in outwrite.ai, then finish entering the secret. Never invent credentials.

Only accept POST. Compare X-Outwrite-Secret with the server secret safely; reject missing or incorrect values. Bound request sizes and validate the complete article v2 contract and workspace ID. An authenticated is_test:true, is_draft:true request must return success without storing any article or receipt.

The payload includes schema_version:2, id, brand_id, content_id, title, slug, content (HTML), content_markdown, tags, metadescription, thumbnail, thumbnail_alt_text, featured_image_credit, keyword_seed, language_code, campaign_id, campaign_name, batch_id, publisher and optional author metadata, timestamps, operation_id, revision and is_draft. Optional metadata can be null; do not invent it.

Use stable article id as the article key and operation_id for delivery deduplication. In one transaction, serialize concurrent deliveries for the article, reject older or conflicting revisions, preserve the first public slug, save the correct private draft or public revision, and save its exact receipt. An identical retry must return its saved receipt without creating another article. Reusing an operation ID for different content must fail. Never let a draft update overwrite the live revision. Keep callback tokens and delivery receipts private, outside public article data and logs.

Store exact title and HTML; sanitize HTML at render time with a real parser. Compute content_hash as lowercase SHA-256 of UTF-8(title), one zero byte, then UTF-8(content). After the transaction commits, return JSON with operation_id, revision, content_hash, remote_id (article id), and status:"remote_draft" for a draft, or status:"published" plus the absolute /blog/{stable-slug} URL for a live article. Never return only {url} or report success before storage commits.

For each real public article render <meta name="outwrite-article" content="ARTICLE_ID:REVISION:CONTENT_HASH"> in the initial HTML, matching that saved live revision. Never add it to an app shell, index, draft or missing page. Make new live content available promptly, including cache invalidation if needed.

Finish by showing me the receiver URL and exactly where to enter the three server settings. No downloadable files should be required from me.

Your tool will tell you where the three server settings go. On Supabase, they belong in the receiver's server secrets. A database service key always stays on your server.

3. Connect it in outwrite.ai

1. Open the integrations page. In Pro, go to Auto Blog → Integrations. In Simple, go to Publishing settings and select Connect or manage your website.
2. Click the Webhook card, then Add destination.
3. In Destination name, enter a name such as "My blog". In Webhook URL, paste the receiver address your tool gave you.
4. Click Save connection. New destinations already use the complete article format with authentication turned on.
5. Click Copy secret. Add it to your website's secure server settings as OUTWRITE_WEBHOOK_SECRET. Don't paste it into the AI chat or into your site's public code.
6. Check the other two settings: OUTWRITE_BRAND_ID is your workspace ID, and OUTWRITE_BLOG_URL is your real blog address ending in /blog. The receiver address and the blog address are different: one receives articles, the other is where readers go.
7. Publish (deploy) your website, then click Test connection in outwrite.ai. You should see Connection accepted the test. No article was published. The test must not create an article on your site.

4. Choose how articles reach your blog

1. Choose this destination. In Pro, open Auto Blog → Campaigns, open your campaign, set Publishing destination to it and Save on website as to CMS draft. In Simple, open Publishing settings, set Where should your articles go? to it and Send articles to your CMS as to Drafts.
2. When the first article arrives, check that it's saved privately and doesn't appear on /blog.
3. Switch to Published (Pro) or Published articles (Simple). When the next article goes live, open its /blog/{slug} page.

Connecting the website doesn't start publishing. Your campaign (Pro) or publishing settings (Simple) control that.

5. Have your tool check the finished setup

Paste this final prompt before turning on automatic live publishing. It tests the setup with throwaway records and reports anything that still needs fixing.

Verify this outwrite.ai blog integration end to end, using disposable test records only. Do not publish real content or change unrelated pages without my permission.

Test the authenticated connection check: it must create no article. Wrong or missing secrets and wrong workspace IDs must fail. Public readers must not see draft revisions or delivery receipts and must never be able to write articles.

Test a draft, an authorized live article, an identical retry, two concurrent identical deliveries, reuse of an operation ID with different content, and an older revision. Confirm stable /blog/{slug} URLs, no duplicate articles, and an unchanged live article when a draft update arrives. Test cover/alt, tags, HTML and Markdown, null optional metadata, long titles, slug collisions and unsafe HTML.

On /blog and the article page, inspect desktop and mobile layout, headings, tables, links, photo credit, dates, pagination, canonical URL, description, social image, structured data and sitemap. Verify the real article HTML and its exact outwrite-article marker without executing JavaScript. A nonexistent slug must return 404. Drafts must never have public URLs or sitemap entries.

Check that receipt fields match the stored revision and that outwrite.ai confirms the actual public article after publication. A 200 response alone is not proof. If the host only serves an empty app shell to the checker, fix the project's SSR/prerendering instead of inserting a fake marker. Keep my real articles unchanged. Report the tested page URLs and any remaining limitation.

What your blog receives

Each article arrives with its HTML and Markdown, cover image and alt text, photo credit, tags, search description, language, and campaign details. Updates keep the article's web address. A draft update leaves the live article in place until you publish the new version.

How to tell it's working

If a page is waiting for confirmation

Ask your tool to check the article's page, its saved confirmation and the page's HTML. A success reply from the receiver doesn't prove an article is live. A draft stays private until you publish it.

outwrite.ai reads the article page's HTML without running JavaScript. If your site only fills in its pages with JavaScript, outwrite.ai can't see the article. Newer Lovable projects support server rendering; older ones may behave differently. Ask your tool to check your project's routing and rendering before choosing a fix, and not to add a placeholder marker to an empty page. Lovable's rendering guidance explains the options.

Common questions

Already have a blog?

Ask your tool to connect the receiver to your existing article storage, and to keep your current web addresses and design. Make, Zapier and n8n can use the same webhook reference, but a simple "received" reply isn't a publication confirmation.

I already had a webhook connection before. What changes?

Existing connections keep their current format. Use Advanced settings only if you're upgrading an older receiver. Changing the format or authentication rotates the secret: update it on your website, then reselect the destination in affected campaigns.

Does this import my old blog posts into outwrite.ai?

No. This connection sends new articles to your website. It doesn't read your existing articles. Existing Content needs a supported platform that allows reading and updating posts; see Existing Content.

Can I edit an article after it's published?

Update live post doesn't support webhooks. Edit the article on your site, or ask your tool to add an editing screen.

Where's the technical detail for my developer?

The full implementation reference includes reference code your tool can read online, and the Webhook guide covers the payload, confirmation and API. You don't need to transfer any files yourself.

Related guides

• Webhook
• Connect your tools
• Create and manage campaigns
• Start with Simple