Pular para o conteúdo principal
Para manter um ERP, CRM ou BI em dia, consulte de tempos em tempos os pedidos que mudaram desde a última leitura. Assim vêm os pedidos novos e também os antigos que mudaram: pagamento aprovado, reembolso, chargeback, cancelamento, cliente corrigido. A sincronização usa três peças: sort=updated_at_asc, o filtro updated_gte com uma janela de 5 minutos e a gravação por id.

Como funciona

1

Primeira carga

Chame GET /v1/orders?sort=updated_at_asc, sem updated_gte, e percorra todas as páginas. Grave cada pedido pelo id. Guarde o maior updated_at lido: essa é a marca.
2

Rodadas seguintes

Chame GET /v1/orders?sort=updated_at_asc&updated_gte=<marca − 5 min> e percorra todas as páginas.
3

Grave por id, substituindo

Para cada pedido lido, substitua a versão que você já tem pelo mesmo id, ou insira se for novo.
4

Avance a marca

Depois de ler a última página, troque a marca pelo maior updated_at lido. Se a rodada falhar no meio, não avance a marca: a próxima rodada relê do mesmo ponto.
Rode o processo periodicamente, por exemplo a cada 5 minutos. Uma rodada sem mudanças costuma custar uma única requisição.

Exemplo com horários

Na 2ª rodada, ord_8k2m4q6s1v3x5z7b9d0f2h volta mesmo sem ter mudado. Gravado por id, ele só substitui a cópia igual que você já tinha.

Por que a janela de 5 minutos

  • A mudança chega à API alguns segundos depois de acontecer. Um pedido atualizado pouco antes da marca pode ficar visível só depois da sua leitura. Sem a janela, essa mudança nunca seria lida.
  • updated_gte é inclusivo. O pedido da marca sempre volta na rodada seguinte. Por isso a gravação por id é obrigatória, mesmo sem a janela.
O custo da janela é pequeno: reler os pedidos que mudaram nos 5 minutos antes da marca. Se você também recebe webhooks, um webhook pode chegar antes de o GET refletir a mudança: repita a leitura em alguns segundos.

Por que gravar por id

O mesmo pedido pode vir mais de uma vez: na janela de sobreposição e quando ele muda durante a leitura (com sort=updated_at_asc, um pedido atualizado no meio da paginação volta numa página seguinte, já com os dados novos). A ordem crescente de updated_at garante que a última versão lida é a mais nova. Substitua o pedido inteiro; não some nem acumule versões.

O que conta como atualização

updated_at avança quando algum campo que a API devolve muda: status, valores, pagamento (inclusive estorno, recusa e parcelas), cliente, endereço, itens, oferta, cupom, UTM, rastreamento (tracking), navegador (navigator) ou metadados. Reprocessamentos internos da Zouti que não mudam nada do que a API devolve não avançam o updated_at: um pedido não volta à sincronização sem motivo.
  • updated_at é o instante em que a mudança chegou à API, não o horário do evento no adquirente. Para saber quando o pedido foi pago ou estornado, use paid_at e payment.refunded_at.
  • Pedidos anteriores a esta funcionalidade receberam como updated_at inicial uma estimativa da última mudança conhecida.
  • updated_at null indica um pedido que ainda não passou pelo preenchimento inicial. Ele entra na primeira carga (no fim da lista), mas nunca numa consulta com updated_gte.
  • Um pedido que deixa de aparecer na API não é sinalizado pelo updated_at.