DEV Community

Jakub
Jakub

Posted on

Content API Beats Clicking Publish: Why I Stopped Using the UI

#webdev #api #startup #productivity

I haven't clicked Publish in three weeks. My blog has more posts than ever.

When you run one product, the editor workflow makes sense. Open dashboard, write, click Publish, done. Maybe five minutes of overhead. No big deal.

But I run 14 products. Each has its own blog on its own domain. Each blog needs fresh content for SEO, for AI visibility, for keeping the product alive in search results. Multiply that five-minute overhead by 14 and suddenly you're spending an hour just navigating dashboards before you've written a single word.

So I built a Content API instead.

The Problem With UI Publishing at Scale

Every blog platform has a slightly different editor. Different button placement, different preview behavior, different autosave quirks. When you're context-switching between 14 products in a day, that cognitive load adds up fast.

Here's what a typical morning used to look like:

  1. Open project for Product A
  2. Navigate to blog section
  3. Write post in the rich text editor
  4. Preview, fix formatting issues
  5. Click Publish
  6. Verify the sitemap updated
  7. Submit to Google Search Console
  8. Repeat for Product B, C, D...

By product number four, I'd already lost 20 minutes to just navigating UIs. The actual writing was maybe 30% of the time spent.

What a Content API Looks Like

The idea is dead simple. Instead of clicking through a UI, you POST a JSON payload to an endpoint and the blog post appears on your site.

curl -X POST https://yourproduct.com/api/blog/publish \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "How We Reduced Load Time by 40%",
    "slug": "reduced-load-time-40-percent",
    "content": "## The bottleneck was...",
    "author": "Jakub",
    "status": "published",
    "tags": ["performance", "optimization"],
    "meta_description": "A quick walkthrough of..."
  }'
Enter fullscreen mode Exit fullscreen mode

That's it. No clicking, no waiting for autosave, no "are you sure?" modals. The post is live.

For my stack (Supabase + React), the API is an Edge Function that validates the payload, inserts into the blog_posts table, and returns the slug. The frontend already knows how to render posts from the database, so there's zero deployment step.

The Auth Part Nobody Talks About

Most tutorials show you the happy path. Here's what actually matters:

Token rotation. Don't hardcode a token that lives forever. I rotate mine weekly. A cron job generates a new one, stores it encrypted, and the old one expires.

Idempotency by slug. If you POST twice with the same slug, the second call should update, not duplicate. This saved me more times than I want to admit. Typo in the content? Just re-POST with the fix.

INSERT INTO blog_posts (slug, title, content, author, status)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (slug)
DO UPDATE SET title = $2, content = $3, updated_at = now();
Enter fullscreen mode Exit fullscreen mode

Rate limiting. Even on your own API. I hit my own endpoint 47 times in one session while debugging a script. Without rate limiting, that would've been 47 published posts.

The Script That Replaced My Morning Routine

I wrote a small bash wrapper that chains the whole publish flow:

#!/bin/bash
PRODUCT=$1
SLUG=$2
CONTENT_FILE=$3

# Publish
curl -s -X POST "https://$PRODUCT/api/blog/publish" \
  -H "Authorization: Bearer $(vault_token $PRODUCT)" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg t "$(head -1 $CONTENT_FILE)" \
            --arg s "$SLUG" \
            --arg c "$(tail -n +3 $CONTENT_FILE)" \
            '{title:$t, slug:$s, content:$c, status:"published"}')"

# Verify sitemap
sleep 5
curl -s "https://$PRODUCT/sitemap.xml" | grep -q "$SLUG" \
  && echo "Sitemap OK" || echo "WARN: slug not in sitemap"

# Request indexing (GSC API)
gsc_index "https://$PRODUCT/blog/$SLUG"
Enter fullscreen mode Exit fullscreen mode

One command. Product name, slug, content file. Post goes live, sitemap verified, indexing requested. What used to take 10 minutes per product now takes 10 seconds.

When NOT to Use a Content API

Not everything should be API-published. Some posts need the UI:

Visual-heavy posts. If the post has custom layouts, embedded widgets, or interactive elements, the WYSIWYG editor is still faster than hand-coding HTML in a JSON payload.

First post on a new product. When you're still figuring out the blog's look and feel, clicking through the editor helps you see what the reader sees. Don't automate discovery.

Collaboration posts. If someone else needs to review before publishing, a shared editor with commenting beats a git-based review flow. At least at our scale.

The Unexpected Side Effect

Once publishing became a one-liner, I started publishing more. Not because I forced myself to, but because the friction disappeared. The mental cost of "I should write a post about this" dropped from "ugh, 20 minutes of UI" to "30 seconds, done."

In the last month, I published more blog posts across my products than in the previous three months combined. Not because I wrote more. Because I stopped losing energy to the publish step.

If you're running multiple products, especially on a stack like Supabase + a React frontend, building a Content API is maybe a weekend project. The ROI hits within the first week.

I'm building tools like Audit Vibe Coding for code quality and Be Recommended for AI visibility tracking. Both have blogs powered by this same API pattern. Same script, different domain, different content. That's the whole point.

Jakub, builder @ Inithouse

Top comments (0)