Negocio de prueba

Qué es un negocio de prueba#

Un negocio de prueba es un restaurante en Flavoso que solo existe para la API. No cuesta nada, no necesita suscripción y, de forma predeterminada, está abierto las 24 horas. A efectos de la API cuenta como plan Pro: todas las rutas están disponibles, también las de reservas.

Cada cuenta tiene como máximo un negocio de prueba, y todas tus apps lo comparten. Incluye una carta de ejemplo con categorías, platos y un grupo de opciones, además de mesas. Lo gestionas desde la consola, en Negocio de prueba, en cinco pestañas: Negocio, Pedidos, Reservas, Carta y Eventos.

Crear y usar#

1. 1

   Crear

   «Crear negocio de prueba»: un clic y ya está. En el asistente de configuración es el segundo paso.

   Consola › Negocio de prueba

2. 2

   Conectar la app

   Con un token de prueba o mediante el flujo de OAuth, eligiendo el negocio de prueba. Solo a partir de ese momento se generan eventos: sin una app conectada con el permiso adecuado, no hay nadie escuchando.

3. 3

   Probar

   Pedir y reservar como cliente, responder como negocio: hacer avanzar los pedidos, pausar, cambiar el horario, marcar platos como agotados. Cada cambio llega a tus apps conectadas como evento.

   Consola › Negocio de prueba

Como un negocio real#

Para tu app, el negocio de prueba se comporta como uno real: las mismas rutas, los mismos eventos, los mismos errores. Los pedidos y las reservas de prueba siguen el mismo camino que los de un cliente, y si haces avanzar un pedido en la consola, haces exactamente lo mismo que la cocina. Cada cambio llega a tu app como evento, por webhook o a través de GET /events. Hay tres diferencias:

• livemode es false, en GET /me y en cada evento. Un negocio de prueba nunca puede convertirse en un negocio real.
• Los pagos online son simulados: un pedido de prueba que creas como pagado online desencadena order.created y, justo después, order.paid, sin proveedor de pagos y sin dinero de por medio.
• El negocio de prueba guarda como máximo 50 imágenes de image_url. Por encima de ese límite, PUT /menu no descarga más y avisa con images_capped; al restablecerlo, se borran.

Las herramientas#

Las pestañas del negocio de prueba en la consola hacen lo que, si no, harían los clientes, la cocina, la recepción y el panel. Se actualizan solas en cuanto algo cambia en el negocio de prueba, incluso cuando es tu app la que hace el cambio a través de la API.

Más sobre las herramientas de tu app en Herramientas.

Carta y sincronización#

La pestaña Carta muestra la carta del negocio de prueba exactamente como GET /menu se la devuelve a una app conectada, con los identificadores de esa app (external_id). Lo que no lleva ningún identificador de esa app aparece marcado: una sincronización nunca lo toca.

1. 1

   Asignar identificadores

   Para cada objeto sin identificador, guarda uno sugerido como external_id de tu app, por ejemplo demo-pizza-margherita. Platos, precios y opciones quedan como están, y no se genera ningún evento.

   Consola › Negocio de prueba › Carta

2. 2

   Sincronización de ejemplo

   Un cuerpo listo para PUT /menu con la carta tal como está ahora, en modo merge o replace y siempre con dry_run. Puedes copiarlo o abrirlo directamente en el explorador de API.

   Consola › Negocio de prueba › Carta

3. 3

   Sincronizar

   Tu app envía su carta. Con identificadores asignados, la sincronización solo cambia lo que difiere; una simulación lo muestra antes.

4. 4

   Comprobar

   «Últimas sincronizaciones» muestra cada PUT /menu de tus apps con modo y resumen, junto a los eventos menu.synced. Estos solo se generan cuando una sincronización cambia algo de verdad.

   Consola › Negocio de prueba › Carta

«Restablecer la carta» vacía la carta o vuelve a crear la de ejemplo; los pedidos, los horarios y las conexiones se mantienen, y las imágenes descargadas de image_url se borran con ella. Cada categoría, plato y grupo borrado genera un menu.*.deleted (las opciones se borran con su grupo), y cada objeto nuevo, un menu.*.created, también cada opción. La consola te indica antes cuántos serán. En Sincronizar la carta se explica cómo funciona la sincronización.

Seguir los eventos#

La pestaña Eventos muestra los últimos 30 eventos del negocio de prueba. Para cada app conectada indica qué hizo su webhook con ellos (entregado, esperando el siguiente intento, fallido u omitido, con el motivo) y si la app ya los ha recogido con GET /events.

• Sobre: una fila se despliega y muestra el evento exactamente como lo recibe la app elegida.
• Reenviar: volver a enviar una entrega, con el mismo identificador de evento.
• Enviar al webhook: enviar al webhook de una app un evento sin entrega, por ejemplo uno anterior a la configuración del webhook o de un tipo al que no está suscrito.
• Recoger desde aquí: copiar la llamada GET /events cuya respuesta empieza exactamente con este evento.

Puedes hacer como máximo diez envíos por minuto y app, sumando los de «Reenviar» y «Enviar un evento de prueba» en Webhooks. Los eventos de prueba y ping nunca aparecen en GET /events; la pestaña lo indica donde corresponde.

Restablecer#

«Restablecer el negocio de prueba» borra todos los pedidos y reservas, vuelve a crear la carta de ejemplo, pone fin a una pausa, borra los días especiales y devuelve el horario, los tipos de pedido, los tiempos de preparación, los encargos, el pedido mínimo, las propinas, la zona de reparto y las reservas a su estado inicial. Las imágenes descargadas de image_url se borran. Las mesas y las conexiones se mantienen.

• La carta genera los mismos eventos que con «Restablecer la carta»: cada objeto borrado, un menu.*.deleted; cada objeto nuevo, un menu.*.created. Así, una caja que replica la carta ve que los platos con sus identificadores ya no existen.
• Si cambian el horario, los días especiales, los tiempos de preparación, los tipos de pedido, los encargos o el pedido mínimo, llega store.updated, y store.resumed si había una pausa en curso.
• Los pedidos y reservas borrados no generan ningún evento.

Puedes restablecer como máximo cinco veces cada diez minutos, contando también «Restablecer la carta».

Distinguir entre prueba y real#

livemode está en GET /me y en cada evento. En el negocio de prueba es false, en cualquier negocio real true. Compruébalo allí donde tu app haga algo real: un pedido de prueba no debe acabar en ninguna caja real.

// Test and live share one API, one address and one token format. livemode tells them apart.
const me = await fetch("https://api.flavoso.com/v1/me", {
  headers: { Authorization: `Bearer ${accessToken}` },
}).then((r) => r.json());
if (!me.livemode) console.log(`Connected to the test restaurant "${me.tenant.name}"`);

// In the webhook handler: never book a test order into a real till
export function handleEvent(event) {
  if (!event.livemode) return handleTestEvent(event);
  return handleLiveEvent(event);
}

Probar con un negocio real#

Incluso antes de la aprobación, tu app puede conectarse también con negocios de los que tú mismo eres propietario. Está pensado para la prueba final con la carta real.