Tipos de datos especiales

Algunos campos de la API de Ordering usan JSON estructurado. Conserva los nombres de campo y tipos de valor exactos mostrados por el esquema de la operación de destino.

Horarios

Los horarios se usan en recursos como negocios, menús y zonas de entrega. Un horario no nulo contiene exactamente siete objetos de día. Cada día tiene un valor booleano enabled y un arreglo de lapses.

[
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": true, "lapses": [{"open": {"hour": 9, "minute": 0}, "close": {"hour": 17, "minute": 0}}]},
  {"enabled": false, "lapses": []}
]

• open y close contienen campos enteros hour y minute.
• Usa el formato de 24 horas. Las horas van de 0 a 23, y los minutos de 0 a 59.
• Una hora de apertura no puede ser posterior a su hora de cierre dentro del mismo lapso.
• La convención de origen ordena los días de domingo a sábado. El validador actual exige siete entradas y su forma, pero no las etiqueta; conserva el orden exigido por la operación consumidora.

Productos de pedido

La entrada de un producto de un pedido contiene un id de producto, quantity, comment opcional, identificadores de ingredientes y opciones seleccionadas.

La forma numérica heredada sigue siendo compatible con el procesamiento actual de pedidos:

[
  {
    "id": 1309,
    "quantity": 1,
    "comment": "No onions",
    "ingredients": [10],
    "options": [
      {
        "id": 53,
        "suboptions": [174, 175]
      }
    ]
  }
]

La forma de objeto agrega position y quantity para cada subopción:

[
  {
    "id": 1309,
    "quantity": 1,
    "comment": "No onions",
    "ingredients": [10],
    "options": [
      {
        "id": 53,
        "suboptions": [
          {
            "id": 174,
            "position": "left",
            "quantity": 1
          }
        ]
      }
    ]
  }
]

Los valores convencionales de position para ubicar modificadores son left, right y whole; whole también es el valor predeterminado. Estos son valores de uso documentados, no una afirmación de que la API valide position mediante un enum.

El procesamiento de pedidos conserva una posición distinta de whole cuando están habilitados tanto el ajuste de proyecto advanced_product_options como el ajuste de la opción superior with_half_option. Para una ubicación de mitad, se usa half_price de la subopción cuando no es nulo; si es nulo, el backend usa el price completo. El precio de mitad se configura, no se calcula como un porcentaje.

La quantity de la subopción tiene un valor predeterminado de 1 y es independiente de la quantity del producto. El ajuste allow_suboption_quantity de la opción controla si se pueden usar cantidades de subopción, y los valores max configurados pueden limitarlas. La ubicación y la cantidad son distintas; esto no define cómo cuenta una ubicación de mitad para el número de selecciones del grupo.

El backend distingue el valor numérico 0 de null, pero la interfaz de cliente revisada usa una comprobación de verdad para este precio. No des por hecho que todos los clientes muestran de forma consistente como gratis un precio de mitad en cero.

Para el flujo de Website, consulta Personalizar y agregar un producto. Para la configuración, consulta Configurar opciones de productos; para los campos de precio de la subopción, consulta el modelo de subopción de opción de extra.

Ubicaciones

Las ubicaciones usan latitud y longitud:

{
  "lat": 40.8065,
  "lng": -73.9536
}

Polígonos

Un polígono es un arreglo de al menos tres ubicaciones distintas:

[
  {"lat": 40.8065, "lng": -73.9536},
  {"lat": 40.8083, "lng": -73.9436},
  {"lat": 40.8013, "lng": -73.9375}
]

La validación de zona de entrega normaliza lat y lng a valores numéricos y rechaza polígonos malformados.

Zonas de entrega basadas en radio

El contrato heredado usa el nombre de campo radio para el radio. Conserva esa clave literal.

{
  "center": {
    "lat": 40.8065,
    "lng": -73.9536
  },
  "radio": 10
}

La documentación de origen describe radio en kilómetros. Confirma la unidad en la operación de destino antes de calcular o transformar datos de zona de entrega.

Datos de cliente

Los objetos de cliente pueden incluir campos de identidad, contacto, dirección y ubicación. Usa datos sintéticos en ejemplos y envía solo los campos aceptados por la operación de destino.

{
  "id": -1,
  "name": "Example",
  "lastname": "Customer",
  "email": "customer@example.com",
  "address": "100 Example Street",
  "address_notes": "Leave at reception",
  "zipcode": "10001",
  "cellphone": "5550100",
  "phone": "5550101",
  "location": {
    "lat": 40.7314,
    "lng": -73.997
  },
  "map_data": {
    "library": "google",
    "place_id": "example-place-id"
  }
}

El contrato histórico usa id: -1 para un cliente no registrado. Verifica ese comportamiento frente a la operación que acepta el objeto de cliente.

Datos de mapa

map_data puede ser null o un objeto que contiene el proveedor de mapas y el identificador de lugar:

{
  "library": "google",
  "place_id": "example-place-id"
}