StackPost — API unificada de redes sociais com 19 plataformas, OAuth centralizado e webhooks HMAC
- 19
- Plataformas
- 114
- Endpoints REST
- 3
- SDKs (TS/Py/Go)
Cliente
StackPost
Setor
Infraestrutura social · API · SaaS
Linha do tempo
4 semanas · 2026-08
Produto ao vivo
Usar agoraResultados
Resultados reportados pelo cliente durante o 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: Contagem de adaptadores
Baseline: publicação, agendamento, analytics, comentários, mídia, webhooks, auth, billing
Fonte: Contagem de rotas Next.js
Baseline: home, docs, platform pages, demo, security, ai-agents, plans
Fonte: Teste de produção
Baseline: TypeScript, Python, Go
Fonte: Repositório StackPost
Baseline: multipart, presigned, TUS/resumable, URL import
Fonte: Configuração StackPost
Baseline: SameSite=Lax para OAuth redirects
Fonte: Configuração de auth
Baseline: retry exponencial + idempotência em todos os writes
Fonte: Arquitetura StackPost
Baseline: preference checkout com init_point, QR code
Fonte: Integração Mercado Pago
Baseline: publicação direta sem código custom
Fonte: Repositório StackPost
Dados reportados pelo cliente
O desafio
O desafio
StackPost é um SaaS de infraestrutura social que elimina meses de engenharia necessários para manter integrações individuais com cada rede. Em vez de implementar 15 OAuth flows, 15 APIs de publicação, 15 sistemas de analytics e 15 tratamentos de webhook, o cliente consome uma única API REST. Multi-tenant por design: cada organização tem suas contas conectadas, usuários com RBAC, audit logs e isolamento total. Adaptadores de plataforma abstraem as diferenças entre Facebook, YouTube, Instagram, TikTok, LinkedIn, Telegram, Reddit, X, Pinterest, Threads, Discord, Google Business, Bluesky, Slack, Mastodon, Tumblr, DEV.to e Hashnode, Mastodon, Slack e Google Business. SDKs em TypeScript, Python e Go, CLI para automação e MCP server para agentes de IA.
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.
A abordagem
A abordagem
Tratamos a integração social como infraestrutura, não como feature. A arquitetura multi-tenant isola cada organização com suas contas conectadas, usuários e permissões. OAuth 2.0 é centralizado: o cliente não implementa nenhum flow, só conecta a conta uma vez. Adaptadores de plataforma abstraem as diferenças — publicar no Instagram ou no Bluesky usa o mesmo endpoint REST. Webhooks são HMAC-signed com retry exponencial e replay para garantir entrega. Idempotência em todos os endpoints de escrita evita duplicação. O MCP server expõe a API para agentes de IA, permitindo que Claude, Cursor e outros publiquem em redes sociais diretamente.
A solução
A solução
- 114 endpoints REST unificados para publicação, agendamento, analytics, comentários, importação e mídia
- 19 adaptadores de plataforma: 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
- OAuth 2.0 centralizado para Google, Discord, Facebook/Meta e demais plataformas — o cliente não implementa nenhum flow
- Multi-tenant com organizações, RBAC, roles, audit logs e isolamento total entre contas
- Mídia: upload multipart, presigned upload, TUS/resumable upload, URL import — arquivos até 1GB
- Agendamento com retry, best-time ML, A/B testing, bulk posting e cross-posting entre plataformas
- Webhooks HMAC-signed com retry exponencial, replay e idempotência em todos os endpoints de escrita
- Analytics unificada: alcance, impressões, engajamento e métricas por plataforma em uma única resposta
- Comentários: listagem, importação, resposta automática e Comment → DM para conversão
- SDKs em TypeScript, Python e Go com tipagem completa e exemplos
- CLI para automação de linha de comando e MCP server para agentes de IA (Claude, Cursor)
- Cobrança por uso via Mercado Pago (PIX) — pague pelo que consumir, não por conta conectada
- OpenAPI 3.1 com Scalar API reference, documentação interativa e exemplos por linguagem
- Auth custom com bcryptjs + jose JWT, cookie HttpOnly, token de 7 dias, SameSite=Lax para OAuth redirects
Linha do tempo
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Semana 1
Arquitetura
- Desenho multi-tenant com organizações, RBAC e isolamento
- Schema do Supabase com RLS em todas as tabelas
- Estrutura de adaptadores de plataforma com interface unificada
- OAuth 2.0 centralizado para Google, Discord e Facebook/Meta
Semana 2-3
Construção
- 114 endpoints REST: publicação, agendamento, analytics, comentários, mídia
- 19 adaptadores de plataforma com OAuth e abstração de diferenças
- Mídia: multipart, presigned, TUS/resumable, URL import até 1GB
- Webhooks HMAC com retry exponencial, replay e idempotência
- Cobrança por uso via Mercado Pago (PIX) com planos e créditos
Semana 4
Validação
- Deploy Cloudflare Workers com OpenNext
- SDKs em TypeScript, Python e Go com tipagem completa
- CLI e MCP server para agentes de IA
- OpenAPI 3.1 com Scalar API reference
- Teste de produção: 20/20 páginas OK, responsividade e velocidade validadas
Metodologia
Como o projeto foi conduzido, do mapeamento ao deploy. How the project was conducted, from mapping to deploy.
Arquitetura multi-tenant desde o início — não bolt-on
Adaptadores com interface unificada para abstrair diferenças entre plataformas
OAuth centralizado — o cliente nunca implementa flow
Idempotência em todos os endpoints de escrita
Webhooks HMAC com retry e replay para garantir entrega
Throttling nos adaptadores para respeitar rate limits por plataforma
Teste de produção completo: páginas, responsividade, velocidade e links
Arquitetura
- → Next.js 15 App Router com 114 endpoints REST e SSR na mesma aplicação
- → OpenNext adapta o build para Cloudflare Workers (edge global, cold start próximo de zero)
- → Supabase Postgres com RLS em todas as tabelas — cada organização isolada
- → 19 adaptadores de plataforma com interface unificada abstraem OAuth, formatos e rate limits
- → OAuth 2.0 centralizado: Google, Discord, Facebook/Meta e demais plataformas
- → Mídia: multipart, presigned, TUS/resumable e URL import (até 1GB)
- → Webhooks HMAC com retry exponencial, replay e idempotência
- → Multi-tenant: organizações, RBAC, roles, audit logs e isolamento total
- → SDKs TS/Python/Go + CLI + MCP server para agentes de IA
- → Cobrança por uso via Mercado Pago (PIX) — preference checkout com init_point
Diagrama conceitual — não reflete implementação real
Stack tecnológica
Escolhas técnicas e o que ficou para fora.
saas
Por quê: API routes e SSR na mesma app, OpenNext para Workers
Alternativa rejeitada: Express separado (mais serviços pra manter)
Por quê: Edge global, cold start próximo de zero, deploy automático
Alternativa rejeitada: Vercel (custo maior em escala)
Por quê: Banco com RLS, Storage e service-role HTTP client
Alternativa rejeitada: Prisma + Postgres direto (mais código)
Por quê: Hash de senha e JWT assinado, cookie HttpOnly de 7 dias
Alternativa rejeitada: NextAuth (menos controle sobre o cookie)
saas
Por quê: Server Components e hooks de concorrência para o dashboard
Alternativa rejeitada: Vue (ecossistema menor para SaaS)
Por quê: Tokens consistentes, CSS pequeno, dark mode nativo
Alternativa rejeitada: CSS puro (mais lento para iterar)
Por quê: Ícones oficiais de todas as plataformas sociais
Alternativa rejeitada: SVG manual (manutenção alta)
saas
Por quê: OAuth centralizado — cliente não implementa nenhum flow
Alternativa rejeitada: Cada cliente implementa o próprio (meses de engenharia)
Por quê: Interface unificada abstrai diferenças entre redes
Alternativa rejeitada: SDK oficial de cada plataforma (15 dependências, 15 manutenções)
Por quê: Retry exponencial, replay e idempotência garantem entrega
Alternativa rejeitada: Polling (custo de API, latência alta)
saas
Por quê: Preference checkout com init_point, PIX e QR code
Alternativa rejeitada: Stripe (sem PIX no Brasil)
saas
Por quê: Documentação interativa com exemplos por linguagem
Alternativa rejeitada: Swagger UI (UX inferior)
Por quê: Tipagem completa, exemplos e versionamento semver
Alternativa rejeitada: Apenas REST (mais código no cliente)
Por quê: Agentes de IA (Claude, Cursor) publicam diretamente
Alternativa rejeitada: Sem MCP (IA não consegue publicar sem código custom)
Decision log
O que escolhi, o que rejeitei e por quê.
Multi-tenant desde o início, não bolt-on
Por que: Isolamento entre organizações com RLS no Supabase desde o schema. Adicionar multi-tenant depois custa refator de meses.
Alternativas rejeitadas: Single-tenant com deploy por cliente escalaria custo e operação linearmente.
Adaptadores com interface unificada
Por que: Cada plataforma tem OAuth, formatos e rate limits diferentes. Uma interface unificada permite adicionar plataformas novas sem mudar o código do cliente.
Alternativas rejeitadas: SDK oficial de cada plataforma criaria 15 dependências e 15 manutenções independentes.
Cloudflare Workers em vez de Vercel
Por que: Edge global com cold start próximo de zero e custo previsível. OpenNext permite usar Next.js sem mudar código.
Alternativas rejeitadas: Vercel seria mais simples no início, mas o custo escala rápido com tráfego de API.
MCP server para agentes de IA
Por que: Agentes de IA (Claude, Cursor) não conseguem publicar em redes sociais sem código custom. MCP server expõe a API nativamente para eles.
Alternativas rejeitadas: Apenas REST exigiria que cada agente implementasse integração manual.
Cobrança por uso, não por conta
Por que: SaaS e agências gerenciam dezenas de contas. Cobrança por conta conectada desincentiva uso. Cobrança por uso alinha custo com valor.
Alternativas rejeitadas: Plano fixo por conta limitaria escala e criaria atrito na adição de perfis.
Assistente de IA
Pipeline de publicação via MCP
Agente de IA (Claude, Cursor) chama o MCP server do StackPost
MCP server valida permissões da organização e RBAC do usuário
Sistema identifica o adaptador da plataforma de destino (ex: Instagram)
Adaptador normaliza conteúdo, mídia e metadados para o formato da plataforma
OAuth token da conta conectada é recuperado do Supabase (criptografado)
Publicação é enviada para a plataforma com idempotency key
Webhook HMAC é disparado para o cliente com status de sucesso ou falha
Analytics é coletada e unificada na próxima chamada de metrics
Mecânicas de produto
Planos por uso
Créditos e planos com limites por consumo — pague pelo que usar, não por conta conectada. Upgrade e downgrade automáticos.
Multi-tenant com organizações
Cada organização tem suas contas, usuários, roles e audit logs. Convida membros, define permissões e isola dados.
Plataformas progressivas
Conecte uma plataforma de cada vez. Cada adaptador é independente — adicionar Instagram não exige configurar LinkedIn.
Webhooks com replay
Receba notificações HMAC-signed de cada evento. Replay permite reprocessar webhooks perdidos sem duplicação.
MCP para agentes de IA
Claude, Cursor e outros agentes publicam diretamente via MCP server — sem código custom, sem integração manual.
Segurança e acesso
Segurança e conformidade
-
Senhas com hash bcryptjs, JWT assinado com jose
-
Cookie HttpOnly de 7 dias com SameSite=Lax para OAuth redirects
-
Middleware protege rotas autenticadas e libera rotas públicas de marketing/docs
-
Supabase RLS ativado em todas as tabelas do schema público
-
OAuth tokens criptografados antes de salvar no banco
-
Webhooks assinados com HMAC para garantir origem e integridade
-
Idempotency keys em todos os endpoints de escrita evitam duplicação
-
RBAC com organizações, roles e audit logs para rastreabilidade
-
Rate limiting por organização para evitar abuso da API
Lições aprendidas
Nem tudo saiu como planejado.
— OAuth centralizado é o maior economizador de tempo. Cada plataforma tem escopos, redirects e quirks diferentes — abstraí-los uma vez economiza meses em cada novo cliente. Webhooks sem idempotência viram duplicação silenciosa. SameSite=Lax (não Strict) é obrigatório para OAuth redirects funcionarem. Cloudflare Workers tem limites de CPU/memória que aparecem só sob carga — throttling nos adaptadores evita 503 em massa. MCP server mudou o posicionamento: StackPost não é mais só uma API, é infraestrutura para agentes de IA.
Veja também outros produtos
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.
Ver 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.
Ver 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.
Ver case →Quer um produto como esse?
Posso fazer o mesmo para o seu negócio. Vamos conversar.