Saltar al contenido principal

​
22 de junio de 2026 — Nueva guía: Estructura de productos · Publicación de menús actualizada

​
Nueva guía: Estructura de productos

Nueva página Estructura de productos en la pestaña Guías — cubre el tipo COMBO y los overrides de modificadores:
  • Tipo COMBO — priceInfo.price es siempre 0; usar priceInfo.referencePrice como precio de encabezado del producto.
  • Precio de referencia — suma de (opción más barata × minOptions) en cada grupo de modificadores obligatorio (minOptions ≥ 1).
  • Overrides de modificadores — productModifiers[n].overrides define un precio diferente para una opción dentro de un combo específico; tiene precedencia sobre el precio base del producto en products[].
  • Precios delta — grupos obligatorios muestran +R$ X respecto al baseline; grupos opcionales muestran el precio completo del add-on.

​
Guía de publicación de menús

  • Eliminada la sección menus.sync — ese evento ya no existe.
  • Corregido el formato del payload: event es ahora un objeto anidado (id, type, executionId, createdAt), no campos al nivel raíz.
  • El paso de verificación de firma ahora especifica que el signing secret se obtiene en Integraciones de agregadores en el dashboard de Fire.
  • Añadida sección de estructura del menú con descripción de list, categories, products (tabla de tipos) y modifierGroups.
Actualizado en EN / ES / PT.

​
15 de junio de 2026 — order.completed — nuevos campos de método de pago

Añadidos 4 campos a payments.paymentMethods[n] en el evento order.completed. Todos son nullable y ya están en producción.
  • idAuth (string | null) — ID de autorización del procesador de pago (ej. SiTef IdAuth). Distinto de authorizationCode.
  • receiptCustomer (string | null) — Texto completo del comprobante para el cliente; puede ser multilínea.
  • receiptMerchant (string | null) — Texto completo del comprobante para el comercio; puede ser multilínea.
  • acquirer.cnpj (string | null) — CNPJ de la credenciadora de pago — solo Brasil.
Actualizado en EN / ES / PT.

​
15 de junio de 2026 — Campos de detalle de método de pago

Añadidos 5 campos opcionales a payments.paymentMethods[n] en Inyectar orden:
  • id_auth (string | null) — Número de autorización NFCE (SiTef 952 / IdAuth).
  • receipt_customer (string | null) — Vía del cliente: texto del comprobante impreso para el portador (SiTef 121 / ReceiptCustomer).
  • receipt_merchant (string | null) — Vía del comercio: texto del comprobante impreso para el establecimiento (SiTef 122 / ReceiptMerchant).
  • acquirer.cnpj (string) — CNPJ de la credenciadora para NFCE (SiTef 950 / CNPJAuth). acquirer queda documentado como nullable — enviar null para métodos sin credenciadora.
  • card.media (string) — Tipo de lectura de la tarjeta: CHIP, MAGNETIC, NFC, MANUAL (SiTef 2090 / Media). card queda documentado como nullable — enviar null para métodos sin tarjeta.
Todos los campos son opcionales y ya están implementados en el validador. Actualizado en EN / ES / PT.

​
14 de junio de 2026 — Webhook de estado de orden de agregador

  • Nuevo webhook entrante POST /v1/webhooks/aggregators/order-status — tu agregador de delivery (Rappi / Uber / Didi / iFood / PedidosYa / Glovo…) hace POST con el estado de entrega de la orden a medida que avanza (courier_assigned → on_route → delivered…). Fire refleja el último estado en orders.aggregator y registra cada evento.
  • El estado es passthrough — no se impone ningún enum; las etiquetas propias del agregador se guardan tal cual, y el estado actual es el del occurredAt más reciente (sin compuerta anti-regresión). Las etiquetas amigables y traducidas se resuelven al momento de mostrar desde el catálogo del canal.
  • Correlación flexible de la orden — envía orderId (UUID de Fire) y/o externalOrderId (tu referencia, comparada contra metadata.order_id); al menos uno es requerido, ambos vendor-scoped. Si envías ambos y correlacionan a órdenes distintas → 409.
  • No hay un eventId emitido por Fire para ecoar — un estado de agregador es un evento externo espontáneo (Fire no es la fuente de verdad aquí). La idempotencia se llavea por (channelCode, providerEventId) + status; channelCode debe ser igual al metadata.channel.code de la orden.
  • Auth: API key vendor-scoped con el nuevo scope webhooks:aggregator. 202 async + cola, mismo envelope que los callbacks fiscal / KDS.
  • Documentado en EN / ES / PT.

​
12 de junio de 2026 — Descuentos del agregador en Inyectar orden

Documentado cómo enviar descuentos promocionales del agregador (iFood, Rappi, UberEats, etc.) en el endpoint Inyectar orden.
  • Los descuentos del agregador son un método de pago, no una fila de descuento. Cuando el agregador aplica un descuento al cliente, el local recibe el importe completo y el agregador reembolsa la diferencia — modélalo como una entrada extra en payments.paymentMethods[] con paymentMethodCode: "AGGREGATOR_DISCOUNT", transactionType: "BENEFIT", processor con el nombre del agregador y card: null.
  • payments.discounts[] queda vacío para descuentos del agregador — ese array es solo para promos/cupones que absorbe el local.
  • Nueva regla de balance documentada: SUM(paymentMethods[].totalBill) debe ser igual a productos + cargos extra + envío.
  • Nuevo ejemplo de request con una orden de iFood (BRL 38.69 CREDIT + BRL 1.00 AGGREGATOR_DISCOUNT = BRL 39.69 bruto).
  • Actualizado en EN / ES / PT.

​
11 de junio de 2026 — Nomenclatura underscore + payload thin de cierre de día

  • Nombres (breaking) — store.day-closed → store.business_day_closed y order.status-updated → order.status_updated (nomenclatura underscore). Actualiza tu switch de event.type.
  • store.business_day_closed ahora es un payload thin — identidad del cierre (businessDayId, businessDayDate, timezone, status), timing (openedAt/closedAt), closedBy y una store mínima (uid, code, externalId, countryCode, timezone, currencyCode). Removido del evento: sales, metrics, summary, byChannel, byPaymentMethod, forceClosedOrders, closureStats, cancelledOrders, metadata — consúltalos por businessDayId cuando los necesites. snapshotId renombrado a businessDayId (mismo valor).
  • Documentado en EN / ES / PT.

​
10 de junio de 2026 — Eventos canónicos de orden + evento de cocina

Los eventos fiscales pierden el país del nombre y pasan a ser canónicos de orden — sigue siendo el contrato v1, solo cambia el event.type:
  • fiscal.authorized.br → order.invoiced y fiscal.cancelled.br → order.reversed. Si tu integración despacha por event.type, actualiza el switch — el payload no cambia de forma.
  • Ahora disparan para todos los países: Brasil (SEFAZ vía tu proveedor fiscal) y CO/EC/CL/AR/VE vía el callback fiscal genérico. El país viaja en fiscal.countryCode.
  • Nuevo evento order.status_updated — el KDS avanza la orden en cocina (preparing → ready → dispatched), con bloque kitchen y el recorrido completo en history.
  • Fire es la fuente de verdad — los webhooks entrantes (callback fiscal, estados KDS) ahora validan que eventId referencie un evento emitido por Fire para esa orden; si no, responden 400 antes del 202. Ecoa siempre el event.id de un envelope que recibiste.
  • Documentado en EN / ES / PT.

​
9 de junio de 2026 — Contrato de eventos v1

El contrato de eventos de orden/fiscal/cierre es ahora oficialmente v1. Todas las adiciones son retrocompatibles (campos opcionales nuevos); la forma anterior se preserva como v0 (deprecada, histórica) — cambia con el selector de versión arriba de cada página de evento.
  • Descuentos — descuentos de orden y de producto viajan como objeto Discount (priority, type FIXED/PERCENTAGE, value, net_price, discount_value, net_price_after_discount) en payments.discounts, payments.totals[].discounts y orderLines[].price.*[].discounts + lineTotals[].discounts.
  • Impuestos granulares — taxes[] ahora lleva los impuestos de la reforma BR IBS_UF, IBS_MUN, CBS junto a ICMS/PIS/COFINS, con metadata de reforma (cClassTrib, reducao, rateNominal, rateEffective). El desglose es uniforme en todos los países — LATAM lleva su IVA local en el mismo taxes[]; solo la emisión SEFAZ (metadata.fiscal, fiscal.*.br) es BR-only.
  • itemType — enum completo: PRODUCT / COMBO / MODIFIER / PACKAGING.
  • fulfillment.delivery.deliveryConfirmationCode — código de confirmación del agregador (ej. iFood / Rappi).
  • store.business_day_closed — sales ahora incluye product_discounts, gross_before_discounts, shipping, extra_charges, total_charged y taxes_by_type. (Superado el 11 de junio — estos agregados ya no van embebidos en el evento; el payload de cierre ahora es thin. Ver la entrada de arriba.)
  • order.cancelled / order.invoiced / order.reversed — llevan el snapshot v1 de orden.
  • Documentado en EN / ES / PT con ejemplos actualizados.

​
8 de junio de 2026

  • menu.updated: añadido productModifiers[n].overrides[] — permite definir un precio diferente para una opción específica de modificador cuando pertenece a un producto concreto. Cada override apunta a un productId y proporciona su propio priceInfo.price y priceInfo.salePrice. Actualizado EN/ES/PT.

​
5 de junio de 2026

  • menus.sync: página eliminada — Fire envía un único evento menu.updated por menú; la sincronización en lote ya no es un evento separado.
  • menu.updated: campo event.timezone eliminado del payload. Añadido data.groupId — UUID que identifica el batch de sincronización; varios eventos emitidos juntos comparten el mismo valor, lo que permite correlacionarlos en sistemas externos. Los arrays schedules de categorías y productos ahora incluyen ejemplos completos de 7 días con distintas ventanas de horario por categoría (p. ej. Hamburguesas 11:00–23:00, Desayunos 07:00–11:00). Campo standardTime en productos documentado: true hereda los horarios del menú, false significa que el producto tiene su propio array schedules. Actualizado EN/ES/PT.
  • Inyectar orden: el campo type es ahora obligatorio en cada ítem de order.products[], en cada ítem de selectedModifiers[] y en cada ítem de payments.extraCharges[]. Valores aceptados: COMBO (producto con grupos de modificadores no vacíos), PRODUCT (producto simple vendible o opción vendible dentro de modificadores), MODIFIER (opción de modificador puro), PACKAGING (ítem de empaque). Los payloads que omitan type son inválidos. Ejemplos de petición actualizados en EN/ES/PT.
  • Inyectar orden: documentado shippingMethod.delivery.additionalInfo.deliveryConfirmationCode como string opcional para enviar el código de confirmación de entrega.

​
1 de junio de 2026

  • Inyectar orden: secciones Montos y tramos de precio y Envío y descuentos; tres ejemplos de petición conciliados (entrega simple, descuento en línea + envío, varios productos + descuento de orden); énfasis en payments.shippingCost[], payments.discounts[] y discountsValue por producto (EN/ES/PT).

​
27 de mayo de 2026

  • menus.sync: ejemplo de payload completo (categorías, productos, grupos de modificadores, horarios); data.menus[] reemplazado por data.menu (un menú por evento); páginas EN/ES/PT en webhook reference.
  • menu.updated: estructura general alineada con menus.sync — campos del catálogo (list, categories, products, modifierGroups, scheduledActivities) anidados bajo data.menu; tablas de campos y ejemplo de borrado actualizados.
  • Guía Publicación de menú (EN/ES/PT): ejemplos y pasos de procesamiento actualizados para data.menu.
  • Inyectar orden: campo opcional comment documentado en order.products[]; ejemplo de petición actualizado (sustituye productComment).
  • menu.updated / menus.sync: los productId de las opciones de modificador deben existir en products; el ejemplo incluye prod_size_small y prod_size_large.
  • menu.updated: corregida la indentación del ejemplo principal del payload bajo data.menu.
  • Webhooks de menú (menu.updated, menus.sync, product.updated): data.country documentado y ejemplificado como ISO 3166-1 alpha-2 (p. ej. EC, BR, CO) en lugar de un ID numérico de país.

​
26 de mayo de 2026

  • Agregada la pestaña Manuales de usuario como sección principal de la navegación.
  • Agregados manuales de FIRE POS V2 para Vinculación, Cajeros y Códigos de autorización en inglés, español y portugués.
  • Agregadas imágenes placeholder sutiles para las capturas pendientes de POS, manteniendo la estructura visual final de las guías mientras se preparan las capturas.
  • Inyectar orden: eliminado el campo order.stock del cuerpo (no aplica al contrato). Ejemplo de respuesta 200 actualizado al sobre real (data, isArray, status, method, pathname, duration, traceId).
  • Login (playground): authMethod: none, URL absoluta de staging en el frontmatter api:, cabecera Content-Type con valor por defecto y grant_type por defecto para evitar el error Missing required fields al usar Probar.
  • Inyectar orden: price de línea de producto documentado con todos los campos del tramo de precio y taxes[] (name, rate, amount, metadata opcional).
  • Inyectar orden: payments.shippingCost[] y payments.discounts[] documentados como las mismas filas de tramo de precio que totals[]; ejemplo de petición actualizado con líneas de envío y descuento.
  • Cancelar orden: referencia API actualizada a la ruta de agregador POST /api/v4/integrations/sales/aggregator/orders/{order_uid}/refund, con campos de cancelación/reembolso y sobre estándar de respuesta; movida debajo de Inyectar orden en la referencia API.

​
11 de mayo de 2026

  • Nueva pestaña Cambios al final de la navegación y esta página inicial.
  • Eliminada la página de canales de venta (listado) y su entrada en la navegación (todos los idiomas).
  • Intro de la API: texto ajustado; retirada la tarjeta de canales de venta.
  • Inyectar orden: documentada la cabecera Authorization (EN). ES y PT: ruta, cabeceras y cuerpo actualizados al contrato actual de integración (objetos de canal/servicio, dispositivo, operador, ejemplos).
  • Login (ES y PT): alineado con POST /api/authentication/login y respuesta accessToken (client credentials).
  • Inicio en español (/es/): contenido revisado.
  • Configuración: nueva guía Integraciones de agregadores (panel Fire: endpoints de webhook y eventos de prueba).