I Built a Content Engine That Creates 21 Social Posts a Week Using the Buffer API
Overview
Publish Plan and schedule your content across social media platforms
Analyze Measure performance and turn insights into growth
Details
Collaborate Work together seamlessly, from planning to publishing
Start Page Build a custom link-in-bio page in minutes
AI Assistant Get help creating, refining, and repurposing content
APIConnect Buffer to your agents, automation tools, or build something entirely new
Creators Grow your community with confidence, not complexity
Small Business A simpler way to manage your small business’ social media
Higher Education Social media management built for schools and universities
Developers Add a social layer for whatever you're building
Blog Real-life stories and resources on growing an engaged audience
Templates Plug-and-play content templates to jump-start your planning
Free Tools Easy-to-use tools to grow your presence across social media
Social Media Insights Data-driven benchmarks, trends, and tips to grow smarter on social
Our Community Learn, connect, and grow with creators around the world
Support Help articles and tutorials to get the most out of Buffer
Developer Docs Connect Buffer to your agents, automation tools, or build something entirely new
I Built a Content Engine That Creates 21 Social Posts a Week Using the Buffer API
I went from impulse-posting to 21 posts a week across three platforms. Here's the automation I built with the Buffer API.
Last year, I built Unstream, a side project that helps music fans find better ways to support the artists they actually love beyond the streaming apps. The first iteration came together over a weekend of vibe coding, but there have been a lot of iterative improvements and refinements that have caused marketing to take a back seat.
My marketing strategy, if you could call it that, was impulse posting. I'd think of something, drop everything to write it, push it to Threads or Instagram, then try to get back to what I was actually doing. It worked occasionally. It wasn't sustainable.
Then I realized I'd been sitting on a content engine the whole time with my database of artists, a log of every feature I'd shipped, and all I had to do was automate the assembly. Here’s how I did it.
When I built Unstream, I ended up with two useful data pools without really thinking of them as content.
The first was a database of indie artists. About a month before I built the automation, I'd added a way for artists to claim and verify their profiles on Unstream. They could curate their own links and confirm their presence on different platforms. One hundred and fourteen artists signed up, giving me a clean, verified list of smaller independent musicians, and every way you can support them directly.
The second was more established artists. I used Claude Code to build a script — originally just for SEO — that pulled from the Wiki Info and Music Brainz APIs to generate pages for musicians at a certain level of prominence. They aren’t quite Taylor Swift-popular, but that second- or third-tier of working artists most people don't realize they can support outside of Spotify. I also filtered out anyone who wasn't active anymore to highlight musicians who actually benefit from that support right now.
If I had to distill the workflow, here's the order it runs in:
Git Hub Actions fires the job on a schedule: every Monday at 9 a.m.
The artist databases and features log supply the raw material
My templates (drafted with Claude Code, following my voice-and-tone guidelines) shape each post
The Buffer API schedules and publishes everything across Instagram, Threads, and Bluesky
⚡ To be clear: Claude didn't write these posts. I built a small set of templates (some with Claude's help) that the automation reuses for every post — closer to a daily syndication of artist and feature updates than AI churning out content.
It's a bit more involved than those four lines, though, so here's everything that goes into running the automation.
Claude Code is what I've been using to build Unstream from the start. It helped me write the scripts that populated my artist databases, and it helped me build the Type Script automation that assembles the posts from my templates. It was the natural choice because I was already working in it every day, so there was no context-switching involved.
The Buffer API is how I schedule and publish posts. Once the automation generates a week of content, it pushes everything to Buffer, which handles the publishing across Instagram, Threads, and Bluesky. The API also lets me do platform-specific things, like adding Threads posts to the Music topic and appending hashtags on Instagram and Bluesky, without having to manually adjust each post.
Git Hub Actions is where the job runs. I have one action — "schedule weekly social posts" — that fires every Monday at 9 a.m. It calculates the upcoming calendar week, runs the Type Script script, and that's it. No need for a manual trigger means there's no scheduled task I need to revisit.
i A Writer, a distraction-free text editor, is where I do spot-checks. All the generated posts and the upcoming schedule are stored as Markdown files in the repo, so I can pull them up in i A Writer whenever I want to review what's going out. It's not a required step since the system runs fine without me looking, but it's nice to have a window into it.
Music Brainz is the large music database I use to populate platform links and artist data for the more established artists. It's one of the APIs that powers Unstream's search, so the content pipeline is pulling from the same data source the product itself uses.
Inside the automation that generates 21 posts each week
Every Monday at 9 a.m., Git Hub Actions fires the script. Then:
The Type Script script starts by selecting six artists: three from the verified indie pool and three from the established artist pages. Indie artists come from the 114 musicians who’ve claimed their Unstream profiles. Established artists come from the Wiki Info and Music Brainz-generated pool.
Each artist gets flagged as “promoted” once they’ve been featured. They won’t appear again until every artist in the pool has had a turn. This is one of the details that make the system work in the long term. More on that in a bit.
The six artists get organized into a seven-day schedule, one post per day. Indie and established artists alternate every other day for variety. The seventh day is reserved for a feature spotlight, pulled from my shipped features file.
This runs across three platforms: Instagram, Threads, and Bluesky — for a total of 21 posts per week. It’s the same content calendar, adapted for each platform.
This is where the Type Script (code written in plain text) file does the heavy lifting. For each post, it handles the business logic: pulling the artist’s Instagram handle if they have one, listing the platform names where you can support them, and generating copy from a set of standard post templates.
The copy varies based on the type of artist. For indie artists, the angle is exposure and awareness (check out this artist, here’s how you can support them). For established artists, it’s more like, “That artist you love on Spotify? You can support them better through these platforms”. Feature posts are straightforward — what’s new and why it matters.
Artist photos get pulled automatically, either from the artist’s verified page on Unstream or from the same search API that powers the platform itself. Hashtags get applied in the code for Instagram and Bluesky. Threads posts get added to the Music topic.
To give you a sense of the range: my upcoming queue right now includes Neccos for Breakfast (a friend of mine from Threads), Steve Reich (a composer I very much love), and Bear Mc Creary (who has scored a bunch of sci-fi TV shows). It’s pulling from all over the place, which is exactly the point.
At the end of the script, all the generated content is written and scheduled through the Buffer API. Posts land in my Buffer queue at 9 a.m. daily across all three platforms.
The result: I open Buffer and see a full week of content, ready to go.
This is the part that makes the system sustainable, rather than something that runs out of steam after a few weeks.
Every artist gets flagged as promoted once they’ve been featured. The system won’t pick them again until every other artist in the pool has had a turn. Once everyone’s been covered, the whole list resets and the cycle starts over.
Features work the same way. Each entry in the shipped features file has a true/false "announced" tracker. It flips to true once that feature has been posted about. When everything’s been announced, the whole list resets to false, and we go again.
The nice thing about this approach is that the system naturally expands. As more indie artists verify their profiles and more features ship, the content pool grows without any extra work from me. I don’t need to feed it new material — the product growth feeds the content engine.
One thing I knew from the start: if the posts sounded like generic AI, this whole thing would be pointless. Consistency only matters to me if the content actually sounds like it came from someone who cares about what they're saying.
So before I wrote a single template, I spent time teaching Claude how I actually talk. I did it in a few steps:
First, I had it trained on my entire back catalog of published blog posts. They live at bgreen.lol, but I keep local copies as Markdown files, so I pointed Claude at those to get a feel for how I write long-form.
Then I pulled my last 50 Threads posts using an alpha version of the Buffer API. Blog posts and Threads posts are different animals — the blog shows how I think, but Threads shows how I write short. Since the social posts were going to be short, that second sample mattered just as much.
From there, I had Claude study the tone across both, with a few instructions: stick to the talking points I cared about, and bias toward my Threads voice and shorter lengths, since these were meant to be quick posts, not essays.
All of that became a voice-and-tone.md file — a set of guidelines describing how I talk about music, artists, and Unstream. Claude then proposed the boilerplate templates, and I made a few manual tweaks to get them exactly to my liking.
The templates give the posts structure, but the voice guidelines are what give them personality. They're what make the difference between a post that reads like a press release and one that sounds like me sharing something I'm genuinely excited about.
Each post gets a handful of likes and reposts, and Threads posts land somewhere between a few dozen and a few hundred views. But it’s OK because I have a different goal for my workflow.
I went from posting impulsively whenever I remembered to posting 21 times a week across three platforms, all without touching my workflow. Consistency was always Step 0, as you can't grow anything organically on social if you're not showing up. Now I'm showing up every day across three platforms without it costing me the time I need to actually build the product.
The system is also getting better on its own. Every artist who verifies their profile and every feature I ship expands the content pool without any extra work, so the pipeline and the product are growing together.
Next up: I'm thinking about expanding to Tik Tok and posting artist photos there. Adding a new platform is mostly just adding another API call, so it should be fairly straightforward.
What you can steal from this, even if your stack looks nothing like mine
My setup is specific to my project, which is to be expected, but the underlying approach works for anyone who’s building something and struggling to market it consistently. Here’s what can apply to most situations:
You probably already have your content. I started with a database I’d already built for product reasons. If you work with any sort of structured data — a list of customers, projects, testimonials, features you’ve shipped, partners you work with — you already have the raw material for a content engine. You just might not be thinking of it that way yet.
The two-bucket approach keeps things interesting. I alternate between content that promotes other people (the artists) and content that promotes my product (the features). That balance is what makes it feel like a feed worth following instead of a billboard.
If you’re a freelancer, one bucket could be client wins, and the other could be things you’ve learned. If you’re running social for a Saa S company, one bucket is customer stories, and the other is product updates.
Deduplication is what makes it sustainable. Without the tracking logic that prevents repeats and cycles through the full pool, this system would have run out of steam in a few weeks. That’s the difference between a one-time batch of content and an engine that keeps running.
Voice guidelines are non-negotiable. If you’re using AI to draft content, the voice file is the single most important piece. Without it, you get generic posts that could belong to anyone. With it, you get content that sounds like a real person with real opinions.
Start with “good enough.” My engagement numbers aren’t super impressive and I’m OK with that. I went from zero consistency to daily posts across three platforms, and the system gets better as my content pool grows.
If you're taking Buffer's API for a spin, we've got resources to get you moving. Our developer docs cover the Graph QL schema, auth flow, and quick-start examples. The Buffer MCP server docs walk through plugging it into Claude or any MCP-compatible AI agent.
If you need hands-on help, our support team is around, or you can join our Discord server and chat to other people building with the API.
We'd love to hear about what you make. Find us in our Discord server, or @buffer on all major social channels.
200,000+ creators, small businesses, and marketers use Buffer to grow their audiences every month.
I Had 1,000+ Pokémon Cards to Sell — So I Built an App That Lists Them in My Store and Promotes Them via Buffer
How the Engineer Behind Coding Kitty Built a Full Video Publishing Engine on Buffer's API
A full-stack developer who builds everything himself chose Buffer's API over three platform integrations. Here's how the developer behind coding.kitty automated his publishing.
We Built a Custom Workflow with the Buffer API — and Tripled Our X Impressions
Needing a fresh coat of paint on an important workflow, Anthony built a custom workflow for QAJobs using the Buffer API.
200,000+ people like you use Buffer to build their brand on social media every month
Key Takeaways
- Publish Plan and schedule your content across social media platforms
- Analyze Measure performance and turn insights into growth
- Collaborate Work together seamlessly, from planning to publishing
- Start Page Build a custom link-in-bio page in minutes
- AI Assistant Get help creating, refining, and repurposing content
