The browser does not print kitchen tickets. The backend owns routing and creates durable print jobs, which is what makes the system resilient when a printer fails mid-service.
The chain
- An order is placed in Restaurant POS.
- The order API applies kitchen station routing, deciding which station each item belongs to based on its product group.
- A durable print job is created for each station.
- The local bridge polls for pending jobs, renders each into a ticket, and sends it to the mapped local printer.
- The bridge acknowledges success or reports failure back against the job.
Configuring routing
- Assign every sellable dish and drink to a product group.
- Map each product group to a kitchen station: hot kitchen, cold kitchen, tandoor, bar, dessert.
- Map each station to a physical printer through the bridge’s station target mappings.
An item whose product group is not mapped to a station will not produce a ticket. If a dish never reaches the kitchen, check its product group first.
Why jobs are durable
Because the job exists independently of the browser session, a printer that is offline, out of paper or unplugged does not lose the ticket. The job stays pending and is retried. Compare this with printing straight from a browser dialog, where a failure is simply lost.
Kitchen Display System
If you prefer screens to paper, the KDS view shows the same routed orders per station, and the pass display gives the expediter a consolidated view of what is ready.
Did this answer your question? If not, our support team can look at your actual configuration.
Contact support