StackPost — unified social media API with 19 platforms, centralized OAuth and HMAC webhooks
- 19
- Platforms
- 114
- REST endpoints
- 3
- SDKs (TS/Py/Go)
Client
StackPost
Sector
Social infrastructure · API · SaaS
Timeline
4 semanas · 2026-08
Live product
Use nowResults
Client-reported results during rollout
Baseline: Facebook, YouTube, Instagram, TikTok, LinkedIn, Telegram, Reddit, X, Pinterest, Threads, Discord, Google Business, Bluesky, Slack, Mastodon, Tumblr, DEV.to e Hashnode, Mastodon, Slack, Google Business
Fonte: Adapter count
Baseline: posting, scheduling, analytics, comments, media, webhooks, auth, billing
Fonte: Next.js route count
Baseline: home, docs, platform pages, demo, security, ai-agents, plans
Fonte: Production test
Baseline: TypeScript, Python, Go
Fonte: StackPost repository
Baseline: multipart, presigned, TUS/resumable, URL import
Fonte: StackPost configuration
Baseline: SameSite=Lax for OAuth redirects
Fonte: Auth configuration
Baseline: exponential retry + idempotency on all writes
Fonte: StackPost architecture
Baseline: preference checkout with init_point, QR code
Fonte: Mercado Pago integration
Baseline: direct posting without custom code
Fonte: StackPost repository
Client-reported data
The challenge
The challenge
StackPost is a social infrastructure SaaS that eliminates months of engineering required to maintain individual integrations with each network. Instead of implementing 15 OAuth flows, 15 publishing APIs, 15 analytics systems and 15 webhook handlers, the customer consumes a single REST API. Multi-tenant by design: each organization has its connected accounts, RBAC users, audit logs and full isolation. Platform adapters abstract the differences between Facebook, YouTube, Instagram, TikTok, LinkedIn, Telegram, Reddit, X, Pinterest, Threads, Discord, Google Business, Bluesky, Slack, Mastodon, Tumblr, DEV.to e Hashnode, Mastodon, Slack and Google Business. SDKs in TypeScript, Python and Go, CLI for automation and MCP server for AI agents.
SaaS, agências e agentes de IA precisam publicar em múltiplas redes sociais, mas cada plataforma tem OAuth próprio, rate limits diferentes, APIs que mudam sem aviso e webhooks inconsistentes. Manter 15 integrações em casa custa meses de engenharia e um time dedicado só pra isso.
The approach
The approach
We treat social integration as infrastructure, not as a feature. The multi-tenant architecture isolates each organization with its connected accounts, users and permissions. OAuth 2.0 is centralized: the customer implements no flow, just connects the account once. Platform adapters abstract the differences — posting to Instagram or Bluesky uses the same REST endpoint. Webhooks are HMAC-signed with exponential retry and replay to guarantee delivery. Idempotency on all write endpoints prevents duplication. The MCP server exposes the API to AI agents, allowing Claude, Cursor and others to post to social media directly.
The solution
The solution
- 114 unified REST endpoints for posting, scheduling, analytics, comments, imports and media
- 19 platform adapters: Facebook, YouTube, Instagram, TikTok, LinkedIn, Telegram, Reddit, X, Pinterest, Threads, Discord, Google Business, Bluesky, Slack, Mastodon, Tumblr, DEV.to e Hashnode, Mastodon, Slack, Google Business
- Centralized OAuth 2.0 for Google, Discord, Facebook/Meta and other platforms — the customer implements no flow
- Multi-tenant with organizations, RBAC, roles, audit logs and full isolation between accounts
- Media: multipart upload, presigned upload, TUS/resumable upload, URL import — files up to 1GB
- Scheduling with retry, best-time ML, A/B testing, bulk posting and cross-posting across platforms
- HMAC-signed webhooks with exponential retry, replay and idempotency on all write endpoints
- Unified analytics: reach, impressions, engagement and per-platform metrics in a single response
- Comments: listing, import, automated reply and Comment → DM for conversion
- SDKs in TypeScript, Python and Go with full typing and examples
- CLI for command-line automation and MCP server for AI agents (Claude, Cursor)
- Usage-based billing via Mercado Pago (PIX) — pay for what you consume, not per connected account
- OpenAPI 3.1 with Scalar API reference, interactive documentation and per-language examples
- Custom auth with bcryptjs + jose JWT, HttpOnly cookie, 7-day token, SameSite=Lax for OAuth redirects
Timeline
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Semana 1
Arquitetura
- Multi-tenant design with organizations, RBAC and isolation
- Supabase schema with RLS on all tables
- Platform adapter structure with unified interface
- Centralized OAuth 2.0 for Google, Discord and Facebook/Meta
Semana 2-3
Construção
- 114 REST endpoints: posting, scheduling, analytics, comments, media
- 19 platform adapters with OAuth and difference abstraction
- Media: multipart, presigned, TUS/resumable, URL import up to 1GB
- HMAC webhooks with exponential retry, replay and idempotency
- Usage-based billing via Mercado Pago (PIX) with plans and credits
Semana 4
Validação
- Cloudflare Workers deploy with OpenNext
- SDKs in TypeScript, Python and Go with full typing
- CLI and MCP server for AI agents
- OpenAPI 3.1 with Scalar API reference
- Production test: 20/20 pages OK, responsiveness and speed validated
Methodology
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Multi-tenant architecture from the start — not bolt-on
Adapters with unified interface to abstract differences between platforms
Centralized OAuth — the customer never implements a flow
Idempotency on all write endpoints
HMAC webhooks with retry and replay to guarantee delivery
Throttling in adapters to respect per-platform rate limits
Full production test: pages, responsiveness, speed and links
Architecture
- → Next.js 15 App Router with 114 REST endpoints and SSR in the same app
- → OpenNext adapts the build to Cloudflare Workers (global edge, near-zero cold start)
- → Supabase Postgres with RLS on all tables — each organization isolated
- → 19 platform adapters with unified interface abstract OAuth, formats and rate limits
- → Centralized OAuth 2.0: Google, Discord, Facebook/Meta and other platforms
- → Media: multipart, presigned, TUS/resumable and URL import (up to 1GB)
- → HMAC webhooks with exponential retry, replay and idempotency
- → Multi-tenant: organizations, RBAC, roles, audit logs and full isolation
- → TS/Python/Go SDKs + CLI + MCP server for AI agents
- → Usage-based billing via Mercado Pago (PIX) — preference checkout with init_point
Conceptual diagram — does not reflect real implementation
Tech stack
Technical choices and what was left out.
saas
Why: API routes and SSR in the same app, OpenNext for Workers
Rejected alternative: Separate Express (more services to maintain)
Why: Global edge, near-zero cold start, automatic deploy
Rejected alternative: Vercel (higher cost at scale)
Why: Database with RLS, Storage and service-role HTTP client
Rejected alternative: Prisma + direct Postgres (more code)
Why: Password hash and signed JWT, 7-day HttpOnly cookie
Rejected alternative: NextAuth (less cookie control)
saas
Why: Server Components and concurrency hooks for the dashboard
Rejected alternative: Vue (smaller ecosystem for SaaS)
Why: Consistent tokens, small CSS, native dark mode
Rejected alternative: Plain CSS (slower to iterate)
Why: Official icons for all social platforms
Rejected alternative: Manual SVG (high maintenance)
saas
Why: Centralized OAuth — customer implements no flow
Rejected alternative: Each customer implements their own (months of engineering)
Why: Unified interface abstracts differences between networks
Rejected alternative: Official SDK per platform (15 dependencies, 15 maintenances)
Why: Exponential retry, replay and idempotency guarantee delivery
Rejected alternative: Polling (API cost, high latency)
saas
Why: Preference checkout with init_point, PIX and QR code
Rejected alternative: Stripe (no PIX in Brazil)
saas
Why: Interactive documentation with per-language examples
Rejected alternative: Swagger UI (inferior UX)
Why: Full typing, examples and semver versioning
Rejected alternative: REST only (more client code)
Why: AI agents (Claude, Cursor) post directly
Rejected alternative: No MCP (AI cannot post without custom code)
Decision log
What I chose, what I rejected, and why.
Multi-tenant from the start, not bolt-on
Why: Isolation between organizations with RLS in Supabase from the schema. Adding multi-tenant later costs months of refactor.
Rejected alternatives: Single-tenant with per-customer deploy would scale cost and operation linearly.
Adapters with unified interface
Why: Each platform has different OAuth, formats and rate limits. A unified interface allows adding new platforms without changing customer code.
Rejected alternatives: Official SDK per platform would create 15 dependencies and 15 independent maintenances.
Cloudflare Workers instead of Vercel
Why: Global edge with near-zero cold start and predictable cost. OpenNext allows using Next.js without changing code.
Rejected alternatives: Vercel would be simpler at first, but cost scales fast with API traffic.
MCP server for AI agents
Why: AI agents (Claude, Cursor) cannot post to social media without custom code. MCP server exposes the API natively to them.
Rejected alternatives: REST only would require each agent to implement manual integration.
Usage-based billing, not per account
Why: SaaS and agencies manage dozens of accounts. Per-account billing discourages usage. Usage-based billing aligns cost with value.
Rejected alternatives: Fixed plan per account would limit scale and create friction in adding profiles.
AI Assistant
Publishing pipeline via MCP
AI agent (Claude, Cursor) calls the StackPost MCP server
MCP server validates organization permissions and user RBAC
System identifies the target platform adapter (e.g. Instagram)
Adapter normalizes content, media and metadata to the platform format
OAuth token of the connected account is retrieved from Supabase (encrypted)
Post is sent to the platform with idempotency key
HMAC webhook is fired to the customer with success or failure status
Analytics is collected and unified in the next metrics call
Product mechanics
Usage-based plans
Credits and plans with consumption limits — pay for what you use, not per connected account. Automatic upgrade and downgrade.
Multi-tenant with organizations
Each organization has its accounts, users, roles and audit logs. Invite members, set permissions and isolate data.
Progressive platforms
Connect one platform at a time. Each adapter is independent — adding Instagram doesn't require setting up LinkedIn.
Webhooks with replay
Receive HMAC-signed notifications for each event. Replay allows reprocessing lost webhooks without duplication.
MCP for AI agents
Claude, Cursor and other agents post directly via MCP server — no custom code, no manual integration.
Security and access
Security and compliance
-
Passwords hashed with bcryptjs, JWT signed with jose
-
7-day HttpOnly cookie with SameSite=Lax for OAuth redirects
-
Middleware protects authenticated routes and allows public marketing/docs routes
-
Supabase RLS enabled on all public schema tables
-
OAuth tokens encrypted before saving to the database
-
Webhooks signed with HMAC to guarantee origin and integrity
-
Idempotency keys on all write endpoints prevent duplication
-
RBAC with organizations, roles and audit logs for traceability
-
Per-organization rate limiting to prevent API abuse
Lessons learned
Not everything went as planned.
— Centralized OAuth is the biggest time saver. Each platform has different scopes, redirects and quirks — abstracting them once saves months per new customer. Webhooks without idempotency become silent duplication. SameSite=Lax (not Strict) is mandatory for OAuth redirects to work. Cloudflare Workers has CPU/memory limits that only show under load — throttling in adapters avoids mass 503s. The MCP server changed the positioning: StackPost is no longer just an API, it's infrastructure for AI agents.
See also other products
VulnStrike VulnStrike
Scanner de vulnerabilidades SaaS: digite um domínio e receba nota de segurança A+–F com achados explicados e correção passo a passo — scan grátis sem cadastro.
View case →
Nexus IA Nexus IA — Plataforma de IA
Plataforma de IA com 620+ endpoints REST, Nexus Auto com roteamento automático entre 20+ modelos, workspace com agente autônomo, multimodal e 6 planos comerciais.
View case →
SEEDS Experience SEEDS Experience
Comunidade exclusiva de mulheres empreendedoras onde a membro entra, conecta-se e acessa oportunidades de capital e mentoria via IA.
View case →Want a product like this?
I can do the same for your business. Let's talk.