New feature in CREA.MBA: schedule blog posts from Postiz

This week we shipped a new feature in the CREA.MBA boilerplate: an endpoint that lets you publish blog posts from Postiz, just like you'd schedule a tweet or a LinkedIn post. The editorial calendar lives in one place again.

If you self-host Postiz for your social media and your blog runs on CREA.MBA, this guide explains how to activate it in under 2 hours.

The feature

The boilerplate now ships with POST /api/postiz-publish and GET /api/postiz-publish/health. These are the two endpoints a Postiz custom provider needs to connect and publish to your blog. They come with everything that matters:

• Bearer auth — server-to-server, no user sessions.
• Locale validation against next-intl supported locales — if fr arrives and the app doesn't support it, return 400 before writing garbage to the DB.
• Multi-language with translationGroupId — es/en versions of the same article are linked automatically for hreflang and the language switcher.
• Category + tags — category looked up by slug, tags via automatic connectOrCreate.
• Idempotency — if the post already exists, flip its status to PUBLISHED instead of duplicating. Retries are safe.
• CSRF bypass — the route is exempt from Origin validation (Postiz workers are server-to-server, no Origin header).

The full flow architecture

The boilerplate provides the receiver. The other half of the bridge — the provider that shows up in the Postiz UI — lives in a Postiz fork we released as reference. Three pieces:

Custom provider in the Postiz fork — a TypeScript module defining how the channel connects and how it publishes. In the UI it shows up as just another channel next to X, LinkedIn, YouTube.

Receiver endpoint in your app (included in the boilerplate) — validates API key, looks up the publisher by email, finds/creates the category and tags, writes the Post with status PUBLISHED, returns the canonical URL.

Per-slug React illustration component — illustrations don't travel inside content (Postiz sanitizes HTML). They live in the blog repo, mapped by slug.

The undocumented Postiz orchestrator gotcha

One detail will cost you hours the first time. The Postiz orchestrator silently filters out any provider whose identifier contains a hyphen before creating the worker in Temporal:

.filter((f) => f.identifier.indexOf('-') === -1) .map((integration) => ({ taskQueue: integration.identifier.split('-')[0], // ... }))

That means linkedin-page and instagram-standalone do NOT create their own worker — they share their primary's (linkedin, instagram). If your custom provider uses a hyphenated identifier and there's no matching primary, jobs get scheduled, queues get created in Temporal, but no worker processes them.

Recommendation: name your provider without hyphens. Our blogcreastack avoids the filter and creates its own dedicated worker.

The illustration pattern in the boilerplate

Postiz sanitizes the HTML in the content field. Any inline SVG disappears. The clean fix — already part of the boilerplate's blog system — is to keep illustrations as React components mapped by slug:

const blogIllustrations: Record = { 'audit-logs-produccion-rastro': IllustrationAuditLogs, 'audit-logs-production-trail': IllustrationAuditLogs, // same illustration, en slug // ... };

export function renderBlogIllustration(slug: string) { const Component = blogIllustrations[slug]; return Component ? : null; }

The post header component calls renderBlogIllustration(slug). If the slug is mapped, it renders the illustration. If not, no break.

Postiz schedules content. The blog injects the illustration at render time. Each thing where it belongs. And the same illustration is reused across es and en versions thanks to the double mapping.

Activating it on your CREA.MBA-based project

If you already have a project based on the boilerplate:

Pull latest main from the boilerplate. It brings both endpoints + the CSRF bypass + the documented env vars.

Configure env vars in production: POSTIZ_PUBLISH_API_KEY (generate with openssl rand -base64 32) and POSTIZ_PUBLISHER_EMAIL (an existing User in your blog DB that will appear as author).

Fork Postiz and add the custom provider. The template is in our reference repo.

Build your own Docker image with the provider, deploy on your Coolify.

Connect the channel in the Postiz UI with your blog URL and the API key.

Total time: 1-2 hours if you already have Postiz self-hosted.

The real cost of the fork

When we said “maintainable fork” we meant about 30 minutes per upstream release. We measured it: almost all the provider code lives in our own files. Only two upstream friction points are integration.manager.ts and show.all.providers.tsx — both trivial (add 2-5 lines). Actual rebases: ~5 minutes when upstream only touches other providers, ~20 minutes when they change the SocialAbstract interface (rare).

Why this matters

The boilerplate isn't trying to be the most advanced blog in the world. It's trying to make the publishing flow not get in your way. Having the editorial calendar unified with your social media — the same Postiz you already used for X and LinkedIn — removes real friction. One tab, one calendar, everything planneable.

And the endpoint is small enough that you can read it in 10 minutes and tweak it if your blog has quirks.

The recursive post

The post you're reading was scheduled by Postiz against the /api/postiz-publish endpoint of this same blog. The first real post published with the feature tells exactly how to activate it. Recursive.