Integração Bling com Mercado Livre e Shopee: limites e middleware

Informações de outubro de 2026. A integração nativa do Bling com Mercado Livre e Shopee resolve o básico: importa pedidos, sincroniza estoque, vincula anúncios e emite a nota. Os limites aparecem em três lugares: no plano do Bling (pedidos de marketplace por mês), na API v3 (3 requisições por segundo e 120.000 por dia) e nas regras de negócio que a integração nativa não cobre. Este artigo mostra cada limite e quando vale colocar um middleware no meio.

O que a integração nativa do Bling já faz #

A integração nativa conecta a conta do marketplace ao Bling e cobre o fluxo principal de venda: importação de pedidos, sincronização de estoque, vínculo de anúncios com produtos e variações, emissão de NF-e e atualização do status de envio. Para uma loja com um CNPJ e regras simples, isso costuma bastar.

O blog do Bling descreve a atualização de estoque após cada venda, e o artigo sobre a Shopee mostra onde ativar a sincronização. Um cuidado prático: depois de mudar o cadastro de variações no Bling, confira o vínculo de cada variação com o anúncio no Mercado Livre antes de liberar a sincronização de estoque.

Os limites do plano do Bling #

O primeiro limite é comercial: cada plano do Bling tem um teto de pedidos por mês, e só contam os pedidos vindos de marketplaces e de integrações via API. Em outubro de 2026, os tetos iam de 200 pedidos no plano de entrada a 10.000 no Diamante, com o Elite personalizável.

Fonte: planos e preços do Bling, consultada em 27/10/2026. Os preços estavam em promoção na data da consulta, por isso não os reproduzimos; confira o valor do mês na página. Pedidos manuais, do PDV e da loja virtual do próprio Bling não consomem o limite.

Na prática, o plano é escolhido pelo volume de pedidos dos marketplaces somados. Uma loja com 1.200 pedidos no Mercado Livre e 600 na Shopee precisa da faixa de 2.000 do Titânio, mesmo que as vendas no balcão sejam muitas.

Os limites da API v3 do Bling #

O segundo limite é técnico e vale para qualquer sistema que fale com o Bling pela API v3, seja um hub, um middleware ou um script: 3 requisições por segundo e 120.000 por dia por conta. Acima disso, o Bling responde HTTP 429, e excessos repetidos bloqueiam o IP de origem.

Fonte: limites da API do Bling, consultada em 27/10/2026. Os limites são da conta, não de cada aplicativo: se a integração nativa, um hub e um script próprio usam a mesma conta, dividem a mesma cota.

Uma conta para dimensionar: 120.000 requisições por dia equivalem a 5.000 por hora, ou cerca de 1,4 por segundo em média. Um middleware que consulta o saldo de 5.000 SKUs, um por vez, a cada hora gasta a cota inteira do dia só com isso. É por esse motivo que integrações bem feitas trabalham com webhooks (o Bling avisa o que mudou) em vez de consulta periódica de tudo.

O que um middleware precisa respeitar #

Quem escreve um middleware para o Bling precisa tratar autenticação OAuth 2.0 com renovação de token, webhooks com resposta em até 5 segundos, eventos fora de ordem e repetidos, e as regras de bloqueio de IP. Sem isso, a integração funciona na homologação e falha no primeiro pico de vendas.

Autenticação. O código de autorização expira em 1 minuto, e o refresh token vale 30 dias. Se o middleware ficar mais de 30 dias sem renovar o token, alguém precisa autorizar o aplicativo de novo. Alterar os escopos do aplicativo revoga o acesso de todos os usuários (documentação de aplicativos).

Webhooks. Segundo a documentação de webhooks, o Bling envia eventos de pedido de venda, produto, estoque, estoque virtual, produto fornecedor, NF-e e NFC-e, com as ações criado, alterado e excluído. As regras que mais derrubam integrações:

• a resposta precisa ser HTTP 2xx em até 5 segundos; o processamento pesado vai para uma fila;
• sem resposta, o Bling tenta de novo por até 3 dias e depois desabilita o webhook daquele recurso até alguém reativar à mão;
• a ordem de entrega não é garantida: uma alteração pode chegar antes da criação;
• o mesmo evento pode chegar duas vezes, e o sistema precisa ser idempotente;
• cada requisição traz o cabeçalho X-Bling-Signature-256, um HMAC-SHA256 do corpo com o client secret do aplicativo, em hexadecimal e precedido de sha256=, que deve ser validado.

Marketplaces. O Mercado Livre também limita requisições, mas a documentação do erro 429 não publica um número: orienta recuo exponencial com variação aleatória (backoff com jitter), menos chamadas simultâneas e pedido de aumento de cota com evidência de uso.

Quando a integração nativa basta e quando usar middleware #

A integração nativa basta quando há uma conta por marketplace, um CNPJ, um depósito e preço igual em todos os canais. Hub ou middleware passam a valer quando há várias contas ou CNPJs, regras de estoque por canal, kits e composições, preço por canal ou outros sistemas que também precisam dos pedidos.

Hub de marketplaces é um sistema pronto que fica entre o ERP e vários canais, com anúncios, preços e estoque centralizados; o Bling tem integração com a ANYMARKET, por exemplo. Middleware próprio é código ou workflow (em n8n, por exemplo) escrito para a regra da empresa, com fila, registro de cada evento e alerta de falha. O hub tem mensalidade e menos flexibilidade; o middleware próprio tem custo de desenvolvimento e de manutenção.

Um caso que merece atenção é o estoque em centro de distribuição do marketplace, como o Mercado Livre Full: o produto fisicamente está no armazém do marketplace, e o saldo daquele canal não deve ser misturado ao depósito da loja. Confira no Bling como a sua conta trata esse estoque antes de ativar a sincronização.

Checklist antes de integrar #

Antes de ligar a integração, confirme o plano pelo volume de pedidos somados, defina qual depósito alimenta cada canal, vincule variações e categorias, decida quem é o dono das contas e das credenciais e prepare o monitoramento de falhas. Esses itens evitam a maior parte das vendas sem estoque e dos pedidos perdidos.

1. Volume: some os pedidos mensais de todos os marketplaces e de integrações via API, com folga para datas de pico, e escolha a faixa do plano.
2. Cadastro: SKU único por variação, código de barras quando houver, e o mesmo SKU no Bling e nos anúncios.
3. Estoque: um depósito por origem física; estoque de segurança por canal, se a integração permitir; estoque em armazém do marketplace separado.
4. Anúncios e categorias: variações vinculadas uma a uma no Mercado Livre; categorias do Bling vinculadas às da Shopee.
5. Fiscal: natureza de operação e regras de tributação por canal revisadas com a contabilidade, incluindo a adequação da NF-e ao IBS e à CBS.
6. Acessos: contas do marketplace e do Bling em nome da empresa; aplicativos e tokens documentados.
7. Cota de API: liste todos os sistemas que usam a mesma conta do Bling e estime as requisições por dia.
8. Monitoramento: alerta para pedido não importado, estoque divergente e webhook desabilitado.
9. Teste: pedido real de baixo valor em cada canal, do anúncio até a nota e o envio, antes de abrir para o volume total.

Como a SDI ajuda #

A SDI configura e documenta a integração nativa quando ela basta e escreve o middleware quando a regra de negócio pede, com fila, registro de eventos, validação da assinatura dos webhooks e alerta de falha. Código, workflows e credenciais ficam em nome da empresa.

Na integração de sistemas, projetos têm referência a partir de R$ 5.000, e a sustentação mensal, a partir de R$ 400. Valores de referência: cada atendimento é dimensionado após levantamento do ambiente e do escopo, e o valor final consta na proposta. As mensalidades do Bling, dos marketplaces e de eventuais hubs são contratadas pela empresa, à parte.

• bling
• mercado livre
• shopee
• marketplace
• api
• webhook
• erp