Índice do artigofaltam 8 min de leitura
Publicar é a parte fácil. O projeto se decide nos limites: quantos posts por hora, em quais redes o comentário existe e o que acontece quando o token expira numa sexta à noite.
Uma API de publicação em redes sociais entrega três coisas concretas: uma autenticação em vez de dezesseis, um formato de requisição em vez de dezesseis, e o processo de aprovação de desenvolvedor de cada plataforma resolvido por outra pessoa. Esse terceiro item costuma ser o que decide, porque é o único que não se resolve com tempo de engenharia.
O que ela não entrega é uniformidade. Cada rede continua com suas regras, e a API única as expõe em vez de escondê-las. Este texto é sobre exatamente isso: o que dá para fazer, onde a plataforma trava e o que apurar antes de prometer volume para alguém.
Os números vêm da documentação pública da Zernio, uma empresa externa, espanhola, fundada em 2025, sem relação societária com a X-Apps, usada aqui como caso concreto e documentado da categoria, não como recomendação de compra. O quadro de negócio que motiva esse tipo de projeto está em Redes sociais: o sistema que ficou de fora da integração.
Resumo do artigo
- O recorte desta peça é técnico: o que a API de publicação entrega e onde cada plataforma trava, em velocidade, teto diário, comentário em só 8 das 16 redes, token e webhook, para quem vai construir a integração.
- O teto de velocidade é de 25 posts por hora por conta, com limite diário próprio de cada rede, e o do Pinterest é o mais baixo, em 25 por dia.
- Token válido não é sinal de conta viva. O endpoint de saúde é o que detecta a conexão morta antes de o cliente detectar.
- O que transforma publicação em integração é o webhook de volta, e a deduplicação é responsabilidade de quem recebe, não de quem envia.
A conexão é OAuth, e isso muda quem guarda a senha
O primeiro ganho de uma API de publicação não é técnico, é de acesso: o dono da conta autoriza por OAuth e nunca entrega a senha. A autorização é revogável por ele, a qualquer momento, sem trocar credencial de nada.
Isso destrava um caso comercial inteiro. Agência, franqueadora e software que atende vários clientes deixam de precisar pedir a senha do Instagram do cliente, que é uma das objeções que mais atrasam a entrada desse tipo de projeto.
Na estrutura apurada, contas ficam dentro de containers chamados profiles, e o profile é a fronteira de isolamento entre clientes. A chave de API pode ser restrita a profiles específicos, e uma chamada para fora do escopo dela é recusada com 403.
Traduzindo para o que importa: um erro no seu código não vaza a conta de um cliente para outro, porque o limite não está no seu código, está na credencial.
Existe também um modo em que você constrói a própria tela de seleção de conta, em vez de mandar o cliente para a interface hospedada do fornecedor. É a diferença entre um produto que parece seu e um que parece revenda.
Um endpoint, três modos de publicar
A parte mais simples é a que menos rende discussão, e vale registrar para dimensionar o esforço: publicação, agendamento e rascunho são o mesmo endpoint, diferenciados por parâmetro. Com data e fuso, agenda; com a marcação de publicar agora, publica; sem nenhum dos dois, guarda como rascunho.
- Rascunho, criado sem data e sem ordem de publicar, útil para fila de aprovação interna.
- Agendado, com data e fuso horário explícitos, que é onde mora o erro clássico de publicar às 3 da manhã.
- Imediato, para o caso disparado por evento do seu sistema, como produto novo no catálogo.
O que isso destrava em produto: a fila de aprovação passa a ser sua, dentro do seu sistema, com o seu fluxo de quem aprova o quê. O rascunho existe justamente para o post ficar parado até alguém liberar, sem depender do fluxo de aprovação do fornecedor.
Onde a plataforma trava: velocidade e teto diário
Este é o ponto que mais derruba estimativa de projeto. O teto de velocidade apurado é de 25 posts por hora por conta conectada, e cada rede tem seu limite diário próprio.
| Rede | Teto diário apurado |
|---|---|
| Threads | 250 posts |
| 100 posts | |
| 100 posts | |
| X | 50 posts |
| Demais redes | 50 posts |
| 25 posts |
Limites publicados em docs.zernio.com/rate-limits, lidos em 1º de setembro de 2026.
O Pinterest é o gargalo em qualquer operação de catálogo, e é ele que define o cronograma real de uma carga inicial. Uma loja com 3.000 produtos que quer estar em todas as redes leva mais de quatro meses só no Pinterest, se a estratégia for publicar tudo. A conclusão de projeto não é "aumente o limite", é selecione: publicar o catálogo inteiro em rede visual é decisão de conteúdo mal tomada, e o limite da plataforma está apenas cobrando essa decisão.
Há um segundo teto, o de requisições, que escala com o tamanho da operação: 60 por minuto na faixa gratuita, 600 por minuto entre 3 e 2.000 contas conectadas, e 1.200 acima disso. Chamadas de análise têm janela própria de um segundo. Todas as respostas trazem cabeçalhos com o limite, o quanto sobrou e quando reinicia, e o 429 traz o tempo de espera no corpo.
O que isso destrava em custo: um cliente com 400 contas não precisa de 400 chaves nem de negociação de limite. O limite acompanha o crescimento sozinho, o que remove uma conversa comercial recorrente de operações multi-cliente.
Token válido não é sinal de conta viva
Esta é a armadilha operacional que mais gera chamado de suporte, e ela é sutil: o token de acesso pode estar perfeitamente válido enquanto a plataforma se recusa a atender pela conta.
O caso documentado é o do WhatsApp, em que a Meta pode recusar servir o objeto do número mesmo com o token bom, por exemplo depois de uma desconexão feita pelo celular. Por isso o endpoint de saúde traz uma sonda ao vivo do vínculo com a plataforma, separada do estado do token: a conta aparece com estado de erro mesmo com credencial válida.
-
A conta publica normalmente
Token válido, permissões concedidas, nada a fazer.
-
Alguém mexe na conta pelo aplicativo
A permissão cai ou o vínculo com a plataforma quebra. Nenhum alerta chega, porque ninguém tentou publicar ainda.
-
A campanha agendada falha
Resposta 401 com código de token expirado. A publicação não sai e a fila acumula.
-
O cliente percebe antes de você
Só a reconexão pelo dono da conta resolve, e ela depende de alguém do lado do cliente estar disponível.
O que isso destrava: uma varredura diária no endpoint de saúde de todas as contas transforma esse incidente em tarefa agendada. O custo de implementar é uma rotina; o custo de não implementar é descobrir pelo cliente.
Webhook é o que transforma publicação em integração
Sem evento de volta, uma API de publicação é um agendador com sotaque de código. O que a torna integração é o retorno: post publicado, post falhou, comentário recebido, mensagem recebida, conta desconectada, anúncio mudou de estado.
Na oferta apurada os eventos vêm em sete grupos, e é possível desligar grupos que você não consome. A assinatura é HMAC SHA-256 em hexadecimal minúsculo sobre o corpo bruto, com a chave do seu segredo de webhook.
O contrato de entrega é at-least-once, com prazo de 5 segundos para responder 2xx, até 7 tentativas por evento numa janela cumulativa de cerca de 51 horas, e fila de descarte no fim. Cada evento traz um identificador estável, repetido em cabeçalho.
A leitura de projeto é direta: a deduplicação é sua. O identificador é oferecido justamente porque a entrega repetida é esperada, não excepcional. Um sistema que grava evento sem checar o identificador vai duplicar lead, duplicar mensagem no atendimento e duplicar linha no relatório, e vai fazer isso exatamente no dia de pico, quando a rede oscila e as retentativas disparam.
O prazo de 5 segundos também é uma decisão de arquitetura disfarçada de detalhe. Ele obriga o seu endpoint a apenas receber, validar a assinatura, gravar e responder. Qualquer processamento pesado precisa acontecer depois, fora do ciclo da requisição.
Endpoint que chama o CRM de forma síncrona antes de responder é o padrão que produz retentativa em cascata quando o CRM fica lento.
Post feito pelo celular também precisa entrar na conta
Nenhuma equipe posta só pela API. Alguém sempre publica um story pelo celular, e esse post existe para o público, para o algoritmo e para o relatório.
A oferta apurada trata isso como publicação externa, sincronizada de fora para dentro em intervalos de cerca de 90 minutos. É o suficiente para relatório e para histórico, e não é o suficiente para um painel que promete estado ao vivo.
O que isso destrava em produto, e é o ponto mais fácil de errar na promessa: o painel interno deve mostrar a hora da última sincronização, não fingir tempo real. Um número certo com atraso declarado gera confiança; um número certo apresentado como instantâneo gera chamado toda vez que alguém publica pelo celular e não vê na tela.
O que custa por chamada, e não por conta
O modelo de preço apurado é por conta conectada, com duas gratuitas, e cai por faixa conforme o volume. Fora dele existem custos por uso que não aparecem na página principal, e um deles muda o desenho do software.
O X repassa o custo da própria API, sem margem, por chamada: leitura de post a US$ 0,005 por recurso, criação de conteúdo a US$ 0,015 por requisição, conteúdo com URL a US$ 0,200 por requisição, leitura de mensagem direta a US$ 0,010 e envio a US$ 0,015. Existe teto mensal configurável, com aviso em 80% e pausa em 100%.
Preços de repasse publicados em docs.zernio.com/pricing, lidos em 1º de setembro de 2026.
A diferença de mais de dez vezes entre publicar com link e sem link é a informação de arquitetura escondida no preço. Uma automação que republica cada artigo do blog com o link no corpo tem um custo por post; a mesma automação com o link no primeiro comentário tem outro. Vale conhecer a conta antes de escolher o formato padrão do seu conector, e não depois da primeira fatura.
A conta completa por porte de operação está em Quanto custa operar 40 contas de cliente em redes sociais.
Camada única ou integração direta com cada rede
Não existe resposta universal, e a escolha depende de duas variáveis: quantas redes e quão fundo em cada uma.
Camada única compensa quando
- São mais de três redes, e a manutenção de cada API nativa viraria trabalho contínuo
- Você atende vários clientes e precisa de isolamento por tenant sem construir isso
- O processo de aprovação de desenvolvedor de alguma plataforma é bloqueio real de prazo
- A operação inclui anúncio, comentário e mensagem, não só publicação
Integração direta compensa quando
- São uma ou duas redes, e elas não vão mudar tão cedo
- Você precisa de recurso que só a API nativa expõe e a camada ainda não cobriu
- Existe exigência contratual de não haver terceiro no caminho do dado
- O volume é alto o suficiente para o preço por conta superar o custo de manter o código
Há um caminho intermediário que costuma ser o certo e quase nunca é considerado: usar a camada única para as redes secundárias e ir direto na rede que é o centro do seu negócio. Ninguém precisa escolher um modelo só, e desenhar o adaptador com essa hipótese em mente custa pouco no começo e muito depois.
Em qualquer um dos três caminhos, a peça que não muda é a sua: o registro do que chegou e do que saiu, com vocabulário único e identificador próprio. É ela que faz a troca de fornecedor virar trabalho de adaptador em vez de reescrita.
Vai integrar publicação em redes sociais?
Solicite um orçamento e avance com escopo, arquitetura e entrega.
Fontes e método
Os números deste artigo vêm da leitura da documentação pública da Zernio em 1º de setembro de 2026, cobrindo a matriz de plataformas, os limites de uso, os webhooks, o glossário de modelo de dados, os endpoints de saúde de conta e a página de preços. O registro público de mudanças da plataforma foi consultado na mesma data para dimensionar o ritmo de evolução.
A Zernio foi escolhida como caso concreto porque publica os limites em página aberta, sem contato comercial, e não porque tenha sido comparada e vencido: nenhuma comparação entre fornecedores foi conduzida para este artigo.
Preço e limite de plataforma mudam com frequência, e os desta apuração valem para a data declarada. Nenhum dos números foi medido em produção pela X-Apps com esse fornecedor.
Fontes primárias consultadas em 1º de setembro de 2026: docs.zernio.com (plataformas, limites de uso, webhooks, preços, glossário e endpoints de contas).
Perguntas frequentes
Usando uma camada intermediária, sim: quem passa pelo processo de aprovação da plataforma é o fornecedor, e você chama uma API única. Indo direto na Meta, você assume o processo de revisão e a manutenção de cada mudança da Graph API.
Na oferta que apuramos, 25 posts por hora por conta conectada, com teto diário que varia por rede: 100 no Instagram e no Facebook, 250 no Threads, 50 no X e 25 no Pinterest. Esses tetos são da plataforma, não do intermediário.
Em 8 das 16 redes cobertas pela oferta apurada. Mensagem direta chega a 10 e leitura de métrica a 10 completas mais 2 limitadas. Publicar e agendar é a única capacidade presente nas 16.
A publicação falha e a conta precisa ser reconectada pelo dono. O erro é explícito, com código de token expirado, mas só chega quando alguém tenta usar a conta, então vale consultar o endpoint de saúde de forma preventiva.
Aparece, com atraso. Na oferta apurada a sincronização de publicações feitas fora da API roda a cada 90 minutos aproximadamente, então painel que promete tempo real vai parecer errado enquanto o time postar pelo aplicativo.
Direto compensa quando você usa uma ou duas redes e precisa de recursos que só a API nativa expõe. A camada única compensa quando o número de redes cresce, porque o custo real não é a primeira integração, é manter todas elas depois.
