Skip to main content

Dois modos de sync

Batch periódico

A cada 10 minutos, envia deltas acumulados de estoque e preço. Otimiza rate limit e latência.

Imediato pós-venda

Após cada venda no sistema integrado, envia só o SKU vendido com o novo estoque. Reduz risco de overselling.

Batch a cada 10 minutos

Mesmo padrão pra preço.

Imediato pós-venda

Assim que uma venda for confirmada no sistema integrado, envie o novo estoque:
Se você processa 100+ vendas por minuto, considere agrupar em micro-batches (janela de 2s + até 50 SKUs) pra não estourar rate limit. O ganho de “imediato” já cai muito depois de 2s.

Preço: mesmo padrão

Tratamento de erros

1. Variante não encontrada (207 Multi-Status)

Provavelmente essa variante foi criada no sistema integrado mas ainda não foi enviada via POST /variantes. Verifique fluxo de cadastro; envie a variante antes de tentar de novo.

2. Rate limit (429)

Aguarde Retry-After segundos, retente. Ver Rate Limits.

3. Erro 5xx

Backoff exponencial: 1s, 2s, 4s, 8s, 16s. Máx 5 tentativas.

Boas práticas

Sempre batch quando puder. 500 chamadas de 1 SKU = 500 requests. 1 chamada de 500 SKUs = 1 request. Ambos gastam ~1s de compute do servidor — mas a primeira gasta 500 unidades do seu rate limit.
  • Use fila local (BullMQ, Sidekiq, etc) pra desacoplar “detectar mudança” de “chamar API”
  • Se sua janela de 10 min tem picos > 500 mudanças, quebre em micro-lotes de 500 e rode em sequência (com pause de 100ms entre eles pra não bater rate limit)
  • Log só erros — sucessos podem ser aggregate (123 SKUs atualizados) pra não poluir
  • Após batch, valide contra GET /produtos?hunter_id=<amostra> pra checar consistência

Divergência de estoque

Se você suspeitar que o estoque na loja divergiu do sistema integrado (bug local, envio perdido, corrupção), faça sync full temporariamente:
Sync full é oneroso mas idempotente — nada quebra.