Online & Delivery Orders on Third Party Kitchen Video
Who this is for: venue managers, kitchen managers and NX support handling a site that runs third-party kitchen video systems (3P-KDS) (i.e. Crunchtime Kitchen (ConnectSmart Kitchen / formerly QSR Automations)) as its kitchen display.
What it covers: how orders that come from outside the POS β your own online ordering, DoorDash, UberEats, Grubhub and other delivery partners, and subscription orders β reach the 3P-KDS screens, what they look like when they get there, and what to check when one doesn't arrive.
1. The short version
Orders your staff ring on the register have always appeared on 3P-KDS. Orders that arrive from the internet are different: they're built in the cloud, not on a terminal.
For those, NX now does this:
- The order arrives and NX prepares it for the kitchen.
- NX builds the 3P-KDS ticket in the cloud and queues it for one terminal in your store.
- That terminal sends it to your 3P-KDS server over the local network.
- The ticket appears on the kitchen screens, alongside everything rung in-store.
Why a terminal is involved at all: 3P-KDS kitchen server lives inside your store, on your network. Our cloud can't reach it directly and can't confirm delivery if it tries β so one of your terminals passes the order across on the cloud's behalf. That terminal doesn't decide anything about the order; it just delivers it.
The order also reaches your NX printers and NX kitchen screens exactly as before. 3P-KDS is additional β nothing about your existing setup changes.
2. What you need for it to work
| Requirement | Where | Notes |
|---|---|---|
| A 3P-KDS integration with a server address | Portal β venue β Integrations β example: QSR Automations β Primary Server Host | This is the on/off switch. No address = nothing is sent. |
| Server port | same screen | Defaults to 32768 if left blank. |
| Site ID | same screen | Defaults to 0 if left blank. |
| A relay terminal (optional but recommended) | same screen β POS Device | See below. |
| Second server address | same screen β Secondary Server Host | Optional backup. Sent to as a courtesy; never delays the primary. |
Which terminal sends the order
- If you nominate a terminal in the integration settings, that terminal sends every external order.
- If you leave it blank, NX automatically uses your lowest-numbered station and records a notice once a day so support can see it wasn't set.
Nominate one deliberately. Pick a terminal that is:
- always powered on during service,
- on the same network as the 3P-KDS server,
- not something staff carry around or let sleep (a fixed station beats a handheld).
The nominated terminal does not need to be the one taking orders, and it doesn't need to be in the kitchen. It just needs to be awake and on the network.
3. What the kitchen sees
A relayed order arrives as a normal 3P-KDS check containing:
| On the ticket | Where it comes from |
|---|---|
| Check number | the order's NX check number (online orders use a high range, e.g. 999001) |
| Every item, with modifiers | the order as the guest built it |
| Item notes | shown as their own line under the item |
| Guest name | the customer account, or the delivery/contact name on the order |
| Delivery partner | e.g. DoorDash / UberEats, where the order came from a partner |
| Promise time | the order's due time β pickup and scheduled delivery |
| Paid / unpaid | most online orders are already paid |
| Guest count, table, tent number | where the order has them |
| Terminal | always 999 for cloud orders, so kitchen staff can tell at a glance that it didn't come from a register |
Timing. The ticket is queued at the same moment NX prints its own kitchen chits β so if you also run NX printers, the two should appear together. For a scheduled or pre-order, that moment is when the order is released for making, not when the guest placed it. A lunch pre-order placed at 9am appears when it's due to be prepared, not at 9am.
4. What is deliberately not sent
These are working as designed β not faults:
- Held orders. If your online ordering area is set to hold orders for release, nothing goes to 3P-KDS on arrival. The order goes across when a staff member releases it, exactly like an in-store order. A partly held order sends only the items that were released.
- Self-order kiosk orders. A kiosk is a register, so it sends its own orders through the normal path. Relaying them again would put them on the line twice.
- Cancelled or voided lines. Removed items are never sent.
- An order with nothing to make. If every line is held or voided, no ticket is created at all.
Cancellations
If a delivery partner or your staff cancel an order that already reached 3P-KDS, the ticket is pulled from the kitchen screen automatically. NX only sends a cancellation for an order 3P-KDS actually accepted β if the order never landed, there's nothing to pull, and no cancellation is sent.
5. Troubleshooting
Work down the list. The first four checks resolve most cases.
An online or delivery order didn't appear on 3P-KDS
1. Did it appear on your NX printers or NX kitchen screens?
- No, nowhere at all β this isn't a 3P-KDS problem. The order didn't reach the store. Check the order shows on the POS order list, and treat it as a missing-order issue.
- Yes, but not on 3P-KDS β continue below.
2. Is the order actually meant to be sent yet?
- Is the area set to hold online orders? Then it's waiting for release β release it and it will go.
- Is it a scheduled/pre-order? It sends when it's due to be made, not when it was placed.
- Is it a kiosk order? Those come from the register path, not this one.
3. Is the relay terminal awake and on the network?
This is the single most common cause. Check the nominated terminal is:
- powered on and not asleep or locked behind a black screen,
- connected to the venue network (not dropped onto a guest SSID),
- not sitting on a "no connection" banner.
Wake it. A queued order stays queued β a terminal that comes back within about two hours will pick up anything outstanding, and it also re-checks for missed orders every minute. Orders older than two hours are deliberately left alone rather than sent late.
4. Is the 3P-KDS server reachable from that terminal?
- Can other terminals see the kitchen? If in-store orders are also missing from 3P-KDS, the problem is the kitchen server or the network, not this feature.
- On the relay terminal: Device Info β Third-Party Kitchen shows whether the integration is reachable and reports its status.
5. Was the server address changed recently?
Clearing or mistyping the Primary Server Host in Portal stops all sending immediately. Re-enter it and confirm the port and Site ID.
Only some orders are missing
- Everything from one partner (e.g. only DoorDash): check that partner's orders are actually reaching NX at all β look for them on the POS order list first.
- Only held orders: expected. See Β§4.
- Only large orders: unlikely to be this feature; capture one example and escalate.
Modifiers are missing from a ticket
Modifiers dropping off a ticket while the item itself appears was a known fault and has been fixed. If you still see it, capture the check number and escalate β include whether the item was a repeat of another line on the same order.
The order appeared on 3P-KDS twice
Duplicates should not be possible; each order is delivered once and tracked. If you see one:
- Note both check numbers and whether they're identical.
- Check whether a staff member also rang the order manually on a register.
- Escalate with the check number β this needs looking at.
A cancelled order is still on the kitchen screen
- Was the order ever on 3P-KDS? If it never arrived, no cancellation is sent (nothing to pull).
- Cancellations are sent as soon as NX learns of them, but they still travel through the relay terminal β so if that terminal is asleep, the cancellation waits with it. Wake it.
- If the ticket is still up after the terminal is confirmed awake and online, pull it manually on the 3P-KDS screen and escalate.
Nothing has ever worked at this site
Confirm in order:
- The venue has a 3P-KDS integration with a Primary Server Host filled in.
- A relay terminal is nominated (or accept the automatic lowest-station choice).
- That terminal has been restarted since the setting was saved β settings sync automatically, but a restart removes any doubt.
- The terminal is running a build that supports this feature. If it's an older build, external orders are ignored rather than sent β safely, but silently. Update it.
6. When you escalate
Support can trace an order end to end, but only with the identifiers. Include:
- Venue name
- Check number and the order time
- Where it came from β your online ordering, or which delivery partner
- Which terminal is nominated as the relay (name or station number)
- What did appear β NX printer chit? NX kitchen screen? 3P-KDS? None?
- Any error on the 3P-KDS screen or its logs, quoted exactly
- Whether the order was held, scheduled, or cancelled
If the site has cloud logging enabled on the integration, support can also see the exact order data that left the terminal β worth asking for it to be switched on if a site has recurring trouble.
7. Good to know
- This feature can't affect your in-store orders. Orders rung on a register reach 3P-KDS by a completely separate path that this doesn't touch.
- It can't stop an order reaching the guest. The relay sits alongside the order; it never blocks the order, the receipt, or payment. A relay failure means a kitchen ticket is missing β never a lost sale.
- Turning it off is immediate: clear the Primary Server Host (stops everything) or clear the nominated terminal (falls back to the lowest station).
- If 3P-KDS refuses an order, the terminal tries again a few times and then records it as not delivered. Nobody is watching a screen for a cloud order the way staff watch one they rang, so it's worth checking the kitchen screen against your order list during a busy service the first few days after go-live.