Why use Flint for this
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.
The same workflow works whether you publish manually through the Flint agent, or trigger it automatically from an external tool like Airtable, Clay, or any system that can make an API call. This guide covers both.
Step 1: Create your template in Flint
Every page you publish is built on a template. The template defines the layout, sections, and design. Flint fills it with your content, so the structure only needs to be built once.
If you already have an approved page you want to use as a base, you can reference it directly. If not, ask the Flint agent to create one. For example:
Create a template for a case study page where the content will be populated from an Airtable + Flint API integration, as markdown. All content should be placeholder as it will be replaced by the markdown.
This works for any content type: blog posts, case studies, articles, or landing pages. The key is that all content in the template is placeholder text that will be replaced when you publish.
Step 2: Prepare your markdown
Before publishing, make sure your content is clean and finalized in markdown:
- •Structure headings correctly (H1 for the title, H2 for main sections, H3 for subsections)
- •Format FAQ questions as headings so they render as expandable or structured entries
- •Use standard bullet and numbered lists for any list content
- •Include full URLs for any links
Flint maps each markdown element directly to your template's styles, so the cleaner the input, the less you need to review afterward.
Step 3a: Publish via the Flint agent
Open the Flint agent and paste your markdown along with this prompt:
Please create a new blog post that is linked in /articles with the exact text pasted after the instructions. Please make sure all of the headings render out as they are in the markdown. Specifically, FAQs should have the questions as headings exactly like it is in the markdown. And then make sure all lists or bullet points in the markdown render out as actual lists and bullet points: "<INSERT ARTICLE MARKDOWN>"
Swap /articles for your own section path, and replace the placeholder with your markdown. Save this prompt as a reusable snippet so you don't rewrite the formatting rules each time.
What each instruction does:
- •Links the new 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
Step 3b: Publish via Airtable or any external tool
Instead of pasting manually, the same publish action can be triggered automatically from any tool that can make an HTTP request. The Flint API accepts a page slug, markdown content, and metadata, then builds the page on your template without any manual step.
Airtable: Set up an automation that watches for a status change (for example, a record moving to "Ready to publish") and fires a webhook to the Flint API. The record's content fields become the page content. See the Airtable page generator guide for setup details.
Clay: A table of content drafts in Clay can automatically trigger a new Flint page per row, with the markdown passed as part of the API payload. See the Clay personalized outbound guide for a related example.
Claude or other AI tools: If you use an AI tool to draft content, you can chain it directly to Flint. The AI generates the markdown, then passes it to the Flint API to build the page with no copy-paste step in between.
The same pattern applies to Make, Zapier, n8n, or any custom script. See the Flint API documentation for endpoint details and authentication.
Step 4: Review before publishing
Whether you published manually or via automation, check the following before making the page live:
- •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. For example: "The FAQ section on this page is showing as paragraph text instead of headings. Please fix that." Fix elements one at a time rather than regenerating the whole page.
There are two URLs to be aware of:
- •Preview URL: A staging link visible only to people with the link. Use this for review.
- •Live URL: The published page on your real domain, visible to everyone.
See the Publishing documentation for details on how to push to your domain.
Step 5: The published page
Once approved, publish to your live domain. The page is built on your template, formatted from your markdown, and live at the URL you specified.
Tips for speed and consistency
The more you publish, the more these habits pay off:
- •Save your publishing prompt as a reusable snippet so you don't rewrite 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
- •Keep templates consistent: Avoid modifying the base template between posts unless it's an intentional update. Changes to the template affect every new page published from it.
- •Batch publishing: If you have several posts ready at once, publish them in sequence. Each post takes one chat request or one API call.
