O que é o Bling
O Bling é um ERP em nuvem muito usado por quem vende em vários canais: loja própria, Mercado Livre, Shopee, Amazon. Já traz integrações nativas com boa parte dos marketplaces, o que resolve o caminho padrão.
A necessidade de integração aparece quando existe regra que o caminho padrão não modela — preço por tabela de cliente, separação por filial, comissão própria — ou quando um sistema sob medida precisa conversar com ele.
O que a API entrega
A versão 3 da API é REST com autenticação OAuth 2, o que significa fluxo de autorização e renovação de token — diferente da chave fixa da versão anterior, e um ponto que costuma ser subestimado no planejamento.
Há webhooks para eventos de pedido e de estoque, o que evita consulta periódica na maior parte dos casos. Como todo webhook, ele reenvia: o consumo precisa ser idempotente por desenho.
Existe limite de requisições por segundo. Carga inicial de catálogo grande precisa ser feita com controle de ritmo, senão a importação falha na metade e deixa estado parcial.
Fluxos que construímos
Pedido de canal próprio para o Bling
Venda que acontece fora dos marketplaces nativos — site próprio, força de vendas, sistema sob medida — entra no Bling com a mesma disciplina de chave e de-para dos canais nativos.
Estoque unificado
Saldo distribuído entre canais com regra de reserva ou colchão, incluindo os canais que não estão na integração nativa.
Nota e etiqueta
Emissão disparada pelo fluxo e retorno de chave e etiqueta para o canal de origem, sem alguém abrindo o Bling para cada pedido.
Conciliação de repasse
Extrato de marketplace cruzado com os pedidos correspondentes, com a regra de comissão de cada canal aplicada e divergência em fila.
O que costuma quebrar
Token OAuth expirado sem renovação
A integração funciona por semanas e um dia para. Renovação automática e alerta quando ela falha precisam existir desde o primeiro dia — não são refinamento posterior.
Webhook reenviado criando duplicata
Reenvio é comportamento normal, não erro. Sem chave de idempotência, cada reenvio vira um pedido novo.
Carga inicial estourando o limite
Importar dez mil produtos sem controle de ritmo falha no meio e deixa catálogo parcial, que é pior que catálogo nenhum porque parece completo.
Conflito com a integração nativa
Quando a nativa e a sua mexem no mesmo pedido, o resultado depende da ordem. Definir quem é dono de cada campo evita o dado que 'volta sozinho'.
Prazo típico
- 2 a 4
- semanas para pedido e estoque em produção
- +1
- semana para nota e etiqueta
- +2
- semanas para conciliação de repasse
Perguntas frequentes
As integrações nativas do Bling não bastam?
Para o caminho padrão, bastam — e se atendem, fique com elas. Construir vale quando existe regra que a nativa não modela ou quando um sistema próprio precisa participar do fluxo.
A migração da API v2 para a v3 quebra o que já existe?
Muda a autenticação e parte dos contratos, então integração escrita para a v2 precisa de revisão. Se você tem algo rodando na versão antiga, o diagnóstico avalia o esforço antes de qualquer compromisso.
Dá para usar webhook e consulta periódica juntos?
Dá, e costuma ser o desenho mais robusto: webhook para reagir rápido e uma varredura de reconciliação em janela curta para pegar o que porventura não chegou. Confiar só em webhook deixa buraco quando o endpoint fica indisponível.
Quanto tempo até parar de digitar pedido?
Entre 2 e 4 semanas para o fluxo de pedido em produção, dependendo de quantos canais entram na primeira fase. Começar por um canal e ampliar é mais rápido que tentar todos de uma vez.