Publishing Blog Posts and Case Study Pages

Flint turns a finished piece of markdown into a live, on-brand page through a single chat request, so you never rebuild a page layout by hand. Because the template and design are already approved, you skip the design step entirely and focus only on getting your content in. The agent handles the structure: headings, FAQs, lists, and links map onto your template, and the page goes live on your real domain.

For teams publishing regularly, this means content can move from draft to published in one place, using the same repeatable prompt every time, without touching code or fighting a traditional CMS editor. The payoff grows the more you publish: a saved prompt and a consistent content structure make each new post faster and more predictable than the last.

This guide covers publishing blog posts and case study pages using the Flint agent and an existing, approved template.

Who it's for: Anyone publishing content to a section like /blog or /articles who already has a page template in place.

The core idea: You bring finished content in markdown, and Flint builds the page on your template so you're not designing from scratch each time.

Make sure the following are ready before you begin:

• •Have your content ready in markdown (headings, FAQs, lists, and links already structured)
• •Confirm your blog or case study template exists and is approved
• •Decide which section the page lives in (for example /blog or /articles)
• •Optional: keep your publishing prompt saved somewhere reusable so you're not rewriting formatting rules each time

Follow these steps every time you publish a new post:

1. 1.Prepare your markdown so it's clean and final
2. 2.Open the Flint agent
3. 3.Paste your content along with the publishing prompt (see section 4)
4. 4.Tell Flint which template to use and which section to link the page into
5. 5.Let Flint generate the page
6. 6.Review the page (see section 6), then publish to your live domain

Use this copy-paste prompt for every post:

Swap /articles for your own section, and replace the placeholder with your markdown. Save this as a reusable snippet so the formatting rules carry over to every post.

What each instruction does:

• •Links the page into the right section of your site
• •Preserves your heading structure exactly as written
• •Formats FAQ questions as headings rather than paragraph text
• •Keeps bullet and numbered lists as real lists

When you paste your markdown into the publishing prompt, Flint maps each element to your template's styles:

• •Headings: H1, H2, and H3 structure maps to your template's heading styles
• •FAQ sections: Each question renders as a heading, with the answer below it
• •Lists: Bullet and numbered lists render as actual lists
• •Links: Anchor text and destinations attach correctly rather than showing as raw markdown

If any element doesn't render as expected after the initial pass, re-prompt and name the specific element to fix rather than regenerating the whole page.

Before publishing, check the following:

• •Confirm headings follow the right hierarchy (H2s and H3s nested correctly)
• •Confirm FAQ sections show as question-and-answer, not a single block of paragraph text
• •Confirm bullet and numbered lists display as lists
• •Confirm links show readable anchor text, not raw markdown

If something needs adjusting: Re-prompt the agent and name the specific element to fix rather than regenerating the whole page. For example: "The FAQ section on this page is showing as paragraph text instead of headings. Please fix that."

There are two different URLs to be aware of:

• •Preview URL: A staging or share link that lets you review the page before it goes live. Only people with the link can see it.
• •Live URL: The published page on your real domain, visible to everyone.

Always confirm the final live URL after publishing so there's no ambiguity about what's actually live. See the Publishing documentation for details on how to publish your page to your domain.

The more you publish, the more these habits pay off:

• •Save your publishing prompt as a reusable template or custom instruction so you don't repeat formatting rules each time
• •Keep your markdown clean and finalized before pasting to reduce review cycles
• •Reuse the same content structure across posts so results stay predictable

A saved prompt and a consistent content structure make each new post faster and more predictable than the last.

For teams publishing many posts, a few practices help keep things consistent:

• •Keep templates consistent: Avoid modifying the base template between posts unless it's an intentional update. Changes to the template affect every new page you publish from it.
• •Reuse prompts: Store your publishing prompt in a shared doc or snippet manager so the whole team uses the same instructions.
• •Organize content: Keep your markdown files in a consistent folder structure before they come into Flint. This makes it easier to track what's been published and what hasn't.
• •Batch publishing: If you have several posts ready at once, publish them in sequence using the same prompt. Each post takes one chat request.

The same publishing flow can be triggered automatically from tools you already use, rather than pasting markdown into the agent manually. The Flint API lets external systems create and update pages programmatically, which means any tool that can make an API call can kick off the same workflow.

Clay: If your content pipeline runs through Clay, you can use a Clay workflow to call the Flint API once a row is ready. For example, a table of case study drafts in Clay can automatically trigger a new Flint page per row, with the markdown content passed in as part of the API payload. See the Clay personalized outbound guide for a related example of this pattern.

Airtable: Airtable automations can watch for a status change (for example, a record moving to "Ready to publish") and fire a webhook to the Flint API. The record's content fields become the page content. This is useful for editorial teams that already use Airtable as a content tracker. See the Airtable page generator guide for setup details.

Claude: If you use Claude or another AI writing tool to draft your content, you can chain it directly to Flint. Claude generates the markdown, then passes it to the Flint API to build the page without any copy-paste step in between. This is useful for teams that want a fully automated draft-to-published pipeline.

In all cases, the output is the same: a page built on your approved template, formatted consistently, and ready for review. The Flint API handles the page creation; you handle the content source and trigger logic in whatever tool fits your workflow. See the Flint API documentation for endpoint details and authentication.

• •Template setup
• •Domain configuration
• •Publishing your pages