Publish your AI blog to your own website.
FounderReply generates and stores your SEO articles. Your site pulls the published ones over a single read API and renders them on your domain — with the schema.org structured data already attached. No webhooks to maintain, no scheduler to babysit.
# list your published posts
curl https://founderreply.com/api/public/blog?workspace_id=<your-workspace-id>Published content is public by design — no API key, just your workspace id.
The model
A pull, not a push
FounderReply never reaches out to your site. Instead, your site asks for posts when it builds. That keeps your blog fast, statically hosted, and independent — it keeps working even if this app is down between builds. Only posts you've marked published are ever exposed; drafts and archived posts stay private.
Step 1
Get your workspace id
Your workspace id is the key that tells the API whose published posts to return. Copy it from your dashboard URL or settings, and store it as an environment variable on your site — e.g. FOUNDERREPLY_WORKSPACE_ID. It is an unguessable identifier and only ever surfaces public, published content.
Step 2
Receive your posts
Two endpoints. The list gives you every published post (bodies omitted) so you can build an index and routes. The detail gives you one full article by slug, with the markdown body and ready-to-embed JSON-LD.
GET /api/public/blog?workspace_id=…
{
"ok": true,
"posts": [
{ "slug", "title", "type", "keywords",
"meta_description", "cover_image_url",
"created_at" }, …
]
}GET /api/public/blog/<slug>?workspace_id=…
{
"ok": true,
"post": {
…all list fields,
"body_markdown": "…",
"json_ld": [ Article, FAQPage? ]
}
}Both responses are CORS-open and edge-cached for ~5 minutes, so they're cheap to call from a build step or directly from the browser. A slug that isn't a published post returns 404.
Step 3
Set the frequency
There's no schedule to configure inside FounderReply — you decide how often your site refreshes by choosing how it pulls. Pick whichever fits your stack:
// app/blog/[slug]/page.tsx
export const revalidate = 300 // secondsStep 4
Render it
Generate a route per slug from the list, fetch the detail for each, render the markdown with your component of choice, and drop the JSON-LD into a script tag for rich results.
// app/blog/[slug]/page.tsx
const WS = process.env.FOUNDERREPLY_WORKSPACE_ID
const BASE = "https://founderreply.com/api/public/blog"
// one route per published slug
export async function generateStaticParams() {
const { posts } = await fetch(`${BASE}?workspace_id=${WS}`).then(r => r.json())
return posts.map((p) => ({ slug: p.slug }))
}
// render one article
export default async function Page({ params }) {
const { slug } = await params
const { post } = await fetch(`${BASE}/${slug}?workspace_id=${WS}`).then(r => r.json())
return (
<article>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{ __html: JSON.stringify(post.json_ld) }}
/>
<Markdown>{post.body_markdown}</Markdown>
</article>
)
}Use any markdown renderer (react-markdown, marked, MDX). The same pattern works in SvelteKit, Nuxt, Astro, or a plain build script — it's just two GET requests.
Going live
One last thing: mark it published
A freshly generated article starts as generated — it won't appear in the public API until you review it and flip it to published in your dashboard. That review step is the gate: nothing reaches your site automatically.