Seu produto precisa publicar em plataformas sociais. Alguém vai perguntar se deve integrar as plataformas diretamente ou usar uma API de publicação, e a resposta honesta depende de coisas que não aparecem na primeira estimativa.
A estimativa que está sempre errada
A primeira estimativa é para o caminho feliz numa plataforma: conseguir um token, publicar algum texto, pronto. Essa parte é genuinamente questão de alguns dias.
Veja o que a estimativa deixa de fora, por plataforma.
Ciclo de vida do token. Tokens expiram. Alguns em semanas. Renová-los é um job agendado, e quando ele falha a falha é silenciosa: a conexão morre, a publicação falha, e ninguém descobre até um usuário reclamar. Você precisa de detecção e de um fluxo de reconexão.
Mídia. Cada plataforma ingere mídia de um jeito diferente. Algumas buscam uma URL. Algumas querem um upload em partes retomável. Algumas querem dimensões, durações ou codecs específicos, e rejeitam qualquer outra coisa. Você vai estar hospedando e possivelmente transcodificando.
Publicação assíncrona. Em várias plataformas, aceitar sua publicação não é publicá-la. Você recebe um id e consulta o status, e a eventual falha chega muito depois da sua requisição ter retornado 200. Seu modelo de dados precisa de um estado “achamos que isso está publicando”, que não é óbvio até você esbarrar nele.
Limites de taxa. Janelas diferentes, cabeçalhos diferentes, comportamento diferente quando excedido. Você precisa de fila e recuo por plataforma.
Aprovação. Várias plataformas travam a publicação atrás de um processo de revisão, com exigências sobre seu app, sua política de privacidade e às vezes um vídeo de demonstração. Isso é tempo de calendário que você não consegue comprimir, e pode ser recusado.
Mudança contínua. Versões de API são descontinuadas no cronograma da plataforma. Campos são renomeados. Permissões são apertadas. Cada uma é trabalho não planejado com um prazo que você não definiu.
Esse último item é o que decide isso. Construir não é um projeto que termina, é um compromisso de manutenção permanente que cresce a cada plataforma.
A comparação real
Não é “alguns dias por plataforma” contra uma assinatura. É:
| Construir | Comprar | |
|---|---|---|
| Inicial | Semanas por plataforma, mais o tempo de aprovação que você não controla | Uma integração |
| Contínuo | Mudanças de plataforma, falhas de renovação de token, pipeline de mídia | Absorvido pelo provedor |
| Adicionar uma plataforma | Outra integração completa | Um parâmetro |
| Modos de falha | Seus para detectar, depurar e explicar | Expostos pelo provedor |
| Aprovação | Sua para obter e manter por plataforma | Já obtida |
Quando construir é certo
Três casos em que genuinamente é.
Uma plataforma, permanentemente. Se você publica em exatamente uma rede e isso não vai mudar, uma integração direta é mais simples e remove uma dependência.
Publicar é o seu produto. Se o seu diferencial é a camada de publicação, isso é a coisa que você deveria possuir.
Você precisa de profundidade além da publicação. Gestão de anúncios, moderação completa de comentários, análises profundas. Isso vai além do que uma API de publicação cobre, e você vai estar na própria API da plataforma de qualquer jeito.
Quando comprar é certo
Qualquer coisa alcançando três ou mais plataformas em que publicar é uma funcionalidade em vez de o produto. A manutenção é o custo, não a construção, e a manutenção escala com o número de plataformas enquanto sua equipe não escala.
Além disso: qualquer coisa com um prazo. Processos de aprovação de plataforma levam o tempo que levam, e comprar significa que alguém já passou por eles.
O que checar antes de comprar
- A lista de plataformas suportadas, especificamente. Não “todas as principais redes”
- Modelo de autenticação. Se seus usuários conectam as próprias contas, você precisa de OAuth, não só uma chave de API
- Limites de taxa no nível em que você realmente estaria
- Webhooks, para saber de falhas sem ficar consultando
- Se a validação acontece antes de publicar. Pegar uma legenda acima do limite no momento da publicação significa uma publicação que falhou
- O que acontece quando uma plataforma quebra. Isso é o que você está pagando
A API do BulkPublish
- URL base:
https://app.bulkpublish.com - Autenticação: chave de API para a sua própria conta, OAuth 2.1 para agir em nome das contas de outras pessoas
- Superfície: 59 endpoints documentados cobrindo publicações, agendamento, mídia, canais, etiquetas, análises, feeds RSS e cotas
- Plataformas: 15
| Free | Pro | Business | |
|---|---|---|---|
| Requisições de API/dia | 30 | 5.000 | 50.000 |
| Chaves de API | 1 | 5 | 10 |
| SDKs de Node e Python, uma coleção do Postman, e um servidor MCP para agentes de IA. O nível gratuito é dimensionado para avaliar a API, não para rodar tráfego de produção. |
O resumo
A estimativa de construção geralmente está certa sobre a primeira plataforma e errada sobre tudo depois dela, porque o custo é manutenção, não construção. Construa se você está em uma plataforma para sempre, se publicar é o seu produto, ou se você precisa de profundidade além da publicação. Do contrário, a integração que você não mantém vale mais do que a que você mantém.