AI blog drafts published to the site, with an API and without one
Five Make scenarios, from two builds, turn an Airtable content calendar into published blog posts. OpenAI drafts the article and handles the images, a person approves in Airtable, and the post is published through the site's API or, where the CMS has none, by fetching its admin form and submitting it as a browser would. One build also posts a LinkedIn teaser.
Where this applies
Small marketing teams and site owners who want a steady blog from a content calendar, on a site with a content API or without one.
- scenarios across two builds
- 5
- ways to publish: API and form replay
- 2
- approval drives the site post and the LinkedIn post
- 1
The problem
A blog run from a content calendar needs the same steps every time: draft, image, review, publish, announce. Doing them by hand is why most company blogs stop after a few posts.
The publish step is where automation usually stops. Some site builders have a content API that needs images imported before a post can use them; some admin panels have no API at all, only a form that a person fills in.
What we built
Drafts with their images
In the first build, a scheduled scenario picks queued topics from the calendar, aggregates their source material into one prompt, has OpenAI write the article and saves it to the record, then iterates the images and has Vision describe each one, so the alt text comes from the picture. The second build writes the article, generates a cover image, parses the result and creates the record for review.
Media before the draft
For the site with an API, the draft scenario imports each image into the site's media library first, has a completion format the body, and creates the blog draft through the API, so the draft refers to images the site already hosts. The record is marked as drafted, and an error handler keeps one bad post from holding up the rest.
Publish and announce from one approval
On the publish date, a router on the approved record does two things: one route publishes the draft through the API and stamps the record; the other has a completion write a short LinkedIn post about the article and posts it to the company page.
Publishing where there is no API
For the CMS without an API, the publish scenario requests the admin panel's add-post form, pulls the hidden form fields out of the HTML with two pattern matches, downloads the cover image and posts a multipart form exactly as the browser would, then marks the record as published. Each of the three HTTP calls has its own error handler.
The outcome
Both builds are switched off. The API build was made in August and September 2025, the form-replay build in December 2024.
Neither has a run in the period Make's history still holds, so this page describes the design rather than a volume.
Where it stops
Replaying an admin form depends on the form's markup: if the CMS renames its fields or changes the page, the pattern matches fail and nothing is published. The scenarios publish what was approved and do not check the article for accuracy. Both builds are switched off. A standalone LinkedIn scenario that repeats the publish step's second route, and an earlier combined prototype, are not described.
Built with
- Make.com
- Airtable
- OpenAI
- Wix API
- HTTP
Patterns used
- Import media first
- Form replay where there is no API
- Two AI passes: text, then images
- One approval, two outputs
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no