Set up printers and receipts

Find the printer settings

Open Settings and click Kitchen printer in the left-hand nav — the printer icon, sitting between Team and Payments. Kitchen printing comes with the Full plan, and it's open to owners, admins and editors alike, the same as most of Settings' content sections.

The card itself is upfront about where it stands: a Beta chip next to the heading, and four short lines above the printer list that are worth reading once — kitchen printing is in beta, no printer model has been verified on hardware by TableSpark yet, a ticket's print status in Orders is the way to actually confirm it printed, and a delivery ticket's address should be checked for legible printing on the first few tickets. None of that is a caveat about whether the feature works — it's the honest read of what a polling connection to a physical printer can and can't promise, stated plainly rather than smoothed over.

Connect a CloudPRNT printer

With no printer connected yet, the panel shows one button: Add a printer. Pressing it creates a printer row and gives every card a CloudPRNT Server URL — a single web address ending in a long random token, with a Copy button next to it. That URL is the one thing to paste into the physical printer's own CloudPRNT configuration page; the printer then polls TableSpark for work on its own. The token is the printer's only credential — there's no separate login and nothing else to configure on the printer itself.

The first printer you add always becomes the kitchen printer. Add a second and the button changes to Add a front-of-house printer — guest receipts print there, and that second printer takes the role automatically. Once both roles are covered, the Add button disappears entirely and is replaced by a plain note: you already have a kitchen printer and a front-of-house printer, one printer per role, and changing that means changing a role or removing a printer rather than adding a third.

Kitchen or front of house: the role selector

Every printer card carries a role dropdown with two options: Kitchen — kitchen tickets and Front of house — guest receipts. Change it and the card confirms what will print there from that point on. Next to the role, a chip states the traffic plainly — Receives kitchen tickets or Receives guest receipts — so a glance down the printer list tells you exactly what each machine is for.

Routing is automatic, not something you choose per order: the kitchen-role printer gets every automatic kitchen ticket, the front-of-house-role printer gets every guest receipt. With only one printer connected, it receives both — nothing changes for a single-printer restaurant. And the status dot on each card is deliberately neutral, never green or red: “Polling only means the printer asked TableSpark for work. It does not mean it has paper, its cover is shut, or that anything printed.” That's the honest limit of what a poll can tell you, stated on every card rather than implied by a colour.

Edit what prints on the paper

Under Ticket layout — what prints on the paper, every card carries a Heading field (blank keeps *** NEW ORDER ***), a Header for your name, address and phone (up to six lines), and a Footer for a thank-you and your VAT number (up to six lines) — and six Show on the ticket toggles: Order time, Options (+ lines), Dish notes (− lines), Order notes, Paid / pay-at-restaurant line, and Service charge line. These fields hold static text only — there's nowhere to insert an order's own details — which is exactly what keeps a diner's name, phone or address off a dine-in or collection ticket no matter what you type into Header or Footer.

A live preview sits beside the fields and updates as you type or tick a box, rendered by the same code that feeds the physical printer — what you see in the preview is what comes out on the paper. Save ticket layout keeps it; Reset to default clears all three fields and re-checks every toggle. FIG. 03 above shows the kitchen ticket preview in full: the heading and order reference, the restaurant's own header block, the table and time, each dish with its + option lines and − notes, the service charge, the total, a pay-at-restaurant line, and the order note — all from the same sample order, unedited.

The preview is role-specific, one per card: a kitchen-role card shows the kitchen ticket; a front-of-house-role card shows the guest's own receipt instead, built from the same fields. That guest receipt is laid out differently on purpose — a boxed heading with the restaurant's name at the top, an itemised money column, and a VAT breakdown box when the order carries a rated line — and it never carries a customer's name, phone, address or dish notes, even on a delivery order's own copy of the bill.

Send a test print

Print test page on this printer sends a real test ticket straight to that one printer. If the printer's switched off in your account, the button waits, disabled, with a tooltip explaining why — a test only fires at a printer that can actually receive it.

What happens next is reported to you exactly, never optimistically: a confirmed send names the printer it reached and points you to that order's print status in Orders to check the paper; an unconfirmed result means the print service accepted the job but couldn't confirm which printer it reached — it may already have printed on your first connected printer, so the guidance is to check before retrying rather than risk a duplicate; and a mismatch tells you the print service reported a different printer than the one you clicked. Every order also carries its own small print-status chip — Printing…, Printed, Print failed, Print expired, or Print unconfirmed — check the paper — using that same three-way honesty.

Alongside the test button, each card has Rename, a paper width switch between 80mm and 58mm, Rotate token (issues a fresh Server URL — paste the new one into the printer), and Remove.

Where tickets fire automatically

Most of what a kitchen printer does happens without anyone pressing a print button. A new online order routes straight to the kitchen-role printer the moment it comes in. And on the floor, a table order fires the same way: the instant a waiter presses Send order on a table's order pad, the order is saved and a kitchen ticket is queued to the connected kitchen printer in that same action — fire-and-forget, so a printer problem never holds up service. See Take an order in the service guide for the order pad itself.

Print receipt — the guest's own copy, in the boxed layout from step 4 — is a button rather than an automatic fire, and it lives in two places doing the identical thing: on every order in Orders, and inline on the table's till inside the booking sheet on the floor (see Take payment). Reprint sits next to it in both places, for recovering a jammed or missing kitchen copy at any time; a delivery order with no address on it prints DO NOT DISPATCH on the paper itself rather than being refused, so a jammed ticket is never a dead end.

Two roles, one editor each, and every ticket accounted for — the new online order that fires itself, the table order that prints the moment it's sent, and the guest receipt and reprint sitting exactly where the till already is. See Where orders land for the online side of the same tickets.