Endereço na criação do pedido

Novidade · POST /v1/orders

customer.address.latitude e customer.address.longitude são opcionais. Sem os dois, a API localiza o ponto com o endereço informado (street, number, city, state e, quando houver, postalCode, neighborhood e complement) e grava as coordenadas no pedido. Se o cliente já enviar latitude e longitude, esses valores são mantidos.

A resposta 201 continua só com { "orderId" }. As coordenadas voltas em GET /v1/orders/:id, em delivery.address.latitude e delivery.address.longitude, e no endereço do cliente em GET /v1/customers/:id.

Se a localização não resolver, o pedido é criado do mesmo jeito. As coordenadas ficam ausentes.

Pedido com delivery.deliveryType DELIVERY exige customer.address. TAKEOUT e DINE_IN recusam endereço.

Em customer.address:

• obrigatórios: street, number, city, state
• neighborhood ou postalCode: um dos dois basta; os dois juntos também
• opcionais: complement, latitude, longitude
• postalCode aceita 01310-100 ou 01310100 e é gravado só com dígitos

A API procura um endereço já cadastrado daquele cliente por CEP (só dígitos), logradouro e número. Se achar, atualiza. Se não achar, cria. Cliente e endereço entram na mesma transação do pedido: se o pedido falhar, nada disso fica gravado.

Quem já criava delivery sem endereço passa a receber 422 'customer.address' is required when 'deliveryType' is DELIVERY.

Quem envia endereço em retirada recebe 422 'customer.address' is not allowed when 'deliveryType' is TAKEOUT. Em consumo local, a mesma mensagem, com DINE_IN no lugar de TAKEOUT.

Sem bairro e sem CEP: 400 'customer.address.neighborhood' or 'customer.address.postalCode' is required.

"customer": {
  "customerName": "Maria Oliveira",
  "phone": { "number": "11988887777", "extension": "+55" },
  "address": {
    "street": "Av. Paulista",
    "number": "1000",
    "neighborhood": "Bela Vista",
    "city": "São Paulo",
    "state": "SP",
    "postalCode": "01310-100"
  }
}

Esse body não traz latitude nem longitude. A API calcula as duas.