Integração Bling com n8n: passo a passo

Dá, e funciona bem. O n8n não tem um nó oficial do Bling, mas conversa com a API v3 do Bling pelo nó HTTP Request, com autenticação OAuth 2.0, e recebe eventos em tempo real pelos webhooks do Bling. O que a integração exige: um aplicativo cadastrado no Bling, uma credencial OAuth2 configurada no n8n e cuidado com três coisas — limite de requisições, validade dos tokens e eventos duplicados.

Este texto é para quem decide e para quem vai montar. Primeiro o porquê, depois o como.

Por que integrar, e não só exportar planilha

O Bling costuma ser o centro da operação em indústria pequena e distribuidora: pedido, estoque, nota fiscal. O problema aparece em volta dele. O pedido chega pelo portal, pelo e-commerce próprio ou pelo WhatsApp do representante, e alguém redigita no Bling. O estoque muda, e a planilha da produção só fica sabendo no dia seguinte.

É o cargo invisível de que falamos em por que o dado não chega: a pessoa que leva o dado de um sistema para o outro. Uma integração no n8n tira essa pessoa do meio — e, junto com ela, a latência e a divergência entre os números.

O que a API do Bling oferece

Os pontos que importam para o desenho:

Autenticação OAuth 2.0, fluxo Authorization Code. Você cadastra um aplicativo, o usuário da conta autoriza, e o aplicativo recebe um access_token e um refresh_token.
Tokens com prazo. No exemplo da documentação, o access_token vale 6 horas. O refresh_token vale 30 dias e serve para pedir um token novo sem o usuário autorizar de novo.
Escopos. O aplicativo só enxerga os módulos que você marcou no cadastro. Mudar os escopos depois revoga a autorização de todos os usuários do aplicativo.
Webhooks. O Bling avisa quando algo é criado, alterado ou excluído em pedido de venda, produto, estoque, estoque virtual, produto do fornecedor, nota fiscal e nota fiscal de consumidor.
Paginação. Consultas trazem 100 registros por página por padrão, controlados pelos parâmetros pagina e limite. Filtro por período não aceita intervalo maior que um ano.

Passo a passo resumido

1. Crie o aplicativo no Bling

Na Central de Extensões, entre na Área do Integrador e crie um aplicativo privado. A documentação recomenda um usuário próprio para quem desenvolve, com a permissão de “Cadastro de aplicativos”. No cadastro:

Marque só os escopos necessários — pedidos, produtos, estoque, notas, conforme o fluxo.
Em Link de redirecionamento, cole a URL de redirecionamento OAuth que o n8n mostra ao criar a credencial (passo 2).
Guarde o Client Id e o Client Secret, na aba “Informações do app”.

2. Crie a credencial OAuth2 no n8n

No n8n, crie uma credencial genérica do tipo OAuth2, com o grant type Authorization Code:

Authorization URL:  https://bling.com.br/Api/v3/oauth/authorize
Access Token URL:   https://api.bling.com.br/Api/v3/oauth/token
Client ID / Secret: os do aplicativo no Bling
Authentication:     Header   (o Bling exige as credenciais em Basic Auth no cabeçalho)

Clique em conectar, faça login no Bling e autorize. Daí em diante, o n8n renova o token sozinho com o refresh_token.

3. Monte o primeiro fluxo

Comece com uma leitura, não com uma escrita. Um nó HTTP Request com a credencial do passo anterior, chamando a API de produtos ou de pedidos (https://api.bling.com.br/Api/v3/...), já mostra se a autenticação e os escopos estão certos. Só depois disso vale criar pedido ou mexer em estoque.

Cinco fluxos que se pagam rápido

Em indústria e distribuição, estes aparecem quase sempre:

Pedido de fora para dentro. Pedido do portal B2B, do e-commerce próprio ou de um formulário do representante vira pedido de venda no Bling, com cliente e itens conferidos antes de gravar. Some a redigitação — e o erro de digitação junto.
Estoque em tempo real para quem precisa. O webhook de estoque alimenta a planilha da produção, o BI ou um alerta de estoque mínimo no WhatsApp do comprador. A decisão de compra deixa de esperar o relatório de segunda.
Nota emitida, cliente avisado. O webhook de nota fiscal dispara o e-mail ou a mensagem para o cliente com os dados da nota, e avisa a expedição.
Pedido aprovado, produção sabendo. Pedido de venda em determinada situação gera a demanda no sistema ou no quadro do PCP, sem ninguém repassar por mensagem.
Fechamento do dia sem montar planilha. Uma rotina noturna consulta pedidos e notas do dia e manda o resumo para quem toca a reunião da manhã.

O critério para escolher o primeiro: o fluxo em que hoje existe uma pessoa copiando dado do Bling para outro lugar, todo dia, mais de uma vez por dia.

As armadilhas que derrubam a integração

Montar o fluxo leva horas. O que dá trabalho é ele continuar funcionando no terceiro mês.

O limite de requisições é da conta, não da sua integração

A API do Bling aceita 3 requisições por segundo e 120 mil por dia por conta — somando todos os aplicativos ligados a ela. Se o marketplace e o hub de frete também consomem a API, a sua integração divide o limite com eles. Passou disso, a resposta é 429 Too Many Requests.

E há bloqueio de IP: 300 erros em 10 segundos ou 600 requisições em 10 segundos bloqueiam o IP por 10 minutos. Mais de 20 pedidos de token em 60 segundos bloqueiam por uma hora. No n8n, use a opção de Batching do HTTP Request (itens por lote e intervalo entre lotes) para não estourar o ritmo.

O token expira — e o refresh também

O n8n renova o access_token, mas o refresh_token vale 30 dias. Integração que fica um mês parada perde a autorização, e alguém precisa reconectar a credencial. Revogar usuários ou mudar os escopos do aplicativo tem o mesmo efeito.

O Bling também está migrando a autenticação de tokens opacos para JWT, que pede um cabeçalho extra (enable-jwt: 1) na emissão e na renovação do token. Antes de pôr em produção, confirme como a sua credencial no n8n lida com isso. É o tipo de mudança que para uma integração do dia para a noite.

Paginação esquecida

Sem paginar, a consulta traz só as 100 primeiras linhas, e o relatório sai errado sem aviso nenhum. O HTTP Request do n8n tem paginação embutida: configure para incrementar o parâmetro pagina até a resposta vir vazia.

Evento duplicado, fora de ordem ou perdido

A documentação do Bling é clara: o mesmo webhook pode chegar duas vezes, e a atualização de um produto pode chegar antes da criação dele. Na prática:

Responda rápido. O Bling considera entregue quem responde com código 2xx em até 5 segundos. Responda primeiro e processe depois.
Trate duplicidade. Use o eventId do evento para não criar o mesmo registro duas vezes.
Fique de olho nas retentativas. Se o seu endpoint falha, o Bling tenta de novo por até 3 dias. Depois disso, desativa o webhook daquele recurso e só volta quando alguém reativar à mão.
Valide a assinatura. Cada evento traz o cabeçalho X-Bling-Signature-256, um HMAC SHA-256 do corpo com o Client Secret. Sem essa conferência, qualquer um que descubra a URL consegue mandar evento falso.

PUT apaga o que você não mandou

Na API do Bling, PUT substitui o registro inteiro: campo omitido volta ao padrão, sem volta. PATCH altera só o que foi enviado — mas não existe em todo endpoint. Para quem monta integração copiando exemplo, esse é o erro mais caro da lista.

Ninguém fica sabendo quando falha

Fluxo que quebra em silêncio é pior que fluxo nenhum, porque todo mundo confia nele. Ative a repetição em caso de falha nos nós que chamam a API e crie um workflow de erro no n8n que avise alguém — com o pedido ou o evento que falhou, para reprocessar.

Quando não fazer sozinho

Um fluxo de leitura, um alerta de estoque, um resumo diário: dá para alguém da casa com alguma intimidade técnica montar e manter.

Vale chamar quem faz isso todo dia quando:

O fluxo escreve no Bling — cria pedido, baixa estoque, altera produto. Erro aqui vira nota errada e estoque furado.
Vários canais mexem no mesmo estoque, e a ordem dos eventos importa.
O volume encosta no limite da conta, e é preciso fila e controle de ritmo.
O processo não pode perder um pedido, e precisa de log, reprocessamento e monitoramento.

Se a dúvida é qual ferramenta usar, comparamos as opções em n8n vs Make vs Zapier. O raciocínio deste texto — OAuth, limite, webhook, duplicidade, monitoramento — vale igual para integrar n8n com Omie, TOTVS ou Sankhya. Muda a API; as armadilhas são as mesmas.

Perguntas frequentes

O n8n tem integração nativa com o Bling?

Não existe nó oficial do Bling no n8n. A integração é feita pelo nó HTTP Request com uma credencial OAuth2 genérica, que cobre toda a API v3. Existem nós da comunidade para o Bling, mas não são mantidos pelo Bling nem pelo n8n, e os não verificados só rodam no n8n auto-hospedado.

Qual é o limite de requisições da API do Bling?

3 requisições por segundo e 120 mil por dia, por conta Bling, somando todos os aplicativos conectados. Acima disso a API responde 429, e excesso de erros ou de requisições pode bloquear o IP por 10 minutos.

Quanto tempo dura o token da API do Bling?

O access_token tem validade curta — 6 horas no exemplo da documentação — e é renovado com o refresh_token, que vale 30 dias. Se a integração ficar mais de 30 dias sem renovar, é preciso autorizar o aplicativo de novo.

Dá para receber pedidos e notas do Bling em tempo real?

Sim, pelos webhooks: pedido de venda, produto, estoque, nota fiscal e outros recursos. No n8n, o nó Webhook recebe o evento. O endpoint precisa responder em até 5 segundos e estar preparado para eventos duplicados e fora de ordem.

Preciso de n8n auto-hospedado para integrar com o Bling?

Não necessariamente. Com o HTTP Request e a credencial OAuth2, o n8n Cloud atende. O auto-hospedado passa a ser necessário se você quiser usar um nó da comunidade não verificado, ou se a política da empresa pedir que os dados fiquem na sua infraestrutura.

Quer tirar a redigitação entre o Bling e o resto da operação? Agende um diagnóstico ou veja a frente de automação e integração.

Integração do Bling com n8n: como conectar o ERP sem digitar duas vezes