Vendors / QSR & drive-thru
Bite Ninja
Remote human cashier marketplace — 'NinjaQ' queues virtual order takers across a chain's drive-thrus and front counters — now owned by Voicify, which pairs it with AI. It rides the operator's POS via a PAR Brink/Revel API integration or the 'Shinobi' remote-access fallback, but it also ships its own operator web application, Zenu (zenu.biteninja.com), so it is not purely a labor product. Separate company from Bite/getbite.com.
scored unknown legacy rubric
- Claims in scope
- 296
- Scored
- 44
- Assessed
- 41
- Unknown
- 255
- Not applicable
- 18
- Values challenged
- 50
unknown, never as no.Identity
- Owner
- Voicify — Voicify announced it acquired Bite Ninja (banner on biteninja.com; date not stated on the page)
- Who it is for
- QSR chains staffing drive-thru and front-counter order taking with remote/virtual cashiers, and multi-location chains wanting to pool labor across sites
- Site
- https://biteninja.com/
Pricing
transparency: quote-only · unit: per-transaction platform fee plus a separate hourly fee for Ninja usage; amounts not published · processor lock-in: unknown
- Software
- No pricing published; quote only. Every archived pricing page is a placeholder ('COMING SOON', 'No plans available'). Required hardware (Control Box, vehicle sensors, firewall) is rented, included in the monthly platform fee, rather than sold outright.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Not scored by this record.
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
CLAIM: split by item, seat, even N-way and arbitrary amount, plus merge (also after partial payment). MEETS, arbitrary-amount only: Bite Ninja's own 'Zenu API' 2.0 OpenAPI 3.0 spec ('For managing menus and placing orders', served anonymously at api.biteninja.com/docs, Wayback capture 2025-04-15) gives Order a payments array of OrderPayment. It also carries an isFullyPaid flag. OrderPayment.amount reads 'Total amount that should be applied against the order. The sum of all successful OrderPayment amounts should equal the Order total.' POST /orders/{orderId}/payments (PaymentDto: amount, type cash|giftCertificate) and POST /payments/stripe/paymentIntents (CreatePaymentIntentDto: orderId, station, optional amount, paymentMethod terminal|online) each take a caller-set amount. So one order can be settled by several payments of arbitrary amount. FALLS SHORT: the 181-path manifest has no split, merge, seat or check resource. The staging copy (178 paths, 2025-03-19) differs only by three /voicify/calls paths. The order surface is /orders/{orderId} plus items POST, items/{itemId} POST/DELETE, discounts, payments, calculate and status. There is no endpoint that moves an item between orders or joins two orders. Order, OrderItem and OrderItemDto have no seat field. So item split, seat split and merge are not modelled. There is no even-split operation either: an N-way split could only be keyed by hand as N arbitrary payments. Percentage split is also absent. BOUND: this rests on the API manifest. The live zenu.biteninja.com bundle (80 anonymously fetched chunks) has no 'Split' or seat-split UI string, but those chunks are not a census of the post-sign-in app. CURRENCY: the spec is a 2025 archive and live /docs now 404s. The live bundle still reads isFullyPaid and has a Gift Certificate payment dialog, which fits the same payments model. SCOPE: the API covers only Zenu's native mode. Restaurants in operationMode integratedPos or shinobi run on their PAR/Revel POS instead. https://web.archive.org/web/20250415233140id_/https://api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Not scored by this record.
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Zenu's own source blocks order entry offline. The /_app chunk wraps every page in a component that listens for the browser 'offline' event and replaces the entire app with a full-screen 'No internet' screen until 'online' fires. The operator order screens, kiosk, KDS and card-reader pages are therefore unusable without connectivity. There is no service-worker registration and no local order queue: the indexedDB hits are Sentry's 'sentry-offline' transport and Firebase installations. The vendor publishes no offline scope ('offline' in the site census appears only in /terms and Wix boilerplate). Both limbs fail. https://zenu.biteninja.com/_next/static/chunks/243cde8d43e61cc2.js · retrieved 2026-09-15 adversarially verified
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
Not scored by this record.
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
Not scored by this record.
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
Not scored by this record.
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
Not scored by this record.
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
Not scored by this record.
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
Zenu (Bite Ninja's native order app) takes future-dated pickup orders with a lead time set per station, but no fire-time injection into the kitchen queue is shown. Live, anonymously served Zenu web bundle, read 2026-09-15. Chunk b176bdb8ad77aebf.js has a 'Pickup date' DatePicker with minDate now and maxDate addMonths(now,2), so pickup can be set up to two months ahead. Choosing a date or time writes updateOrderDetails(id,{collectionTime}). The earliest time offered is getLeadTimeDetails(station.leadTime,...).earliestPickupTime, checked against the restaurant's operating hours. The lead-time constants are LEAD_TIME_MIN_MINUTES 15, LEAD_TIME_MAX_MINUTES 180 and LEAD_TIME_INTERVAL_MINUTES 15. When station.collectionTime is 'required', validateOrder rejects a collectionTime that is not later than now. Chunk d41d2dcc5df97627.js, the station admin form, shows the leadTime.value picker only when collectionTime is 'required'. The archived Zenu API 2.0 OpenAPI spec (Wayback 2025-04-15) matches this. Station has collectionTime enum(hidden|required|optional) and leadTime {validFrom, value default 15}. Order.collectionTime is described as 'The time at which the customer intends to pick up the order. This is set to the time the order is placed if it is to be prepared immediately.' A station is a per-channel order point, such as the online-order slug or a kiosk. SHORTFALL: there is no computed fire time. The only deferral in the bundle is an open-orders view filter: it hides an order unless showFutureOrders is on or collectionTime < startOfDay(addDays(now,1)), with a 'Show future' switch. That is a calendar-day display filter, so an order for later today appears at once. Ticket views run an OrderTimer against collectionTime. 0c925fd2bbd24130.js sorts open orders by compareAsc(collectionTime). No prep-time or fire-time field exists in the spec or the bundle: fireTime, fireAt, prepTime, holdUntil, readyTime, preparationTime, scheduledFor and scheduledAt are all 0 across the 80 fetched chunks. This is a failed search over the served client and the 2025 spec, not a vendor statement of absence. SCOPE: native Zenu mode only. PAR ParIntegration.minimumLeadMinutes is imported from PAR, not Zenu's own. CURRENCY: the live api.biteninja.com/docs now returns 404, but the live bundle independently carries the same collectionTime and leadTime model. https://zenu.biteninja.com/_next/static/chunks/b176bdb8ad77aebf.js · retrieved 2026-09-15 adversarially verified
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
Not scored by this record.
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
Not scored by this record.
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
Not scored by this record.
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
Not scored by this record.
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
Not scored by this record.
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
Not scored by this record.
Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator
payments-surcharge-guardrails
Not scored by this record.
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Zenu, Bite Ninja's own operator app, takes card-present payments on Stripe Terminal readers. The archived Zenu API 2.0 spec (2025-04-15) exposes /payments/stripe/terminals, /connectionToken, /{terminalId}/cancel and /simulateCard, and /payments/stripe/paymentIntents with /capture. StripeTerminalDto.device_type enumerates bbpos_chipper2x, bbpos_wisepad3, bbpos_wisepos_e, simulated_wisepos_e, stripe_m2 and verifone_P400. StripeReaderAction.type includes process_payment_intent. The live bundle has a 'Card Reader' page (/manage/restaurant/payments), a TerminalPicker, and 'Please follow the instructions on the card reader.' So there is a first-party payment path to certify, and the earlier no, 'no first-party terminal', is falsified. The claim's conjuncts are not established. Bite Ninja publishes nothing on EMV chip, contactless or Apple Pay/Google Pay acceptance: 'emv', 'contactless', 'nfc', 'apple' and 'google_pay' are zero in the parsed spec. The bundle's single 'contactless' is an emoji keyword and its 'emv' hits are not the word. The enum is Stripe's device list, not a statement of which readers Bite Ninja supplies or of what they accept. Whether the readers are Bite Ninja-supplied hardware is also unstated. || 323rd: 323rd, NEW SURFACE: NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. It does not settle the cell. The shipped payment screen drives Stripe Terminal through a TerminalPicker and shows "Terminal is not connected." and "Please follow the instructions on the card reader.", but the app never names an acceptance method: apple pay / google pay / contactless / tap to pay together score ONE distinct site in 48.9 MB, and it is the emoji-mart keyword list for the wireless emoji (keywords wifi, internet, contactless, signal) - pure POISON. Bite Ninja therefore still publishes nothing about EMV chip, NFC or wallet acceptance on its own readers; the only acceptance facts are Stripe's, about Stripe's hardware, which is third-party (grade D) and cannot carry a table-stakes yes. Retrieved 2026-09-17. || 328th: 328th, PER-CELL RE-GREP of the corpus already on disk that no pass had checked against THIS cell: the 302-file / 48,869,132-byte Turbopack chunk census of the Zenu operator web app (zenu.biteninja.com, taken to a fixpoint in the 323rd, 4 rounds, zero fetch misses, 50 Pages-router routes including /manage/restaurant/payments). Tokenised, case-insensitive, word-boundary controls over all 302 chunks: EMV 0, 'tap to pay' 0, 'apple pay' 0, 'google pay' 0, NFC 0. `contactless` returns exactly 1 hit and it is POISON - it is a keyword in the emoji-picker dictionary entry for the wireless/wifi glyph ('keywords':['wifi','internet','contactless','signal'], unified 1f6dc), not a payment term. So the shipped operator UI - the app that drives the card reader - never names EMV, NFC, Apple Pay or Google Pay anywhere. This does not carry a `no`: the readers themselves are Stripe Terminal devices whose acceptance behaviour is Stripe's to publish, not Bite Ninja's, and the claim's subject ('first-party payment terminals') is exactly what remains unstated - whether Bite Ninja supplies the hardware. Retrieved 2026-09-18. || 330th: 330th, TWO NEW CORPORA, both zero on acceptance vocabulary. (1) The CURRENT marketing site censused against its own publisher manifest: www.biteninja.com/sitemap.xml -> pages-sitemap.xml lists exactly 10 URLs (blog, privacy, book-a-demo, contact, ninjas, about, terms, product-info, for-restaurants, faq); 10/10 fetched plus the home page = 9,481,611 bytes. (2) TWELVE RETIRED pages recovered from Wayback CDX with id_ timestamps (pos-integration, copy-of-pos-integration, products-services, online-ordering, plans-pricing, experience, ninjaq, curbninja, seamless-process, tremendous-roi, news, for-ninjas) = 7,680,763 bytes; retired copies carry positives only. Tokenised word-boundary controls over both: emv 0, nfc 0, contactless 0, 'tap to pay' 0, 'google pay' 0, 'chip' 0 in the retired set and 10 in the current set - ALL POISON, every one the Wix CSS custom property --ricos-internal-sb-chip-half; 'apple pay' 1 in the retired set and it is POISON too, the Wix module-id table entry 3944:"applePay". So Bite Ninja has now published nothing about EMV, contactless or wallet acceptance across its API spec, its 302-file operator-app census, its whole current site and its retired site. The nearest prose is the opposite claim, that the product needs no hardware of its own: "There's no need for additional display screens, tablets, cash drawers, or other extra equipment. Your kitchen team's experience remains cohesive, as they continue viewing tickets on your existing [system]" (retired /pos-integration). Held unknown rather than moved: the Stripe Terminal reader models the vendor's own spec enumerates do accept EMV/NFC/wallets, but that is Stripe's fact about Stripe's hardware (grade D) and the vendor never states it, so neither a table-stakes yes nor a no is available. Retrieved 2026-09-18. adversarially verified
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
Not scored by this record.
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
Not scored by this record.
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
Not scored by this record.
Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator
payments-offline-store-and-forward
Not scored by this record.
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
Not scored by this record.
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
No first-party gift card. Zenu's register lists a fixed set of tender types: the live zenu.biteninja.com bundle (chunk b176bdb8ad77aebf.js) declares enum {Card=0, Cash=1, Discount=2, GiftCertificate=3}. The 'Gift Certificate' menu item opens a dialog with two required fields, 'Amount' (CurrencyInput) and 'Gift certificate number' (free-text TextField), then calls applyPayment({amount, certificateNumber, note, orderId, printerId, restaurantId, stationSlug, type:"giftCertificate"}). Nothing looks up or deducts a balance. The operator types in both the number and the amount. The archived Zenu API 2.0 OpenAPI spec agrees (Wayback 2025-04-15; 181 paths, 173 schemas; the live /docs now returns 404). It has PaymentDto.type enum [cash, giftCertificate] with certificateNumber as a plain string, OrderPayment.type enum [cash, card, discount, giftCertificate], and online payment only through Stripe (CreatePaymentIntentDto.paymentMethod enum [terminal, online]). No path in the 181-path manifest issues, looks up or reloads a gift card or stored-value balance. The only 'balance' fields are on StripeCustomerDto (Stripe's customer balance). 'voucher' is a Discount type described as 'Single use redemption vouchers', which is a discount, not stored value. This is a manual tender that records a paper certificate. It has no balance tracking, no issued card, and no cross-location or online redemption, so it meets none of the claim's conjuncts. The no rests on these closed tender and resource lists: the 2026 bundle tender enum and the 2025 spec manifest. It covers native Zenu mode only; in integrated-POS mode tenders belong to the host POS. Bundle control: 'gift' has 16 hits across the 80 fetched chunks, all emoji-picker data except the certificate dialog; 'giftCard', 'gift_card' and 'cardBalance' have 0 hits. https://zenu.biteninja.com/_next/static/chunks/b176bdb8ad77aebf.js · retrieved 2026-09-15 adversarially verified
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
Not scored by this record.
A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.
payments-split-tender
Not scored by this record.
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
CLAIM: voids, refunds, discounts and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. EVIDENCE: the cancellation/refund flow is fully inside the census and has no approval step. OrderCancellationReason is a closed enum of four strings - NotPaidNotMade="Food was not paid for nor made", PaidMade="Food was paid for and made (issue refund)", PaidNotMade="Food was paid but not made (issue refund)", Other="Restaurant cancellation" - collected in a dialog that then calls updateOrderStatus(orderId,"cancelled",{cancellation}). There is no PIN prompt, no approver field and no second-user confirmation anywhere; the only gate is the coarse page-level allowedRoles list (105 sites) over Role ADMINISTRATOR|DEVELOPER|MANAGER|NINJA|INSTORE|EMPLOYEE|MONITOR, which merely hides nav items, plus the restaurant-level on/off toggles cancelOrder / discount / modifyOrder on /manage/restaurant/features. POISON named: the token PIN is chat message PINNING (POST /chats/{roomId}/messages/{messageId}/pin, a switch name:"pin", "Remove pin"/"Pin message"), and audit scores 4 sites that are all the Firebase reCAPTCHA enforcementState enum (ENFORCE|AUDIT|OFF) - either would falsely read as a yes. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/67bbd89f8bc248a2.js · retrieved 2026-09-17 adversarially verified
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
Not scored by this record.
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
Not scored by this record.
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Not scored by this record.
A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator
payments-multi-entity-routing
Not scored by this record.
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
Not scored by this record.
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
CLAIM: items route to specific KDS stations by item, category, order type or revenue center, with routing rules configurable per location. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. EVIDENCE: the COMPLETE Station editor (/manage/stations/[stationId]) is in the census. Its entire field list: Name (maxLength 27); three switches Public / "Allow Tip" / "Kitchen Post" (isKitchenPost); customerName, customerPhone, collectionTime, address (required/optional); Lead Time; ONE PrinterPicker (TextField label:"Printer", a single select over the restaurant printer list, writing station.printer) and one TerminalPicker; Dining Option chips (packagingOptions/defaultPackagingOption); Replace background; Rustdesk Id/Password; Sensor ID; headset; Nexeo Serial Number with "Lane 1"/"Lane 2"; Transcription off/live. There is no routing rule, no station-per-item and no station-per-category: the Product editor exposes only Name, Short Name, Description, Prices, Tax Exempt, Modifiers, Color, and setFieldValue("station" scores 0 in all 302 files, so the spec's undescribed Product.station is not operator-settable anywhere in the shipped app. CONTROLS: "routing rule" 0, "prep station" 0, "print to" 0, "printer group" 0. POISON named: a raw route count is 538 distinct sites and is almost entirely Next.js useRouter/resolveHref plus the Google Places address component literally called route; notifyStation (2 sites) pushes the presented item to the ninja's customer-facing screen, not to a kitchen. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/3a3486274af67036.js · retrieved 2026-09-17 adversarially verified
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
CLAIM: an expo screen consolidates items from multiple prep stations into one order view and marks the order complete only when every contributing station has bumped its items. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. Both KDS views, /manage/orders/kds and /manage/orders/touchless-kds, are in the page-chunk table and held. EVIDENCE: controls over all 302 files: expo 0, expedit 0, consolidat 0. The order status vocabulary is a closed list - draft, pendingPayment, requested, served, plus cancelled and complete - and the KDS card action is a single whole-order toggle: AsyncButton onClick updateOrderStatus(order.id, order.status!=="served" ? "served" : "requested"), labelled "Serve"/"Undo". Nothing is per-station and nothing waits on another station. POISON named: the token bump matches only the MUI X chart curve options "Bump X"/"Bump Y" (2 sites). Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/43cf9e7899ac98b8.js · retrieved 2026-09-17 adversarially verified
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
Not scored by this record.
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
Not scored by this record.
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
Not scored by this record.
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
Not scored by this record.
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
Not scored by this record.
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
https://web.archive.org/web/20231207030928/https://www.biteninja.com/pos-integration · retrieved 2026-09-06 adversarially verified
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Not scored by this record.
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
Not scored by this record.
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Not scored by this record.
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
Not scored by this record.
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
Not scored by this record.
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Not scored by this record.
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
Not scored by this record.
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
Not scored by this record.
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Not scored by this record.
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
Not scored by this record.
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
Not scored by this record.
Delivery, dispatch & third-party channels
Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).
delivery-driver-roster
https://www.biteninja.com/ · retrieved 2026-09-06 adversarially verified
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
https://www.biteninja.com/ · retrieved 2026-09-06 adversarially verified
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
Not scored by this record.
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
Not scored by this record.
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Not scored by this record.
Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator
delivery-driver-comp
Not scored by this record.
Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.
delivery-daas-dispatch
Not scored by this record.
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
Not scored by this record.
Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator
delivery-3p-direct-integration
Not scored by this record.
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
Not scored by this record.
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
Not scored by this record.
Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.
delivery-store-pause
Not scored by this record.
Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator
delivery-3p-reconciliation
Not scored by this record.
Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator
delivery-injection-error-visibility
Not scored by this record.
Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.
delivery-tracking-page
Not scored by this record.
Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator
delivery-promise-time
Not scored by this record.
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
Not scored by this record.
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
CLAIM: a first-party, commission-free web ordering site on the restaurant's own branding/domain writing orders directly into the POS. VERDICT: unknown -> partial. The prior note declined partial because the shortfalls were unknowns rather than NAMED shortfalls; the census now names one. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. SATISFIED: the storefront is first-party and in the page table - /restaurants/[restaurant], /restaurants/[restaurant]/online-payment, /restaurants/[restaurant]/order-confirmation - and it writes into Zenu itself (addOrderItem, then updateOrderStatus(id,"pendingPayment" or "requested") and a Stripe payment intent), i.e. directly into the POS of record. OWN BRANDING is satisfied: /manage/restaurant/brand ("Manage Brand", tabs General / Socials / Contact) uploads per-restaurant images typed logo and header which the storefront renders. NAMED SHORTFALL: an own DOMAIN is not offered - "custom domain" is 0 over all 302 files and no form field anywhere sets a hostname (the 154 domain hits are Next.js locale-domain plumbing, getDomainLocale/isLocaleDomain: POISON); every storefront is vendor-hosted at zenu.biteninja.com/restaurants/<slug>. Commission-free is still unpublished (pricing is quote-only) and is counted neither way. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/4be094128f92f86a.js · retrieved 2026-09-17 adversarially verified
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Not scored by this record.
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
https://www.biteninja.com/terms · retrieved 2026-09-06 adversarially verified
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
Not scored by this record.
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
Not scored by this record.
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
Not scored by this record.
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
Not scored by this record.
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
Not scored by this record.
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
Not scored by this record.
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
Not scored by this record.
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
Not scored by this record.
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
Not scored by this record.
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
Not scored by this record.
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
Not scored by this record.
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
Not scored by this record.
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Not scored by this record.
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
Not scored by this record.
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Not scored by this record.
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
Not scored by this record.
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
Not scored by this record.
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
Not scored by this record.
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
CLAIM: a single guest profile automatically merging in-store POS, first-party web/app and kiosk transactions under one identity, with documented dedup/merge behaviour. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. This matters because all three channels the claim names are inside the census: the station order flow, the kiosk (/instore/kiosk) and the first-party storefront (/restaurants/[restaurant], /online-payment, /order-confirmation). EVIDENCE: none of the 50 routes is a guest or customer record - the route table has no customers, guests, loyalty or CRM page at all - and the order object all three channels build carries only a free-text name and contactNumber. Loyalty appears in the shipped UI as exactly one switch on /manage/restaurant/features with the tooltip "Toggles the ability to enable loyalty.", and /manage/restaurant/integrations offers only four providers (par, revel, voicify, xenial) behind a DISABLED type select whose options are pos and loyalty. There is no identity to merge, so no dedup/merge behaviour can exist. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/63187b437f7083cc.js · retrieved 2026-09-17 adversarially verified
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
Not scored by this record.
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
CLAIM: at least two of points-per-dollar, visit/punch-count and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor. VERDICT: unknown -> no; the earlier note's "leans bolt-on" is now settled by the shipped app. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. EVIDENCE: the 50-route table contains NO loyalty configuration page. Loyalty in the operator app is one switch on /manage/restaurant/features (tooltip "Toggles the ability to enable loyalty.") and, on /manage/restaurant/integrations, a per-restaurant integration whose type select is DISABLED with options pos and loyalty over the four named providers par / revel / voicify / xenial (GET|PUT /restaurants/{id}/integrations/par|revel|voicify|xenial). There is no accrual configuration to configure: tier/tiers 0 and multiplier 0 over all 302 files, and no points, punch or visit-count field exists in any form. Loyalty reaches an order only as a REDEMPTION - Discount.type cash|loyalty|voucher with a free provider string - which is precisely the bolt-on vendor the claim excludes. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/63187b437f7083cc.js · retrieved 2026-09-17 adversarially verified
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Not scored by this record.
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
Not scored by this record.
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
Not scored by this record.
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Not scored by this record.
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
Not scored by this record.
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
CLAIM: triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) shipped as configurable always-on campaigns. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. EVIDENCE: the 50-route page-chunk table has no marketing, campaign, messaging or loyalty page of any kind. The shipped Management nav is exactly Menu (Products/Modifiers/Categories/Menus), Restaurant (Brand/Hours/Features/Taxes/Printers/Payments/Integrations), Stations, Users, Shifts, Payouts, Billing, Organizations, Lobbies, Connecteam, NEXEO Service. There is no guest record to trigger on (the order carries a free-text name and contactNumber only), and the only customer-directed message the shipped code can send is VoicifyIntegration.sendSmsForPayment, a payment link. Together with the npm SDK's NotificationsService, whose oneof holds exactly one variant (userInvitation, a staff invite), no campaign machinery exists in either the client or the published API. Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/43cf9e7899ac98b8.js · retrieved 2026-09-17 adversarially verified
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
Not scored by this record.
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Not scored by this record.
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
Not scored by this record.
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
Not scored by this record.
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
Not scored by this record.
Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator
guest-loyalty-cdp-event-api
Not scored by this record.
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
Not scored by this record.
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
Not scored by this record.
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
Not scored by this record.
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
Not scored by this record.
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
Not scored by this record.
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
Not scored by this record.
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Not scored by this record.
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
CLAIM: employees clock in and out at the POS terminal using a PIN, badge or card, with no separate time-clock hardware required. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. EVIDENCE: time and attendance is DELEGATED to a third party in the shipped nav. The sidebar carries a "Connecteam" item pointing at /users/connecteam, a page whose entire content is "Connecteam Account has been successfully registered/linked." or "Failed to register/link with Connecteam", the user's email and phone, and a Button href="https://app.connecteam.com/index.html#/Login" labelled "Connecteam login page"; behind it is GET /users/connecteam (getConnecteamUser). /manage/shifts is not a time clock: its strings are "Shift Management", "Ninja Count", "Select Lobby", "Previous Week"/"Next Week", "Operating Hours Not Configured" - it staffs remote Ninja lobbies by weekday. CONTROLS over all 302 files: clock.?in 0, clockIn 0, clock_in 0, timecard 0; "time clock" matches only MUI's TimeClock picker component (MuiTimeClock, 9 sites). POISON named: a raw punch search hits only the emoji-mart keyword table (facepunch / punch / angry / violence). Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/2697674a5d9f0e40.js · retrieved 2026-09-17 adversarially verified
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
Not scored by this record.
Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.
labor-geofenced-mobile-punch
Not scored by this record.
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
Not scored by this record.
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Zenu (Bite Ninja's native web POS) grants access only by assigning fixed roles at a scope. There is nowhere to set per-action permissions. The Zenu API 2.0 OpenAPI spec (Wayback capture 2025-04-15; 181 paths, 173 schemas; the staging copy has the same role schemas) defines one grant object, UpdateUserRolesDto {authorizationScope: RolesScope{organizationId, restaurantId}, roles}. Its roles field is a closed enum: administrator|developer|manager|ninja|employee|instore|public. The spec describes authorizationScope as 'The _level_ at which the user should be granted the role. When neither organizationId nor restaurantId are specified, the role is granted at the _global_ level.' UserRoles, UpdateUserMappedRolesDto and the GET /staff/roles filter all reuse that same enum. No schema or path in the manifest is a permission, policy or capability resource. The spec's one use of 'permissions' is the isNinja flag ('has the Ninja role anywhere in their permissions'). The live zenu.biteninja.com bundle, served anonymously in 2026, has the same design. The role enum {UNSPECIFIED:0,ADMINISTRATOR:1,DEVELOPER:2,MANAGER:3,NINJA:4,INSTORE:5,EMPLOYEE:6} and ROLE_SCOPE GLOBAL/ORGANIZATION/LOCATION are in chunks c55fbc518176dc67.js and d391086c461a1c07.js. The only addition since the spec is one more hard-coded constant, MONITOR_ROLE = 7. The operator user editor (chunk d41d2dcc5df97627.js) is a set of on/off switches, one per fixed role: Organization Manager, Employee, Ninja, Monitor, Restaurant Manager, Instore. It has no per-action toggles. Navigation in 735b9963daf3460b.js is gated by allowedRoles arrays hard-coded in the client; for example Reports (End of Day Report, Orders, Cash by Station) is allowedRoles [ADMINISTRATOR, MANAGER]. Shortfall against the claim: roles can be scoped to an organization or a location, but no action (void, comp, discount, refund, drawer open, price change, report access) can be granted separately from a fixed role tier. This is the fixed-tier model the claim excludes. Bounds: this covers native Zenu only. Restaurants in integratedPos or shinobi mode use the host POS's permissions. The docs.biteninja.com /users/authorization specification is auth-gated and was not read. https://web.archive.org/web/20250415233140id_/https://api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
CLAIM: see taxonomy. VERDICT: still unknown. NEW SURFACES (318th): (1) npm package @bite-ninja/zenu-sdk 0.122.0 (published 2026-09-02 by npm user bite-ninja-dev <dev@biteninja.com>; tarball https://registry.npmjs.org/@bite-ninja/zenu-sdk/-/zenu-sdk-0.122.0.tgz, 20 files, ts-proto gRPC-web client). It defines exactly five services: zenu.notifications.v1.NotificationsService, zenu.users.v1.UsersService, AgreementsService, UserAgreementsService, NinjaOnboardingService. It is a census of the gRPC services SHIPPED IN THIS SDK only, not of Zenu (orders/menus/payments remain REST-only in the Swagger), so it cannot carry a no. (2) dev.zenu-api.biteninja.com/docs/swagger-ui-init.js (685,876 bytes; 292 paths, 223 schemas; robots.txt 'User-agent: * Disallow: /', generic bar, not ClaudeBot-named): diffed against prod zenu-api (268 paths), the 24 extra paths and 9 extra schemas are all /organizations/{id}/quiz/* staff games (wordle, sketch, throwdowns); nothing bears on this cell. (3) crt.sh lists 52 biteninja.com names; orders, portal, portal-api, app-api, training, hub, boost, metabase, login, prodapi, staging.* do not resolve; app.biteninja.com is Vercel DEPLOYMENT_NOT_FOUND; auth -> Firebase bite-ninja-404fe (404); zenu.biteninja.com 307s every path incl. /restaurants/<slug>?station=online-order to /users/sign-in. EVIDENCE: users_service.d.ts: Role = ADMINISTRATOR | DEVELOPER | MANAGER | NINJA | INSTORE | EMPLOYEE | MONITOR; RoleScope = GLOBAL | ORGANIZATION | LOCATION; UpdateUserRolesRequest "Full replacement of all roles for this user." Roles are coarse, scoped grants; no permission, approval, approver or override message exists in the five services (tokenised controls 'override','approv','audit','permission': 0). Order and discount mutation is not in the SDK, so this does not reach a no. Retrieved 2026-09-16. || 320th: VERDICT: still unknown. NEW EVIDENCE, live Swagger https://zenu-api.biteninja.com/docs/swagger-ui-init.js: descriptions name permissions MonitorAudio.Read, Station.Update, StationState.Update and describe role asymmetries (enableTranscription: "once a ninja enables it, only an admin can turn it off"; muteStation: "admins can override from the lobby"), and startStationRecording calls itself "a manual override" - these are station-audio controls, not manager approvals of order actions, and nothing writes an approver to an audit trail (approver/approv/audit 0; Discount.userId records the applier only). Not a no. Retrieved 2026-09-16. || 323rd: 323rd, NEW SURFACE: NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. It settles that the product has NO manager-override or approval mechanism at all: no PIN prompt, no approver field and no second-user confirmation in any of the 50 routes, the only role gate being the coarse page-level allowedRoles list over Role ADMINISTRATOR|DEVELOPER|MANAGER|NINJA|INSTORE|EMPLOYEE|MONITOR. Per merge policy a capability the product lacks ENTIRELY is held unknown rather than scored no, so this stays unknown. POISON worth recording: the token audit scores 4 distinct sites in 48.9 MB and every one is the Firebase reCAPTCHA enforcementState enum (ENFORCE|AUDIT|OFF). Retrieved 2026-09-17. || 330th: 330th: controls re-run against the live spec at its CURRENT size (292 paths / 223 schemas / 501,536 bytes parsed, up from the 268-path copy the 320th used), because a corpus that grew invalidates notes bound to the old one. Tokenised, word-boundary: approve 0, approval 0, approver 0, audit 0, pin 3 (all `pinned`/`pin` on chat messages - poison). `override` scores 3 and all three are still non-managerial: two are the station-audio controls the 320th already recorded, and the third is new and equally irrelevant, NinjaLobby.overriddenDates "Dates (YYYY-MM-DD) that override the weekly pattern" in the ninja SCHEDULING model. Also new since the last pass: a Xenial POS integration module (/restaurants/{id}/integrations/xenial/{session,menus/json}) joins Par, Revel and Voicify - i.e. the register of record is increasingly the RESTAURANT'S OWN POS, which is where a manager override would be authorised and logged. Held unknown as a claim that does not apply: Bite Ninja is a remote-staffing/drive-thru product with no manager-approval module at all, not a full POS whose absence of one could be scored no. Retrieved 2026-09-18. adversarially verified
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Not scored by this record.
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
Not scored by this record.
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
Not scored by this record.
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
Not scored by this record.
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
Not scored by this record.
Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.
labor-fair-workweek-support
Not scored by this record.
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
Not scored by this record.
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
Not scored by this record.
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
Not scored by this record.
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
Not scored by this record.
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Not scored by this record.
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
Not scored by this record.
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
Not scored by this record.
Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.
labor-digital-onboarding-i9
Not scored by this record.
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
Not scored by this record.
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
https://www.biteninja.com/for-restaurants · retrieved 2026-09-06 adversarially verified
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
https://www.biteninja.com/for-restaurants · retrieved 2026-09-06 adversarially verified
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
Not scored by this record.
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
Not scored by this record.
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Not scored by this record.
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
https://www.biteninja.com/for-restaurants · retrieved 2026-09-06 adversarially verified
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
Not scored by this record.
Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator
inventory-vendor-catalogs-edi
Not scored by this record.
Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator
inventory-invoice-ocr
Not scored by this record.
Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator
inventory-price-change-alerts
Not scored by this record.
Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator
inventory-par-auto-suggest
Not scored by this record.
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Not scored by this record.
Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.
inventory-transfers
Not scored by this record.
Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.
inventory-commissary
Not scored by this record.
Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.
inventory-lot-traceability
Not scored by this record.
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
Not scored by this record.
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
Not scored by this record.
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
Not scored by this record.
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
330th: the MOBILE half of this claim is now bounded by an APP-STORE CENSUS, which no prior pass ran. VERDICT: unknown -> partial. BROWSER HALF (satisfied): GET /reports/dashboard (getDashboardSummary; organizationId + from/to) returns DashboardSummary{orders: OrdersSummary{total, averageOrderValue, totalRevenue, byRestaurant[]}, ninjaHours: NinjaHoursSummary{totalHours, byDay[]}} in the live 292-path Zenu API spec re-derived today, and /dashboard is inside the app's own __turbopack_load_page_chunks__ table, so a live sales dashboard ships in the browser. MOBILE HALF (absent): iTunes Search API `term=bite ninja&entity=software&country=us` returns 19 apps and NOT ONE is published by Bite Ninja (results are Fruit Ninja, Ninja Must Die, etc. - the word `ninja` is the poison here, so the search is deliberately over the product name and the publisher is checked on every row); the Google Play search page for "bite ninja" likewise lists no biteninja package (com.biteout.app, com.biteloyalclub.android, com.caterstation.bite are other firms). Corroborated by three corpora holding ZERO app-store references: the CURRENT marketing site fetched to its own pages-sitemap.xml (10/10 pages + home, 9,481,611 bytes: 'app store' 0, 'google play' 0, 'ios app' 0, 'android app' 0, 'mobile app' 0, and zero apps.apple.com / play.google.com hrefs), 12 RETIRED marketing pages pulled from Wayback id_ (7,680,763 bytes, same zeros), and the 302-file / 48.9 MB Zenu client census (no native-app link or deep link). The product is a responsive web client only. Browser conjunct met, off-premise mobile-app conjunct not => partial. Refresh latency is still undocumented. Retrieved 2026-09-18. https://zenu-api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-18 adversarially verified
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
330th, NEW MEASUREMENT: the six /reports/orders/* summaries were named by earlier passes but their FIELD SETS had never been read. Live anonymous swagger-ui-init.js re-derived today (54,359 bytes; "Zenu API" 2.0; 292 paths / 223 schemas, up from 268/214 in the 328th) and the response schemas parsed out verbatim. VERDICT: unknown -> partial. EVIDENCE (all from components.schemas of that spec): SalesSummary {averageOfSubTotal, sumOfDiscountedSubTotal, sumOfSubTotal, sumOfTotal} = gross and discounted/net sales; TaxSummary {_id, count, sumOfTaxValue}; DiscountsSummary {_id, count, sumOfDiscountAmount}; PaymentsSummary {_id, count, sumOfPaymentAmount, sumOfPaymentAmountReceived, sumOfPaymentChange} grouped by _id, i.e. BY TENDER, since OrderPayment.type is the closed enum ["cash","card","discount","giftCertificate"] and OrderPayment.amountReceived is documented "The amount of cash received from the customer. This is usually whole round numbers depending on bills received." with a sibling `change` - so tender-type totals and the expected-cash figure are both computed; plus StationsSummary and OrdersStatusSummary. All six take x-restaurant + from/to, so a single-day close-out is exactly the intended call, and POST /jobs/restaurants/endofday (runEndOfDay) with Restaurant.disableAutomatedEndOfDay runs it nightly. SHORTFALL, tokenised word-boundary controls run over the joined JSON of the seven report/dashboard schemas (2,343 bytes, the whole reporting response surface): tip 0, tipAmount 0, refund 0, refunded 0. Tips and refunds ARE in the order model (Order.tip "Tip rate to apply on the order", Order.tipAmount, OrderPayment.status enum includes "refunded") but no report summarises either, and the six are six separate endpoints, not one document - the /manage/reports/end-of-day-report page is an app-router route whose chunks are still not served anonymously, so whether it welds them into one packet is unread. 6 of 8 conjuncts evidenced, 2 absent from the reporting surface => partial, not yes. Retrieved 2026-09-18. https://zenu-api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-18 adversarially verified
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
NEW SURFACE. SURFACE: live anonymous Swagger at https://zenu-api.biteninja.com/docs (swagger-ui-init.js 654,318 bytes; "Zenu API" 2.0, 268 paths, 214 schemas; the prior pass had only the 2025-04-15 Wayback copy, 181 paths). NOT a census of the API: the bundle calls /users/sign-in, /users/connecteam etc., which the live spec omits (28 /users, /staff, /shifts paths dropped from the doc). GET /transcripts/reports/items-sold, /top-items and /by-daypart exist but belong to the voice-transcript analytics module (Transcript, TranscriptAnalysis) and declare no response schema; no revenue-center concept. Item-level and daypart reporting exist in some form; modifier level, gross/net and a POS-sales basis are undetermined. Retrieved 2026-09-16. || 323rd: 323rd: not reachable from the new census. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. The reports section of the shipped nav is exactly three items - "End of Day", "Orders", "Cash by Station" - with no product-mix or item-sales report among them, and all three are app-router routes whose chunks are not served anonymously, so their columns (item versus modifier level, gross/net, daypart, revenue center) cannot be read. The absence of a PMIX entry from the nav is suggestive, but that nav list is role-filtered, so it is not published as a no. Retrieved 2026-09-17. || 328th: 328th, PER-CELL RE-GREP of the on-disk 302-file / 48,869,132-byte Turbopack census of the Zenu operator app, which no pass had run for this cell's vocabulary. Tokenised, case-insensitive controls: 'product mix' 0, PMIX 0, 'items sold' 0, 'revenue center' 0, 'gross sales' 0, 'net sales' 0, 'tender type' 0. POISON NAMED AND IT IS THE INTERESTING RESULT: `daypart` is NOT zero - 25 hits - but every one is the ninja-staffing lobby, not reporting: the same helper repeated across chunks, `updateLobby({path:{lobbyId:e},body:{autoInvite:r,dayparts:s,name:t,timezone:n}})`. A daypart in this product is a remote-agent scheduling window, so the claim's 'filterable by daypart' conjunct must not be read off that token. Still unknown for the standing reason: the three report routes the nav enumerates (/manage/reports/end-of-day-report, /orders-report, /cash-by-station) are app-router routes whose chunks are not served anonymously, so their columns are unread - and docs.biteninja.com's newly-public sidebar shows no product-mix or item-sales specification either (its 26-page manifest is listed on the end-of-day row; 24 of the 26 pages 302 to sign-in). Retrieved 2026-09-18. || 330th: 330th, NEW MEASUREMENT (still not a move): the six /reports/orders/* response schemas were parsed out of the live 292-path spec for the first time and NONE is item-level - SalesSummary is four scalars (averageOfSubTotal, sumOfDiscountedSubTotal, sumOfSubTotal, sumOfTotal), and TaxSummary/DiscountsSummary/PaymentsSummary/StationsSummary/OrdersStatusSummary are all {_id, count, sum...} group-bys. Controls over the joined 2,343-byte reporting-response surface: item 0, modifier 0, product 0, quantity 0, daypart 0, revenue 0. Over the whole 501,536-byte spec: `modifier` scores 23, every one in the ORDER DATA MODEL (OrderItemModifier / OrderItemModifierDto), never in a report; `revenue center` 0 across all 292 paths; `pmix` and `product mix` 0. The only item-level report endpoints in the entire API are /transcripts/reports/items-sold and /top-items, which sit in the voice-transcript analytics module (they declare no response schema and their basis is LLM analysis of drive-thru call transcripts, not POS sales) - an adjacent module, so not a partial. STILL UNKNOWN for the standing reason: the published spec is NOT a census of the API (the shipped client calls /users/sign-in and /users/connecteam, which the doc omits), so an absent PMIX endpoint cannot be published as a no. Retrieved 2026-09-18. adversarially verified
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
Not scored by this record.
Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.
reporting-cash-over-short
Not scored by this record.
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
Not scored by this record.
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
Not scored by this record.
Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator
reporting-multiloc-drilldown
Not scored by this record.
Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator
reporting-custom-report-builder
Not scored by this record.
Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.
reporting-scheduled-delivery
Not scored by this record.
Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator
reporting-raw-warehouse-export
Not scored by this record.
Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator
reporting-public-api
Not scored by this record.
Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator
reporting-webhooks
Not scored by this record.
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
Not scored by this record.
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
Not scored by this record.
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
Not scored by this record.
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
Not scored by this record.
Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.
reporting-nl-query
Not scored by this record.
Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator
reporting-guest-cohorts
Not scored by this record.
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
Not scored by this record.
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
Not scored by this record.
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
NinjaQ is marketed as letting multi-location chains share a labor pool; no named hierarchy object or scoped permissions documented. https://biteninja.com/ · retrieved 2026-08-01
Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator
multi-location-local-override-policy
Not scored by this record.
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
The claim is about one item record carrying prices keyed by location group, order channel and daypart without being duplicated. Bite Ninja's Zenu API 2.0 OpenAPI spec (181 paths, 173 schemas, archived by Wayback 2025-04-15) has no key of that kind. The Price schema has exactly three fields: {validFrom: date-time, value: number, currency: enum USD|JPY}. Product.price is an array of Price, so it is a list of prices by effective date and has no location, channel or daypart field. POST /products/{productId}/prices (operationId setProductPrices) takes that same Price array as its body. Product and Category each carry a single restaurantId. A different price at another location therefore means a separate product record in that restaurant: POST /jobs/synchronizations/menus (SynchronizeMenusDto items {fromRestaurantId, toRestaurantId}) copies menus between restaurants, and copying the record is the duplication the claim rules out. The only other price field is CategoryProduct.priceOverride (an array of Price), which is a per-category-membership override with the same three fields. No path in the manifest is named for a price level, zone, tier or list. Two near-matches were checked and are not price keys: DayPart exists only on NinjaLobby (staffing hours for the remote-cashier queue), and 'channel' appears only as headset switchChannel enum(a|b|none) and notification ChannelPreference {email, sms}. The live zenu.biteninja.com bundle served in 2026 still uses the same model: setProductPrices is called with a productId, synchronizeMenus sends {fromRestaurantId, toRestaurantId}, and category products still carry priceOverride. Across 80 chunks it has zero hits for price zone, tier, level, list or book. This applies to native Zenu menus only; restaurants integrated with PAR set prices in the host POS (ParMenuItemDto price/priceMethod). https://web.archive.org/web/20250415233140id_/https://api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified
Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator
multi-location-scheduled-publish
Not scored by this record.
A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator
multi-location-new-store-template
Not scored by this record.
The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator
multi-location-corp-vs-franchisee-roles
Not scored by this record.
Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator
multi-location-royalty-calculation
Not scored by this record.
Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.
multi-location-royalty-collection
Not scored by this record.
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
Not scored by this record.
Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator
multi-location-normalized-item-rollup
Not scored by this record.
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Not scored by this record.
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Not scored by this record.
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
Not scored by this record.
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Not scored by this record.
Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.
multi-location-multi-currency-locale
Not scored by this record.
Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator
multi-location-config-audit-log
Not scored by this record.
Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator
multi-location-enterprise-sso
Not scored by this record.
Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator
multi-location-enterprise-api
Not scored by this record.
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
Not scored by this record.
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
Not scored by this record.
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
The vendor names only the client class - a web platform reachable from any device with an internet connection - plus one stated shortfall ('mobile optimization coming soon', 2023). No client operating system is named and no minimum OS version, browser version or device spec is published anywhere in the live-site census; the Shinobi path adds only that 'It requires a dedicated register (can be a virtual instance)'. https://www.biteninja.com/for-restaurants · retrieved 2026-09-06 adversarially verified
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
Not scored by this record.
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
Not scored by this record.
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
The terminal software is the Zenu web app, whose /_app wrapper replaces every page with a full-screen 'No internet' screen on the browser 'offline' event. With the internet down, terminals cannot take orders, print (printing is API-driven: /orders/{id}/reprint, /restaurants/{id}/printers/{printerId}/print) or record cash sales. There is no service worker or local order store. The vendor documents no degraded-function list. https://zenu.biteninja.com/_next/static/chunks/243cde8d43e61cc2.js · retrieved 2026-09-15 adversarially verified
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
The vendor does provide a first-party kitchen display device - a monitor or tablet showing Zenu orders in real time - so the claim's 'sells or supports a dedicated kitchen display system' limb is met, on touch/tablet input. Three shortfalls: no bump bar or programmable keypad is named anywhere ('bump' and 'keypad' are zero across all 69 documents); no station routing, the device being a single screen viewing all Zenu orders; and no course or fire timing. The carrying sentence is a 2023-12-07 capture of the Standalone System page, whose live path 404s and whose packaging the 2026 site does not mention. https://web.archive.org/web/20231207035204/https://www.biteninja.com/copy-of-pos-integration · retrieved 2026-09-06 adversarially verified
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Not scored by this record.
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
Not scored by this record.
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Not scored by this record.
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Not scored by this record.
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Not scored by this record.
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
Not scored by this record.
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
Not scored by this record.
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Not scored by this record.
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
Not scored by this record.
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
Not scored by this record.
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
Not scored by this record.
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
Not scored by this record.
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
https://docs.biteninja.com/reference/ninjas · retrieved 2026-09-06 adversarially verified
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
Not scored by this record.
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
Not scored by this record.
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
CLAIM: third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, revocable permissions. VERDICT: no (grade B). EVIDENCE: live anonymous Swagger UI at https://zenu-api.biteninja.com/docs (swagger-ui-init.js 654,318 bytes; "Zenu API" 2.0, 268 paths, 214 schemas; prior passes held only the 2025-04-15 Wayback copy of api.biteninja.com, 181 paths). components.securitySchemes is an ENUMERATION with one entry: {bearer: http, bearerFormat JWT}. The only other auth construct is a first-party device key (RegisterDeviceDto.type enum unknown|instoreControl|nexeoService with a publicKey JsonWebKey). ParIntegration/RevelIntegration/XenialIntegration/VoicifyIntegration hold Bite Ninja OUTBOUND credentials to partner systems, not inbound partner grants. CONTROLS (tokenised, word-boundary, case-insensitive, over the spec): oauth 0, revoke 0, scope 1 (a backfill job "scoped" to one org), apiKey 3 (VoicifyIntegration outbound key). POISON: in the Zenu web bundle, oauth hits are Firebase Auth fields (oauthAccessToken/oauthIdToken) and client_secret is Stripe payment_intent_client_secret. BOUND: the security-scheme list is closed; the spec is NOT a path census (the app calls 28 /users, /staff, /shifts paths the doc omits), but a partner OAuth flow would have to appear as a declared scheme. docs.biteninja.com page bodies are login-gated and were NOT used for this verdict. Retrieved 2026-09-16. https://zenu-api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-16 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
330th, VERDICT: unknown -> no. This vendor's API is itself PUBLISHED anonymously, so the 328th rule applies: the published doc has no outbound event surface at all. BOUND, three independent corpora. (1) The vendor's own live anonymous OpenAPI, https://zenu-api.biteninja.com/docs/swagger-ui-init.js, re-derived today at 292 paths / 223 schemas (its largest version yet; 181 in the 2025 Wayback copy, 268 in the 328th) - the publisher's own complete path list. Tokenised, case-insensitive, word-boundary controls over the 501,536-byte parsed spec: `callback` 0, `subscription` 2 (both the Ably PubSubMessageDto envelope field, poison), `subscribe` 1 ("Mint a subscribe-only LiveKit listener token for the listen-in feature" - audio, poison), `webhook` 1 and `webhooks` 1, and BOTH are INBOUND receivers: POST /webhooks/soniox/transcription-complete (a speech vendor posting TO Zenu) and a station-recording summary saying "Normally driven server-side off the LiveKit webhook". POST /payments/stripe/events is likewise an inbound Stripe receiver. There is NO registration/subscription resource of any kind - no POST /webhooks, no endpointUrl/targetUrl field, no event-type enum - and the only order-event surface is a POLL: POST /events (logEvent) writes to an event log and GET /events/{resourceId} (getEvents) reads it back by resource id, which is precisely the polling the claim contrasts with. (2) The vendor's published npm client @bite-ninja/zenu-sdk (registry.npmjs.org, 242 versions): its five gRPC services' 30 RPCs are all requestStream:false / responseStream:false, so no server-streaming subscription either. (3) The 302-file / 48,869,132-byte Turbopack census of the Zenu operator app (taken to a fixpoint in the 323rd, zero fetch misses): `webhook` scores 0 distinct sites, and the client's own realtime path is Ably subscription + TanStack Query polling. (4) docs.biteninja.com's Starlight sidebar manifest (26 pages, read in the 328th) names no webhook, event-subscription or partner-API specification. Bite Ninja publishes no order-lifecycle webhooks; integrators poll. Retrieved 2026-09-18. https://zenu-api.biteninja.com/docs/swagger-ui-init.js · retrieved 2026-09-18 adversarially verified
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
Not scored by this record.
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
Not scored by this record.
Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator
extensibility-data-symmetry
Not scored by this record.
API rate limits are published as specific numeric quotas with documented throttling behavior and headers.
extensibility-published-rate-limits
Not scored by this record.
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
Not scored by this record.
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
Not scored by this record.
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Not scored by this record.
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
Not scored by this record.
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
Not scored by this record.
Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator
extensibility-bi-data-warehouse
Not scored by this record.
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
Not scored by this record.
Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.
extensibility-custom-fields-scripting
Not scored by this record.
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
Not scored by this record.
The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.
extensibility-api-versioning-deprecation
Not scored by this record.
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
Not scored by this record.
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
https://web.archive.org/web/20231207022726/https://www.biteninja.com/products-services · retrieved 2026-09-06 adversarially verified
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Not scored by this record.
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
Not scored by this record.
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
Not scored by this record.
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
Not scored by this record.
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
https://web.archive.org/web/20231207022726/https://www.biteninja.com/products-services · retrieved 2026-09-06 adversarially verified
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
CLAIM: automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff. VERDICT: unknown -> no. NEW SURFACE (323rd), a PAGE-CHUNK CENSUS of the Zenu operator web app: zenu.biteninja.com is a Next.js/Turbopack app whose sign-in page (200, anonymous) loads a chunk graph that names every other chunk. Taking the static/chunks/*.js reference set to fixpoint gave 302 files / 48,869,132 bytes with ZERO fetch misses (4 rounds; round 4 added 0). The chunks carry a script-loader table, __turbopack_load_page_chunks__(<route>, [chunks]), for 50 Pages-router routes (incl. /manage/menu/items, /manage/menu/categories, /manage/menu/modifier-sets, /manage/menu/menus, /manage/stations/[stationId], /manage/restaurant/{features,printers,payments,brand,integrations,taxes,hours}, /manage/orders/kds, /manage/orders/touchless-kds, /manage/payment, /manage/order-history, /manage/shifts, /manage/users, /instore/kiosk, /restaurants/[restaurant]) - i.e. this is the whole Pages app, and the code is the vendor's shipped UI, grade B. BOUND/LIMIT: the app-router routes named in the nav (/manage/reports/end-of-day-report, /manage/reports/orders-report, /manage/reports/cash-by-station, /manage/monitor, /manage/transcripts/*, /manage/orders/kitchen-post, /manage/nexeo-service) are NOT in that table and their chunks are not served anonymously; nothing below rests on them. No source maps: <chunk>.js.map and the nonsense controls <chunk>.js.NONSENSE.map and /zzz-nope.js.map all return an identical 9-byte 404, so there is no soft-200 shell here. /manage/restaurant/printers and /manage/stations/[stationId] are both in the page-chunk table. EVIDENCE: a Station has exactly ONE printer (PrinterPicker, a single-select TextField label:"Printer" writing station.printer); the printers admin card shows MAC, Name and a status colour only; there is no backup, secondary or fallback printer field. CONTROLS over all 302 files: backup 0, "secondary printer" 0, "printer group" 0. The ALERT half of the claim IS satisfied - the payment screen renders Alert severity="error" with "Printer is not connected." and "Terminal is not connected." and blocks the flow - but the claim is conjunctive and the failover half is absent from the complete shipped operator app, so this is a no rather than a partial. POISON named: fall.?back scores 119 distinct sites and is 100% library noise (MUI's fallback avatar slot, emotion useInsertionEffectAlwaysWithSyncFallback, popper fallbackPlacements, SWR fallbackData). Retrieved 2026-09-17. https://zenu.biteninja.com/_next/static/chunks/3a3486274af67036.js · retrieved 2026-09-17 adversarially verified
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
Not scored by this record.
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
Not scored by this record.
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
Not scored by this record.
A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator
reliability-contractual-uptime-sla
Not scored by this record.
The vendor publishes written post-incident reports or root-cause summaries for major outages.
reliability-incident-postmortems
Not scored by this record.
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
Not scored by this record.
The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator
reliability-onsite-install
Not scored by this record.
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Not scored by this record.
Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.
reliability-backup-restore
Not scored by this record.
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
Not scored by this record.
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Not scored by this record.
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
Not scored by this record.
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
Not scored by this record.
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
Not scored by this record.
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
Not scored by this record.
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
Not scored by this record.
The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.
commercial-autorenew-terms-published
The Terms of Use is the only publicly accessible contract document on the site, and it is written mainly for the 'Ninja' independent contractors — account creation, contractor classification, arbitration, IP, disclaimers. The single fee provision is 'You may not receive a refund of fees. If you have paid for any services and you decide to terminate your account, you may use those services through the end of the commitment period.' It acknowledges a commitment period but never states its length, whether it renews automatically, or any cancellation notice window. No MSA, order form or subscription-terms page exists; /faq states pricing is customised per partner ('a per-transaction fee for access to the platform, and a separate hourly fee for Ninja usage') and directs buyers to book a demo, so renewal mechanics live only in a signed quote. Scored no on the publication test itself, which the vendor's own public terms settle; the underlying renewal term remains undisclosed. https://www.biteninja.com/terms · retrieved 2026-08-04
The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator
commercial-processing-not-bundled
Not scored by this record.
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
Not scored by this record.
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
Not scored by this record.
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
No rates, per-hour figures or subscription pricing anywhere on the site. https://biteninja.com/ · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
Not scored by this record.
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
https://web.archive.org/web/20231207022726/https://www.biteninja.com/products-services · retrieved 2026-09-06 adversarially verified
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
Not scored by this record.
One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.
commercial-implementation-fee-published
Not scored by this record.
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
Not scored by this record.
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Not scored by this record.
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Not scored by this record.
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Not scored by this record.
The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).
commercial-source-available-selfhost
Not scored by this record.
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
Not scored by this record.
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
Not scored by this record.
Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.
commercial-soc2-attestation
Not scored by this record.
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
Not scored by this record.
Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator
commercial-wcag-kiosk-accessibility
Not scored by this record.
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
Not scored by this record.
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 50 values — 30 upheld, 19 downgraded, 1 upgraded. It separately resolved 13 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| commercial-autorenew-terms-published | unknown, grade F, placeholder rationale 'No public documentation located during the 2026-08-01 research pass' — the cell was never examined | resolve-to-no | Read the vendor's only public contract document. biteninja.com/terms is written mainly for the Ninja contractors and its sole fee clause is 'You may not receive a refund of fees. If you have paid for any services and you decide to terminate your account, you may use those services through the end of the commitment period.' A commitment period is acknowledged; its length, whether it auto-renews, and any notice window are not stated. There is no MSA or subscription-terms page, and /faq confirms pricing is customised per partner behind a demo form, so the renewal term exists only in a signed quote. The claim tests publication, and the published terms answer it. source |
| commercial-hardware-purchase-outright | unknown, grade F, placeholder rationale 'No public documentation located during the 2026-08-01 research pass' — the cell was never examined | resolve-to-no | Hardware is required: /faq says the platform 'works in tandem with a small hardware component to tap into your restaurant's headset and POS system', and the Voicify acquisition release calls the platform 'both proprietary hardware and software'. No price is published for it. /faq: 'We customize pricing for our restaurant partners depending on integration needs, number of locations, and service type(s)'; /for-restaurants gives only a per-transaction platform fee plus an hourly Ninja fee and a demo form. The site has no pricing page and no hardware store, so the claim's published-price requirement is falsified by the vendor's own pricing statements. No lease is asserted — the commercial form of the hardware component is simply undisclosed. source |
| order-capture-scheduled-orders | unknown, grade F, placeholder rationale 'No public documentation located during the 2026-08-01 research pass' — the cell was never examined | resolve-to-no | /product-info (2026-08-04) enumerates the complete order-capture model and both modes are live-only: direct API integration with PAR Brink and Revel where the remote cashier enters the order in real time, or 'Shinobi' remote access where 'your remote workers will use the POS in the exact same way as your in-store team' on a dedicated register. NinjaQ dispatches a cashier only when a customer is detected present at the drive-thru or front counter (NinjaQ launch release). Bite Ninja therefore has no order channel of its own for a future-dated order to arrive through and no make queue of its own to fire it into — both belong to the merchant's underlying POS. /faq and /for-restaurants mention no scheduled or order-ahead path. Consistent with the record's existing structural noes (split-merge, offline entry, menu engine). source |
| extensibility-public-api-docs | unknown, grade F, placeholder rationale 'No public documentation located during the 2026-08-01 research pass' — the cell was never examined | resolve-to-no | The claim tests whether public, self-serve API reference documentation is readable, and an exhaustive sweep of the vendor's public estate on 2026-08-04 shows none exists: docs.biteninja.com (the only documentation host) contains contributor onboarding and a single /reference/ninjas user guide for remote cashiers, with no endpoints, auth or schemas; the pages-sitemap lists the whole of biteninja.com (ten marketing/legal pages) with no developer section; api.biteninja.com 404s; developers., developer., help. and support. subdomains do not resolve; the github.com/bite-ninja org's sole public repo is a desktop-automation library. /product-info positions the product only as an API consumer of PAR Brink and Revel. documentation.getbite.com belongs to Bite/getbite.com, a different company, and was not read onto this record. Like the commercial publication cells, the publication test itself is answered by the vendor's own public surface. source |
| order-capture-split-merge | no / F - Remote order-taking labor layer; check management belongs to the operator's POS." | downgrade-to-unknown | I attacked this the other way, hunting for a sentence that assigns check management to the operator's POS: the closest is /for-restaurants 'Bite Ninja works with your existing POS system', which is a compatibility claim and does not name checks. Row stands. |
| order-capture-offline-order-entry | no / F - Remote cashiers require connectivity by definition." | upheld | Target 6. The analyst's citation (the /product-info 'offsite order injection' sentence) fails: a sentence about how orders REACH the POS says nothing about connectivity and cannot make an offline absence positive. The value survives on a different, live 2026 sentence - the vendor conditions the whole platform on web access and the order-taker is definitionally offsite ('It allows remote workers to connect with your restaurant to place orders from offsite'), corroborated by the 2023 'accessed on any device with internet access'. The claim's second limb (published offline scope) also fails on a closed page census where 'offline' occurs only in /terms and in Wix store boilerplate. Value upheld, citation corrected. source |
| menu-pricing-nested-modifiers | no / F - No menu engine; operators' POS holds the menu." | downgrade-to-unknown | I tested whether /product-info's 'tap into your menu via API and display it with the Bite Ninja platform interface' plus the 2023 'Any menu changes made in your POS are automatically reflected in your Bite Ninja menu' positively assign menu authoring to the merchant POS and so rescue the 'no'. They do not: an imported menu still needs a modifier data model to render, and the vendor's own 'Menus' and 'Order Calculation' specs prove one exists. Row stands. |
| menu-pricing-modifier-price-by-parent-size | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | Same test as the nested-modifiers row, extended to 'size', 'matrix' and per-parent wording; I re-ran the tokenisation over all 69 texts and confirm the zero counts. No sentence makes the absence positive. Row stands. |
| menu-pricing-topping-quantity-tiers | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I re-ran the tokenisation and confirm topping=1, multiplier=0. I looked for a scope sentence assigning item pricing to the merchant POS and found none that names pricing. Row stands. |
| multi-location-central-menu-publish | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I tested the strongest anti-evidence (menu flows POS-to-Bite-Ninja) and it is scoped to the PAR Brink/Revel path only and dated 2023; the live 'Menus' spec title survives it. Nothing settles governance either way. Row stands. |
| multi-location-price-zones | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I checked that the analyst had not confused the vendor's own pricing with the merchant's menu pricing, and that the Zenu toggle sentence really is per-configuration rather than global; it is a feature-toggle sentence and supports neither value. Row stands. |
| payments-emv-nfc | no / F - Not a payments product; no first-party terminals." | upheld | Target 1. The analyst's carrying quote - the /product-info order-injection sentence - never mentions payment and cannot make a payment absence positive; I struck it. The value survives on the vendor's own description of where tender happens, which assigns acceptance to the merchant's window, counter and kiosk, corroborated by a first-party equipment list across 2021-2026 that names Control Box, vehicle sensors, firewall, kiosks, tablets and cameras and never a card reader, and by zero hits for EMV/NFC/contactless/Apple Pay in all 69 documents. Date ruling: the carrying sentence is a 2022 how-it-works page, so I lean on the 2026 census for the absence of any first-party terminal to certify. Value upheld, citation corrected. source |
| payments-gift-cards | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I broke the carrying quote two ways: it is a floor introduced by an 'and also' clause and is contradicted by the vendor's own broader Zenu scope sentence, and it is one editorial act the analyst repeated across four separate cells (gift cards plus all three inventory cells), which is not corroboration. No sentence anywhere assigns stored value to the merchant POS. Demoted no/C to unknown/F. |
| payments-refund-void-controls | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I confirmed the token counts myself (void 15, all legal; refund 4, all legal or shipping) and checked the row against labor-manager-override-audit and labor-granular-rbac, which the standing record already held at unknown on the same evidence - the record contradicted itself and this resolves it. Row stands. |
| inventory-recipe-bom-costing | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Target 2. I struck both of the analyst's supports: the FAQ 'remote labor pool' sentence is a floor (contradicted by the 2023 Zenu list ending 'view reports, and more'), and the argument that NO inventory title appears in the docs sidebar is exactly the forbidden move - a 25-page internal engineering doc site is not a product feature census and its silence is not the product's. The value nevertheless survives on a live 2026 vendor sentence that positively leaves the POS and its back office with the operator, against a definitional scope ('technology to staff their drive-thru and front counter with virtual cashiers') and zero corpus hits for inventory, recipe, ingredient, COGS or depletion across six years of vendor prose. Value upheld, citation and reasoning corrected. source |
| inventory-unit-conversion-yields | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Same ruling as the recipe cell: the repeated FAQ 'labor pool' quote is a floor and the sidebar-silence argument is struck. The value survives on the live sentence that keeps the merchant's POS and its purchasing and stock back office with the merchant; 'yield', 'waste', 'unit of measure', 'purchase order', 'par level', 'supplier' and 'inventory' are all zero across all 69 documents, and no document has ever placed a stock ledger in Zenu. Value upheld, citation corrected. source |
| inventory-count-modes | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Same ruling and same correction. I verified the tokenisation: 'inventory' 0, 'stock' 2 (both 'stockholders' in 2021 legal captures), 'count' only inside 'front counter'. There is no Bite Ninja stock ledger to count - orders terminate in the merchant POS under both published modes - and the live sentence makes that assignment positive rather than merely silent. Value upheld, citation corrected. source |
| reporting-eod-closeout | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | This is the sidebar used the honest way - to kill a no, not to keep one alive - and the date logic runs the right direction, a 2026 title outranking a 2023 export sentence. Row stands. |
| reporting-pmix-modifier-level | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I tested whether that POS-side reporting sentence could carry a no in 2026, when both surviving modes inject into the merchant POS. It cannot: it is mode-scoped, dated 2023, and coexists with a Zenu dashboard the vendor asserts in the same capture set. Row stands. |
| reporting-realtime-dashboard | unknown / F - /for-restaurants (2026-08-04) advertises a web-based platform to 'manage from anywhere' and 'optimiz | upheld | Target 3. The carrying quote does not name the feature, which breaks the partial on its face. Arguing both ways on date: the Standalone System packaging is gone from the 2026 census, but 2026 silence is not withdrawal, so I did not use age against it - the row falls on evidence. A partial's note must name a KNOWN shortfall; here the core limb, live sales within minutes, is unestablished rather than shortfallen. Demoted partial/C back to unknown/F. |
| kitchen-station-routing | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Target 1. I struck the /product-info injection sentence as the carrier: a sentence about how orders REACH the POS is not an enumeration of what the product does not do, and 'We offer two methods for connecting with your POS system:' closes the CONNECTION list, not the feature list. The value survives on a sentence that actually assigns kitchen ticket display elsewhere, and on the fact that the vendor's only two published kitchen arrangements are single-destination - the merchant's existing display screen in the integrated path, one provided 'monitor or tablet' in the standalone path. No stations and no routing rules in either. Value upheld, citation corrected. source |
| kitchen-expo-consolidation | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Same correction as station routing: the injection sentence is struck and replaced by the sentence that positively locates the kitchen view. Expo consolidation presupposes multiple contributing prep stations; both published kitchen arrangements are one screen, and 'expo', 'bump' and 'consolidat' are zero across all 69 documents. Value upheld, citation corrected. source |
| kitchen-bump-bar-hardware | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Target 3. I tested the date: this is a Dec-2023 sentence on a path that 404s today, so I asked whether it may speak about the 2026 product. It may, in this direction only - the 2026 census sells no kitchen hardware at all, so the 2023 denial is the vendor's most recent word and nothing has reversed it. 'bump' and 'keypad' are zero corpus-wide, and the vendor's only kitchen device ever named is 'a monitor or tablet', an affirmative statement of what is provided, so the absence of a bump bar and of any supported-model list is positive. Row stands. source |
| delivery-driver-roster | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | I checked that this is a definitional scope sentence naming the channels served rather than a feature list that could be read as a floor, and confirmed 'driver' is zero across all 69 documents while every 'delivery' hit is service-of-notice legalese. A native driver module with clock-in state and run history falls outside the two channels the vendor names. Grade D is correct for a home-page sentence. Row stands. source |
| delivery-dispatch-board | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | I tested the one dispatch-shaped thing the vendor does own, the NinjaQ 'lobby', and confirm it dispatches remote cashiers to a customer station rather than orders to drivers ('the next available cashier is automatically pulled to the station'). No run batching and no driver availability anywhere. Row stands. source |
| hardware-offline-mode | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Date ruling: this is a 2023 sentence, but the web-based architecture it states is confirmed live in 2026 ('Our platform is web-based, meaning it can be accessed from anywhere.', /faq and /for-restaurants), so it may speak about the 2026 product on this narrow point. The connectivity precondition is affirmative rather than inferred from silence, and the claim's documentation limb - that the vendor documents which functions degrade - fails on a closed page census where 'offline' appears only in /terms and in Wix store boilerplate. Row stands. source |
| hardware-kds | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upgrade-to-partial | Target 4, and it falls. Analyst C rejected partial partly because the standalone packaging is absent from the 2026 census - but this sweep's own rule is that silence is not withdrawal, and the same analyst pool applied that rule in the opposite direction in this session, letting the 2023 Zenu loyalty toggle destroy three guest-loyalty 'no's. A flat 'no' asserts the vendor neither sells nor supports a dedicated kitchen display, and the corpus positively contradicts that. The three functional limbs genuinely fail, which is what the note is for. Corrected no/C to partial/C. source |
| hardware-os-platforms | unknown / F - No published client OS list or device specs for cashier or in-store endpoints." | resolve-to-partial | I pressed on whether 'web-based' names a platform at all, since the claim asks for specific OSes AND minimum versions. It survives as a partial because the claim's own parenthetical treats web as a platform family, the vendor documents it affirmatively, and the documentation surface here is a census - so the missing OS names are a measured shortfall rather than an unknown. Row stands. source |
| reliability-offline-order-entry | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Same date ruling as hardware-offline-mode: the web-based precondition is restated live in 2026, so the 2023 sentence may speak. The order-taker is definitionally offsite and reaches the store over the internet, so this is a stated precondition rather than an inference from silence, and 'cache', 'local mode' and 'store-and-forward' are zero corpus-wide. Row stands. source |
| reliability-offline-kds-printing | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | I checked the strongest objection - that in the integrated mode kitchen printing belongs to the merchant POS and would survive a WAN outage - and it does not rescue the claim, because that printing is not a Bite Ninja function at all; the only Bite Ninja-side kitchen paths are the Zenu monitor and the one provided receipt printer, both fed by a platform the vendor conditions on internet access. Row stands. source |
| reliability-printer-fallback | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I verified the token count myself: 'printer' appears exactly once across the corpus. A provisioning sentence cannot carry a resilience absence, and the record's prior 'no' was sourceless. Row stands. |
| commercial-hardware-purchase-outright | no / C - Hardware is required — /faq: 'The software platform works in tandem with a small hardware component | upheld | Target 5, and it survives. 'Depending on your package, additional equipment may also be provided or purchased.' does not defeat the no: 'or purchased' is scoped to ADDITIONAL equipment, whereas the claim requires ALL REQUIRED hardware to be purchasable outright, and the required Control Box, sensors and firewall are stated to be rental included in a monthly fee for all packages. The published-price limb fails independently on a live 2026 sentence - /faq 'We customize pricing for our restaurant partners depending on integration needs, number of locations, and service type(s).' - with the archived pricing pages reading 'COMING SOON' and 'No plans available', so the row does not rest on the 2023 capture alone. Row stands. source |
| digital-first-party-web | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | I attacked this as a possible category error - a restaurant's own-branded ordering domain might not be governed by these Terms - but the Terms govern zenu.biteninja.com and biteninja.com, which is where any Bite Ninja-produced ordering surface would live, and a diner using such a surface would be using the Services. I also checked the one candidate for a guest channel, the 2023 'Choose between two views to place orders: the traditional POS view, and an online ordering view', and confirmed both are remote-cashier views inside Zenu, not diner-facing. Grade B is correct for a vendor legal page. Row stands. source |
| digital-menu-single-source | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | Target 1. The analyst cited the /product-info injection sentence, which says nothing about digital channels or menu propagation; struck. The argument the analyst actually made is a dependency on digital-first-party-web - there are no first-party digital guest channels for a menu edit to propagate to - so I re-cited the row to the sentence that establishes that, raising the grade from C to B. The one propagation sentence in the corpus ('Any menu changes made in your POS are automatically reflected in your Bite Ninja menu', 2023, PAR Brink/Revel only) propagates into an internal operator view, which is not a digital ordering channel. Value upheld, citation and grade corrected. source |
| digital-account-saved-payment | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | upheld | I tested whether this quote really closes the account taxonomy, since a two-way 'may vary depending on' could in principle be a floor. It is closed by the neighbouring 'The Services are for the use of Workers/Ninjas and Clients only', and corroborated by the live Zenu /users/sign-up form, which asks only for first name, last name, email and password - no address, no card. I deliberately do not count this as independent corroboration of the two sibling rows: all three rest on the same Terms passage, which is one editorial act. Row stands. source |
| guest-loyalty-unified-profile | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I checked the token count myself - 'loyalty' occurs exactly once in 69 documents, in that sentence - and confirmed it is vendor prose about Zenu's own feature set rather than a third-party reference. A single toggle name cannot establish identity resolution in either direction. Row stands. |
| guest-loyalty-accrual-models | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I confirmed this is not double-counting dressed as corroboration: it is one sentence carrying three loyalty rows and the analyst says so. A toggle named 'loyalty programs' says nothing about how points are earned, so partial is unavailable too. Row stands. |
| guest-loyalty-lifecycle-automation | no / F - Migrated from the 2026-08-01 research pass; no source URL was recorded." | downgrade-to-unknown | I tested the privacy-policy sentence for miscitation risk and agree it is the vendor's own mailing list, correctly excluded rather than pressed into service. No scope sentence assigns guest marketing to the operator's own stack. Row stands. |
| labor-clock-in-at-pos | unknown / F - Product is a labor marketplace with its own shift/queue model; no POS time clock." | upheld | I tested whether the Ninja scheduling and payout titles could be pushed into a yes or a partial and they cannot - a title never establishes contents. I also checked the record was not being quietly upgraded off its existing unknown; it is not. Row stands. |
| labor-granular-rbac | unknown / F - Checked biteninja.com in full on 2026-08-04 — home, /about, /for-restaurants, /product-info, /faq, / | upheld | I broke the analyst's promotion to partial. A partial's note must name a KNOWN shortfall; this note names two unknowns ('it does not show...'), and the evidence establishes only the baseline the claim was written to rule out. Crediting it as partial would score the vendor for the thing the claim excludes. Corrected partial/C to unknown/F. |
| labor-manager-override-audit | unknown / F - Same sweep of the seven public biteninja.com pages on 2026-08-04, plus the NinjaQ launch release and | upheld | I checked the 'override' hit for miscitation and confirm the analyst correctly excluded an anti-abuse clause rather than pressing it into service. Attribution and immutability are the whole claim and neither is evidenced at all, so partial is unavailable. Row stands. |
| extensibility-public-api-docs | no / B - The claim tests publication itself, and the vendor's public estate answers it. docs.biteninja.com is | upheld | The serious objection is that the Zenu sign-up at /users/sign-up is public and self-serve, so the gated docs might be readable without a partner agreement, NDA or sales call - which would defeat the no. It is defeated in turn by the vendor's own Terms: 'we will determine whether or not to approve the proposed account based on the needs of Bite Ninja's Clients', so account creation is discretionary, not self-serve in effect. I also confirmed the two readable pages contain no endpoints, authentication, schemas or webhooks, and that the bite-ninja GitHub org's entire public list is one archived Windows automation library. Row stands. source |
| extensibility-oauth-partner-apps | unknown / F - Bite Ninja appears in /product-info (2026-08-04) only as an API CONSUMER: 'We currently have a direc | upheld | I checked specifically that the Google SSO button had not been read as evidence for or against the claim; it correctly is not. Row stands. |
| extensibility-webhooks-push | unknown / F - No API surface of any kind is published. /product-info (2026-08-04) describes only inbound integrati | upheld | I verified 'webhook' is zero across all 69 documents and that the RFC title is used only to destroy a no, never to support a yes. Push versus poll is untestable from a corpus containing no API surface. Row stands. |
| order-capture-scheduled-orders | no / C - /product-info enumerates the product's entire order-capture model and both modes are live-only: a di | downgrade-to-unknown | Target 7, emitted as an unassigned correction. This is the floor-versus-ceiling error stated explicitly in the record's own note, and the corpus positively refutes the enumeration premise via the gated sidebar's phone-order channel. Demoted no/C to unknown/F. |
| extensibility-oauth-partner-apps | unknown, grade F | upheld | Proposed no from the archived Zenu API 2.0 spec and live zenu.biteninja.com bundle (310th session); rejected on verification: Quotes confirmed, conclusion not. Re-fetched the Wayback capture (200, 485,754 bytes). Parsed as JSON, both local specs ('Zenu API' 2.0, 181 and 178 paths) define components.securitySchemes as exactly {bearer: http/bearer/JWT}. GET /organizations also references an undefined 'cookie' scheme. The bundle literal security:[{scheme:"bearer",type:"http"}] appears 270 times, in served chunks including b176bdb8ad77aebf.js. RevelIntegration {key, secret} and VoicifyIntegration {key} exist as described. The 'oauth' bundle hits are the Firebase Auth error table and oauthToken handling. The 'client_secret' hits are Stripe payment_intent_client_secret. /payments/stripe/authorize is Stripe Connect. So the poison controls hold. But the proposal does not bound the claim. (1) This spec is the first-party app backend, self-described as 'For managing menus and placing orders', and it describes the operator and Ninja app's own JWT session. It is not a partner-integration surface. A single bearer scheme there shows how Bite Ninja's own client logs in. It is not a closed enumeration of how third parties are authorised. (2) The record's existing F rationale names gated docs.biteninja.com pages, /users/authorization/ and /integrations/ordering/. Those are a partner-facing ordering integration spec and an authorisation spec whose bodies nobody has read. That is exactly where partner auth would be documented, so the no rests on a failed search of the wrong corpus. (3) The DEVELOPER role and a DEVELOPER-gated nav both exist, so non-operator access runs through a model this spec does not explain. (4) The key/secret fields are outbound credentials, with Bite Ninja acting as a client of Revel, Voicify and PAR. They say nothing about how apps authenticate INTO Bite Ninja. (5) The spec is a 2025-04-15 capture. Live /docs now returns JSON 404, and the live operator portal is Voicify-branded, so the backend may have changed. (6) The one defensible finding, that there is no public third-party API programme, is already scored as extensibility-public-api-docs = no/B. A no here would largely double-count that cell rather than add positive evidence about OAuth. Absence of an OAuth scheme in a first-party backend is not positive evidence of absence. The cell stays unknown/F. Suggested rationale addition: the archived Zenu API 2.0 spec defines only a bearer-JWT scheme and no authorize/token/client/scope resources, but it is the first-party app backend, and the gated /users/authorization/ and /integrations/ordering/ specs remain unread. source |
| extensibility-webhooks-push | unknown, grade F | upheld | Proposed no from the archived Zenu API 2.0 spec and live zenu.biteninja.com bundle (310th session); rejected on verification: The proposal's facts check out, but they do not support a `no`. I parsed the archived Zenu API 2.0 spec as JSON: 181 paths, 173 schemas, bearer JWT only, and no OpenAPI `callbacks` or `webhooks` object. Every construct named 'webhook' is inbound, as the proposal says. POST /lobbies/presences takes AblyWebhookPresenceDto, whose Event.webhookId is Ably's id. POST /sensors/events and POST /summons/event take AblyWebhookSensorEventDto. POST /payments/stripe/events reads the stripe-signature header, and UserStripe says it is 'updated from the Stripe webhook'. PubSubMessageDto is the body of POST /jobs/runTask, a GCP push coming in. Of the 17 url-like fields, none is a partner delivery target (the named ones are Voicify.webSocketUrl, Image.uri, RedirectDto.url and onboarding media). The integration schemas (ParIntegration, RevelIntegration, VoicifyIntegration, plus the itsacheckmate and connecteam jobs) have Bite Ninja calling other systems' APIs. None of them is a subscription. The AblyMessageType enum does include orderUpdated. GET /users/ably/createTokenRequest needs a bearer token, and the Role enum has DEVELOPER, so whether an API user could subscribe to order channels is undocumented, not ruled out. In the served chunks, 'webhook' appears 0 times in zenu-all.js and in all 80 chunks. Ably is used via channels.get and subscribe for chat and station state (b176bdb8ad77aebf.js), and createAblyTokenRequest is the generated client in 570346cfb8eaea52.js and 82fa9906c3820bde.js. Why that still falls short of `no`: (1) A spec that lacks a subscription resource is a failed search, not a vendor statement of absence. Webhook targets are often set up out of band, and nothing in the spec lists the ways Bite Ninja sends events out. (2) The proposal left out that the spec has its own outbound notification surface: GET /notifications/{id}/email and /sms, and Contact.orderEmail, 'Email addresses to send order notifications to'. (3) The docs sidebar, which is gated, names /specifications/notifications/notifications/, /specifications/integrations/ordering/ and /specifications/orders/statuses/. Those unread pages are exactly where an outbound event contract would be documented. (4) The sidebar also lists /rfcs/rfc-20251016/, six months newer than the 2025-04-15 capture. Live /docs now returns 404, so the archive cannot stand in for the current API. Keep the prior unknown/F. Suggested rationale refresh: the archived 2025-04-15 Zenu API spec (181 paths) has no webhook-subscription resource; every webhook in it is inbound (Ably presence and sensors, Stripe, GCP Pub/Sub). Order fan-out goes over Ably to bearer-authenticated clients (AblyMessageType orderUpdated), and email/SMS order notifications exist. The gated Notifications, Integrations/Ordering and Order Statuses specs, and an RFC dated after the capture, leave a platform-wide no unbounded. source |
| labor-granular-rbac | unknown, grade F | resolve-to-no | Re-parsed both local spec copies as JSON (api-spec.json 181 paths/173 schemas, zenu-api-spec.json 178/170). Walked every enum: all six role enums are the same 7-value list. Schemas matching role/perm/scope/policy/access/grant are only UserRoles, UpdateUserMappedRolesDto, RolesScope and UpdateUserRolesDto. Checked control words in the spec: 'permissions' (1 hit) is the isNinja description; 'capability' (2) is the Ably token DTO; 'access' (2) is the PAR locationToken; 'granted' (2) is the scope description. 'policy', 'privilege' and 'acl' have 0 hits. In the bundle, all 5 'permission' hits are Firebase Storage SDK errors; 'capability' is Ably or MIME tables; 'ability' is yup nullability. canEdit, canView and privilege have 0 hits. The enum, ROLE_SCOPE and allowedRoles strings are all in chunks under js/ (80 served chunks). The Reports allowedRoles quote is confirmed verbatim. Why amended rather than upheld: (1) the proposal calls the live role set closed at 7, but the bundle adds MONITOR_ROLE = 7 outside the generated enum and gates navigation on it (J=[ADMINISTRATOR,MANAGER,7]). That is still a fixed role, so the verdict holds, but the note must not say the list is exhaustive. (2) The strongest evidence of absence was missing from the proposal: the operator role editor is a list of per-role switches, which is the actual granting UI and exposes no per-action grants. Why no and not partial: the claim's core limb, grants per discrete action beyond fixed tiers, is positively absent. The grant object's only fields are a role enum and a scope, and the live editor offers only role toggles. Location scoping meets one qualifier of a limb that does not exist, so a partial would contradict itself. This rests on a closed enumeration in the spec and the live UI, not only on a failed search. Currency: the 2025 spec is now 404 at api.biteninja.com/docs, but the 2026 live bundle independently shows the same role-plus-scope model. Grade A: an OpenAPI spec plus served client source. No double count: the only related bite-ninja cell, labor-manager-override-audit, is unknown and asks a different question (override logging). The prior unknown rationale ('roles with varying access levels ... is precisely the fixed arrangement this claim EXCLUDES') is consistent with this verdict. Residual risk: the gated /users/authorization doc page was not read, but the API manifest and the live editor it would have to describe are both read. source |
| menu-pricing-modifier-price-by-parent-size | unknown, grade F | resolve-to-partial | Parsed both local specs (api-spec.json prod, 173 schemas; zenu-api-spec.json staging, 170) as JSON. CategoryProduct, Price, Category (isModifier, isFreeOfCharge, products) and Product (price, modifiers) match the quotes exactly. priceOverride appears only in CategoryProduct, Category and UpdateCategoryDto. A property-name census over all schemas for size/variant/portion/parent found only ParIntegration.itemSizes and teamSize (a substring trap: shifts, not menus). The currency worry is answered by the live bundle. Served chunk b176bdb8ad77aebf.js (a notes.json key) resolves the modifier-card price as priceOverride ?? product.price, gated by isFreeOfCharge. Chunks 570346cfb8eaea52/82fa9906c3820bde deserialize priceOverride. So the 2025 model is still what the live app runs. Conjunct fit: the parent-item leg is partly met, since one modifier record is priced differently per parent through set membership, which is the 'rather than duplicating the modifier' test. The size leg and the matrix leg are not met. This follows the marketman precedent (per-topmost-item override with no size axis = partial), so the partial names a real shortfall and still meets one conjunct. It is not self-refuting. 'no' would need positive evidence of absence. A schema census bounds the published API but cannot rule out size handled some other way (for example nested size sets carrying their own overrides), so 'no' is not earned. 'unknown' would throw away a documented partial mechanism. No double count: the neighbouring nested-modifiers and topping-quantity-tiers cells are unknown/F and do not score this override. Grade A: OpenAPI spec plus served source. source |
| menu-pricing-nested-modifiers | unknown, grade F | resolve-to-yes | I re-parsed both local specs as JSON: api-spec.json has 181 paths and zenu-api-spec.json has 178, both 'Zenu API 2.0'. Category, Product, OrderItemModifierDto and OrderItemModifier match the quoted descriptions and self-references exactly. Every bundle quote is in a fetched chunk. The proposal blurred which chunk holds what: the recursive validator Q/T is in 0c925fd2bbd24130.js, and the renderer plus childModifiers are in b176bdb8ad77aebf.js. I found and added a third proof of depth the proposal lacked: component O calls O for each nested product's modifier tree, so the UI renders arbitrary depth as well as validating it. Conjunct fit: (1) >=3 levels is met because nesting is recursive in the schema, the validator and the renderer. (2) Independent per-level min/max is met, since Q reads each category's own fields. (3) The required flag is met by min>=1, which the spec labels 'required selections'. That matches the settled flipdish yes/A, which rests on a min field and recursive schema with no boolean. Partial was considered and rejected: a partial needs a named material shortfall, and 'no boolean' plus 'no observed 3-level menu' are not functional limits. Currency: the 2025 spec is corroborated by the 2026 live bundle using the same field names, so the archive is not stale. Substring traps: the quotes are Zenu menu code in named functions, not MUI 'override' noise. No double count: the only related bite-ninja cells are modifier-price-by-parent-size and pmix-modifier-level, which make different propositions. The weight is table-stakes, so no grade floor applies. Grade A is correct for an OpenAPI spec plus source. source |
| multi-location-central-menu-publish | unknown, grade F | resolve-to-partial | Re-opened the Wayback capture myself: HTTP 200, 485,754 bytes, containing /jobs/synchronizations/menus and SynchronizeMenusDto exactly as quoted. Local api-spec.json matches (Zenu API 2.0, 181 paths). Found synchronizeMenus, fromRestaurantId/toRestaurantId, compileMenusForRestaurant, importPosMenus and the 'Synchronize Menus' card title in the served chunk b176bdb8ad77aebf.js, and synchronizedAt deserialisers in chunks 570346cf and 82fa9906. On whether this is 'central publish': it is not. There is no master menu object, and the source is just another restaurant, so conjunct 1 (a corporate-level menu) is met only by treating one location as the de facto template. Whether synchronizationId makes re-syncs update linked copies rather than make one-off clones is undocumented, so the note asserts neither. Conjunct 2 (one action to chosen locations) is met at the API level. Conjunct 3 (history of what, when and by whom) is absent. The spec's own manifest is the census for that absence: searching the spec for audit, history, changedBy, createdBy, updatedBy and master gives zero hits. The 'publish' hits are Restaurant.publishedAt and a Pub/Sub publishTime, which are unrelated, and the 'version' hits are the info block and an API-domain field. At least one conjunct is really met, so the partial does not refute itself. Grade A holds because this is an OpenAPI spec corroborated by the live 2026 bundle. No double count: multi-location-price-zones mentions sync only as context for per-location product records, and scores a different proposition. I amended the note to say the source is a peer location, the UI sends one pair, history is transient page state, and the 2026 bundle confirms the spec is still current. source |
| multi-location-price-zones | unknown, grade F | resolve-to-no | I parsed both specs myself: the prod Wayback copy (api-spec.json, 181 paths) and staging (zenu-api-spec.json, 178 paths). Price, Product, CategoryProduct, SynchronizeMenusDto, setProductPrices, NinjaLobby.dayparts and the headset/notification 'channel' fields are all as quoted. Price and priceOverride are the only price fields on menu entities; the rest are on orders, the PAR integration, and indicativePrice (keyed by currency only). The spec lists what a price record can hold, so this is not a failed search. Separate products per restaurant do give different prices per location, but only by duplicating the record, which the claim wording excludes. So the multiple restaurants do not rescue the claim, and the no does not rest on the absence of the word 'zone'. On whether a 2025 spec is still current (live /docs now 404s): the 2026 live bundle confirms setProductPrices, synchronizeMenus {fromRestaurantId,toRestaurantId} and priceOverride in served chunks 570346cfb8eaea52, 82fa9906c3820bde, 0c925fd2bbd24130 and b176bdb8ad77aebf, and has zero price zone/tier/level/list/book hits. Wording fix: fromRestaurantId sits in chunk 0c925fd2bbd24130 (not a notes key), while b176bdb8ad77aebf only calls synchronizeMenus(from,to), so the note cites the spec for field names. No double count: no other bite-ninja claim cites this spec, synchronization or priceOverride. Grade A fits a vendor OpenAPI spec. Remaining risk is a post-2025 model change on the server that the frontend does not show; nothing supports that. source |
| order-capture-scheduled-orders | unknown, grade F | resolve-to-partial | Re-opened both sources. Spec parsed as JSON: Station.collectionTime enum, the LeadTime schema and the Order.collectionTime description are quoted verbatim. Bundle strings are confirmed in served chunks, but the proposal pinned two quotes to the wrong chunk. compareAsc(e.collectionTime,t.collectionTime) is in 0c925fd2bbd24130.js, and the leadTime.value admin form is in d41d2dcc5df97627.js, not b176. getLeadTimeDetails, earliestPickupTime and "required"===i.collectionTime are in b176. Amended the note with stronger evidence the proposal missed. A 'Pickup date' DatePicker allows up to two months ahead, which firmly establishes future-dated orders. A 'Show future' switch hides orders dated tomorrow or later, a whole-day display filter and not a computed fire time. That makes the shortfall concrete rather than a bare gap. It does not prove absence, so the verdict stays partial, not no. Two of three conjuncts are met, so this is not a self-refuting partial. Substring controls: collectionTime (37) and leadTime (10) were read in context. Fire, prep and schedule tokens are 0 when tokenised. Currency: the 2025 spec is used only as corroboration, and the cited URL is the live bundle, grade A as served client source. No double count: the only related scored cells are hardware-kds and reliability-offline-kds-printing, and neither concerns scheduling or lead time. source |
| order-capture-split-merge | unknown, grade F | resolve-to-partial | Re-parsed api-spec.json and zenu-api-spec.json as JSON. Title, path counts (181/178), the OrderPayment.amount description, PaymentDto and CreatePaymentIntentDto shapes and Order.payments all match the proposal exactly. There is no split, merge, seat or combine token in either spec, and every 'transfer' hit is voicify call-transfer or Stripe. Listed every /orders path: no move or merge endpoint, and no seat on Order or OrderItem. The shortfall is bounded by the vendor's own complete path manifest, confirmed by the independent staging capture, not by a failed search. Conjunct fit: several arbitrary-amount payments against one order meets the 'arbitrary dollar amount' conjunct only. Four conjuncts are missing, so this is partial, not yes, and not self-refuting: one conjunct is positively met. Amended for three reasons. (1) The proposal treated the bundle's zero split strings as a control. My raw grep found 231 'split' hits (JS .split calls), and 'Merge' is deepmerge/ChannelMergerNode, 'evenly' is CSS space-evenly and 'seat' is emoji data. More importantly, 80 anonymously fetched Next.js chunks are not a census of the signed-in app, so that zero is now only a bound. (2) 'Even N-way absent from the API' overstated things: N arbitrary payments can reproduce an even split by hand. The note now says there is no even-split operation. (3) It now notes that paymentIntent amount is optional and that percentage split is absent. No double count: payments-split-tender and order-capture-seat-level have no bite-ninja row and are not in its scope listing. Grade A holds, since this is the vendor's primary OpenAPI spec. The 2025 archive is accepted with its currency caveat, because the live bundle still shows the same isFullyPaid and gift-certificate payment model. source |
| payments-gift-cards | unknown, grade F | resolve-to-no | I re-parsed api-spec.json and zenu-api-spec.json as JSON (Zenu API 2.0, 181 and 178 paths). I confirmed the PaymentDto and OrderPayment type enums, that certificateNumber is a plain string, and that the only balance fields are on StripeCustomerDto. No path matches gift, card-balance, voucher, wallet or loyalty; the only 'card' path is Stripe simulateCard. Scanning all 80 chunks in js/, the dialog strings (DialogTitle 'Gift Certificate', label 'Gift certificate number', type:"giftCertificate") and the Card/Cash/Discount/GiftCertificate enum appear in served chunk b176bdb8ad77aebf.js. certificateNumber also appears in 0c925fd2bbd24130.js. The other 'gift' hits, in 55c70ca114c9784c.js, are emoji data. The proposed partial refutes itself: a hand-typed certificate number and amount with no balance meets no conjunct of the claim, which asks for first-party cards, real-time balance, cross-location redemption and online redemption. The live 2026 bundle confirms the tender list is current, so the 2025 spec is recent enough for the tender list; absence of a balance resource is bounded to that spec's manifest. The evidence gives a closed tender enumeration plus no balance resource, so the value is no, not partial. Double-count check: the split-tender proposal (order-capture-split-merge) cites PaymentDto for a different point, and no other bite-ninja cell covers this. source |
| reporting-eod-closeout | unknown, grade F | upheld | Proposed partial from the archived Zenu API 2.0 spec and live zenu.biteninja.com bundle (310th session); rejected on verification: Checked every quote. Parsed api-spec.json and zenu-api-spec.json as JSON. The six report paths, their from/to params, the six schemas' properties, POST /jobs/restaurants/endofday and Restaurant.disableAutomatedEndOfDay match the proposal exactly. The nav quote is in the served chunk js/735b9963daf3460b.js, which also holds excludeModes. But the partial fails on conjunct fit and on how it names its shortfall. (1) The step from the summaries to the End of Day page is the analyst's inference. The endpoints sit under /reports/orders/ and could just as well back the 'Orders' report, and the page's own chunk was never read (the live route 307s to sign-in and 0 schema field names are in the bundle). No source ties any gross, net, tax, discount or tender figure to the End of Day Report. (2) The named shortfall (no tips, refunds or expected deposit) rests on silence in six schemas from a 2025 spec. GET /orders/by-date (from/to) returns full Order objects carrying tipAmount and OrderPayment.status 'refunded', so the page could compute them client-side. That makes the shortfall a failed search, not a closed enumeration, and a partial whose limit is unestablished is not a finding. (3) The mapping has holes of its own. sumOfSubTotal as 'gross' and sumOfDiscountedSubTotal as 'net' are labels the analyst chose. 'Cash by Station' has no dedicated endpoint (StationsSummary holds only sumOfSubTotal, not cash). And the spec is 17 months older than the live UI, whose /docs now 404s. (4) Grade A would really mean an archived spec plus a minified nav label, and neither says what the report reconciles. No double count: reporting-realtime-dashboard and pmix are separate cells, and none of them uses the report summaries. Net effect: the new evidence strengthens the unknown (a native EOD report exists, so no 'no'), and the rationale should be replaced with amended_note. The value should not move. source |
| reporting-pmix-modifier-level | unknown, grade F | upheld | Proposed no from the archived Zenu API 2.0 spec and live zenu.biteninja.com bundle (310th session); rejected on verification: Neither enumeration closes the product's reporting surface. (1) Nav: 735b9963daf3460b.js holds TWO nav configs. The proposal quotes only the old 'Reports' subnavigation (End of Day / Orders / Cash by Station). The same chunk's newer grouped nav X=[{label:'Live'...}] has an 'Analytics' section (Store Pulse /manage/transcripts/pulse, Transcripts, Dashboard /manage/transcripts/dashboard) and a 'Live > Orders' /manage/order-history entry, none of which lists the report pages. So 'exactly three reports' is one of two menus, not a census. (2) Spec: the 2025-04-15 Zenu API 2.0 spec (api-spec.json parsed, 181 paths; the six /reports/orders/*-summary GETs and their schemas were confirmed as quoted) is provably STALE. The live generated client (570346cfb8eaea52.js / 82fa9906c3820bde.js) calls 11 paths absent from the spec, including GET /reports/dashboard (getDashboardSummary). Its client also does not include the six /reports/orders/* summaries, so the live report API manifest is unknown; live /docs 404s. (3) Unread pages: _buildManifest.js does not list /manage/reports/* at all (app-router, lazy), and the /manage/order-history loader 241beb33451fea16.js names 8 chunks (e3d8a051a0fcc28c, a33868e3225dac4c, 1893bbe6ae4dbc11, 900081f952c04b79, 1a66d361824daa83, b34d2c1536aaa55b, 15262209e27ddaaa, 6a4acb6df903567e) absent from the 80-chunk corpus. The Orders report columns, the order-history grid and any export are unread. (4) Export path open: the bundle ships MUI X DataGrid with 'Download as CSV' / 'Download as Excel' / 'Pivot' toolbar locale strings (d41d2dcc5df97627.js; library defaults, showToolbar:false by default, so not proven enabled). GET /orders/by-date returns full Orders whose items carry productName and self-referential modifiers (b176bdb8ad77aebf.js searches 'items.productName'), so an item-level export cannot be excluded. Controls: 'pmix|productMix|itemSales|salesByItem' are 0 across the bundle; the lone 'daypart' hit is updateLobby dayparts (NinjaLobby staffing), as the proposer said. Those are zeros from a failed search over a partial corpus, not positive absence. Keep unknown/F; the existing rationale stands, and this pass adds that the Zenu reports namespace exists but its item/modifier granularity is unread. source |
| payments-emv-nfc | no, grade C | downgrade-to-unknown | Parsed api-spec.json (181 paths) myself and confirmed the enum, the terminal paths and the reader action types. Grepped zenu-all.js: 0 bbpos/verifone/stripe_m2 literals, 'Card Reader' x5, reader-online guard 'Unable to take a payment as the card reader [...] is currently not online.' The published no was upheld on 2026-09-06 because the equipment list 'never names a card reader' and tender belongs to the merchant. The spec and bundle contradict that premise. They do not reach EMV, NFC or wallet acceptance, and a terminal model enum is not documentation of those conjuncts. So the value is falsified but no new value is reached. source |
| digital-first-party-web | no, grade B | downgrade-to-unknown | Read the raw 2022-05-20 capture myself. The visible text is only the restaurant name/address and 'Expand all List Orders', but __NEXT_DATA__ holds the cart/checkout i18n strings and the restaurant object. Read the zenu CDX list: 30 captures, storefront paths 2022-2024 all 200. Read the live _buildManifest routes. The 2026-09-06 upheld verdict dismissed the only guest-channel candidate as a remote-cashier view. These captures are a guest cart with online payment, so that premise fails. The Terms sentence 'The Services are for the use of Workers/Ninjas and Clients only' cannot outweigh a vendor-hosted storefront taking diner orders. source |
| kitchen-station-routing | no, grade C | downgrade-to-unknown | Checked the spec schemas and bundle myself. The per-product 'station' field is real, but it is undescribed and sits beside a Station model built for headsets, sensors and remote-desktop cashiers. The one bundle use found copies r.station when re-adding an order item. I found no filter of order items by product station in the KDS code. Route names and an undescribed field are not item-to-station routing rules, so the new evidence kills the no but reaches no value. source |
| kitchen-expo-consolidation | no, grade C | downgrade-to-unknown | Tokenised controls over both corpora: expo/expedit/consolidat 0, and bump 3, all emoji-keyword poison. Read the KDS card code: a single Serve/Undo button on order status, plus item 'done' styling. With stations and a restaurant-wide view present, a no based on single-screen can no longer stand on silence, and nothing reaches a partial or yes. source |
| order-capture-offline-order-entry | no, grade C | upheld | Grepped js/243cde8d43e61cc2.js myself: 'No internet' and addEventListener("offline",t) on line 4, and (eW,{children:(0,n.jsx)(e,{...t})}) plus let n="/_app" on line 8. serviceWorker.register is 0 in zenu-all.js. The value is unchanged, but the carrier moves from a /faq marketing sentence (C) to first-party source code (A) that positively enforces the absence. source |
| hardware-offline-mode | no, grade C | upheld | Same source check as order-capture-offline-order-entry, in chunk 243cde8d43e61cc2.js. The spec shows kitchen and receipt printing as server endpoints, so no local print path survives a WAN outage. Value upheld with stronger, grade-A first-party evidence replacing the 2023 products-services marketing page. source |
Sources
Every URL this record cites. 20 in total.
- https://biteninja.com/
- https://www.biteninja.com/product-info
- https://www.biteninja.com/for-restaurants
- https://www.biteninja.com/faq
- https://www.biteninja.com/terms
- https://www.biteninja.com/privacy
- https://www.biteninja.com/about
- https://www.prnewswire.com/news-releases/bite-ninja-launches-ninjaq-remote-staffing-system-301857855.html
- https://docs.biteninja.com/
- https://www.biteninja.com/pages-sitemap.xml
- https://github.com/orgs/bite-ninja/repositories
- https://web.archive.org/web/20220128184259/https://biteninja.com/restaurants/
- https://web.archive.org/web/20231207030928/https://www.biteninja.com/pos-integration
- https://www.biteninja.com/
- https://web.archive.org/web/20231207022726/https://www.biteninja.com/products-services
- https://web.archive.org/web/20231207035204/https://www.biteninja.com/copy-of-pos-integration
- https://docs.biteninja.com/reference/ninjas
- https://web.archive.org/web/20250415233140id_/https://api.biteninja.com/docs/swagger-ui-init.js
- https://zenu.biteninja.com/_next/static/chunks/b176bdb8ad77aebf.js
- https://zenu.biteninja.com/_next/static/chunks/243cde8d43e61cc2.js