Nueva feature en CREA.MBA: programar posts del blog desde Postiz

Esta semana hemos añadido al boilerplate de CREA.MBA un endpoint que permite publicar posts del blog desde Postiz, igual que programas un tweet o un post de LinkedIn. El calendario editorial pasa a estar en un solo sitio.

Si self-hosteas Postiz para tus redes y tu blog vive en CREA.MBA, esta guía explica cómo activarlo en menos de 2 horas.

El feature

El boilerplate ahora trae POST /api/postiz-publish y GET /api/postiz-publish/health. Son los dos endpoints que necesita un provider custom de Postiz para conectarse y publicar contra tu blog. Vienen con todo lo que importa:

• Bearer auth — server-to-server, sin sesiones de usuario.
• Validación de locale contra los soportados por next-intl — si llega fr y la app no lo soporta, 400 antes de escribir basura en BBDD.
• Multi-idioma con translationGroupId — los posts es/en del mismo artículo se enlazan automáticamente para el hreflang y el language switcher.
• Categoría + tags — categoría buscada por slug, tags con connectOrCreate automático.
• Idempotencia — si el post ya existe, flippea su status a PUBLISHED en lugar de duplicar. Reintentos seguros.
• CSRF bypass específico — la ruta está exenta de la validación de Origin (Postiz workers son server-to-server, sin Origin header).

La arquitectura del flujo completo

El boilerplate aporta el receptor. La otra mitad del puente — el provider que aparece en la UI de Postiz — vive en un fork de Postiz que liberamos como referencia. Tres piezas:

Provider custom en el fork de Postiz — módulo TypeScript que define cómo se conecta el canal y cómo se publica. En la UI aparece como un canal más al lado de X, LinkedIn, YouTube.

Endpoint receptor en tu app (incluido en el boilerplate) — valida API key, busca el publisher por email, encuentra/crea categoría y tags, escribe el Post con status PUBLISHED, devuelve el URL canónico.

Componente React de ilustración por slug — las ilustraciones no viajan en el content (Postiz sanitiza HTML). Viven en el repo del blog mapeadas por slug.

El detalle no documentado del orchestrator de Postiz

Hay un detalle que cuesta horas la primera vez. El orchestrator de Postiz filtra silenciosamente cualquier provider cuyo identifier contenga un guion antes de crear el worker en Temporal:

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

Eso significa que linkedin-page e instagram-standalone NO crean su propio worker — reusan el de su primary (linkedin, instagram). Si tu provider custom usa identifier con guiones y no hay primary correspondiente, los jobs se programan, las queues se crean en Temporal, pero ningún worker las procesa.

Recomendación: nombra tu provider sin guiones. Nuestro blogcreastack evita el filtro y crea su propio worker dedicado.

El patrón de ilustraciones que viene con el boilerplate

Postiz sanitiza el HTML del campo content. Cualquier SVG inline desaparece. La solución elegante — que ya viene en el sistema de blog del boilerplate — es mantener las ilustraciones como componentes React mapeados por slug:

const blogIllustrations: Record = { 'audit-logs-produccion-rastro': IllustrationAuditLogs, 'audit-logs-production-trail': IllustrationAuditLogs, // misma ilustración, slug en // ... };

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

El componente del header del post llama a renderBlogIllustration(slug). Si el slug está mapeado, renderiza la ilustración. Si no, no rompe.

Postiz programa contenido. El blog inyecta la ilustración al renderizar. Cada cosa donde tiene que estar. Y la misma ilustración se reusa para versión es y en gracias al doble mapeo.

Activarlo en tu proyecto basado en CREA.MBA

Si ya tienes un proyecto basado en el boilerplate:

Pull del último main del boilerplate. Trae los dos endpoints + el bypass CSRF + las env vars documentadas.

Configurar env vars en producción: POSTIZ_PUBLISH_API_KEY (genera con openssl rand -base64 32) y POSTIZ_PUBLISHER_EMAIL (un User existente en tu BBDD del blog que aparecerá como autor).

Forkear Postiz y añadir el provider custom. La plantilla está en nuestro repo de referencia.

Build imagen Docker propia con el provider, deploy en tu Coolify.

Conectar canal en Postiz UI con la URL de tu blog y la API key.

Tiempo total: 1-2 horas si ya tienes Postiz self-hosteado.

El coste real del fork

Cuando decíamos “fork mantenible” hablábamos de unos 30 minutos por release upstream. Lo medimos: casi todo el código del provider va en archivos propios. Solo dos puntos de fricción con upstream son integration.manager.ts y show.all.providers.tsx — ambos triviales (añadir 2-5 líneas). Rebases reales: ~5 minutos cuando upstream solo toca otros providers, ~20 minutos cuando cambian la interfaz SocialAbstract (raro).

Por qué esto importa

El boilerplate no busca ser el blog más avanzado del mundo. Busca que cuando un builder se sienta a publicar, el flujo no le distraiga. Tener el calendario editorial unificado con redes sociales — mismo Postiz que ya usabas para X y LinkedIn — elimina friction real. Una pestaña, un calendario, todo planificable.

Y el endpoint es lo bastante pequeño como para entenderlo en 10 minutos y modificarlo si tu blog tiene particularidades.

El post recursivo

El post que estás leyendo lo programó Postiz contra el endpoint /api/postiz-publish de este mismo blog. El primer post real publicado con la feature cuenta justo cómo activarla. Recursive.