Tracking de packages
Tracking a nível de pacote dentro de um stop de entrega. Um stop carrega vários identificadores de package, cada um avançando pending → picked → delivered. Você envia os identificadores ao criar o stop e depois reconcilia o status por pacote — incluindo entregas parciais — de volta no seu WMS ou ERP.
Para quem é
Você entrega mais de um pacote rastreado para o mesmo endereço e seu sistema de registro precisa saber o destino de cada pacote, não apenas se o stop foi concluído. Casos típicos:
- Uma operação 3PL / paquetária onde um endereço recebe vários volumes, cada um com seu barcode, e o cliente ou embarcador espera visibilidade de scan por pacote.
- Um distribuidor B2B multi-volume (pharma, suprimento industrial, food service) com pedidos paletizados ou multi-caixa onde a aceitação parcial é normal — o recebedor assina por 8 de 10 caixas e rejeita 2.
- Um consolidador e-commerce que envia várias linhas distribuídas em caixas que chegam à mesma porta, onde o OMS rastreia o fulfillment a nível de pacote/SSCC.
- Qualquer um que hoje codifique "3 caixas" no label do stop ou num custom field e queira uma lista de primeira classe com status no lugar.
O modelo de dados completo (packages vs tasks vs capacidade), o lifecycle pending → picked → delivered, o código TS/Python/cURL, o production hardening (delivery-only, entregas parciais, reconciliação sem webhook de package) e os common errors vivem em inglês.
Distribuição capacitada
Quando peso, volume, cadeia de frio ou equipamento especialista são inegociáveis. O otimizador respeita cada restrição declarada; o custo de não declarar é um caminhão que fica sem espaço na terceira parada e precisa voltar ao depósito.
Última milha e-commerce
Entrega de pacotes B2C — os pedidos fluem do seu OMS ou WMS para a Routal ao longo do dia, o otimizador os agrupa em rotas densas por bairro, os motoristas executam com tasks de scan de barcode, e os clientes recebem tracking links automaticamente.