How to publish blog posts via custom API endpoints

Every content team hits the same wall: the articles are written, optimized, and ready to rank, then someone spends an afternoon copying, pasting, and clicking "Publish" across a dozen tabs. That manual handoff is the silent killer of content velocity, and it's exactly why learning to publish blog posts via custom API matters more than any prompt tweak.

You're right to be frustrated. You've automated research, drafting, and optimization, yet the final mile still runs on human labor. Here's the promise: by the end of this guide, you'll understand the full pipeline, from sitemap crawl and brand context extraction to article generation and API delivery, and you'll be able to wire your CMS to accept finished posts without touching a dashboard.

We'll cover what custom API publishing actually means, how to authenticate securely, how to build a valid payload, and how to handle failures gracefully. Along the way, you'll see why an AI SEO content engine treats the API endpoint as a first-class citizen, not an afterthought. And one surprising finding: most teams don't need a headless CMS to get there, the bridge already exists in WordPress.

What Publishing via Custom API Actually Means

Publishing via a custom API means sending an authenticated POST request to your CMS endpoint so a finished article lands in your database as a draft or published post, no manual upload required. You don't need a headless CMS to do this; the WordPress REST API already bridges the gap between a classic WordPress install and programmatic publishing.

Think of an API endpoint like a restaurant's order window. The kitchen (your CMS) doesn't care whether the order comes from a waiter or a printed ticket, it just needs the right dish name, the right table number, and proof the order is legitimate. Your POST request is that ticket: a structured payload (the article content) sent to a specific endpoint (the URL that accepts orders), authenticated so the kitchen knows it's you.

There are three common delivery mechanisms. A REST API is a request-response model: you send a POST, the server replies with a status code and the new post ID. A webhook flips the direction, your CMS or middleware pings your endpoint when an event happens, useful for triggering downstream actions like cache clearing. A custom endpoint is simply a REST route you define yourself, often to accept a non-standard payload shape or apply custom validation before saving.

One term you'll encounter constantly: idempotency. An idempotent request can be retried safely, sending the same POST twice with the same idempotency key produces one post, not two. Without it, a network timeout followed by an automatic retry can duplicate your article. This matters because the entire pipeline, sitemap crawl, brand context extraction, article generation, API delivery, assumes the final step is reliable, not just functional.

Step 1: Authenticate Without Exposing Credentials

Authentication is the gatekeeper: it proves to your CMS that the incoming POST request is authorized to create content. The two practical options for WordPress are application passwords and OAuth tokens, and choosing correctly prevents both lockouts and leaks.

Prerequisites: Administrator access to your WordPress site, HTTPS enabled on your domain, and a secure place to store secrets (environment variables or a secrets manager, never your frontend code).

1. Open your WordPress dashboard, then navigate to Users to Profile. Scroll to the Application Passwords section. If you don't see it, confirm your site runs WordPress 5.6 or later.
2. Type a label like "BloGoose Publishing" and click Add New Application Password. WordPress generates a 24-character password with spaces. Copy it immediately, you'll see it only once. Expected outcome: a new password entry appears in the list with your chosen label.
3. Store the password in your environment variables. For example, set WP_APP_PASSWORD in your server config or CI/CD secrets. Never paste it into a JavaScript file that ships to the browser, because anything client-side is readable by anyone who views source.
4. Test the credential with a minimal authenticated request. Send a GET request to /wp-json/wp/v2/users/me using Basic Auth with your username and application password. You should see a JSON response containing your user ID and capabilities, a green light that authentication works.

When should you choose OAuth instead? Application passwords are ideal for server-to-server publishing where one trusted system (like an AI content engine's API integration) pushes articles on a schedule. OAuth tokens are the better fit when multiple third-party services need scoped, revocable access without sharing your main credentials, for example, if you let a freelancer's tool publish drafts but not edit published posts.

BloGoose handles this in production by encrypting credentials at rest and injecting them only into the server-side publishing step, never into the article payload or the browser session. That separation is what keeps your API key out of client-side code even when the publishing pipeline runs on autopilot.

With authentication locked down, the next move is building the actual article payload your endpoint will accept.

Step 2: Construct the Post Payload

A post payload is the JSON body you send to the API endpoint containing every field the CMS needs to create a post, title, content, status, slug, and optionally featured media. Get this structure wrong and your request returns a 400 error before anything publishes.

Prerequisites: You need a valid authentication token from Step 1, your CMS's API base URL, and a JSON-capable tool like Postman, cURL, or a script in Python or Node. js. This step takes roughly 10 - 15 minutes the first time.

1. Open your API testing tool and create a new POST request. Point it at your CMS's posts endpoint, for WordPress REST API, that's https://yoursite.com/wp-json/wp/v2/posts. You should see an empty request body field ready for JSON.
2. Type the required fields first: title, content, and status. Title accepts a plain string, content accepts HTML, and status accepts draft, pending, or publish. You should see your JSON validate without syntax errors.
3. Add the optional slug field with your target URL string. Use lowercase words separated by hyphens, like "slug": "custom-api-publishing-guide". You should see the slug appear in your payload preview exactly as typed.
4. Upload featured media separately before referencing it. Send a POST to /wp-json/wp/v2/media with the image file first, then copy the returned media ID into your post payload as "featured_media": 123. You should see a numeric ID in the media response confirming the upload succeeded.
5. Verify the complete JSON structure matches this pattern:

{
 "title": "Your Post Title",
 "content": "< p> Your HTML content here</p>",
 "status": "draft",
 "slug": "your-post-slug",
 "featured_media": 123
}

Here's where most tutorials stop, and where your posts start breaking. Featured media is the most common failure point: the post endpoint rejects a media URL or filename, so you must upload the image first and reference its numeric ID. NoCodeHack's n8n + ChatGPT + WordPress REST API workflow follows this exact pattern, using separate nodes for media upload and post creation before the final publish call.

If you're generating automated SEO content at scale, building this payload programmatically, not by hand, is the only sustainable approach. A single malformed field in a batch of 50 posts means 50 failed requests.

Step 3: Send the Request and Handle Errors

Sending the request is the moment your payload either creates a post or returns an HTTP status code telling you exactly what went wrong. The fix for a 401 is different from a 429, and knowing the difference saves hours of debugging.

Prerequisites: Your completed JSON payload from Step 2, a valid auth token, and your API testing tool with the request ready to fire. This step takes 5 - 10 minutes for a successful send, longer if errors appear.

1. Click Send in your API tool and watch the response panel. A 201 Created status means success, you should see the full post object returned with an id field. A 200 OK also works on some endpoints.
2. Map any error code to its specific fix using this table:

3. Add an idempotency key header to prevent duplicate posts on retries. Send a unique value like Idempotency-Key: post-2026-10-16-001 with each request. You should see the server reject a second identical request instead of creating a duplicate post.
4. Implement retry logic for transient failures. For 429 and 500 responses, retry automatically with exponential backoff, wait 2 seconds, then 4, then 8. You should see the request eventually succeed without manual intervention.

Synthflow AI's video on API publishing confirms POST and PATCH as the core verbs for creating and updating content via API. POST creates a new post; PATCH updates an existing one by ID. If your first send fails, check whether you're using the right verb before touching the payload.

For teams running custom API publishing at volume, error handling is the difference between a pipeline that runs overnight and one that silently drops posts. BloGoose ships articles directly to your custom API with retry logic and idempotency built in, so a transient 500 never costs you a published post.

Step 4: Verify the Post Went Live

Publishing isn't done when the request returns, it's done when the post renders. A 201 response confirms the CMS accepted your payload, but verification means checking the post actually appears on your site and is ready for indexing.

1. Check the response code and post ID. A 201 Created with an id field in the response body is your first confirmation. This matters because a 200 with an empty body can mean the request was accepted but not processed, always look for the ID.
2. Confirm the post status field. If you sent "status": "draft", the post exists but is not public. This matters because a draft that you think is live means zero traffic, switch to publish or review in your CMS dashboard.
3. Open the rendered post URL in a browser. Visit the actual permalink and confirm the title, content, and featured image all display correctly. This matters because API-created posts can render with broken HTML or missing media that the API response doesn't reveal.
4. Check your XML sitemap for the new URL. Search your sitemap for the post slug to confirm the CMS registered it. This matters because a post missing from the sitemap won't be discovered by crawlers, and won't rank.

Once the post renders and appears in your sitemap, the next step is making sure search engines actually find it. Learn how to get your posts indexed after publishing with an internal link map that points crawlers to your new content.

Frequently Asked Questions About Custom API Publishing

Custom API publishing raises practical questions about platform compatibility, scheduling, and architecture. These answers cover the most common scenarios publishers encounter when moving beyond manual WordPress uploads.

Can I publish to non-WordPress platforms via a custom API?

Yes. Any CMS or platform with a documented REST or GraphQL API accepts custom publishing requests, including Ghost, Contentful, Sanity, Webflow, and custom-built systems. You send an authenticated POST request with your content payload to that platform's endpoint, and it creates the post natively.

How do I schedule posts via API?

Set a future timestamp in the post payload's date or publish_at field, and the CMS holds the post until that time. Most platforms treat a future-dated post as scheduled automatically. Verify the field name in your platform's API documentation, since naming varies between status, date, and publish_at.

What's the difference between a webhook and a REST API for publishing?

A REST API lets you actively send a request to create or update content. A webhook is a passive notification your server receives when an event happens elsewhere. For publishing, you use REST to push posts out; webhooks typically confirm delivery or trigger downstream actions after publishing succeeds.

Do I need a headless CMS to publish via API?

No. Traditional CMS platforms like WordPress expose REST APIs that accept post creation requests without decoupling the frontend. A headless CMS is only necessary if you want to serve content to multiple frontends or custom applications. API publishing works with both architectures.

Why does my API request return a 401 error even with correct credentials?

A 401 typically means the authentication token is missing, expired, or sent in the wrong header format. Check that you're using the Authorization header with the correct scheme, such as Bearer or Basic, and that your token hasn't been revoked or rate-limited by the platform.

Build a Publishing Pipeline That Runs Itself

The four-stage pipeline, authenticate, construct the payload, send the request, verify the response, is the same pattern every production publishing system follows. What separates reliable automation from fragile scripts is idempotency: designing requests so retries never create duplicate posts, and verifying every response before declaring success.

That discipline is exactly what BloGoose's AI SEO content engine bakes into its publishing layer. It ships finished, voice-accurate articles directly to WordPress or your custom API endpoint with AI included, so you skip the manual payload construction and error handling entirely.

Your next step: connect your API endpoint in BloGoose and let one test post validate the full pipeline. Once that post goes live, you've replaced a manual publishing loop with a system that scales without extra hands.