Square KDS: supported low-latency Kitchen/Bar completion and recall

Questions
1

We integrate a customer collection display with Square Restaurants/KDS. One customer order contains food and drinks routed to separate Kitchen and Bar KDS devices. Each station independently completes its items.

Our real test produced order.fulfillment.updated with PROPOSED → PREPARED; authoritative RetrieveOrder returned one IN_STORE fulfillment applying to ALL items, without station/item readiness.

What supported production API/webhook exposes independent station completion and recall, correlated to order ID, line-item ID and station/device-code ID?

Your preview Reporting schema exposes KitchenPerformanceItems.completed_at, recalled_at, device_id and order identifiers, but documented freshness is approximately 15 minutes. Is there a supported low-latency equivalent or partner interface?

Can normal POS/KDS configuration produce independently updated Food/Drinks fulfillments while preserving one customer order/ticket? Please identify required settings, permissions, availability and completion/recall semantics.

3

No, there’s no supported low-latency public API or webhook for per-station KDS completion/recall today.

Webhooks: order.fulfillment.updated only carries fulfillment_uid, old_state, new_state, order_id, and location_id — no line-item or KDS device granularity, which matches what you observed. (event reference)

Orders API: OrderFulfillment.line_item_application and entries do model per-line-item fulfillment, but both are Beta and read-only, so you can’t author independent Food/Drinks fulfillments on one order. Your single IN_STORE / ALL result is expected. (OrderFulfillment) Note IN_STORE itself is still closed beta.

Reporting API: KitchenPerformanceItems genuinely does give you completed_at, recalled_at, device_id, plus order_id and order_line_item_id (joinable to the Orders line-item uid) and a station_type dimension, so the correlation you want exists, just not in real time. Two caveats beyond the latency: the cube is marked preview, and rows are only written for completed kitchen tickets, so it can’t drive live expo state. Most cubes carry roughly a 15-minute delay, and Square’s own guidance is “for real-time order data, use the Orders API instead.” (data freshness).

Configuration: Station routing will correctly split food and drinks onto separate Kitchen and Bar screens, and each station bumps independently — but that state stays inside KDS. No POS/KDS setting surfaces it as separate, independently-updated fulfillments on the order while preserving one ticket.

Practical path: poll RetrieveOrder/SearchOrders for order-level state in real time, use KitchenPerformanceItems for after-the-fact station analytics, and track live per-station readiness in your own system. If near-real-time station events are a hard requirement for your collection display, that’s worth raising as a feature request.

5

Thanks Ashley, that’s very helpful and confirms what we observed in production.

Please could you record this as a feature request for a low-latency KDS completion/recall webhook containing order_id, order_line_item_id and device_id/station identity.

Our use case is a customer-facing collection display where a single Square order is routed independently to Kitchen and Bar KDS screens. We need the existing KDS Complete action to update Food/Drinks readiness externally without requiring staff to perform a second action.

The existing KitchenPerformanceItems model contains exactly the correlation required, but the Reporting API latency makes it unsuitable for live customer collection.

Thanks again.

6

Yes I will flag to our product team! You are also welcome to create a new post with the “feature request” type (sometimes this inspires other devs to reply with their support which can help with priority setting)