HungerRush

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

The 'Guest & Table Management Guide' PDF attached to support.hungerrush.com article 31404054201101 documents a full graphical floor-plan editor: 'This section will show you how to design and build your dining area(s) and/or bar(s) visual room layout ... which will allow your servers and bartenders to open and maintain orders by using the graphical room layout.' Rooms are created with Add (Room Name, Background Image, Tile) and switched via a Current Room dropdown, so multiple layouts are saved per store; the object library holds tables that 'vary in size to represent a 2 Top, 4 Top, Round, and Booth' plus Bar Seats, each dropped by click, rotatable with green arrows, and carrying Table Properties of Table Type, Table Name and Number of Seats. Layouts export/import as a .rdf file. Server assignment: POS Config > System > Install Settings has 'Use Table Layout' and 'Open Table Selection', and the guide states that without Open Table Selection 'a manager to assign tables prior to each shift', with 'Server table assignments ... set within the Revention point of sale under Config > Table Management'; labor types Server and Bartender each get 'Use Table Lookup' and a Default Room. Live layout colour-codes owned tables green and other servers' tables orange. https://support.hungerrush.com/hc/article_attachments/31404066628749 · retrieved 2026-08-08

Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.

order-capture-seat-level

Printer Configuration documents 'Print Seat Number' (prints the seat number next to the item in brackets) and 'Sort by Seat Number' (organizes the kitchen ticket by seat) as configurable printer options, confirming order lines carry a seat attribute at entry. Shortfall: no article documents assigning a seat number during order entry from a specific UI control, or splitting a check specifically 'by seat' afterward -- 'How to Split an Order' only supports free-form item-to-check splitting, not a seat-tagged split mode. https://support.hungerrush.com/hc/en-us/articles/19248778146445-Printer-Configuration · retrieved 2026-08-04

Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.

order-capture-coursing-hold-fire

The HungerRush Orders Guide (PDF attached to support.hungerrush.com article 25386625695245) lists HoldFire as an assignable Order Action: 'HoldFire allows users to send portions of the entire order to the kitchen and hold off on other items until "fired" to the kitchen. Once enabled, the applicable Order Types will need to be designated before HoldFire can be used.' The order display marks a 'Held Item' with a red highlight 'denot[ing] this Menu Item as held and not fired/sent to the kitchen' and shows a 'Hold Time' column for how long items have been held; the Guest & Table Management guide adds that a table with a partly fired order shows a segmented red line. A separate SendStay action sends time-sensitive items 'like appetizers or drinks ... to their respective printers before the main course'. Shortfall: hold-and-fire is per-item, not per-course -- no documented course construct to which items are assigned, and no fire-next-course action; nothing states HoldFire is available on the handheld tablet as opposed to a terminal. https://support.hungerrush.com/hc/article_attachments/25386767266957 · retrieved 2026-08-08

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

'How to Split an Order' documents splitting a rung-in order into multiple checks by moving individual items, including splitting one item's price evenly across an operator-chosen number of checks. 'Order Lookup Screen Functions' documents a Merge Orders function that merges two orders together with a confirmation step (irreversible). Shortfall: explicit splitting by seat, by even N-way for a whole check, and by arbitrary dollar/percentage amount are not separately documented, and merging after partial payment is not addressed. https://support.hungerrush.com/hc/en-us/articles/19248774462093-How-to-Split-an-Order · retrieved 2026-08-04

Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator

order-capture-bar-tab-preauth

Documents an order-type flag ('Get Cust Name From CC') for bar order types: swiping the card at Collect/Send pulls the customer's name from the mag-stripe, 'which allows you to pre-authorize a credit card to start a tab shortly afterwards.' Confirms card-based tab opening exists. Shortfalls: no documented configurable authorization amount, no incremental re-auth as the tab grows, and no documented auto-close of stale tabs at end of day. https://support.hungerrush.com/hc/en-us/articles/19248805682445-Requiring-Customer-s-Name-For-Credit-Card-Swipe · retrieved 2026-08-04

An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.

order-capture-transfer-audit

Documents transferring an open order between servers via a 'Reassign Server orders' security permission and a Reassign action in Order Lookup. Table/device transfer is not separately documented, and no article states the transfer is written to a queryable audit log naming both employees -- only that the order's current server changes. https://support.hungerrush.com/hc/en-us/articles/19248802101389-Transferring-Orders-Between-Servers · retrieved 2026-08-04

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

First-party POS Tablet, water-resistant, 8-hour battery, for tableside ordering and payment. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

'Forcing Credit Cards - DataCap' and the TriPOS twin document the POS operating through an internet outage: the operator configures 'the test site that Revention will try to reach if it detects a loss of connection' and 'the amount of time that Revention will try for a connection before rolling over to force mode', with an Auto Force toggle; in use, 'once you try to collect payment with no internet you will get a declined error on screen', i.e. the order was built and taken to tender locally, and the transaction is then forced and stored for later manual batching. HungerRush 360 runs on in-store Windows stations (menus import/export to C:\Revention, station restarts are local), and www.hungerrush.com/products/hardware/ advertises 'offline operations mode'. Shortfall: the vendor publishes no offline feature matrix -- nothing states what does and does not work offline, whether the tablet handheld and KDS keep receiving from the local network, or whether cash tender and kitchen routing are unaffected. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-08

Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator

order-capture-qr-same-check

HungerRush's only QR surface is payment, never ordering. The Scan to Pay article's guest flow is complete and closed: 'The guest scans the QR code on their POS receipt or directly in the DriverTrack app', then 'The guest can select from a pre-set list of tip percentages', 'Then choose the payment type, either credit/debit card or Apple Pay', 'The guest then enters their credit/debit card information', 'Once the information is complete, they tap "Pay Now."' The operator setting is named for it: '(8) Display QR Code for Payment adds a QR code on receipts that links to your store's online payment'. No item selection by the guest occurs at any step, so nothing is written onto the open check — the check is only settled and closed. The Scan to Pay Data Sheet's Key Features list ('QR Code Payments', 'Automatic Check Closeout', 'Digital Receipts', 'Multiple Payment Types', 'Customizable Gratuity Options', 'Flexible Configuration') likewise contains no ordering feature. This is now a finding of absence rather than silence because the help centre is a closed census (313 of 313 articles read; the Zendesk API and /hc/sitemap.xml agree exactly, 0 articles in one and not the other), QR-at-table is an operator-configured feature that would be documented there, and all 67 occurrences of 'QR' across the census are payment-related; 'scan to order', 'QR menu', 'table QR', 'same check', 'add to check' and 'order at table' return zero. https://support.hungerrush.com/hc/en-us/articles/40694197880461-Scan-to-Pay · retrieved 2026-09-04 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

Kiosk is supplied by third-party partner INFI, listed under Integrations. No first-party kiosk in the hardware catalog. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

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

'Creating New Order Types' documents a 'Drive thru?' checkbox when creating an order type, and 'Configuring Specific Payment Types by Station' documents excluding payment types at a drive-thru station -- drive-thru is a distinct, configurable order type. Shortfall: no documentation of order-point/pay-window/pickup-window separation, tandem-lane sequencing, or pull-forward/parking-spot assignment; the flag is a reporting/workflow tag only. https://support.hungerrush.com/hc/en-us/articles/19248787462541-Creating-New-Order-Types · retrieved 2026-08-04

Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.

order-capture-drive-thru-timers

The System Configuration Guide (PDF attached to support.hungerrush.com article 25386625695245) documents order-type property 16: 'Drivethru? Indicates the order type is a drive thru order and the system will track the time lapse between order taken time and order paid time.' The POS dashboard carries a gauge that alternates between 'Delivery Out the Door Time or Drive Thru, depending on which gauge is active', and drive-thru is also a first-class order type for KDS filtering and per-station payment-type restriction. Shortfall: exactly one interval is captured per order (order taken to order paid). No order/total/window segmentation is documented, no window or presenter timestamp exists, and no drive-thru speed-of-service report appears among the 40 articles in the Report Purpose and Metric Guides section. https://support.hungerrush.com/hc/article_attachments/25386797512845 · retrieved 2026-08-08

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

Downgraded from yes/D on re-verification. OrderAI Talk is genuinely first-party and the product page says it 'syncs directly with your POS to eliminate manual entry', but that is a sell page, not documentation. Named shortfalls: (1) the vendor help centre at support.hungerrush.com returns zero articles for 'OrderAI', 'ConverseNow' or voice ordering — no setup, configuration, menu-training or order-injection doc exists publicly, so the POS-side injection path is unverified; (2) OrderAI Talk appears on neither published pricing tier (Starter or Custom), so it is a quote-only separate purchase; (3) trade reporting on the Jet's Pizza flagship deployment describes phone-bot programs through 'both ConverseNow and HungerRush', so the reference deployment is not purely first-party. No grade A/B evidence located, so a differentiator 'yes' cannot stand. https://www.hungerrush.com/products/orderai-ai-ordering-system/ · retrieved 2026-08-02 adversarially verified

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

Release notes (9/27/2022) document 'Throttling for Online Ordering', configurable at System and Store level in the Admin Portal, 'set to allow only the max order count per 15-minute time slots across open store hours' -- per-channel, per-time-slot capacity limiting. Shortfall: documented for the website ordering channel only (not other digital channels), and it caps/rejects orders rather than automatically extending the quoted prep time. https://support.hungerrush.com/hc/en-us/articles/19248733300109-Release-Notes-09-27-2022 · retrieved 2026-08-04

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

'Pre-ordering' is listed. Per-channel lead time and computed fire-time injection into the make queue are not documented. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01

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

The System Configuration Guide (PDF on support.hungerrush.com article 25386625695245) lists Catering among the built-in order types ('Dine In, Bar, To Go, Pick Up, Delivery, Catering, Walk In, Counter, Web Delivery and Web Pick Up') and documents order-type property 24, 'Minimum Order is the minimum order amount required for the order type. This is a setting used for delivery or catering orders.' Catering orders can be filtered onto their own kitchen display ('only items from ToGo, Web Delivery, Web Pickup and Catering orders would appear on this display' -- Configuring an Item Kitchen Display), and the separate Deferred Orders screen holds future-dated orders with an Order Type column, which is the event schedule in practice. Shortfall: no catering quote, no deposit or partial-prepayment step, and no balance-due tracking is documented; the closest is the generic Customer Accounts house-account statement. Deferred orders are the standard future-order queue, not a catering-specific event calendar. https://support.hungerrush.com/hc/article_attachments/25386797512845 · retrieved 2026-08-08

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

DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. THE VERDICT RESTS ON HUNGERRUSH'S OWN DOCUMENTATION, NOT ON THE FLAG — which matters, because a false flag alone could not carry a `no`. The Third Party API subsection of the Releases by Category index enumerates the complete set of outbound third-party events HungerRush has announced — an out-of-stock webhook and an out-of-stock status API alongside GetMenu and ProcessOrder — with nothing about order readiness, read against a help centre closed as a 313-of-313 census. That is a bounded enumeration rather than a mere silence. The registry supplies the independent corroboration the prior pass lacked: `SUPPORT_ORDER_READY_SIGNAL` is FALSE for `hunger_rush_production`, which carries 3 of the 8 high-quality features. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12

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

The Adjustments Details report guide is the exception report and its column list carries the whole control chain: 'The Adjustments Detail report is best used to identify all adjustments to your orders (Adjustments, Coupons, and Voids) along with customer and employee information', with metrics 'Reason: Reason added for the adjustment/coupon' and 'Emp/Apv Emp: Employee that applied the adjustment and the approver (if one needed)'. Adjustments Summary aggregates by type with drill-down. On the POS side, 'How to Adjust the Price of an Order or Item' walks Void, Comp, Percent off and Edit price and states 'For Voids and Comps there are extra steps ... Finally you will be asked to enter reason for the adjustment for reporting purposes' (plus an inventory-waste prompt). Gating is role-based: Config > System has 'Security by Labor Type ... links a Security Group to each Labor Type. This ensures an employee can only perform point of sale tasks related to their current job code', and permissions are also settable per employee under Mgmt > Employee > Securities > Orders. https://support.hungerrush.com/hc/en-us/articles/39832752030349-Adjustments-Details · retrieved 2026-08-08

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

'Preferences' documents a preference (e.g. dressing choice) as one selection layer, and the Menu tab's 'Allow Preference Modifiers' documents a second layer of modifiers applied to a preference ('a baked potato... preference and the butter, sour cream and bacon would be modifiers to that baked potato') -- two levels of nesting confirmed. A third level, and independent min/max selection counts configured per level (only a group-level required flag and a per-modifier max-extra-quantity are documented), are not confirmed. https://support.hungerrush.com/hc/en-us/articles/19248778779021-Preferences · retrieved 2026-08-04

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

'Modifiers' documents that, unless Standard Modifier Pricing is enabled, 'here is where you can price out each mod. It is broken down by sizes on the menu' -- a per-size pricing matrix configured directly per group/item rather than by duplicating the modifier record. https://support.hungerrush.com/hc/en-us/articles/19248810704525-Modifiers · retrieved 2026-08-04

Supports fractional/sectioned modifier placement (at minimum halves, ideally quarters) with independent pricing per section. differentiator

menu-pricing-fractional-placement

The Menu Editor in Restaurant Management guide documents group setting 'Allow Half/Half -- This setting allows the menu items within the group to be ordered as Half and Half and the modifiers within the group can be added to half of an item. There is an option at the modifier level to not allow a modifier to be split in half', and three independent per-section pricing rules: 'Most Expensive Half -- Selecting the Most Expensive Half will charge the customer for the entire amount of the most expensive half of the two halves' (worked example: half Supreme $14.95 / half Cheese+Pepperoni $10.99 charges $14.95); 'Round Up to Next Whole'; and 'Set Half Modifier Price -- allows you to manually set prices for half modifiers ... A whole pepperoni that costs $1.00 and the half price could be set to $.75. When enabled, an extra "Half Price" field appears when pricing each modifier.' If not set, 'the system will charge half of the original modifier price', splitting odd cents ($.99 becomes $.50 + $.49). At order entry the Orders Guide documents Half 1 and Half 2 buttons -- 'Select half 1 to place your modifiers on one side' -- and the current help centre carries the same switches (Manage Modifiers 'No Half/Half', Sizes 'No half and half', Creating a New Group 'Allow Half/Half'). Halves only: no quarters or four-section placement is documented anywhere. https://support.hungerrush.com/hc/article_attachments/46512465331853 · retrieved 2026-08-08

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

Release notes document a configurable 'most expensive half' rule ('When most expensive half is enabled, split items retain their original price...'), and the Modifiers article documents a per-modifier 'No half' flag and a half-specific price field, confirming half-and-half is a real, operator-configurable pricing feature. Only one named rule option (charge the higher-priced half) is documented in public sources; a second option (average, or fractional) required by the claim was not found. https://support.hungerrush.com/hc/en-us/articles/19248762641421-Release-Notes-06-21-2022 · retrieved 2026-08-04

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

The Menu tab documents an 'Extra' quantity label (2X/Xtra) and a 'Lite' label with distinct receipt/kitchen display, plus 'Extra Modifier Limit' (a configurable max extra count), and the Modifiers article documents 'Standard Modifier Pricing' setting 'a different price for extra of the same mod.' Confirms a Lite/Extra two-tier system with distinct extra pricing. A separate 'double' tier with its own multiplier, distinct from repeating 'extra', is not documented. https://support.hungerrush.com/hc/en-us/articles/19248779094413-Menu · retrieved 2026-08-04

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

'Style Pricing' in Menu Manager is a grid: 'click on the field under the column labeled with the size description' for each style row -- a size x style price matrix with per-cell override, matching the claim directly. https://support.hungerrush.com/hc/en-us/articles/38746480618765-Set-Up-Pricing-Setting-Brand-Default-Price-and-Individual-Store-Price-Override · retrieved 2026-08-04

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

Pizza page: interface 'applies ingredient upcharges for you automatically' — implies an included set with overage charging; substitution credit rules undocumented. https://www.hungerrush.com/cuisine/pizza-pos/ · retrieved 2026-08-01

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

The Menu Best Practices guide's 'Linking Modifiers to Preferences' section states 'HungerRush offers a unique design to allow a user to modify the ingredients of a selected Preference. This option is extremely helpful for the setup of combo meals, combination plates, and entree sides', and instructs 'Are there any substitution options for an upcharge? If so, include those options within the Preference selection' -- i.e. component swap with a price delta. The current Menu Manager articles carry the machinery: Preferences with Preference Members, an Assign Preference page with a Default Preference Member and drag-and-drop sequence, a Preferences Pricing tab for per-member prices, and per-member Excluded Stores. Components can route to different kitchen stations ('The Filet will print to the Grill station and the Side Salad will print to the Cold station'). Shortfall: nothing in the 313 help-centre articles or the 12 user-guide PDFs documents automatic detection of eligible a-la-carte items already in the cart and conversion to a combo price -- the nearest mechanisms are Second Item Pricing (buy one, second of the same type at a set price), Tiered Pricing, and Multi Item coupons, all of which are discounts rather than combo conversion. https://support.hungerrush.com/hc/article_attachments/25386797492749 · retrieved 2026-08-08

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

OrderAI 'suggests add-ons to boost sales'. Per-item/per-channel configuration and attach-rate reporting are not documented. https://www.hungerrush.com/products/orderai-ai-ordering-system/ · retrieved 2026-08-01

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

'Menu Control' documents marking items/modifiers/preferences out of stock and using the 'Upload OOStock' button to 'commit your changes to your other stations and online menu' -- propagation to POS stations and first-party online ordering is confirmed. Shortfall: propagation to KDS, kiosk, and connected third-party marketplaces is not documented, no latency figure is published, and the action is a manual upload rather than automatic. https://support.hungerrush.com/hc/en-us/articles/47634977612429-Menu-Control-Set-Menu-Items-Out-of-Stock · retrieved 2026-08-04

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

'Configuring and Using Item Countdown' documents a per-item countdown that decrements on sale and blocks further ringing at zero. The article explicitly states 'Item countdown does not work correctly for online orders and is used for in store application only', and no scheduled auto-restore is documented -- both are named shortfalls against the claim. https://support.hungerrush.com/hc/en-us/articles/19248802268301-Configuring-and-Using-Item-Countdown · retrieved 2026-08-04

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

'How to set up Time Pricing' documents scheduling a price change to activate/deactivate on selected days of the week between a start and stop time, and the Menu tab's 'Allow Custom Group Sequence' documents changing which menu groups display 'based upon time or labor type.' Together these document items and prices activating/deactivating automatically by day and time in the store's own configured hours. https://support.hungerrush.com/hc/en-us/articles/19248812088973-How-to-set-up-Time-Pricing · retrieved 2026-08-04

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

The Menu Editor in Restaurant Management guide documents 'Use Order Type Pricing -- Use Order Type Pricing allows items to be priced differently based on Order Type. Up to 3 different pricing levels are supported. An Order Type must first be set up to use Order Type Pricing before selecting this option', and 'Use Tiered Pricing ... allows for 2nd and 3rd item pricing to be defined by order type.' The Menu Best Practices guide works the example: 'Bar orders will receive the default price. Delivery and Pick-Up items will have a $1 upcharge (Order Type Price 1). Dine-In items will have a $0.50 upcharge (Order Type Price 2)', with the order-type flag set under Config > System > Order Types & Stages > Price by Order Type. Time-Based Pricing separately carries an Applicable Order Types tab so a happy-hour price can exclude Online Pickup. Shortfall: only three price levels exist and each price is typed in per item per level -- no percentage-markup rule applied to a base price is documented; the levels key off POS order types (dine-in / pick-up / delivery / web), not off individual third-party marketplaces, and no kiosk price book appears. The only marketplace-specific pricing note found is a release-note line that DoorDash 'Base price is now the lowest size priced item'. https://support.hungerrush.com/hc/article_attachments/46512465331853 · retrieved 2026-08-08

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

'Creating and Using Surcharges' (updated 2025-11-12) documents the only documented credit-card cost-recovery mechanism: after a Surcharge Liability form, the operator creates a named surcharge in RM (Manage > System > Configuration > Surcharges) or the POS (Config > System > Tax > Surcharges) with a price, a Price Type of 'percentage or flat amount', a Report Group and a Tax Type, then assigns Payment Types ('for this example, we'll create the standard Credit Card Fee') and optionally Assign Order Types so it applies only to chosen channels; the change is pushed to the local level. A March 2026 release note records that surcharges are now calculated on the actual payment amount rather than the order total for split and taxable payments, so the surcharge follows the tender. Shortfall: this is a single added fee line, not item-level dual pricing -- no second stored price per item exists (the RM Pricing tabs are Style, Item, Individual Store Price Override, Time-Based, Modifier, Standard Modifier and Preferences, none of them a cash/card pair), the menu price shown is the cash price rather than the card price, and the Printer Ticket Configuration settings that enumerate receipt content include no cash-price-versus-card-price line. https://support.hungerrush.com/hc/en-us/articles/19248742111757-Creating-and-Using-Surcharges · retrieved 2026-08-08

Menu changes can be staged as an effective-dated version, previewed before publish, and rolled back to a prior version after publish. differentiator

menu-pricing-versioning-effective-dates

The Menu tab documents per-menu 'Start Date' and 'Expiration Date' fields, and 'Menu Validator' lets an editor scan a draft menu against 18 validation rules before 'Sync to Stores' pushes it live -- a stage-then-publish workflow. Shortfall: no documented ability to roll back to a prior published version after sync. https://support.hungerrush.com/hc/en-us/articles/46046096021773-Menu-Validator-Scan-and-Fix-Menu-Issues-before-Syncing-to-Stores · retrieved 2026-08-04

Supports a central corporate menu template pushed to locations with field-level governance controlling which attributes a location may override. differentiator

menu-pricing-franchise-hierarchy

'Menu Security: Company Admin and Store Admin' (updated 2026-05-21) documents two account types created under Manage > Roles with security configured on a Brand Menu tab: 'The Company Admin role has full access to Menu Editor, Pricing, and Syncing to Stores'; 'The Store Admin role has limited access ... Store Admin can view the menu and override pricing for stores they are associated with, but cannot edit and change the brand-level default pricing', and the security options themselves are editable ('Change the security and click Update when finished'). The template is real: 'Set Up Pricing: Setting Brand Default Price and Individual Store Price Override' documents brand-level default prices with a per-store override that survives brand changes ('when brand-level default prices change, they will not affect the store prices override'), Menu Manager carries Excluded Stores pages for groups, modifiers and preference members, and menus are pushed with Sync Now (disabled with a warning when a store is offline). Shortfall: governance is documented at the level of two named roles plus a pricing-versus-structure split; no per-attribute override matrix is enumerated, so which individual menu fields a location may or may not change is not published. https://support.hungerrush.com/hc/en-us/articles/38746875117453-Menu-Security-Company-Admin-and-Store-Admin · retrieved 2026-08-08

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

Release Notes 05/10/2022 record under Online Ordering bug fixes: 'Beverage specific measurements for calories were not displaying correctly for online ordering menus', which establishes that per-item calorie values are held and rendered on the HungerRush online-ordering menu, with unit handling specific to beverages. Shortfall: no allergen flag field exists at item, modifier or preference level -- the Menu Manager item, modifier, size and preference field lists contain none, and the Printer Ticket Configuration settings treat allergen information as free-text ('Special Notes are typically preparation notes (Such as allergen information)'). Nothing documents publishing allergen or nutrition data to DoorDash, Uber Eats or Grubhub menus (the Image Repository pushes images only), and while Inventory recipes exist and can display ingredient portions on the KDS item display, no article describes deriving nutrition values from recipe components -- calorie values are entered rather than calculated so far as the documentation shows. https://support.hungerrush.com/hc/en-us/articles/19248722775437-Release-Notes-05-10-2022 · retrieved 2026-08-08

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

'Creating Recipes In The POS' documents linking menu items, modifiers, and preferences to inventory recipes, including 'batch' items that are themselves composed of other inventory items, with unit quantities per size used for costing and depletion. https://support.hungerrush.com/hc/en-us/articles/19248781181581-Creating-Recipes-In-The-POS · retrieved 2026-08-04

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

Direct DoorDash/Uber Eats/Grubhub/Postmates marketplace integrations are named; per-item sync status and rejection-error surfacing are not documented. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

Rule-based automatic variation exists on two axes. Time: 'Time-based pricing allows an item to have different prices during special hours', configured as named Time Periods with day of week, start and end time, per-item price points, and an Applicable Order Types tab so a window can be excluded from, e.g., Online Pickup. Channel: 'Use Order Type Pricing allows items to be priced differently based on Order Type. Up to 3 different pricing levels are supported' (Menu Editor in Restaurant Management guide). Shortfall: neither is demand-responsive -- no rule keys off order volume, occupancy, inventory depletion, weather or forecast anywhere in the 313 help-centre articles or the 12 user-guide PDFs -- and no floor or ceiling guardrail field is documented, because the operator types each price point directly rather than authorising a system-computed adjustment. https://support.hungerrush.com/hc/en-us/articles/38746480618765-Set-Up-Pricing-Setting-Brand-Default-Price-and-Individual-Store-Price-Override · retrieved 2026-08-08

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

Status page carries FirstData/CardConnect, WorldPay Express (heritage Revention), WorldPay Integrated (heritage CRS) and WorldPay Core; Datacap is a named integration. No documented merchant-choice program. https://status.hungerrush.com/ · retrieved 2026-08-01

Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator

payments-published-rates

Shortfall: only the single-location Starter tier carries a published rate ("3.09% + 15 cents per transaction flat rate (Including Card Present and Card Not Present transactions)"), and it is footnoted "*Must meet qualification criteria"; the page's other tier is literally headed "Custom" with no rate, the page banner reads "Custom Pricing", and the payment-processing page offers only "the most competitive processing rates in the industry". No rate card appears anywhere in the help centre, so anything above the starter bundle is quote-only. https://www.hungerrush.com/pricing/ · retrieved 2026-08-06

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

'Creating and Using Surcharges' (updated 2025-11-12) documents card-cost recovery as a named surcharge configured in Restaurant Management (Manage > System > Configuration > Surcharges) or the POS (Config > System > Tax > Surcharges) with a Price Type of 'percentage or flat amount', then assigned to specific Payment Types (worked example: 'the standard Credit Card Fee') and optionally to specific Order Types; a completed Surcharge Liability form is a prerequisite. The March 2026 Rush Hour release note records 'Credit card surcharges are now calculated based on the actual payment amount rather than the full order total', so the fee tracks the tender on split payments. Shortfall: no native dual-pricing mode exists -- the system stores one price per item per price level (the RM Pricing tabs are Style, Item, Individual Store Price Override, Time-Based, Modifier, Standard Modifier and Preferences), so there is no card price displayed as base with a separate cash price, and the Printer Ticket Configuration settings list contains no cash-total-versus-card-total element for the guest check or receipt. https://support.hungerrush.com/hc/en-us/articles/19248742111757-Creating-and-Using-Surcharges · retrieved 2026-08-08

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

'Creating and Using Surcharges' documents configuring a surcharge (percentage or flat) assigned to specific payment types and order types, at the RM (per-location) or POS level -- per-location enable/disable confirmed. Shortfall: no documented automatic BIN/product-code detection to exclude debit or prepaid cards, and no documented enforcement of a network percentage cap; a January 2026 update only excludes fundraiser/donation amounts, unrelated to card-type detection. https://support.hungerrush.com/hc/en-us/articles/19248742111757-Creating-and-Using-Surcharges · retrieved 2026-08-04

All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.

payments-emv-nfc

Ingenico Lane/3000 reader: insert/tap/swipe, described as PCI compliant; Apple Pay accepted. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

No merchant-phone contactless acceptance is offered; the documented card-present path is a dedicated reader and the documented reader-less path is the guest's own phone. Scan to Pay's FAQ answers the question directly: 'Do I need special hardware? No. Scan to Pay works with your existing printers and the Driver Track app. Guests simply use their own smartphones to scan and pay', and the resulting transactions are 'processed as card-not-present ... because the payment happens on the guest's device rather than at a physical terminal'. www.hungerrush.com/products/hardware/ (re-read 2026-09-04) offers the Lane/3000 reader 'taking all payment types and methods through insert, tap, or swipe' and describes the POS tablet only as taking 'orders and payments tableside'; /products/payment-processing/ names 'cash, credit card, Apple Pay, and more' with no phone-as-reader acceptance. 'Tap to Pay', 'softPOS' and 'Tap on Phone' occur zero times across all 313 help-centre articles, all 45 vendor PDFs and the 2024-2026 release notes read through March 2026. https://support.hungerrush.com/hc/en-us/articles/40694197880461-Scan-to-Pay · retrieved 2026-09-04 adversarially verified

Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.

payments-pay-at-table

The hardware page describes the POS Tablet as a water-resistant mobile extension with 8h battery; the only card reader catalogued is a countertop Ingenico Lane/3000. No sled, EMV-on-tablet path, tip prompt or split behavior is described anywhere, and the product line is delivery/carryout-oriented. Tableside payment capture is not evidenced to a 'yes'. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01 adversarially verified

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

OrderAI provides 'secure mobile payment checkout via texted links' — text-to-pay, not a QR on the printed check; POS check-closing behavior undocumented. https://www.hungerrush.com/products/orderai-ai-ordering-system/ · retrieved 2026-08-01

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

'Adding Tips in During Cashout' documents adjusting credit-card tips during the drawer close/balance process, and 'Adding Tips from Order Lookup' documents a separate manager-security-gated screen ('View all credit cards in order look up') for adjusting CC tips on any order during the shift -- matching the claim's batch/adjust window plus a manager screen for unadjusted tips. https://support.hungerrush.com/hc/en-us/articles/19248765509005-Adding-Tips-in-During-Cashout · retrieved 2026-08-04

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

Via the 7shifts partner integration, not native. 7shifts documents that HungerRush feeds CC tips, auto-gratuity, cash tips and declared tips into 7shifts Tip Pooling, whose rules are by hours worked, points or percentages, producing the per-employee allocation there. Shortfalls: no pooling rule or allocation report exists in HungerRush itself (the help centre documents individual tip attribution only); the payroll export of pooled tips is labelled 'Coming Soon' on the 7shifts side; partner-led and possibly plan-gated. https://kb.7shifts.com/hc/en-us/articles/47411446289171-HungerRush-POS · retrieved 2026-09-03 adversarially verified

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

'Forcing Credit Cards - DataCap' (and its TriPOS twin) document offline card capture: 'Forcing Credit Cards is a method to be able to accept Credit Cards when the internet has failed and without verifying availability of the funds against the credit card processor at the time of the transaction', requiring that 'during initial Datacap setup, they must have Store and Forward enabled at the processor level. It is then enabled in the EMVUSClient, which by default is enabled.' Configurable elements are an Auto Force toggle ('whether or not Revention prompts to force a card or automatically force cards'), the test site the POS pings on loss of connection, and the time it retries 'before rolling over to force mode'; permission to force without manager approval is granted per labor type or per employee. 'These transactions will be stored, and will need to be manually batched from each station.' Shortfall: no configurable per-transaction or cumulative offline limit is documented -- the only bound is a setup-time note that 'forced transactions will be held for up to 72 hours'. The vendor also disclaims the feature: 'HungerRush does not suggest forcing credit card transactions ... is not able to provide troubleshooting support or reimbursement for failed transactions', and forced cards are authorised only at batch, so declines can surface then. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-08

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

'Forcing Credit Cards - DataCap' and the TriPOS equivalent state: 'Forcing credit cards does not include pre-authorization... They will only be authorized when batched, which means it is possible to see declined transactions at the time of batching' and 'HungerRush is not able to provide troubleshooting support or reimbursement for failed transactions due to forcing credit cards' -- documents that the loss from a forced/store-and-forward-style transaction that later declines falls on the merchant. Shortfall: no documented post-reconnect report specifically surfacing failed forced/offline payments. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-04

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

First-party Gift Cards product listed in the Custom plan; Valutec and Givex also integrated. Cross-location redemption and online redemption not explicitly documented. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.

payments-house-accounts

'Setting Customer Account Options' documents per-account status (Open/Hold/Close), 'Change Limit' (increase/decrease the spending cut-off), 'Apply Payment' and 'Adjust Balance' (running balance), and 'Creating an Account Statement' documents generating a statement -- matching per-account credit limit, running balance, and periodic statement generation. https://support.hungerrush.com/hc/en-us/articles/19248805878157-Setting-Customer-Account-Options · retrieved 2026-08-04

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

Release notes reference a named, toggleable 'Split Payments' feature in Restaurant Management, and 'How to Split an Order' documents splitting a single item's price evenly across an operator-chosen number of checks. Shortfall: no article documents settling one single check with multiple different tender types (e.g. part cash, part card) in one transaction, nor states a numeric split-ways cap, so 'no hard cap below eight ways' is unconfirmed. https://support.hungerrush.com/hc/en-us/articles/19248747598221-Release-Notes-06-14-2022 · retrieved 2026-08-04

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

'Manager Functions On The Order Screen' documents Void/Comp/Percent-off/Edit-price actions gated behind a Manager Functions screen, with a required reason captured on every void/comp 'for reporting purposes.' 'Adjustments Details' separately reports 'Emp/Apv Emp: Employee that applied the adjustment and the approver (if one needed).' Shortfall: PIN/role-based authorization is implied by per-employee security groups documented elsewhere but not spelled out specifically for this screen, and no page states the log is immutable. https://support.hungerrush.com/hc/en-us/articles/19248804443661-Manager-Functions-On-The-Order-Screen · retrieved 2026-08-04

In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator

payments-chargeback-tooling

326th, CELL MOVED unknown -> no/B, BECAUSE THE STANDING CORPUS HOLE IS NOW CLOSED. Every prior zero on this vendor was capped by the note 'a large share of this help centre's real content sits inside videos no text census can read' (266 raw iframe hits in 111 articles). NEW SURFACE: that video layer is now ENUMERATED. Parsing the 313 article bodies (re-derived today: /api/v2/help_center/en-us/articles.json reports count 313 / page_count 313, unchanged; 948,472 B of stripped text) yields 125 distinct Loom ids and 5 YouTube ids, and every one resolves anonymously through oEmbed - https://www.loom.com/v1/oembed?url=https://www.loom.com/share/<id> returned 200 with a title and duration for 125 of 125, 0 errors. The 125 titles are a procedure index of the product (e.g. 'Forcing-Credit-cards', 'Batching Previous Days', 'Apply Charge to Same Credit Card', 'Payment-types-by-station', 'Surcharge', 'Order Lookup Guide', 'Manager-Functions', 'Close-Day'); the 5 YouTube embeds are third-party (Uber Eats 'Meet Uber Direct' and four Menufy 'Feedback' videos). CONTROLS, tokenised, case-insensitive, non-word-character boundaries, over the 125 video titles AND the 313 article bodies AND the 39 distinct PDF attachments (1,561 pages) the 320th extracted: charge ?backs? 0, disputes? 0, representment 0, 'retrieval request' 0. POISON NAMED: a substring search for 'charge' in the video titles returns 2 hits and both are innocent - 'Surcharge' and 'Apply Charge to Same Credit Card'. Affirmative evidence points the same way: HungerRush's own Pizza POS Buyer's Guide tells operators to 'have an experienced provider available to help when you have issues like chargebacks, batching issues, deposit delays' - a phone call to a provider, which is what a product without a dispute queue offers. With text, PDF and video layers all enumerated, there is no in-product dispute dashboard and no evidence-submission workflow in HungerRush; disputes are worked in the acquirer's portal under a separate merchant agreement, which is not 'in-product'. Retrieved 2026-09-18. https://support.hungerrush.com/hc/en-us/articles/19248781338765-Purchase-Orders · retrieved 2026-09-18 adversarially verified

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

CLAIM TESTED: tokenized card-on-file for a guest profile, reusable across online ordering, phone orders and in-store, with no PAN stored by the merchant. FINDING: partial. The vendor affirms guest card storage in exactly ONE channel, and in the same enumeration does not give it to the others; the shortfall is named below, so this partial is not a shortfall of every conjunct. MET: 'Suite of HungerRush Products', in the Getting Started Guide PDF, attachment https://support.hungerrush.com/hc/article_attachments/25386767258765, re-fetched by the verifier at anonymous HTTP 200 on 2026-09-15 (5,611,143 bytes, MD5 b49d7fc5b86bb3b3b0c08710aedb9c33, page footers '(c)HungerRush2021 | Proprietary & Confidential. Updated September 7, 2021'), attached to the article 'User Guides' at https://support.hungerrush.com/hc/en-us/articles/25386625695245-User-Guides, category HungerRush, section Legacy POS, whose whole body reads 'User Guides listed here are for Legacy HungerRush/Revention POS': 'HungerRush Mobile Applications - To date, hundreds of customized HungerRush apps have been published in the Apple App Store and Google Play Marketplace. Like online ordering, the mobile app sends orders securely to your HungerRush Point-of-Sale system to be processed. Customers ordering from the mobile apps have access to the same features offered online. An added feature that your customers will absolutely love is the ability to store their credit card information. This can be done without affecting PCI Compliance.' Corroborated, at marketing grade, by www.hungerrush.com/products/payment-processing/ (retrieved 200 on 2026-09-15): 'Capture customer payment information locally and store it securely in the cloud.' SHORTFALL, conjunct by conjunct. That paragraph sits inside a four-item enumeration of the digital ordering suite (HungerRush Online Ordering, HungerRush Facebook Integration, HungerRush Mobile Applications, HungerRush Mobile Ready Site), and stored card is introduced as 'An added feature' OF THE APP, against the web channel described two items earlier, whose registered-account benefits are enumerated without it: 'If a customer opts to register for an account, they have the ability to setup multiple addresses on their profile, save favorite orders and all of their past orders will be saved for easy reordering.' So (a) reuse in WEB online ordering is not documented and is excluded by that contrast; (b) reuse for PHONE orders is not documented - the POS's manual-entry article is explicit that the PAN is re-collected per order, 'For the manual entry you are required to entry in the account number of the card' (https://support.hungerrush.com/hc/en-us/articles/19248791323789-Manual-Credit-Card-Entry, category HungerRush, section Credit Cards), and the one 'same card' function is scoped to a single open ticket, not to a profile: 'You may get an order paid by a customer, and same customer would like to add items to their order. This is how to charge the same credit card on the same order... Select Same Card in the bottom left' (https://support.hungerrush.com/hc/en-us/articles/19248806041741-Apply-Charge-to-Same-Credit-Card); (c) reuse IN-STORE is not documented at all - the Customer Accounts walkthrough enumerates the account screen's four options, 'Change Status, Change Limit, Apply Payment, Adjust Balance' (https://support.hungerrush.com/hc/en-us/articles/19248805878157-Setting-Customer-Account-Options), which is a house charge account, not a card vault; (d) TOKENIZATION is nowhere stated - 'This can be done without affecting PCI Compliance' implies the PAN is not merchant-held but names no vault, token or provider. GRADE C, NOT B, AND WHY: the container is a vendor user guide, but the load-bearing sentence is sales prose inside a 2021 product-suite overview ('hundreds of customized HungerRush apps... your customers will absolutely love'), it names no screen, setting or configuration step, and no admin-guide or configuration evidence for a stored card exists anywhere in this corpus. A first-party page written to sell is grade C. THE SURFACE THAT WOULD SETTLE THIS IS AN ADMITTED HOLE: the help centre's 'Admin Portal' section contains exactly one article, https://support.hungerrush.com/hc/en-us/articles/25385401902221-User-Guides, whose entire body reads 'This page is under construction. Content is coming soon!' BOUND CORPUS AND ITS KNOWN HOLES: 313 articles from support.hungerrush.com's Zendesk Help Center API (the HTML help centre 403s behind Cloudflare; the API serves anonymously), 4,032,659 bytes of body, plus 13 vendor PDFs, plus three live www.hungerrush.com pages. Verifier-re-run href fixpoint: 70 distinct article ids referenced inside the 313 bodies, 12 absent from the listing, each probed at /api/v2/help_center/en-us/articles/<id>.json - 10 x 404, 2 x 401, ZERO unlisted 200s; two fabricated ids returned 404 at 52 bytes, so the ten are stale links. HOLE 1, the two 401s, and the payments-relevant one is weighed here: 40694212678285 'Scan-to-Pay' is gated, but SEVEN articles of that exact title are held at 200, each 17,540 bytes, filed under Tips and Refunds, Credit Cards, Configuration, Restaurant Management, Online Ordering/Admin Portal, Customer and Printers/Printing, so the gated id is very probably an eighth clone; and the seven held copies re-collect the PAN every time - 'The guest then enters their credit/debit card information' - which is evidence against a card-on-file, not for one (https://support.hungerrush.com/hc/en-us/articles/40694176098189-Scan-to-Pay, 2025-11-04). The other 401, 38746931822733 'Use Menu in 3rd Party Channels', is a menu article. HOLE 2: section 25351007766797 'Product Documentation' exists with count 0. HOLE 3: the 'Admin Portal' user-guide stub quoted above. HOLE 4: 133 video embeds (128 www.loom.com, 5 www.youtube-nocookie.com) in 111 of the 313 articles, so about a third of this help centre's content is in video no text census can read. CONTROLS AND POISON, run in three modes (both-boundary token, left-boundary stem, whitespace-squashed substring) over comment-stripped raw bytes and tag-stripped text of all 313 bodies, all 13 PDFs and the marketing pages, positives passing ('HungerRush' 3,888 token hits over 272 of the 313 bodies): 'card on file', 'saved card', 'save credit card', 'stored credit card', 'stored payment', 'saved payment', 'vault', 'tokenize', 'tokenization' and 'express checkout' all 0 in every mode. CORRECTION TO THE PROPOSED FIGURES: 'on file' is NOT 0 - it is 2 hits, both poison ('the owner's email address on file via DocuSign' in the Getting Started guide, and 'if the current customer has an email on file in their customer profile' in the Orders guide); and 'one-click' is 3 hits, all poison (a release-note 'one-click deployment' and two 'One-click registration' bug fixes). 'token' reads 9 token hits over 5 documents on raw bytes and drops to 2 on tag-stripped text: 5 of the 9 are an Atlassian media-CDN JWT in an image query string ('token=eyJhbGciOiJIUzI1NiJ9...'), one is a Tailwind class name 'text-token-text-primary' pasted into an article, and the two real prose hits are internal service auth, not payment tokens - 'Implement new token process for Restaurant Management backend calls' and 'Fixed: Auth token service outage (March 21)'. A STANDING CORRECTION TO THIS RECORD: an earlier note that 'iframe' returns zero across the 313 articles is FALSE on raw bytes - 'iframe' occurs 266 times across 111 articles - but every src resolves to www.loom.com (128) or www.youtube-nocookie.com (5), so there is no payment iframe and the substantive point survives. VOID EVIDENCE, DO NOT REUSE: developer., developers., api., docs. and partners.hungerrush.com all return HTTP 403 behind Cloudflare, but so do the fabricated hosts nonsense-xyzzy-42.hungerrush.com and zzz-not-a-host.hungerrush.com, at the same ~5.4 KB interstitial from the same Cloudflare IPs - *.hungerrush.com is a wildcard, so those probes establish neither the presence nor the absence of a developer portal and no part of this verdict rests on them. https://support.hungerrush.com/hc/article_attachments/25386767258765 · retrieved 2026-09-15 adversarially verified

Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator

payments-payout-timing

'How to Verify Your Daily Credit Card Batch' publishes the funding timeline in prose: 'Settlements will typically appear on the date one day after the batch is submitted. Example: The settlement on 4/24 would be for the transactions for the business day of 4/23', and 'Deposits typically post 24-72 hours after the batch was submitted, so the deposit date may be within 1-3 days after the business date of the transactions.' It also distinguishes transaction status 'Authorized' (approved but unsettled) from 'Approved' ('fully settled, and the funds will be included with the Credit Card Deposit for that business date'), and instructs the operator to reconcile the CC Manager batch report against the WorldPay IQ Portal settlement totals and the bank deposit daily. Shortfall: no same-day or instant funding option is offered -- neither this article, the Credit Cards section, the WorldPay IQ Portal articles nor www.hungerrush.com/products/payment-processing/ mentions accelerated or on-demand payout, and the stated schedule is a description of typical behaviour rather than a contractual deposit-schedule policy. https://support.hungerrush.com/hc/en-us/articles/46955101894669-How-to-Verify-Your-Daily-Credit-Card-Batch · retrieved 2026-08-08

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

Release notes document that 'The Dual Merchant ID (MID) feature was previously deprecated from HungerRush's product offering', with a bug fix removing residual access to it. A feature for routing settlement to more than one MID/bank account existed and was explicitly discontinued -- positive evidence the platform does not currently support multi-entity settlement routing. https://support.hungerrush.com/hc/en-us/articles/19248747598221-Release-Notes-06-14-2022 · retrieved 2026-08-04

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

Lane/3000 stated 'PCI compliant'; no PCI DSS 4.x AoC, no P2PE listing reference, no merchant SAQ type published anywhere. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Items are assigned a 'Kitchen Print Category' in the menu editor, used both for printer routing ('Adding and Renaming a Kitchen Print Category', 'Printer FAQ') and to decide what appears on a given KDS ('Editing What Items show On An Order Display' -- categories map directly to display stations), and displays can additionally be filtered by order type. All configuration is done by the operator in Config, with no vendor involvement. https://support.hungerrush.com/hc/en-us/articles/19248751341965-Printer-Routing · retrieved 2026-08-04

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

The Kitchen Display System Basics guide (PDF on support.hungerrush.com article 25356545391373, dated 2024-08-19) documents the all-stations-bumped rule directly: 'On the Expo Display, each order is greyed, meaning the order cannot be bumped until all items are prepared. As items are bumped off the Item Display, they are highlighted on the Expo Display. Once all items are complete and bumped, the order on the Expo Display is highlighted and may be bumped. The Expo Display is configured as an Order Display with an option flagged Monitor Item Display.' Multiple prep stations are the documented norm: 'When a Kitchen Item Display is in use, it is common to have multiple item displays -- one for each preparation station in the kitchen', with each display filtered by Kitchen Print Category. The current 'Configuring an Order Kitchen Display' article (updated 2026-08-07) carries the same rule as setting 14, 'Prioritize Ready Orders will automatically move orders to the top of the Order Display whenever all of its items have been bumped from all Item Displays', and the Item KDS article's 'Labels Upon Completion' fires 'once the last item from that order has been bumped from this Display ... intended for stores with multiple Item Displays'. The Guest & Table Management guide adds the per-item colour state on the expo order summary (blue bumped, red not yet). https://support.hungerrush.com/hc/article_attachments/31863080469389 · retrieved 2026-08-08

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

The HungerRush Orders Guide (PDF on support.hungerrush.com article 25386625695245) documents HoldFire as an assignable order action: 'HoldFire allows users to send portions of the entire order to the kitchen and hold off on other items until "fired" to the kitchen. Once enabled, the applicable Order Types will need to be designated before HoldFire can be used.' Held items are flagged in the order display -- 'The red highlight denotes this Menu Item as held and not fired/sent to the kitchen' -- with a Hold Time column showing how long they have been held, and the Guest & Table Management guide shows a segmented red line under any table whose order is only partly fired. The order-type property list separately carries 'Allow Hold Kitchen Ticket', described as suiting 'operations that require precise timing for food preparation', and SendStay pushes appetizers or drinks 'to their respective printers before the main course'. Shortfall: items are held individually, not assigned to named courses, and there is no fire-next-course action; firing is initiated from the POS order screen, and no article or guide describes firing from the expo screen or confirms the action is present on the handheld tablet. https://support.hungerrush.com/hc/article_attachments/25386767266957 · retrieved 2026-08-08

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

KDS advertises 'automated dish sequencing and timing'. Per-item configurable cook times and simultaneous-finish staggering are not documented. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Same evidence as order-capture-throttling: online-ordering throttling caps accepted orders per 15-minute slot, System/Store configurable -- an order-volume threshold that paces incoming digital orders. Shortfall: documented for the website ordering channel only, is a hard cap rather than a kitchen-load-driven pace, and does not extend quoted prep times. https://support.hungerrush.com/hc/en-us/articles/19248733300109-Release-Notes-09-27-2022 · retrieved 2026-08-04

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

'Pausing Grubhub Integrations in HungerRush' documents store-pause propagation to a marketplace: 'When a business does not want to accept orders, a store can pause the acceptance of Grubhub orders via our configurations. This pause will not allow orders to be placed in Grubhub during the time frame specified', set at Restaurant Management > Manage > System > Ordering Channels > Grubhub Edit > Is Paused, with the verification step 'Login to Grubhub to see that it is not accepting orders.' For item availability, the 'Releases by Category' index records under Third Party API, dated 8.14.24: 'HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd for online ordering since the last menu update. Additionally, this webhook will notify when items previously marked as OOS are available again, ensuring third parties can keep menus synchronized between daily updates', plus a status API alongside GetMenu and ProcessOrder. Shortfall: both actions originate in Restaurant Management, not from the POS or KDS as the claim requires; the pause toggle is documented only for Grubhub, with no equivalent for DoorDash or Uber Eats; and the 86 path is a webhook third parties must consume, not a documented push into a named marketplace's menu -- the Menu Control article itself says Upload OOStock commits changes 'to your other stations and online menu' without naming a marketplace. https://support.hungerrush.com/hc/en-us/articles/36740618341389-Pausing-Grubhub-Intergration · retrieved 2026-08-08

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

DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. As with order-capture-order-ready-signal, the verdict rests on HungerRush's own corpus and not on the flag: bumping drives only internal stage events, and the complete announced set of outbound third-party events contains no readiness message. `SUPPORT_ORDER_READY_SIGNAL` is FALSE for `hunger_rush_production`, corroborating from the counterparty side. Where no order-ready signal exists, a KDS bump cannot be its trigger. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12

KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.

kitchen-bump-bar-hardware

First-party KDS ships with a bump bar interface. Supported bump-bar model numbers are not published. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.

kitchen-all-day-counts

'Configuring an Item Display' documents a 'Production items' setting for batch-cooked items: the display 'will show the items per order but also the total... the cook should be making' -- an aggregated outstanding-quantity view across open tickets. Shortfall: documented only for items explicitly configured as production/batch items, not confirmed as a general all-day count across every item and modifier on the station. https://support.hungerrush.com/hc/en-us/articles/19248780718477-Configuring-an-Item-Display · retrieved 2026-08-04

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

'Configuring an Item Display' documents 'Caution minutes' (turns the item yellow) and 'Warning minutes' (turns the item red) as configurable target-time thresholds, plus 'Use audio alerts' for an audible alert when speakers are attached -- matching configurable target times with visual color escalation and audible alert. https://support.hungerrush.com/hc/en-us/articles/19248780718477-Configuring-an-Item-Display · retrieved 2026-08-04

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

'Printer Routing' documents rerouting one printer's tickets to a different printer when the original 'stops functioning.' This is a manual admin task (Config > Printer > Printer Routing, then a full POS restart on all stations), not an automatic failover with no ticket loss. https://support.hungerrush.com/hc/en-us/articles/19248751341965-Printer-Routing · retrieved 2026-08-04

KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator

kitchen-offline-operation

NEW SURFACE (Help Center API PDF attachments, not in the prior census). CORPUS: all 39 distinct PDF attachments returned by support.hungerrush.com/api/v2/help_center/en-us/articles/<id>/attachments.json over the 313 live articles (43 PDF attachment rows; some PDFs attached to two articles), text-extracted with pdftotext: 1,561 pages, only 6 low-text pages (all covers), so the text layer is complete; plus the 313 article bodies (comments stripped). Legacy-POS guides are dated Sept 2021; 360/RM guides 2022-2025. Architecture only, no behaviour statement: Legacy 'Printer Kitchen Display Configuration.pdf' (article 25386625695245): 'Kitchen Printers that have an IP connection is set up from Station1. Customer Receipt printers, which communicate via Serial connections, is set up on the Station they are connected to'; 'System Configuration Guide.pdf': 'SQL Server is the SQL Server Name for the point of sale system' and pagers use 'a transmitter connected to the kitchen display computer' (an on-site LAN/SQL Server topology). The 360 'Kitchen Display System Basics.pdf' (article 25356545391373, https://support.hungerrush.com/hc/article_attachments/31863080469389) has zero hits for offline / internet / network / connection / cloud. Tokenised word-boundary controls over all 39 PDFs for offline|internet outage|no internet|internet connection|connectivity: 35 hits, none about the KDS (26 in the legacy online-ordering Getting Started Guide are 'Config - Offline' customer messages and the port-forwarding FAQ; others are loyalty prerequisites and a credit-card timeout). Still unknown: no vendor sentence says the KDS keeps receiving tickets when the internet is down. Retrieved 2026-09-16. || 325th: 325th, NEW SURFACES, CELL NOT MOVED, but two of them narrow it. The vendor now advertises the capability generically - 'Shorten disruptions and downtime with offline operations mode' (www.hungerrush.com/products/hardware/, 52,801 B, fetched 2026-09-17, nonsense control /zzq-nope-control/ returns the 404 shell) - and the KB shows the POS stack is station-local rather than cloud-served for printing and for fallback reporting (kitchen printing is restarted at Station 1, which 'WILL TAKE ALL OTHER STATIONS OFFLINE'; Datacap Store and Forward is on by default; vNext Reporting falls back to on-device Crystal reports 'in case of network connectivity issues'). What is still missing is the KDS-specific proposition this claim makes: tokenised 'offline mode', 'without internet' and 'store and forward' return nothing in a KDS context across the complete 313-article Zendesk Help Center API census (4,078,437 B, re-derived 2026-09-17), and the only KDS lines in the corpus are feature work ('Item KDS - show deferred if items in order are deferred'). No document says whether the KDS keeps receiving and displaying tickets from on-site terminals when the cloud backend is unreachable. Retrieved 2026-09-17. || 326th: 326th, NEW LAYER OF THE CORPUS ENUMERATED, CELL NOT MOVED. The help centre's video layer - the standing corpus hole that caps every text zero on this vendor - is now bounded: the 313 article bodies (re-derived today, count 313 / page_count 313) embed 125 distinct Loom ids and 5 YouTube ids, and all 125 Loom videos resolved anonymously through oEmbed (https://www.loom.com/v1/oembed?url=...) with a title and duration, 0 failures. Tokenised controls over those 125 titles: offline 0, internet 0, network 0, outage 0. The KDS-related titles are configuration only - 'New-order-Display', 'Item-Display-config', 'Items-to-order-display', 'items-to-item-display', 'Change-KDS-station', 'Stages', 'EnableDeferredInDisp' - matching the text corpus, where the only KDS articles are configuration and the only \boffline\b hits mean severed from Station 1. So the video layer contains no offline-KDS proposition either; no HungerRush surface states whether the KDS keeps receiving tickets from on-site terminals when the cloud backend is unreachable. Retrieved 2026-09-18. || 327th: NEW SURFACE (327th), NO MOVE. The vendor's own KDS spec sheet, reached through the previously-unpaged `resources` WordPress post type, settles the hardware question the 320th's PDF set left open: the HungerRush KDS is a Lenovo ThinkCentre M93p Tiny running Windows 10 Pro 64-bit with an RJ45 LAN port, an HDMI/VGA-attached 24" monitor and a 5 V DC bump bar powered from that PC - an on-site Windows client on the store LAN, matching the 'Station 1 / SQL Server' topology the 2021 configuration guides describe. What is still missing is identical to what was missing before: a vendor sentence about BEHAVIOUR when the internet or cloud backend is unreachable. The one `offline` hit in the 758,099-char resources corpus is generic industry advice in a buyer ebook ('a tablet POS that runs on a hybrid cloud solution will minimize downtime by supporting offline mode when the internet is not available'), not a claim about the HungerRush KDS. Held unknown. Retrieved 2026-09-18. || 328th: 328th: CENSUS FRESHNESS RE-DERIVED, NO MOVE. The Zendesk Help Center API was re-paged today (articles.json per_page=100, pages 1-4): count=313, and /sections.json returns 52 sections including a '2026 Release Notes' section (44088608241037) that looks new but contributes no new articles - diffed by article id against the q324 census, ZERO new articles and ZERO with updated_at > 2026-09-10. So every offline/internet/outage zero measured over that corpus in the 320th-327th still stands on a current corpus, and the remaining gap is unchanged: no vendor sentence about KDS BEHAVIOUR when the internet or cloud backend is unreachable. Held unknown. Retrieved 2026-09-18. || 330th: 330th, CELL NOT MOVED, two things worth recording. (1) The two current KDS configuration articles were read as full settings enumerations for the first time - 'Configuring an Order Kitchen Display' (46763710763533) and 'Configuring an Item Kitchen Display' (46707026317837), reached from HUB at Manage > System > KDS Config. Their General tab enumerates Computer Name, Text Size, Caution Minutes, Warning Minutes, text/colour formatting and the 'Order Up!' audio alert, plus Display Categories and Order Types tabs; there is no connectivity, buffering, local-cache or offline setting anywhere in the KDS configuration, and the KDS itself is a POS station role ('The station will then launch into a KDS mode automatically', 19248788249741). (2) THE CENSUS THIS CELL'S ZERO RESTS ON HAS A NAMED HOLE: an href fixpoint over the 313 re-derived bodies (count 313 / page_count 4, 4,032,659 B) yields 72 referenced article ids, 14 outside the listing - 12 return 404 RecordNotFound (deleted), 2 return 401 (38746931822733, 40694212678285). Because the KDS config is cloud-administered (HUB) while the display runs on a store station, and no document in any layer states what the KDS does when the cloud is unreachable, the cell stays unknown rather than moving in either direction. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). Tokenised KDS-within-200-chars-of offline|internet|outage|cloud|disconnect|WAN: 2 hits, both a buyer's-guide question ('Do you need a kitchen display system...'), not a behaviour statement. NEW (images read at full resolution): 'System Printers Configuration' (46676112728077) screenshot shows a printer is defined by 'Computer: Station1', 'Printer Name', 'Windows Printer' and 'Printer Model' - a Windows print queue on a local station - and the 'Kitchen Printer Configuration Settings' (46556738700429) Kitchen Printers tab enumerates 24 ticket-format options with no connectivity, buffering or offline setting. Architecture again, not the KDS-during-WAN-outage proposition; the 325th's hold (architectural inference) still governs. Retrieved 2026-09-18. || 332nd: 332nd: two new surfaces, neither addresses the KDS during an outage. (1) App-store PUBLISHER census: iTunes lookup?id=396756103&entity=software (Revention Inc.) = 2 apps, HungerRush Driver Track and HungerRush HUB Mobile (sales/labour dashboard); Google Play search 'hungerrush' adds only com.hungerrush.hungerrushdeliverydriver, HUB Mobile and branded ordering apps - there is no KDS app in either store (the KDS is the on-site Windows station recorded in the 327th). (2) HungerRush's SwaggerHub org (2 published APIs: Online Ordering, Loyalty) has no kitchen or KDS surface. offline 0 across both store listings and both spec JSONs. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the CAPTIONS of the help centre's Loom videos, which the 326th could only title. Each anonymous share page https://www.loom.com/share/<id> embeds a signed cdn.loom.com/mediametadata/captions/<id>-1.vtt URL; GET of those VTTs for the 125 Loom ids embedded in the 313-article KB returned captions for 104 (97,672 chars; 21 have no caption track). Plus the vendor YouTube channel @HungerRush re-derived today: 26 videos + 10 shorts, captions pulled for 35 of 36 (roCqawSJ7Z4 has none). CLAIM: KDS keeps receiving tickets from on-site terminals when internet/cloud is down. VERDICT: unknown (no move; the 325th merge hold is not re-proposed). EVIDENCE: the five KDS tutorials describe configuration only, done inside the store POS: 'log into prevention, then click on config. Next, select kitchen display. Then click on new item display. Then use the dropdown. Select which computer you wish to make, the item display' (Item-Display-config); 'use a dropdown versus computer name and change it to the correct station' (Change-KDS-station) - the KDS is a POS station role configured locally, as recorded since the 327th. Word-boundary controls over the 104 Loom captions: offline 3 (all 'mark an item offline from your Hunger Rush online ordering', V3 Local Removing Items from Online), internet 1 ('open up a internet browser' to reach HUB), outage 0, connectivity 0; over the 35 YouTube captions: offline 0, internet 0, outage 0 ('cloud' 3 = marketing: 'Hunger Rush 360 is a cloud-based POS system ... simply open a web browser and log in', 6bUktrSZyZ4). Also found: www.hungerrush.com/enterprise/ (WP search 'offline', marketing C) 'Operational continuity with cloud-based data and offline functionality when you need it' - generic, not KDS. No behaviour statement in any layer. Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: the two silent KDS-related recordings (EnableDeferredInDisp, Add_RenameKPC_*) add no statement; no vendor sentence about KDS behaviour during an internet/cloud outage exists in any layer. Unknown. Retrieved 2026-09-18. adversarially verified

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

'Configuring an Item Display' documents item displays showing full modifier detail beyond the ticket line -- settings that 'affect... preference and even changing how modifiers show up' -- and a distinct 'Production items' mode showing per-order and running totals for batch-built items, satisfying the claim's 'full modifier breakout' alternative. https://support.hungerrush.com/hc/en-us/articles/19248780718477-Configuring-an-Item-Display · retrieved 2026-08-04

Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator

kitchen-pizza-fractional-display

'Printer Ticket Configuration Settings' (updated 2026-08-06) documents option 22: 'Half/Half Columns will print half modifiers in two columns, with a solid vertical line separating each half. Example: If this setting is enabled, a pizza is ordered with Pineapple on one half and Pepperoni on the other half would print the modifiers in two columns. The Pineapple would be in one column while the Pepperoni would be in the other.' That is unambiguous sectioned rendering on the kitchen ticket. On the screen side, half placement is carried through to the KDS as Half 1 and Half 2 modifier sets (Release Notes 08/31/2022 fixes 'Preselects on KDS are not displaying Half 1 modifiers'), and the KDS article set gives modifiers their own colours plus separate NO-modifier and Extra-modifier colours in stacked or horizontal format. Shortfall noted for completeness rather than scored: the two-column layout is documented for the printed ticket; the KDS is documented as displaying half modifiers but no article describes a two-column half/half layout on the screen itself. https://support.hungerrush.com/hc/en-us/articles/46613116747021-Printer-Ticket-Configuration-Settings · retrieved 2026-08-08

A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.

kitchen-recall-refire

'Configuring an Item Display' documents 'Recall minutes' -- 'the time frame after you bump the item off the display to when you can bring it back' -- a direct recall/unbump mechanism. Release notes separately reference a 'Print Previous Item' function for reprinting an item to the kitchen without re-entering the order. https://support.hungerrush.com/hc/en-us/articles/19248780718477-Configuring-an-Item-Display · retrieved 2026-08-04

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

The Guest & Table Management Guide documents a live modification indicator on the expo order summary: clicking a table with an active order shows the ticket, where 'blue items have been bumped and red items have yet to be bumped off the Item Display. The number above the items signifies which iteration of that current ticket is on. If additional items are added to the order later, the number will increase by a single increment.' So kitchen staff see, on the live ticket, that the order has changed and how many times. Removals are governed on the print side: 'No Voids On Kitchen' suppresses voided items when an order is sent, while 'Show Voids On Reprint' prints them on a reprint, so a voided item can be made visible on a re-fired ticket. A release note records that 'voiding or replacing an item on an order will now update the deferred order KDS screen.' In the POS order display, unsent items added after a send appear in blue text. Shortfall: the iteration counter signals that the order changed but does not identify which line was added, changed or removed, and no KDS article documents per-item highlighting of a modification on an already-displayed ticket -- the KDS colour scheme covers item, note, preference, modifier, NO-modifier, Extra-modifier and preselect roles plus caution/warning ageing, with no changed-item state. https://support.hungerrush.com/hc/article_attachments/31404066628749 · retrieved 2026-08-08

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

Downgraded from yes/D on re-verification, but on better evidence. The vendor help centre documents the exact trigger the claim asks for: 'Order Ready for Pickup Message when order is bumped off the KDS', with a 120-character message cap and template variables including [order number]; a further template fires 'when order is dispatched' and another 'when driver using Driver Track navigation reaches 5 min or less from the destination'. Named shortfall against the claim's 'without a separate product purchase' condition: Order Notifications is its own top-level help-centre section containing a single messaging best-practices article — no enablement or configuration doc — and it appears in neither published pricing tier (the Custom tier bullet list has no order-notification or SMS line). Bundling is therefore unestablished, and the delivery is SMS, which sits with HungerRush's separately marketed text product. https://support.hungerrush.com/hc/en-us/articles/31634965140365-Order-Notifications-Basics · retrieved 2026-08-02 adversarially verified

Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.

kitchen-waste-logging

Voiding/comping a prepared item prompts whether it was prepared and captures a required reason 'for reporting purposes', and the Menu tab's 'Verify Inventory Waste for Voids' setting will 'automatically set the items to the waste in inventory' when confirmed -- a reason-coded workflow that debits inventory. Shortfall: no report was found that states waste cost as a line item separate from usage variance. https://support.hungerrush.com/hc/en-us/articles/19248804443661-Manager-Functions-On-The-Order-Screen · retrieved 2026-08-04

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

'200+ reports' and delivery metrics (average delivery time, late orders) are advertised; per-station ticket times, percentiles, and CSV/API export are not documented. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01

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

HungerRush surfaces prep quantities to the kitchen through Production Items. The KDS Basics guide: 'The Production Item Display ... purpose is to show the kitchen staff how many items are needed to fulfill all pending orders. Each menu item and/or preference may have a Production Item associated with it. When the item/preference is sold the count of the Production Item is added to the specified box ... When the item is given to the guest and bumped from the KDS or Expo screen the count is reduced.' The Menu Config article explains the setup and intent: 'Burger and wings restaurants use Production Items KDS to show the count of ingredients such as Beef Patties and Wings. It helps kitchen cooks who need to know at a glance how many of each ingredient are needed ... the production item count will summarize at the ingredient level (e.g. 10 Burger Patties)', with counts entered per size (a 6pc Wing Combo needs 6x Wings). Item Prep Time separately staggers when items appear so an order finishes together, and recipes with ingredient portions can display on the item display. Shortfall: every one of these is computed from orders already in the system -- nothing is derived from historical sales or a demand forecast, no forecast report exists in the 40-article Report Purpose and Metric Guides section, and there is no daily prep task list a manager can print or assign. https://support.hungerrush.com/hc/article_attachments/31863080469389 · retrieved 2026-08-08

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

The delivery page documents a dispatch screen and a driver app, not a driver roster: no driver records, no clock-in, no per-driver run history, no assignment rules. The researcher's own note concedes those are undocumented yet still scored yes. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01 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

'Built-in dispatch screen' toggling orders between ready / on the road / complete. Multi-order run batching is not documented. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01

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

'Map Order to see the delivery route and ETA' plus interactive live map; Driver Track has embedded turn-by-turn nav. Multi-stop sequence optimization is not documented. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01

Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator

delivery-driver-tracking

Downgraded from yes/D on re-verification. GPS capture from the driver-facing app is now documented rather than merely marketed: the Driver Track release notes (4/2024, 5/2024, 6/2024) record that 'Delivery drivers can now get all their assigned delivery orders directly onto their phones', that 'features for real time dispatch' shipped on iOS and Android, and that a 'notifications popup reminder' fires 'for users who turn off tracking permissions on the app'; the App Store listing (Revention Inc., v1.0.8, 2025-11-03) declares Precise Location collection and warns the app 'may use your location even when it isn't open'; and Order Notifications Basics documents a message that fires 'when driver using Driver Track navigation reaches 5 min or less from the destination', which only works if live position returns to the platform. Named shortfall on the second half of the claim — surfacing to the dispatch screen. The documented POS Dispatch screen is a list board: 'your delivery orders on the left and your drivers on the right', with Dispatch / On Road / Return Driver buttons and no map or live position. The only documented manager-side view is that 'Managers can view delivery drivers and their status in Restaurant Management' — status, not plotted GPS. The interactive-map 'eye in the sky' remains a marketing-page claim only. Driver Track is also listed solely under the quote-only Custom tier. https://support.hungerrush.com/hc/en-us/articles/30740352348685-Delivery · retrieved 2026-08-02 adversarially verified

Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator

delivery-zones-polygon

'Delivery: Zones' documents drawing an arbitrary polygon on a Google Maps interface ('connecting the dots... just make sure not to cross the lines') to define each delivery zone -- not a radius or ZIP list. https://support.hungerrush.com/hc/en-us/articles/19248815016973-Delivery-Zones · retrieved 2026-08-04

Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.

delivery-zone-pricing

'Delivery: Zones' documents drawing geofenced polygons per zone and then, on the Zones grid, setting 'what the delivery fee and driver compensation for each zone' will be: 'If they are set but you have zones that you want to charge more you would set the additional fee and it will add to the preexisting Delivery comp and fee.' The companion 'Additional Delivery Fee by Zone' article enumerates the Zone Edit box as showing 'the Zone's name, Dlvry Fee (Addnl Fee from the previous screen), and Driver Comp' - the whole per-zone surface. Shortfall: there is no per-zone order minimum, and the quoted promise time is not a zone attribute - 'Estimated Time by Days of the Week' sets Estimated Delivery time per ORDER TYPE with per-weekday time bands (e.g. Monday 90 minutes for 9am-11pm), so all zones share one quote. https://support.hungerrush.com/hc/en-us/articles/19248815016973-Delivery-Zones · retrieved 2026-08-08

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

The delivery-options guide describes drawing the zone on the map and then states: 'Once the dots are connected this shaded area will define your delivery zones. Only addresses in that area will be able to place orders in the pos system as the data is pulled directly from googles maps.' So the address is resolved against Google Maps and an address outside every drawn zone is refused at order entry. 'Delivery: Zones' adds that after building zones you 'Click the Upload Zones button to push it to your online ordering', so the same geofence gates the first-party online-ordering site, and Jan 2026 release notes record 'Longer Delivery Addresses Supported - Street address fields now support up to 100 characters', confirming a structured address field. Re-fetched live 2026-08-08 (HTTP 200) to confirm the sentence verbatim. https://support.hungerrush.com/hc/en-us/articles/19248782850317-Configuring-Delivery-Options · retrieved 2026-08-08

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

'Adding Additional Driver Comp Per Zone' and 'Additional Driver Comp. Per Order Type' document configuring extra driver compensation by zone or order type, and the 'Driver Mileage and Compensation' report tracks per-driver miles, comp amount, and credit-card/cash tips per dispatch -- covering mileage, flat comp, and tips. https://support.hungerrush.com/hc/en-us/articles/19248798506893-Adding-Additional-Driver-Comp-Per-Zone · retrieved 2026-08-04

Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.

delivery-cash-reconcile

'Configuring Delivery Options' documents a driver 'Default starting bank' (starting cash carried) and 'Max $ before drop' (cash threshold before a driver must deposit), and 'Understanding Employee Cash Drawers' documents the balance/reconcile-drawer workflow used for driver cashout, producing an over/short -- matching a driver cash bank / settle-up flow. https://support.hungerrush.com/hc/en-us/articles/19248782850317-Configuring-Delivery-Options · retrieved 2026-08-04

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

Score upheld, confidence should drop to claimed. Verbatim: 'Dispatch orders to your drivers or third-parties in one click' and 'HungerRush allows you to dispatch both in-house and 3rd-party drivers like DoorDash'. DoorDash Drive and Uber Drive are named in the catalog. Marketing pages only — no configuration or fallback documentation, so 'documented' overstates the evidence class. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01 adversarially verified

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

Hybrid fleets are explicitly supported: 'You can combine services and also use your in-house team', and 'Orders are seamlessly managed and processed directly through your HungerRush POS.' Auto-dispatch to a DaaS courier is a real, named mode - the FAQ answers 'Can a store use auto-dispatch if they have both DoorDash Drive and Uber Direct enabled? No, a store cannot use auto-dispatch if they have both DoorDash Drive and Uber Direct enabled. Enabling auto-dispatch for one will automatically disable it for the other', and the onboarding article's step 3 has HungerRush staff 'Set up your preferred dispatch method'. Shortfall: no article states the CONDITIONS under which auto-dispatch fires - no-driver-available, out-of-zone, or a wait threshold are never named; the support article describes the operator selecting the courier and clicking 'Request Driver'; the fee structure must be pre-chosen before the order is placed ('the delivery charge must be pre-determined'); and only one of the two couriers can be on auto-dispatch at a time. https://support.hungerrush.com/hc/en-us/articles/34634498665741-HungerRush-Delivery-Services · retrieved 2026-08-08

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

Vendor integration guide (PDF linked from this help-centre article, hc/article_attachments/28873896164493): DoorDash orders route "directly" into the HungerRush POS, "eliminating the need for the DoorDash tablet and manual order transfers"; onboarding is HungerRush-hosted OAuth started in Restaurant Management; menu/inventory/pricing sync POS-to-DoorDash, separate in-store vs DoorDash menus, and DoorDash commission fees are entered into the POS for net-profit-per-order. All DoorDash fulfillment types (DoorDash Delivery, Merchant Self-Delivery, Customer Pickup) supported; documented gaps are pause and delay, which must be done from the DoorDash tablet/portal. The parallel Uber Eats guide (article 25386194280333) is identical in structure, and Grubhub is a native Ordering Channel in Restaurant Management (article 36740618341389). No Otter/Chowly/Deliverect/Checkmate layer appears in any of the three. https://support.hungerrush.com/hc/en-us/articles/28873927209229-DoorDash-Marketplace · retrieved 2026-08-06

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

'3rd-party integration puts DoorDash orders into the POS.' Caveat: a Software Advice reviewer reports the DoorDash integration stopped working after an update. https://www.hungerrush.com/cuisine/pizza-pos/ · retrieved 2026-08-01

Menu, pricing, modifiers, and photos publish from the POS master menu out to connected third-party marketplaces, including channel-specific price markups, without maintaining a separate menu in each portal.

delivery-menu-push

'Image Repository 2025' documents a central image store in Restaurant Management (Manage Images > 3rd Party) that 'is used for Grubhub, DoorDash, and UberEats', with images 'auto scaled to fit the destination source', and publishing done by 'Manage > System > Stores > Configuration > Ordering Channels. Select the ordering channel you are updating and click the Refresh icon.' The 2024 'Releases by Category' Third Party Integrations notes confirm menu content itself is derived centrally: 'DoorDash Menu Images - Customers will be able to update their DoorDash images through Restaurant Management similarly to Uber' and 'DoorDash Base Price Should be lowest of the size prices - Base price is now the lowest size priced item with customizations or larger sizes adding to the cost.' Shortfall: (1) no channel-specific price markup is documented anywhere - the only pricing overrides in Menu Manager are brand-default vs individual-STORE price override, plus an 'Use Order Type Pricing' POS setting; (2) 'Sync to Store' itself pushes only to 'POS or POS + Online Ordering', so marketplace publishing is a separate per-channel Refresh rather than one sync. https://support.hungerrush.com/hc/en-us/articles/36740426632973-Image-Repository-2025 · retrieved 2026-08-08

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

Same Menu Control evidence as menu-pricing-86-propagation: OOS status uploads to POS stations and the first-party online menu. Shortfall: no article documents this reaching connected third-party marketplaces specifically, nor states a near-real-time latency, which DoorDash's own integration requirements call for. https://support.hungerrush.com/hc/en-us/articles/47634977612429-Menu-Control-Set-Menu-Items-Out-of-Stock · retrieved 2026-08-04

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

Grubhub: 'a store can pause the acceptance of Grubhub orders via our configurations... Go to Restaurant Management > Manage > System > Ordering Channels > Grubhub Edit, Select the Is Paused option', verified by logging into Grubhub to see it is not accepting orders. The HUB mobile app guide extends this to the marketplaces: 'If your store is integrated with DoorDash and/or UberEats... Tap the toggle next to a delivery channel to enable or disable it for that store', including 'Turn On All'/'Turn Off All' across channels and multi-store toggling. Shortfall - timed auto-reactivation is explicitly absent in both places: 'Pauses cannot be scheduled in advance at this time. Pauses will need to be turned off to resume orders' (Grubhub), and 'it will remain On or Off until the status is changed (ie no "snooze for 1 day" ability to keep channel off for the remainder of the day)' (HUB app). https://support.hungerrush.com/hc/en-us/articles/36740618341389-Pausing-Grubhub-Intergration · retrieved 2026-08-08

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

Sales by Channel is the report that would carry this and its column list is fully enumerated, gross-only: 'Channel = The source or platform through which the order was placed (e.g., POS, DoorDash, UberEats). Tax Net... Non-Tax Net... Net Sales... Tax... Gross Sales... Adjustments & Coupons... Total Sales = Gross sales after adjustments and coupons are subtracted. Order Count... Guest Cnt... PPA'. It claims to 'monitor profitability by channel' but carries no commission, marketing-fee, refund-adjustment, payout or deposit column and no missing-order flag - it is what the POS recorded, never what the marketplace remitted. Payment Method Details treats DoorDash as a tender with Count/Amount/Grat/Tips/%Amount, which is the same POS-side figure again. The vendor's own scope statement for these integrations is a three-item enumeration that stops well short of money movement: the third-party delivery integrations data sheet's 'Key Features' are 'POS Integration - Send DoorDash and Uber Eats orders directly to your HungerRush POS', 'Menu Sync' and 'Order Sync'. Across the closed 313-article census 'chargeback' returns zero hits, all three 'commission' hits are marketing about avoiding marketplace commissions, and all 72 'reconcil' hits are cash-drawer, server and driver cashout balancing or the WorldPay IQ Portal's processor-settlement menu - never a marketplace remittance. Nothing matches marketplace payout deposits to POS-recorded 3P sales or identifies unpaid orders. https://support.hungerrush.com/hc/en-us/articles/39832823387533-Sales-by-Channel · retrieved 2026-09-04 adversarially verified

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

Public status page has discrete DoorDash, Third Party Integrations and Google Maps components — platform-level health only, not per-merchant failed-injection alerts. https://status.hungerrush.com/ · retrieved 2026-08-01

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

Guests track their order and are notified; curbside guests notify the store on arrival with vehicle info; automated order-status texts shipped Dec 2024. Own-domain branding not explicitly stated. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01

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

'Estimated Time by Days of the Week' documents per-order-type, per-day-of-week estimated delivery windows, and 'Changing Delivery / Pickup Times' documents temporarily overriding the quoted time based on current volume, with online-facing updates reflecting 'within about 5 minutes.' Shortfall: the adjustment is a manual staff action based on observed volume, not an automatic algorithm driven by live kitchen load, driver availability, and zone drive time as the claim specifies. https://support.hungerrush.com/hc/en-us/articles/19248814780173-Estimated-Time-by-Days-of-the-Week · retrieved 2026-08-04

Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.

delivery-offline-behavior

Delivery-specific offline behaviour is documented for payment collection at the door: 'What if my driver or guest doesn't have internet or cell service? Both the driver and guest need an active internet or cellular connection to complete payment. If service isn't available, the driver can accept cash instead.' Separately, 'Forcing Credit Cards - DataCap' documents accepting cards with no internet via processor-level Store and Forward ('Once you try to collect payment with no internet you will get a declined error... you will need to hit the force button then enter any 4-digit number for the approval code'), with forced transactions held up to 72 hours and manually batched. Shortfall: nothing states whether driver assignment/dispatch from the POS dispatch screen, or driver cashout/settlement, continue during an internet outage - the DaaS courier request explicitly cannot ('If a driver is unavailable, try re-requesting'), but the in-house dispatch and cashout path is not addressed. https://support.hungerrush.com/hc/en-us/articles/40694176098189-Scan-to-Pay · retrieved 2026-08-08

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

Commission-free branded ordering site built with HungerRush Designer — 'save on 3rd-party commission fees'. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

Platform is marketed as one integrated menu across POS and online, but no page states one-edit propagation explicitly. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01

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

Release Notes 05/10/2022: 'Apple Pay is now supported on iOS branded apps and safari browsers (desktop, mobile). Apple Pay is free for merchants who currently are enrolled in MRR and have an iOS mobile app for online ordering'; the same note says configurable privacy/terms updates 'both website and mobile apps' and that 'Apps published after 5/10/22 will inherit this change' - i.e. apps are built and published per merchant. Release Notes 09/14/2022: 'Push notifications can only be delivered via our mobile app for iOS and Android. Please contact sales if you do not currently have a mobile app.' Release Notes 07/12/2022 documents in-app account deletion added for Apple's 6/30/22 requirement, with 'HungerRush will inform the merchant of the application that the request of the customer has been completed.' Current docs still treat it as a live surface: the Coupon Editor Settings Glossary (updated 2026-07-24) has 'Mobile Only restricts the coupon for use only on your store's Mobile App' and 'No Mobile allows the coupon to be used on your standard Online Ordering site, but not on your store's Mobile App', and the Apple Pay activation article (updated 2025-12-22) offers 'Apple Pay (Web Only)' vs 'Apple Pay (Web and App)'. This is a per-brand app, distinct from HungerRush-owned Menufy's multi-restaurant marketplace. It is a paid add-on ('contact sales'), not bundled. https://support.hungerrush.com/hc/en-us/articles/19248722775437-Release-Notes-05-10-2022 · retrieved 2026-08-08

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

Guest accounts are a documented, configurable part of first-party ordering: the 2024 Online Ordering notes describe 'Terms of Use for both creating an account and placing an order', separate content for '(1) user registration and (2) checkout experience', and behaviour differences for 'Registered users' vs guests ('Guest at checkout will always see the opt-in checkbox to enroll in HR360 Marketing. Registered users at checkout will always see the opt-in checkbox unless they have unsubscribed'); Release Notes 05/10/2022 configures privacy/terms 'for the footer and registration screen'; and the Coupon Editor's 'Single Use Only (Once per Customer)' setting works when 'the customer logging into their online ordering account' attaches full customer information (phone, address, name) - so accounts carry saved contact and address details. Shortfall: no article documents a saved/tokenized card on file or a wallet of stored payment methods (Apple Pay is the only documented express payment, enabled per site in the Admin Portal), and no article documents one-tap reorder of a previous order on the web site or the branded app - the only 'use last order' recall found is an employee-side POS popup. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-08-08

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

OrderAI suggests add-ons on the phone channel; digital-checkout upsell configuration and attach-rate reporting are not documented. https://www.hungerrush.com/products/orderai-ai-ordering-system/ · retrieved 2026-08-01

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

Pre-ordering supported; per-daypart capacity throttling and automatic slot closure are not documented. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01

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

Pickup, curbside with arrival check-in, and delivery are all documented. Dine-in / QR table ordering is not. https://www.hungerrush.com/products/delivery-take-out/ · retrieved 2026-08-01

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

'Scan to Pay' documents guests scanning a QR code on the printed dine-in receipt to pay from their phone, with tip selection, and 'the check is automatically closed in your POS' once payment completes -- a genuine QR-attach-to-existing-check flow. Shortfalls: this is scan-to-PAY only (no scan-to-ORDER via the same QR), and no article documents splitting the check via the QR flow -- the FAQ describes a single guest paying the full check. https://support.hungerrush.com/hc/en-us/articles/40694176098189-Scan-to-Pay · retrieved 2026-08-04

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

Kiosk is delivered by third-party partner INFI via the integrations catalog, not as a first-party product sharing the POS menu engine. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

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

I confirmed 'Group ordering' does appear in the online-ordering feature list, so it is not fabricated — but that is the entire evidence: one bullet, no participant links, spend caps or split payment. A single-word marketing bullet does not clear the bar for yes. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01 adversarially verified

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

No catering ordering flow exists as a product. Three vendor-owned enumerations retrieved 2026-09-04 agree: the products navigation lists twelve products (AI Phone Ordering, POS, Hardware, Delivery & Curbside, Payment Processing, Integrations, Online Ordering, Feedback, Automated Marketing, Loyalty, Gift Cards, Text Marketing) with no catering entry; /products/integrations/ is a complete categorised list of twenty partners with no catering partner; and /products/online-ordering/ states the storefront's feature set as 'Pre-ordering, Group ordering, Order throttling, Customizable menus, Multi-location menu management, Pizza-specific configurations'. The site's own WordPress search index returns no catering product or feature page, and the 43-URL page sitemap has none. Across the 313-article help centre 'catering' occurs once, as an operator-named order type in a KDS filter example; across all 45 PDFs once more, as 'mapping features for delivery routing and catering operations'. 'Box lunch', 'banquet', 'proposal' and 'invoice terms' return zero. Adjacent building blocks exist and were read - house accounts with statements, deferred/future orders, user-definable order types - but no catering menu or minimum, lead-time rule, quote/proposal, deposit or invoice term is described anywhere. Caveat: the online-ordering back office is thinly documented (the help centre's 'Admin Portal' section is an 'under construction' stub), so a catering-shaped order type configured inside the storefront cannot be excluded; the claim's quote/deposit/invoice-terms conjunction is unmet regardless. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-09-04 adversarially verified

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

Held to the high bar and it survives: first-party via the Dec 2020 OrdrAI acquisition, and the Dec 11 2025 newsroom release documents Jet's Pizza passing 10M AI purchases and $250M+ in sales via OrderAI. Newsroom evidence, not a feature bullet. https://www.hungerrush.com/newsroom/ · retrieved 2026-08-01 adversarially verified

Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.

digital-drivethru-ai

Re-fetched the OrderAI product page 2026-09-04: it names exactly one channel and names it in the lede -- 'Capture every phone order with AI that understands menu complexity, maximizes revenue, and keeps your team focused on the rush' -- and the rest of the page speaks only of phone orders, calls and phone interruptions. The product is branded 'OrderAI Talk' and framed as 'Never Miss Another Phone Order' and 'Handles multiple calls at once to prevent busy signals'. It does satisfy the claim's two sub-parts on POS integration ('Syncs directly with your POS'; 'Supports your full menu, including modifiers, styles, and brand-specific items') and human escalation ('Monitors calls for friction and loops in human agents to help behind the scenes'), but nothing anywhere names a lane. This is scored no rather than unknown because the enabling hardware is separately enumerated and absent: the five-item hardware catalog contains no lane speaker, headset, menu board or confirmation display, so there is no audio path into a drive-thru to run this on. The OrderAI Talk section of the closed 313-article census is a single stub reading 'This page is under construction. Content is coming soon!', and the OrderAI Talk datasheet PDF is image-only and extracts no text -- neither adds a channel. https://www.hungerrush.com/products/hardware/ · retrieved 2026-09-04 adversarially verified

Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.

digital-sms-ordering

'Voice and Text Ordering' is a named product category; the OrdrAI acquisition (Dec 3, 2020) was explicitly a text-and-voice ordering provider. https://www.hungerrush.com/products/orderai-ai-ordering-system/ · retrieved 2026-08-01

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

CAPABILITY reading, and the claim as written asks for the direct ordering LINK to be provisioned to the Google Business Profile as an ordering option - not for end-to-end order capture inside Google, which Google itself retired. Read the full article: the 6/2024 feature entry is 'Google Food Ordering transition to Google Referral Service - Updated feed with appropriate links for referral - Google is transitioning from accepting orders from customers to referring customers to restaurant websites. We've updated all restaurant feeds to provide referral URLs for Google to use. There will be more changes to come as we build to the new Google system.' A maintained restaurant feed supplying Google with referral URLs to the restaurant's ordering site is exactly the provisioning mechanism the claim describes under the post-transition Google model, and it is stated as done for all restaurants, so this is materially more than unknown. SHORTFALLS that hold it at partial: (1) it is documented only for Menufy, the separately branded HungerRush-owned ordering platform, and no article, no www page and no PDF makes any Google ordering-link claim for the HungerRush 360 online-ordering site; (2) 'Preferred by Business' placement is never mentioned - 'Order with Google' and 'Google Business' return zero hits corpus-wide - so nothing shows the referral link is set as the preferred ordering action rather than sitting alongside marketplace links; (3) the vendor's own sentence flags the work as unfinished ('There will be more changes to come as we build to the new Google system'), and every subsequent release-note seam through 2026 was checked for a follow-up Google entry: there is none. The only other Google integrations in the census are Google Review link embedding (article 32093834769805) and Google Maps for delivery zones, neither of which bears on ordering-link placement. https://support.hungerrush.com/hc/en-us/articles/30742847136909-Menufy · retrieved 2026-09-04

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

This is a published-integration claim, and the publication surface is enumerated and contains nothing about Apple. 'Apple Business Connect', 'Apple Maps', 'Order Food' as a place-card action, 'place card' and 'listing management' return zero across the closed 313-article help-centre census (Zendesk API and /hc/sitemap.xml agreeing exactly, 0 diff), the 287 www sitemap page locs, and all 45 PDFs. HungerRush's only listing-placement material is the Pizza Google My Business Toolkit, which is entirely Google and whose sole maps sentence is about search ranking, not an ordering action: 'Savvy companies of all types use Search Engine Optimization, or SEO, to drive their business listing upward not only on a relevant search results page but also on map searches through Google Maps.' The vendor devoted a whole toolkit to claiming and optimising a place listing and named only Google; that is the closest thing to an enumeration of listing integrations that exists and Apple is not in it. The only Apple-platform material anywhere is payment and app-store compliance — 'Apple Pay Activation - Admin Portal Activation', the 05/10/2022 release note adding Apple Pay to iOS branded apps, and the 07/12/2022 note implementing Apple's in-app account-deletion requirement. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-04 adversarially verified

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

Loyalty runs on 'real-time data from online orders'; the POS order screen applies coupons and loyalty rewards against the same central customer record. https://www.hungerrush.com/products/loyalty/ · retrieved 2026-08-01

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

CLAIM TESTED: guest subscription or membership programs - recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier - managed in the platform. FINDING: no recurring guest charge exists on any of the three surfaces that would carry one, and each of those surfaces is enumerated rather than merely silent. (1) THE PAID-LOYALTY-TIER VARIANT. 'HungerRush Loyalty Version 1 - USER GUIDE' (PDF attachment https://support.hungerrush.com/hc/article_attachments/25386044668813, re-fetched by the verifier at anonymous HTTP 200 on 2026-09-15, 5,430,744 bytes, MD5 62db9a2014bec1fd6b258ae2888f68e3, footers '(c)HungerRush2022 | Proprietary & Confidential. Updated August 11, 2022', attached to https://support.hungerrush.com/hc/en-us/articles/25386068078093-User-Guides, category HungerRush, section Loyalty) enumerates the whole model - p.50 'There are 4 types of point rules' (General, Birthday, Anniversary, Registration) and p.62 'There are five (5) types of reward rules' (Point, Dollar, Birthday, Anniversary, Registration) - and enrolment is free and self-service throughout: p.1, 'Enrolling in HungerRush Loyalty is simple and easy for consumers. They will have the option to enroll in the program by providing the following information whenever they place an order in-store: first name, last name, email, and phone number', and 'Customers become members by enrolling on any ordering platform.' 'Membership' in this product means the enrolment date (the Anniversary rule: 'The membership anniversary marks the date that the customer enrolled in the loyalty program') and the Membership ID, never a paid plan, and there is no price field among the rule editor's enumerated fields (Rule Name, Rule Type, Is Exclusive, Store Admin Access, Days Valid, Reward Type, Min Points, Minimum Dollars Spent Over, Max Reward, Reward $/%). (2) THE DELIVERY-FEE-WAIVER VARIANT. Delivery fees are documented as per-order charges set by zone and distance, and the only documented way to zero one is a coupon applied to a single order: 'RM/HUB - Coupon Editor Settings Glossary', 2026-07-24, https://support.hungerrush.com/hc/en-us/articles/47045403019661-RM-HUB-Coupon-Editor-Settings-Glossary, category HungerRush, section Restaurant Management (Formerly known as HUB) - '(17) Free Delivery will remove the delivery fee from any order this coupon is applied to'. There is no standing entitlement and no subscriber state: tokenised 'waive' = 0 across all 313 bodies. (3) THE PER-PERIOD ENTITLEMENT VARIANT. The registered guest account's benefits are enumerated in the vendor's own product overview ('Suite of HungerRush Products', Getting Started Guide PDF, attachment https://support.hungerrush.com/hc/article_attachments/25386767258765, re-fetched at 200 on 2026-09-15, MD5 b49d7fc5b86bb3b3b0c08710aedb9c33): 'If a customer opts to register for an account, they have the ability to setup multiple addresses on their profile, save favorite orders and all of their past orders will be saved for easy reordering' - three named benefits, no recurring plan among them - and the same guide's Email Club setting is an email opt-in list, not a paid club ('If you offer an Email Club for all stores using HungerRush and this setting is selected, you'll be able to run the Opt In Report to gather customer information'). CATEGORY DISCIPLINE: HungerRush category only (Loyalty, Restaurant Management, Coupons, Delivery, Integrations, Legacy POS user guides). Nothing from Menufy or RPOWER. BOUND CORPUS AND ITS FOUR KNOWN HOLES: 313 articles from support.hungerrush.com's Zendesk Help Center API (the HTML help centre 403s behind Cloudflare; the API serves anonymously), 4,032,659 bytes of body, plus 13 vendor PDFs, plus three live www.hungerrush.com pages. Verifier-re-run href fixpoint: 70 referenced ids inside the 313 bodies, 12 absent from the listing, 10 x 404, 2 x 401, ZERO unlisted 200s; two fabricated ids returned the same 52-byte 404. HOLE 1, the two 401s: 'Scan-to-Pay' and 'Use Menu in 3rd Party Channels'; neither is a loyalty or subscription article. HOLE 2: section 25351007766797 'Product Documentation' exists with count 0. HOLE 3: the category 'HungerRush 360 Loyalty & Rewards' is a single 2024-08-22 article reading 'Check back shortly for KB articles for HR 360 Loyalty & Rewards'. HOLE 4: 133 video embeds (128 Loom, 5 youtube-nocookie) in 111 of the 313 articles. CONTROLS, run in three modes (both-boundary token, left-boundary stem, whitespace-squashed substring) over comment-stripped raw bytes and tag-stripped text of all 313 bodies, all 13 PDFs, three renderings of the loyalty PDF (-layout, plain, -raw) and the three marketing pages, with positive controls passing ('HungerRush' 3,888 token hits over 272 of the 313 bodies; 'loyalty' 389 in the guide and 25 on the marketing pages). ZERO IN ALL THREE MODES AND EVERY CORPUS: 'subscription', 'subscriptions', 'recurring', 'auto-renew', 'autorenew', 'meal plan', 'unlimited', 'membership fee'. THE HOMONYM THE BRIEF WARNED ABOUT WAS HUNTED AND IS PUBLISHED: every near-miss is the OPERATOR'S own bill or the operator's SMS plan, never a guest charge - 'monthly fee' = 2 ('DoorDash Drive may charge a small monthly fee to remain active on their service', and the Getting Started guide's 'The monthly fee begins to accrue on that date. The first month of billing is pro-rated'), 'subscriber' = 17 hits in 5 documents, all HungerRush Text Marketing SMS subscribers with an 'associated pricing tier based on subscriber list' charged to the operator, 'subscribe' = 3 on the marketing pages and it is the newsletter footer 'Subscribe for insights from our experts'. CORRECTION TO AN EARLIER FIGURE: 'membership' is NOT zero as a prior note recorded - it is 0 across the 313 article bodies but 12 token hits in the loyalty guide, and every one is 'membership anniversary' or 'membership ID'. 'prepaid' = 4 hits, all poison (a delivery driver's 'Prepaid orders are delivery orders that were paid ahead of time' and an OrderAI 'Text Prepaid' payment type). 'club' = 13 hits, all the Email Club opt-in list or the loyalty guide's 'Enable Loyalty Separate from E-club' flag. DUAL-PROBE INVARIANCE, run because pdftotext -layout can split a word and manufacture a false zero: 'subscription', 'recurring', 'auto-renew' and 'meal plan' each read 0/0/0 (token/stem/squashed) in all three independent renderings of the loyalty PDF and across all 13 PDFs, so none of these zeros is an extraction artefact. POISON IN THE SQUASHED PROBE ITSELF: squashed 'refer' returns 283 over the PDFs because it matches inside 'preference', so the squashed instrument is published as a cross-check, never alone. The live marketing agrees: www.hungerrush.com/products/loyalty/, /products/payment-processing/ and /pricing/ (all 200 on 2026-09-15) carry 'subscription', 'recurring' and 'membership' 0 times. AND THE PRICING PAGE MAY NOT BE READ AS A CLOSED LIST IN EITHER DIRECTION - its add-on enumeration ends 'and more...', which is an open enumeration that can carry no absence; it is cited here only for the vocabulary control, not as a bound. https://support.hungerrush.com/hc/article_attachments/25386044668813 · retrieved 2026-09-15 adversarially verified

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

The coupon walkthrough documents a single coupon configured to be 'available both In-Store and Online (but only for Delivery)' with channel eligibility as an explicit setting, and 'Upload Online Menu' pushes the same coupon record to the online channel -- one coupon definition honored identically across channels with channel eligibility controls. https://support.hungerrush.com/hc/en-us/articles/47271622663181-RM-HUB-Walkthroughs-for-Creating-Basic-Coupons · retrieved 2026-08-04

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

Of the three legal pages, /terms/ ('Terms and Conditions', last updated April 27, 2026) is the merchant agreement - it applies to 'THE AGREEMENT BETWEEN YOU AND HUNGERRUSH LLC AND ITS AFFILIATES, INCLUDING MENUFY.COM LLC AND ORDR INC.' and is incorporated into signed quotes; /terms-of-use/ governs website visitors and /terms-of-service/ is the older page already cited in this record. It states verbatim: 'You have an ownership interest in all information or data about you and your business that is generated by the Products and Services. However, to the extent that the Company receives or otherwise has access to such information or data, or to information or data about your customers, through the Products or Services, or otherwise, the Company may use such information and data to develop, provide and to support the Products and Services, and for such other business purposes as it reasonably desires.' Shortfall: ownership is asserted but export is not - the Terms contain no bulk-export right, no obligation to return or transfer data at termination, and they place backup/archiving on the merchant while disclaiming liability for 'loss, corruption, or interception of any data or information belonging to you or to your customers'. The only documented export path is the POS Marketing module's CSV export of query results (see guest-loyalty-data-export-portability), which the Terms do not guarantee. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

328th: MOVED unknown -> no, ON THE PUBLICATION CONJUNCT ONLY, and the reason the three prior passes stopped short is now removed. The claim is a CONJUNCTION: hosted fields/HPP AND the vendor publishing PCI DSS 4.0 compliance (incl. the March-2025 client-side script-integrity requirements) AND 3DS. Falsifying one conjunct falsifies the claim, and the publication conjunct is a publication question, which a publication census can carry. (1) NEW SURFACE READ THIS PASS - www.hungerrush.com/terms/ (HTTP 200, 60,496 B, 41,865 chars stripped; the nonsense control www.hungerrush.com/zzq-nonsense-q328/ returns the site 404 shell at 46,628 B). HungerRush's live Terms and Conditions do not assert the vendor's own PCI posture; they ALLOCATE PCI-DSS TO THE MERCHANT, in the customer-obligations clause: 'using the Products and Services in compliance with the Americans with Disabilities Act ("ADA"), the Telephone Consumer Protection Act ("TCPA"), the California Consumer Privacy Act of 2018 (if applicable) ("CCPA"), the Payment Card Industry Data Security Standards ("PCI-DSS") and Payment Application Data Security Standards ("PA-DSS"), and all other applicable laws and rules'. Tokenised controls over those 41,865 chars: PCI 1 (that clause and no other), DSS 1, 3DS 0, '3-D Secure' 0, tokeniz 0, hosted 0, 'script integrity' 0, iframe 0, API 0. (2) THE LEGAL SURFACE IS NOW CLOSED, not merely unread: /legal/, /msa/, /master-service-agreement/, /eula/, /sla/, /terms-of-service/ and /terms-and-conditions/ ALL return the 404 shell (46,489-46,629 B, byte-comparable to the nonsense control), so /terms/ and /privacy-policy/ are the only live agreements HungerRush publishes. There is no unread MSA to find. (3) /payment-security/ re-fetched today (HTTP 200, 50,481 B) is still the sole 'Regulatory Compliance' page and is still framed on 'PCI Compliancy - Point of Sale (PA-DSS)' with 'HungerRush is dedicated to helping our customers quickly and easily become PCI compliant'; over its 50 KB: script 0, integrity 0, 3DS 0, '3-D Secure' 0, SCA 0, hosted 0, tokeniz 0, iframe 0, AOC 0, attestation 0. (4) THE DOC CENSUS IS CURRENT, RE-DERIVED TODAY: support.hungerrush.com/api/v2/help_center/en-us/articles.json paged 1-4 returns count=313 over 52 sections (incl. a '2026 Release Notes' section, id 44088608241037); diffed against the q324 census by article id, ZERO new articles and ZERO articles with updated_at > 2026-09-10, so the published KB has not changed since the 3DS/PCI-DSS/tokenisation zeros were measured over it. BOUND: HungerRush's complete publication surface = 313 KB articles + 39 PDF attachments + the WordPress census (page/post/resources types; 63/63 resources + 59 linked PDFs, 327th) + status.hungerrush.com + 2 live agreements. PCI DSS 4.0 appears nowhere in any of it. HONEST LIMIT: the head clause (vendor-hosted fields vs a hosted payment page) is STILL unmeasured - checkout.menufy.com was probed today and is a real ASP.NET host (root 404, 1,090 B, distinct from the *.menufy.com wildcard 301) but Menufy is a separate acquired brand, not the HungerRush Online Ordering product, so it was not used as evidence. This `no` rests on the publication conjunct alone, consistent with the `no` already recorded at reliability-pci-dss-4-attestation and commercial-pci-dss-4-controls. Retrieved 2026-09-18. https://www.hungerrush.com/terms/ · retrieved 2026-09-18 adversarially verified

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

One configuration serves both channels: surcharges are created in hub.hungerrush.com under Manage > System > Configuration > Surcharges with a name, price, Price Type (percentage or flat), Report Group and Tax Type, then 'Assign Payment Types' and 'Assign Order Types', and saving pushes 'the change to the local level'. That the same records govern digital orders is confirmed by the Online Ordering bug fix of 9.5.24 in 'Releases by Category': 'Fixed multiple issues where surcharges were incorrectly applied to the wrong stores and order types. This occurred when the surcharge for a specific store and order type replaced all other surcharges in the business tables responsible for eCommerce surcharges.' Jan/Feb/Mar 2026 Rush Hour Updates further record 'Surcharge Now Calculated on Payment Amount' and fundraiser/donation exclusion. Compliance is gated administratively, not in software: 'Before creating a Surcharge for credit card transactions, ensure that the Surcharge Liability form has been completed by the customer.' Shortfall: disclosure is described as the operator's own manual duty ('disclosed either on the menu, receipt, or posted signage') with no documented guest-facing disclosure element in the online checkout, and no article addresses jurisdictions where surcharging is prohibited or card-brand rules such as the debit-surcharge ban - the only lever is which payment types the operator assigns. https://support.hungerrush.com/hc/en-us/articles/19248742111757-Creating-and-Using-Surcharges · retrieved 2026-08-08

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

'See and search all customer data from a central dashboard, including contact information, order history, preferences, loyalty status.' Dedup/merge rules are not documented. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

January 2026 release notes: 'Cleaner Loyalty Data for Online and Third-Party Orders -- Incoming online and third-party orders that use shared or generic email addresses are now handled correctly -- they will no longer be incorrectly linked to an existing loyalty customer in your system.' Confirms, as a bug-fix against existing behavior, that third-party orders are matched and attached to loyalty/guest profiles by default rather than landing as anonymous tickets. https://support.hungerrush.com/hc/en-us/articles/44088712489485-Rush-Hour-Updates-Jan-2026 · retrieved 2026-08-04

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

Points-per-purchase documented ('award points right after purchase'). A second accrual model (punch/visit or spend tier) is not documented. https://www.hungerrush.com/products/loyalty/ · retrieved 2026-08-01

Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator

guest-loyalty-tiers

CLAIM TESTED: guest status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. FINDING: HungerRush's loyalty engine has no tier entity, and the absence sits inside two explicitly counted, closed enumerations in the vendor's own 122-page operator manual, not in silence. SOURCE, re-fetched and re-extracted by the verifier on 2026-09-15: 'HungerRush Loyalty Version 1 - USER GUIDE', PDF attachment https://support.hungerrush.com/hc/article_attachments/25386044668813, served anonymously at HTTP 200, 5,430,744 bytes, MD5 62db9a2014bec1fd6b258ae2888f68e3, footer on every page '(c)HungerRush2022 | Proprietary & Confidential. Updated August 11, 2022', table of contents ending at Technical Support p.122. It hangs off the article 'User Guides' at https://support.hungerrush.com/hc/en-us/articles/25386068078093-User-Guides, category HungerRush, section Loyalty, whose entire body reads 'User Guides listed here are for Loyalty programs affiliated with HungerRush Restaurant Management'. QUOTE 1, Point Rule reference table p.50: 'The Rule Type determines how the customer will earn points for the rule. There are 4 types of point rules:' followed by exactly four - General Rules, Birthday Rules, Anniversary, Registration. QUOTE 2, Reward Rule reference table p.62: 'There are five (5) types of reward rules. The Rule Type determines the requirements for the member to earn a reward' - Point, Dollar, Birthday, Anniversary, Registration. QUOTE 3, the rolling-window mechanic the claim names, p.63: 'The Minimum Dollars Spent Over field is used for the dollar rule type... This field has a drop down menu of four (4) options. None--If none is selected the rule will only apply to one order at a time. Last 30, 60, or 90 Days--these three options will allow the rule to review the customer's order history. If a customer has spent the specified amount of money during the selected time period, the reward will be awarded to their account.' So rolling-window spend exists, and its whole documented effect is to drop one expiring reward code into the member's account, not to promote the member to a status; nothing in either enumeration demotes anyone. The guest-facing status view is a progress bar, p.121: 'The Available Points graphic shows the customer a progress bar with their current account point total, the number of points required for the next reward, and a metric for 50% completion.' THE 2022 GUIDE STILL DESCRIBES THE LIVE ENGINE - three independent 2026-dated articles use its primitives: 'RM/HUB - Coupon Editor Settings Glossary' 2026-07-24 (https://support.hungerrush.com/hc/en-us/articles/47045403019661-RM-HUB-Coupon-Editor-Settings-Glossary), '(6) Confirm Loyalty is required for coupons that are part of your restaurant's loyalty rewards system, and will link the coupon to a loyalty reward and prevent customers without the reward from redeeming the coupon'; 'Printer Ticket Configuration Settings' 2026-08-06 (https://support.hungerrush.com/hc/en-us/articles/46613116747021-Printer-Ticket-Configuration-Settings), which prints 'Lty Customer ID (<YCUSTID)... the loyalty ID of the loyalty account attached to this order' - the same Loyalty Membership ID the 2022 guide's barcode encodes; and 'Rush Hour Updates - Jan 2026', 'Incoming online and third-party orders that use shared or generic email addresses... will no longer be incorrectly linked to an existing loyalty customer in your system'. The vendor's live marketing agrees on the model: www.hungerrush.com/products/loyalty/ and the product nav, retrieved 200 on 2026-09-15, say only 'Loyalty - Design an automated loyalty program using points and rewards.' CATEGORY DISCIPLINE: every quote is from the HungerRush category, sections Loyalty, Restaurant Management (Formerly known as HUB), Printer and Print Ticket Configuration and 2026 Release Notes. Nothing from Menufy or RPOWER. BOUND CORPUS AND ITS FOUR KNOWN HOLES: 313 help-centre articles pulled from support.hungerrush.com's Zendesk Help Center API (the HTML help centre 403s behind Cloudflare; the API serves anonymously), 4,032,659 bytes of body, plus 13 vendor PDF attachments. An href fixpoint re-run by the verifier found 70 distinct /hc/<locale>/articles/<id> ids referenced inside the 313 bodies, 12 absent from the listing, each probed at /api/v2/help_center/en-us/articles/<id>.json: 10 x 404 and 2 x 401, ZERO unlisted 200s; two fabricated ids returned 404 at 52 bytes, byte-identical in shape to the ten, so those ten are stale links and not hidden documents. HOLE 1, the two 401s: 40694212678285 'Scan-to-Pay' and 38746931822733 'Use Menu in 3rd Party Channels' - neither is a loyalty article. HOLE 2: section 25351007766797 'Product Documentation' exists and returns count 0 anonymously. HOLE 3, THE ONE THAT MATTERS HERE: the help centre carries a whole category 'HungerRush 360 Loyalty & Rewards' containing exactly one article, dated 2024-08-22, whose entire body is 'Check back shortly for KB articles for HR 360 Loyalty & Rewards', so if a successor loyalty module exists under that name it is undocumented on this host; the 2026 bridge above is what carries the verdict past that hole, not the guide's date. HOLE 4: 133 video embeds (128 www.loom.com, 5 www.youtube-nocookie.com) sit in 111 of the 313 articles, so roughly a third of this help centre's content is inside video that no text census can read. CONTROLS AND POISON, all run in three modes - both-boundary token, left-boundary stem, and a WHITESPACE-SQUASHED SUBSTRING probe that can see a word pdftotext has split - over the comment-stripped raw bytes and the tag-stripped text of all 313 bodies, all 13 PDFs, and three independent renderings of the loyalty PDF (pdftotext -layout, plain, and -raw). Positive control: 'HungerRush' 3,888 token hits over the 313 bodies (272 documents) and 389 over the loyalty guide; 'loyalty' 389 in the guide, 25 on the marketing pages. 'tier' and 'tiers' read 5 token hits in 4 articles and EVERY ONE IS POISON: 'Missing "Begin 2nd Tier" option for Preferences' (a menu preference setting), 'associated pricing tier based on subscriber list' (HungerRush's own SMS billing tier charged to the operator), 'Menu Validator checks against 18 rules across three severity tiers', and 'assign them to your various stores based on pricing tiers'. Stem mode raises 'tier*' to 26 hits in 11 documents and every added hit is 'Tiered Pricing', a 2nd/3rd-item menu price feature. In the 122-page loyalty guide 'tier*' matches EXACTLY ONCE and it is published here because it is the strongest thing against this verdict, p.1 under the heading 'What is a Loyalty Program?': 'It can be a simple program that provides customers a discount after a certain number of visits, or a complex tiered system with multiple rewards based on rules that are constantly managed.' That is a generic industry definition in a preamble, immediately followed by 'HungerRush Loyalty uses two basic rule sets to provide rewards to your customers', and is not a statement about this product. Vendor-vocabulary controls for a status tier, run in all three modes: 'gold', 'silver', 'bronze', 'platinum', 'elite', 'loyalty level', 'membership level', 'status level' all 0; 'rank' 0; 'VIP' 5 hits in 3 documents, all poison (a service-recovery 'VIP gesture' in Customer Credits, and 'group your customers by various notations like "VIP" or "Rewards"' - a free-text Customer ID field); 'club' 13 hits in 3 documents, all poison, being the operator's email opt-in list ('Enable Email Club... run the Opt In Report') and the loyalty guide's 'Enable Loyalty Separate from E-club' flag. DUAL-PROBE INVARIANCE: the squashed probe changed nothing - 'tier' reads 0/1/1 (token/stem/squash) in all three renderings of the loyalty PDF, so no false zero was manufactured by pdftotext word-splitting. POISON IN THE SQUASHED PROBE ITSELF, published so it is not trusted blindly: squashed 'refer' returns 283 hits over the PDFs and 440 over the KB because it matches inside 'preference' and 'preferred'. AND ONE MORE INSTRUMENT DEFECT FOUND AND FIXED HERE: a first pass of the marketing-page control returned 0 for every term including 'loyalty', which is a shell-escaping artefact that collapsed the word-boundary metacharacter; only the positive control caught it, and the figures published above are from the re-run. https://support.hungerrush.com/hc/article_attachments/25386044668813 · retrieved 2026-09-15 adversarially verified

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

This claim is about publication, and the publication surface is now closed: 313 of 313 help-centre articles enumerated two independent ways that agree exactly, and not one states what loyalty lookup, accrual or redemption does when connectivity is lost. The entire documented loyalty-at-the-POS surface is this article, and it is a cloud lookup with no degraded path: 'Go to Config then select Customer Maint. In Customer Maint. tab, go to the last tab called Honeycomb. In Honeycomb input customer's phone number/email address or loyalty ID.' The silence is load-bearing because HungerRush demonstrably does document offline behaviour subsystem by subsystem where it exists - 'Forcing Credit Cards - DataCap' documents processor-level Store and Forward, the Scan to Pay FAQ states 'Both the driver and guest need an active internet or cellular connection to complete payment. If service isn't available, the driver can accept cash instead', and 'Sync to Store' warns 'If the selected store is offline, there will be a warning reminding the user that we are unable to connect to the selected store, and the Sync Now button will be disabled.' Loyalty alone receives no such statement, in the help centre or in the Loyalty data sheet. https://support.hungerrush.com/hc/en-us/articles/19248812234509-Manually-Adding-Points-From-The-POS · retrieved 2026-09-04 adversarially verified

Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator

guest-loyalty-offer-stacking-rules

Stacking is a first-class, per-coupon configuration: setting (23) 'Not Valid with Other Coupons will prevent the coupon from being used alongside any other coupon on an order. This includes using the same coupon multiple times; Leave this setting disabled if you want customers to be able to use the coupon deal multiple times on an order.' Interaction with already-discounted lines is separately configurable: on Order-scope coupons setting (20) becomes 'No Discount Items in Qualifying Amount - This setting excludes any items that already have a discount applied from another coupon from being counted towards a coupon's qualifying amount restriction.' Related exclusivity controls include (26) 'Single Use Only (Once per Customer)' and, in the Text Marketing coupon builder, 'Valid with Other Coupons: Allow the Text Marketing coupon to be used with any other coupon.' Shortfall: precedence is not configurable - the glossary walks all 28 General settings plus the Stores, Date and Time and Items tabs and exposes no order-of-application, priority or best-deal-wins rule when several coupons are simultaneously eligible; combinability is binary per coupon. https://support.hungerrush.com/hc/en-us/articles/47045403019661-RM-HUB-Coupon-Editor-Settings-Glossary · retrieved 2026-08-08

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

'Set triggers to auto-send personalized promotions with precision' and capture data to 'identify repeat orders'. No documented audience rule-builder over recency/frequency/spend/items. https://www.hungerrush.com/products/loyalty/ · retrieved 2026-08-01

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

'Marketing On The POS Overview' (MGMT > Marketing) documents a customer database queryable on 'over 40 different parameters' and, above the user-defined queries, a fixed set of prebuilt ones the system computes: 'New Customers - Prebuilt query that has a preset date range for the past 30 days'; 'Lazy Customers - Prebuilt query that when ran shows customers within a date range that have not placed orders' (lapsed, recency); 'Customers That Require Offers - shows over the range of the past 30 days customers who only ordered when they had a coupon or a discount'; 'Increasing Customers - Prebuilt query that shows increasing in order count or ticket amount in their order history that is increasing over the last 90 days' (frequency and monetary); 'Decreasing Customers - Prebuilt Query that shows customers over the past 90 days who's order history has decreased' (at-risk); 'Customer Special Dates'; and 'All Customers'. Results feed Map, Print Labels, Print and Export to CSV. Caveat recorded rather than a shortfall: these are on-demand queries run in the POS marketing module, not standing audiences - the Text Marketing campaign builder's audience is store selection plus imported lists, so these segments are not selectable as an SMS campaign audience. https://support.hungerrush.com/hc/en-us/articles/19248790708109-Marketing-On-The-POS-Overview · retrieved 2026-08-08

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

'Fully automated email and text marketing campaigns' with triggers, but birthday / first-visit / lapsed win-back are not individually named as shipped always-on automations. https://www.hungerrush.com/products/hungerrush-360-marketing/ · retrieved 2026-08-01

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

Two problems the scorer noted but did not price in: it is positioned as a managed service rather than an operator-run campaign tool, and the loyalty page gates automated marketing 'With Advanced Plan Only' — a tier carrying no published price that does not appear on the pricing page. A paid higher-tier done-for-you service is a partial. https://www.hungerrush.com/products/loyalty/ · retrieved 2026-08-01 adversarially verified

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

Release notes document a checkout-time HR360 Marketing opt-in checkbox with corrected display-rule behavior, and 'Why HungerRush Text Marketing Matters' advertises 'built-in legal guardrails (opt-out controls, character limits, time windows).' A CCPA deletion-request workflow is separately documented. Shortfall: no article documents recording a timestamp and source per consent event, or honoring revocation received by any reasonable means beyond the standard opt-out mechanism, both specifically required by the claim. https://support.hungerrush.com/hc/en-us/articles/38892784170125-Why-HungerRush-Text-Marketing-Matters · retrieved 2026-08-04

Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.

guest-loyalty-10dlc-registration

The claim has two limbs - handles, or explicitly documents - and only the documentation limb can be settled. It fails outright: '10DLC', 'A2P', 'short code', 'campaign registration' and 'brand registration' return zero hits across all 313 articles, and the Text Marketing data sheet's whole compliance statement is the two-line 'Compliance Made Simple / Opt-in/opt-out keeps you covered.' On the handling limb, this article is the end-to-end prerequisite article - 'Before you start sending messages, make sure your system is set up correctly' - and everything it requires is internal: the 'Marketing - New' tab in HungerRush HUB, role-based user permissions, store assignment and a Billing Responsibility permission ('Only stores with billing information properly configured will appear as available options. Billing is completed during the onboarding process'). No carrier, brand or campaign registration step is ever asked of the operator, and the product ships US A2P traffic at scale through a named aggregator ('Our SMS provider, Twilio, follows specific rules about message length'), so registration is being done somewhere off the operator's desk. What IS documented is downstream compliance only, not registration: 'STOP to End - To ensure the message aligns will regulatory Text Message laws this language is added to all messages... This field cannot be removed from message', 'Quite Hours: Messages can only be scheduled between 9AM and 7PM to comply with TCPA quiet hour requirements', a 'Brand Name Missing' enforcement notification, a consent checkbox required before scheduling, and automatic invalid-number scrubbing. Exact shortfall: the operator is never asked to register and therefore cannot verify, evidence or troubleshoot their own brand and campaign registration status, because no article or datasheet states who registers or that registration occurs at all. https://support.hungerrush.com/hc/en-us/articles/38893996947725-Configurations-User-Permissions · retrieved 2026-09-04

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Loyalty page references tracking campaign performance; tying redeemed offers to actual check totals or incremental sales is not documented. https://www.hungerrush.com/products/loyalty/ · retrieved 2026-08-01

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

Self-serve export of the guest list is documented: MGMT > Marketing includes the prebuilt 'All Customers - This is a prebuilt query that takes 1-5 minutes to run and will query all customers in the system', and on the results screen 'Export - This button allows you to export the query results to a .csv file that can be opened in Excel or Notepad', alongside Print and Print Labels (which use 'the customer address information from your search', so contact PII is in scope; the query parameters include email address and rewards-member status). No support ticket or fee is mentioned. Shortfall: this exports the customer records a query returns, not transaction history - order-level history lives in separate RM reports (Order Details, Sales by Account) whose own export article covers running a report and clicking export, and no documented report joins guest contact PII to full per-guest order history; a 'Loyalty Export' is named only in passing in a 12/6/2022 bug fix; and there is no public API export path (developer./docs./kb.hungerrush.com all 404 and no API reference is published). https://support.hungerrush.com/hc/en-us/articles/19248790708109-Marketing-On-The-POS-Overview · retrieved 2026-08-08

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

Braze is a named marketing integration and a HungerRush API exists, implying an outbound guest/order path; no documented webhook or event stream is public. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

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

Half of this is unsupported. The Feedback page does confirm 'Free for all plans.', 'Google Review integration prompts 5-star customers to share online', and 'Track customer sentiment and performance across all stores'. It does NOT describe routing dissatisfied guests into a private recovery flow — only that you can respond quickly to issues. The negative-path routing, which is the substance of the criterion, is not on the page. https://www.hungerrush.com/products/feedback/ · retrieved 2026-08-01 adversarially verified

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

CLAIM TESTED: a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards. FINDING: none of the three conjuncts exists, and the absence sits inside closed enumerations rather than in silence. SOURCE, re-fetched and re-extracted by the verifier on 2026-09-15: 'HungerRush Loyalty Version 1 - USER GUIDE', PDF attachment https://support.hungerrush.com/hc/article_attachments/25386044668813, anonymous HTTP 200, 5,430,744 bytes, MD5 62db9a2014bec1fd6b258ae2888f68e3, page footers reading '(c)HungerRush2022 | Proprietary & Confidential. Updated August 11, 2022', attached to 'User Guides' (https://support.hungerrush.com/hc/en-us/articles/25386068078093-User-Guides, category HungerRush, section Loyalty). Every way a guest can earn is enumerated and counted: p.50, 'The Rule Type determines how the customer will earn points for the rule. There are 4 types of point rules:' - General, Birthday, Anniversary, Registration; p.62, 'There are five (5) types of reward rules' - Point, Dollar, Birthday, Anniversary, Registration. The nearest thing to a referral is the Registration rule, and the guide defines it as a self-enrolment bonus with no second party: 'Registration--only applies when a customer enrolls in your loyalty program. The rule will only apply once per loyalty member.' The enrolment paths are enumerated too, p.1: after the in-store path where 'The guest services member will input the information into the POS', 'Customers may also enroll through HungerRush, Self-Service Kiosks, and Mobile Apps' - no referred-by field, no referrer attribution, nothing linking one member's account to another member's first order. The adjacent coupon engine issues codes but not per-guest ones: 'RM/HUB - Coupon Editor Settings Glossary', 2026-07-24, https://support.hungerrush.com/hc/en-us/articles/47045403019661-RM-HUB-Coupon-Editor-Settings-Glossary, category HungerRush, section Restaurant Management (Formerly known as HUB) - ValCodes are operator-authored strings with 'Single Use Only (Once per Customer)' as the only per-guest limiter, which is one shared code with a usage cap, not a per-guest referral link, and no reward flows back to an issuer. Two-sided rewards appear nowhere in either enumeration. THAT THE 2022 ENGINE IS STILL THE LIVE ONE is carried by three 2026-dated articles using its primitives: the Coupon Glossary's Confirm Loyalty linkage above; 'Printer Ticket Configuration Settings' 2026-08-06 (https://support.hungerrush.com/hc/en-us/articles/46613116747021-Printer-Ticket-Configuration-Settings) printing 'Lty Customer ID (<YCUSTID)... the loyalty ID of the loyalty account attached to this order'; and 'Rush Hour Updates - Jan 2026' fixing how orders link 'to an existing loyalty customer in your system'. CATEGORY DISCIPLINE: the verdict rests only on the HungerRush category. The only referral-shaped text in the entire corpus is about somebody else's product and is named as such below. BOUND CORPUS AND ITS FOUR KNOWN HOLES: 313 articles from support.hungerrush.com's Zendesk Help Center API (the HTML help centre 403s behind Cloudflare; the API serves anonymously), 4,032,659 bytes of body, plus 13 vendor PDFs. Verifier-re-run href fixpoint: 70 distinct article ids referenced inside the 313 bodies, 12 absent from the listing, each probed at the Help Center API - 10 x 404, 2 x 401, ZERO unlisted 200s, with two fabricated ids also returning 404 at 52 bytes, so the ten are stale links. HOLE 1, the two 401s: 'Scan-to-Pay' (40694212678285) and 'Use Menu in 3rd Party Channels' (38746931822733); neither is a loyalty article. HOLE 2: section 25351007766797 'Product Documentation' exists with count 0. HOLE 3: the category 'HungerRush 360 Loyalty & Rewards' holds exactly one article, 2024-08-22, reading in full 'Check back shortly for KB articles for HR 360 Loyalty & Rewards', so a successor module under that name is undocumented; the 2026 bridge above, not the guide's date, is what carries the verdict past it. HOLE 4: 133 video embeds (128 Loom, 5 youtube-nocookie) in 111 of the 313 articles - about a third of this help centre's content is inside video no text census can read. CONTROLS AND POISON, run in three modes (both-boundary token, left-boundary stem, and a whitespace-squashed substring probe that can see a word pdftotext has split) over comment-stripped raw bytes and tag-stripped text of all 313 bodies, all 13 PDFs, and three separate renderings of the loyalty PDF (-layout, plain, -raw). Positive controls: 'HungerRush' 3,888 token hits over 272 of the 313 bodies; 'loyalty' 389 in the guide. 'referral' = 3 hits in ONE document and ALL THREE ARE POISON AND OUT OF SCOPE: they are in the release-note article titled 'Menufy' (id 30742847136909) and describe Google's own product - 'Google Food Ordering transition to Google Referral Service... We've updated all restaurant feeds to provide referral URLs for Google to use'. Menufy is a separate product from HungerRush 360 POS and was excluded; note for the next reader that this article is FILED in the HungerRush category, section Release Notes, so a category filter alone would not have caught it - its SUBJECT is Menufy. 'refer' as a token = 1, 'refer to' prose in a menu-groups article; in the PDFs tokenised 'refer*' resolves to 'name as your company refers to it' and 'QUICK REFERENCE GUIDE'. 'refer a friend', 'invite', 'referral code' = 0 in all three modes. In the loyalty guide 'referral' reads 0/0/0 (token/stem/squash) in all three renderings, so pdftotext word-splitting manufactured no false zero. POISON IN THE SQUASHED PROBE ITSELF: squashed 'refer' returns 283 over the PDFs and 440 over the KB because it matches inside 'preference' and 'preferred' - the squashed instrument must never be read alone. The vendor's live marketing agrees: www.hungerrush.com/products/loyalty/ and the payment-processing and pricing pages, all retrieved 200 on 2026-09-15 (16,776 characters of stripped text combined), contain 'referral' 0 times against 'loyalty' 25. https://support.hungerrush.com/hc/article_attachments/25386044668813 · retrieved 2026-09-15 adversarially verified

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

CLAIM TESTED: issues an Apple Wallet or Google Wallet loyalty pass with a push-updatable balance, as an alternative to requiring a branded app download. FINDING: HungerRush's documented answer to the same problem is the opposite one - the balance lives inside the operator's branded HungerRush mobile app, and guest identity is carried as an in-app barcode of the Loyalty Membership ID. SOURCE, re-fetched and re-extracted by the verifier on 2026-09-15: 'HungerRush Loyalty Version 1 - USER GUIDE', PDF attachment https://support.hungerrush.com/hc/article_attachments/25386044668813, anonymous HTTP 200, 5,430,744 bytes, MD5 62db9a2014bec1fd6b258ae2888f68e3, footers '(c)HungerRush2022 | Proprietary & Confidential. Updated August 11, 2022', attached to 'User Guides' (https://support.hungerrush.com/hc/en-us/articles/25386068078093-User-Guides, category HungerRush, section Loyalty). The guest-facing loyalty surface is a numbered UI reference table, pp.119-121, under the heading 'HungerRush Mobile Apps - My Reward Account', with exactly nine elements: My Reward Account, Acct Status, My Rewards, Scan Loyalty, Available Points, Active Point Rules, Active Reward Rules, Available Rewards, Loyalty Barcode. QUOTES: 'Click Scan Loyalty to bring up the barcode. Employees at the store can use this to expedite loyalty lookup by scanning the ID on a Honeywell USB MS7580 barcode scanner'; 'The Loyalty Barcode is a representation of the customer's Loyalty Membership ID and can be used for a manual key entry lookup or in concert with a barcode scanner'; and the balance is shown in-app rather than pushed to a pass - 'The Available Points graphic shows the customer a progress bar with their current account point total, the number of points required for the next reward, and a metric for 50% completion.' The guide opens by describing the whole program as 'a card-less solution that communicates seamlessly across all HungerRush ordering platforms in real time', and the operator-side Admin Portal settings it enumerates (Loyalty Header, Loyalty Terms, Barcode Text - 'a custom header for the Loyalty Barcode scan function') contain no pass issuance, no pass-type identifier and no push service. NAMED LIMIT OF THIS EVIDENCE, stated because it is the honest residual: that table enumerates a 2022 app SCREEN, and unlike the tiers and referral cells there is no 2026-dated article in this corpus that re-describes the guest app's loyalty screen, so the enumeration is un-bridged on the guest-app side. What carries the verdict past that is the completeness of the vocabulary zero, including over the vendor's live 2026 marketing, plus the demonstrated fact that this vendor documents Apple-platform integrations when it ships them - 'Apple Pay Activation - Admin Portal Activation', 2025-12-22, https://support.hungerrush.com/hc/en-us/articles/42136541899149-Apple-Pay-Activation-Admin-Portal-Activation, category HungerRush, section Online Ordering: 'Locate the Apple Pay on Website option... There is no additional fee to enable Apple Pay.' CATEGORY DISCIPLINE: HungerRush category only - sections Loyalty, Online Ordering, Printer and Print Ticket Configuration. Nothing from Menufy or RPOWER. BOUND CORPUS AND ITS FOUR KNOWN HOLES: 313 articles from support.hungerrush.com's Zendesk Help Center API (the HTML help centre 403s behind Cloudflare; the API serves anonymously), 4,032,659 bytes of body, plus 13 vendor PDFs, plus three live www.hungerrush.com pages. Verifier-re-run href fixpoint: 70 referenced article ids inside the 313 bodies, 12 absent from the listing, 10 x 404, 2 x 401, ZERO unlisted 200s; two fabricated ids returned the same 52-byte 404, so the ten are stale links. HOLE 1, the two 401s: 'Scan-to-Pay' and 'Use Menu in 3rd Party Channels' - neither is a loyalty article. HOLE 2: section 25351007766797 'Product Documentation' exists with count 0. HOLE 3: the category 'HungerRush 360 Loyalty & Rewards' is a single 2024-08-22 article reading 'Check back shortly for KB articles for HR 360 Loyalty & Rewards', so a successor loyalty module under that name is undocumented on this host. HOLE 4: 133 video embeds (128 www.loom.com, 5 www.youtube-nocookie.com) in 111 of the 313 articles, so roughly a third of this help centre's content is inside video that no text census can read - this caps what any text-only zero here can claim. CONTROLS AND POISON, run in three modes (both-boundary token, left-boundary stem, whitespace-squashed substring) over comment-stripped raw bytes and tag-stripped text of all 313 bodies, all 13 PDFs, three renderings of the loyalty PDF (-layout, plain, -raw) and the three marketing pages. Positive controls: 'HungerRush' 3,888 token hits over 272 of the 313 bodies, 389 in the loyalty guide; 'loyalty' 389 in the guide and 25 on the marketing pages. ZERO IN ALL THREE MODES, IN EVERY CORPUS: 'Apple Wallet', 'Google Wallet', 'PassKit', 'pkpass', 'passbook', 'add to wallet', 'digital wallet', 'digital card', 'loyalty card', 'membership card', 'punch card', 'rewards card', 'Google Pay'. In the 122-page loyalty guide the words apple, google and wallet do not occur at all, in any of the three renderings. THE HOMONYM TRAP THE BRIEF WARNED ABOUT IS REAL AND IS PUBLISHED HERE: 'wallet' = exactly 1 token hit in the whole KB and it is a device payment wallet, not a loyalty pass - Release Notes 06/14/2022, 'customers will be required to use Credit Card (including Mobile Wallet), Gift Card, Level Up for order payment'. 'pass' = 4 token hits, all poison ('will pass prints from one printer to the routed printer', and three of 'pass delivery fees on to your customers'); the word-boundary run correctly excluded every 'password', while stem mode raises 'pass*' to 63 hits in 29 documents and the added hits are 'password' and 'passed'. 'Apple Pay' = 31 hits in 11 articles and is a genuine capability, but it is a payment method, not a pass. The vendor's own positive vocabulary for the thing is 'Scan Loyalty' and 'Loyalty Barcode', which is what was searched instead of only our words: 'barcode' reads 8 in the guide and 7 in the KB, and the only third-party loyalty barcode in the corpus is named as somebody else's - 'Prt Punchh Barcode will print a loyalty barcode at the bottom of the receipt for Punchh Loyalty users to scan with their app' (Printer Ticket Configuration Settings, 2026-08-06). DUAL-PROBE INVARIANCE, run because pdftotext -layout can split words and manufacture a false zero: every wallet term above reads 0/0/0 (token/stem/squashed-substring) in all three independent renderings of the loyalty PDF and in all 13 PDFs, so no zero here is an extraction artefact. POISON IN THE SQUASHED PROBE ITSELF, published so it is not trusted alone: squashed 'refer' returns 283 hits over the PDFs because it matches inside 'preference'. The live marketing is in the same corpus and agrees: www.hungerrush.com/products/loyalty/, /products/payment-processing/ and /pricing/, all retrieved 200 on 2026-09-15, carry 'wallet' 0 times and describe the product as 'Design an automated loyalty program using points and rewards.' https://support.hungerrush.com/hc/article_attachments/25386044668813 · retrieved 2026-09-15 adversarially verified

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

In-product DSAR tooling exists for the operator, not only a legal@ mailbox: 'New Feature - UI to Request Deletion of PII Data, as required by CCPA. The California Consumer Protection Act requires restaurants doing more than $25M of business in California to provide a mechanism to delete consumer data, when requested. We have added a form for merchants to submit these requests on behalf of their customers (end users). Navigation: Manage > System > (Select Store) > Customer Maint > Customers > CCPA Delete Request.' Separately the POS Marketing module supports both halves of an access/erasure workflow directly: query the customer, 'Export - This button allows you to export the query results to a .csv file', and 'Delete Selected - This allows you to delete selected customer records completely from the customer database.' A parallel consumer-side path exists in the branded apps (07/12/2022: in-app account deletion request, 'up to 90 days to complete', processed by the HungerRush team). Shortfall: the RM tool is a REQUEST FORM submitted to HungerRush rather than an immediate self-serve erasure, no article states that a deletion propagates to loyalty point balances/rewards banks or to 360 Marketing and Text Marketing subscriber lists, and there is no documented data-access/portability package for a requesting guest beyond the raw CSV. https://support.hungerrush.com/hc/en-us/articles/19248747598221-Release-Notes-06-14-2022 · retrieved 2026-08-08

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

An audit trail over loyalty administration is a shipped, named report: the 11/2/2022 release notes list a fix for 'Running the Loyalty Admin Audit report for MTD/Short date range results in an error message' alongside 'Customer Points Loyalty' and 'Customer Count Loyalty' reports - graded C because the note names the report without describing its contents. A per-customer issuance cap exists for bulk unearned rewards (11/29/2022): 'A merchant cannot run concurrent campaigns for the same store or same loyalty customer. No customer will be allowed to have more than one of these rewards in their bank at a time.' Shortfall: no redemption velocity limit is documented; 'Manually Adding Points From The POS' adds points by phone/email/loyalty ID with no approval step described - manager approval is documented only for coupons ('Require Approval will stop the coupon from being applied to an order unless a manager login is logged into the POS with the Approve Coupon security enabled'), which is a different control; and nothing flags or reports employee self-redemption. https://support.hungerrush.com/hc/en-us/articles/19248740434317-Release-Notes-11-2-2022 · retrieved 2026-08-08

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

The 'Create Message' user guide (updated 2026-02-09) documents a shipped generative feature inside the campaign builder: 'You can start typing any message you want your customers to receive in the messaging window or use the AI Assistant to help you write the perfect message'; the draft field itself reads 'Start Typing or Insert {AI Prompt Here}... Use the AI assistant to help generate content quickly! Keep in mind, AI Assistant is setup to generate text messages, so all prompts will orient around that theme.' The section rationale is explicit that this is offer copy: 'The AI Assistant helps save time and ensures every message sounds on-brand', and the campaign types it drafts for are Coupon campaigns (the coupon parameters are pulled from HUB) and Engagement campaigns. The overview article lists it as a headline capability: 'Reduce effort with AI-powered drafting and streamlined workflows.' Scope note: the AI covers offer CONTENT only - audience is chosen by store selection plus an 'Extend Audience' imported list, and send timing is operator-chosen inside 9AM-7PM TCPA quiet hours with no AI recommendation; a second shipped AI feature, the Feedback 'Match My Brand' response inbox, drafts review replies rather than offers. https://support.hungerrush.com/hc/en-us/articles/38937506757645-Create-Message · retrieved 2026-08-08

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

First-party Gift Cards product in the Custom plan, plus Valutec and Givex integrations. Brand-wide cross-location redemption not explicitly documented. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

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

POS controls 'employee scheduling, communication, pay rates, and security settings' and 200+ reports include labor data, implying POS timekeeping; PIN/badge punch is not explicitly documented. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

Two independent articles state the punch identification methods and both give the same closed pair. This one: 'First at the Revention login screen enter you login code or use a fingerprint to login', and on the way out 'You will then be prompted to enter you login code or use your finger print.' Timeclock Edit opens the same way - 'Login using your code or fingerprint.' Code or fingerprint, twice, with no third option offered. 'photo', 'camera', 'selfie' and 'facial' return zero hits across all 313 articles of the closed census (API and sitemap agreeing exactly), and the Add New Employee screen is walked tab by tab in 'Adding New Employees' - General, Address Info, Driver Info, Security Info, Labor Types - with no image field and no biometric-template setting. The consequence for the second half of the claim is the reverse of favourable: the one verification method beyond a code is a fingerprint, i.e. a biometric template, and no photo-only non-biometric mode exists to fall back to. https://support.hungerrush.com/hc/en-us/articles/19248774749453-How-to-Clock-In-and-Out · retrieved 2026-09-04 adversarially verified

Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.

labor-geofenced-mobile-punch

The HUB App guide (updated 2026-07-06) is the enumeration for HungerRush's only mobile app and it is read-only by design: 'The HungerRush HUB App is a mobile application (iOS and Android) that gives restaurant operators a fast, on-the-go view of their business performance. It provides real-time access to sales, labor, orders, employee activity, and adjustments data.' Its Employees section is a viewer, not a clock - the tile shows 'X Employees Clocked In' or 'X Employees Worked' and its 'Corresponding Report: Payroll Details (Worked count) / Punch In Time (Clock-in/out activity)' - and no screen in the guide performs a punch. Punching is a fixed-terminal act throughout the corpus: 'How to Clock In and Out' begins 'at the Revention login screen' and 'Printing and Emailing Schedules in the POS' says 'Just go to the time clock'. 'GPS' returns zero hits across all 313 articles and 'geofence' returns four, every one of them delivery-zone map drawing ('click the green button below the list of zones that says Geofence, this will bring up a map that shows the physical representation of your configured delivery zones'). HungerRush now does publish a 7Shifts article, and it is a bare pointer that claims nothing for HungerRush: 'For detailed guides, how-to articles, and troubleshooting resources related to 7Shifts, please visit the official 7Shifts Knowledge Base', listing 'Time clocking and timesheets' as a 7Shifts topic - a partner's capability, not this platform's. https://support.hungerrush.com/hc/en-us/articles/46580858814477-7Shifts-Knowledge-Base-Support-Resources · retrieved 2026-09-04 adversarially verified

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

Punching is a local act on an on-premise system - the time clock is reached 'at the Revention login screen' on the station itself, 'Creating a Manual Backup' describes a local database backup, and 'Troubleshooting Printers' warns that restarting Station 1 'WILL TAKE ALL OTHER STATIONS OFFLINE', i.e. there is an in-store server that punches are written to - so a WAN outage plausibly does not touch the time clock at all. Exact shortfall: the claim requires the behaviour to be documented, and it is not. Across the closed 313-article census every offline/outage/store-and-forward hit belongs to payments or menu sync - 'Store and Forward enabled at the processor level', 'No internet connectivity. Force enabled.', and the Sync to Store warning - and none belongs to the time clock. 'How to Clock In and Out', 'Timeclock Edit', 'Allowing Early/Late Clock-in' and 'Automatically Clocking Out Employees at Close Day' are the complete documented timeclock surface and not one mentions a WAN outage, a queued punch, or reconciliation on reconnect. An operator cannot be trained on the behaviour and cannot predict whether a punch survives, so the wage-and-hour risk the claim exists to test is unaddressed even if the punch does survive. https://support.hungerrush.com/hc/en-us/articles/19248774749453-How-to-Clock-In-and-Out · retrieved 2026-09-04

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

Per-employee 'security settings' are configurable from the POS. Whether permissions are per-discrete-action and per-location, versus fixed tiers, is not documented. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

The Adjustments Detail report defines its columns as 'Reason: Reason added for the adjustment/coupon', 'Adj Time', and 'Emp/Apv Emp: Employee that applied the adjustment and the approver (if one needed)' - so voids, comps, percent-off and price edits taken through Manager Functions On The Order Screen (which forces 'enter reason for the adjustment for reporting purposed') are attributed to both the acting employee and the approving manager and are queryable afterwards, per store or aggregated. Restaurant Management additionally ships audit reports: 'Added a Timestamps & Audit Trails report for both Timeclock and Stores & Groups sections' (Release Notes 09/20/2022) and 'Added Auto Clock Time records to the Time Clock Audit report' (Release Notes 08/31/2022), plus a 'Removed Payment Audit'. Shortfall: nothing documents the trail as immutable, and the same release notes show records can be removed - 'Deleting time clock entry should have a confirmation before deleting' and 'Update record in syncrecords when a timeclock record is deleted' - with no published retention or tamper-evidence guarantee. https://support.hungerrush.com/hc/en-us/articles/39832752030349-Adjustments-Details · retrieved 2026-08-08

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

The entire evidence base is one clause: 'Control employee scheduling, communication, pay rates, and security settings across all locations.' No scheduling product page, no shift-building/availability/publish workflow, and the vendor simultaneously sells 7shifts and HotSchedules as its scheduling integrations. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01 adversarially verified

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

Via the 7shifts partner integration, not native. HungerRush's help centre carries only a pointer to kb.7shifts.com (2026-06-11); the 7shifts article 'HungerRush POS' (2026-08-12) documents that HungerRush syncs actual sales into 7shifts and that 7shifts uses those actuals to populate Projected Sales for the Labor Budget Tool, 1-2 weeks after activation and up to four weeks ahead, which is then used to build schedules against target labor percentages. Shortfalls: the forecast and the recommended staffing live in 7shifts, not in HungerRush's own scheduler; the integration is partner-led and 'may require an upgrade from your existing plan'; the HungerRush scheduler itself remains the manual, template-based one documented in the help centre. https://kb.7shifts.com/hc/en-us/articles/47411446289171-HungerRush-POS · retrieved 2026-09-03 adversarially verified

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

The HUB mobile app 'provides real-time access to sales, labor, orders, employee activity, and adjustments data', with a Labor Cost section showing 'total labor cost in dollars, labor percentage.' The RM(HUB) web Dashboard likewise displays a live 'Labor Percent' tile -- a manager view outside end-of-day/next-morning reports, matching the claim. https://support.hungerrush.com/hc/en-us/articles/46550421835149-HUB-App-How-To-and-Permissions-Guide · retrieved 2026-08-04

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

The clock-in gate is documented in full and counts minutes against the schedule, not hours against a threshold: 'Go to Config. Go to System. From here on the bottom right, the options for allowing early clock in and late clock in will be listed. Use the up or down arrows to change how many minutes you will allow employees to clock in early and or late.' The only other documented block on clocking in is a message-read gate - Creating Event Questions, 'the check box for required is enabled, this will force employees to read this message upon clock in'. Across all 313 articles of the closed census 'overtime' occurs seven times and every occurrence is a payroll report column: Payroll Details, Payroll Summary and Payroll by Labor Type each define 'OT Hours = Overtime hours worked, if applicable' and 'OT Rate = The hourly pay rate applied to overtime hours', and Payroll Details is framed as verification before payroll runs rather than prevention before hours accrue. There is no occurrence of the word in any configuration, security or time-clock article. Note that Config > System > Labor is navigated to by Creating a New Labor Type and Creating a Break Type but is not enumerated field by field in either - they name only the setting each task needs - so the finding rests on the clock-in gate article and the corpus-wide word test, not on a field enumeration of that tab. Nothing warns or blocks at the punch. https://support.hungerrush.com/hc/en-us/articles/19248798329101-Allowing-Early-Late-Clock-in · retrieved 2026-09-04 adversarially verified

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

'Creating a Break Type' documents configuring named break types per labor type, and the 'Employee Break Types' report 'helps managers monitor compliance with labor laws, track paid versus unpaid breaks.' Shortfall: no article documents a per-state/jurisdiction rules engine, required break attestation prompts, or automatic flagging of missed breaks for premium pay -- break types are a generic, operator-defined reporting construct, not a jurisdiction-aware compliance engine. https://support.hungerrush.com/hc/en-us/articles/19248772883725-Creating-a-Break-Type · retrieved 2026-08-04

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

The scheduling module is exactly two articles in the closed census and both were read end to end. Creating a schedule is a per-employee, per-day entry with no publish event and no notice clock: 'Go to Mgmt in the bottom left of the screen. Go to Employee Schedule on the right... Select Name; and select your Employee Name... Next, we will select the employees' time schedule for the day. 9a-6p. On a Sunday.' Distribution is print or email, with no versioning, no acknowledgement and no advance-notice deadline: 'The HungerRush POS System has a feature that allows an employer to print out and even email a schedule to an employee.' 'predictive scheduling', 'fair workweek' and 'predictability' return zero hits across all 313 articles. The nearest artefact is a variance report, not a premium calculation - Scheduled vs Actual Time 'compares the hours and labor costs employees were scheduled to work against the hours they actually worked... This helps managers control labor costs' - which measures the gap in dollars for the operator, not predictability pay owed to the employee. Nothing tracks an advance-notice deadline and nothing computes an employer-initiated-change premium. The named labor partners do not rescue this: HungerRush's own 7Shifts article is a pointer to the partner KB and asserts no HungerRush capability. https://support.hungerrush.com/hc/en-us/articles/19248758582157-Creating-Employee-Schedule · retrieved 2026-09-04 adversarially verified

Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.

labor-minor-labor-rules

No age-based enforcement exists on either surface the claim names. Add New Employee (30912363407629) enumerates the employee record as five tabs -- General, Address Info, Driver Info, Security Info, Labor Types -- with no documents, compliance or minor-status tab; note its text names only required fields, so the absence of a date-of-birth field is not independently established. Scheduling is a two-article module in which a schedule is typed per employee per day ('9a-6p. On a Sunday') with no constraint check, and the only documented clock-in restriction is the schedule-relative minutes-early/minutes-late window in 'Allowing Early/Late Clock-in', which is age-blind. 'minor', 'under 18', 'child labor', 'school day' and 'maximum hours' return zero hits across all 313 articles. The one labor-law feature in the product is retrospective: the Employee Break Types report 'helps managers monitor compliance with labor laws... especially useful for labor audits'. https://support.hungerrush.com/hc/en-us/articles/30912363407629-Adding-New-Employees · retrieved 2026-09-04 adversarially verified

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

Via the 7shifts partner integration, not native. 7shifts' HungerRush POS article (2026-08-12) states 'The HungerRush integration supports automated tip collection for use with 7shifts Tip Pooling. This data feeds into custom pooling rules based on hours worked, points, or percentages', with CC tips, auto-gratuity, cash tips and declared tips as sources. Shortfalls: the rule engine and the per-shift allocation are computed in 7shifts, not in the HungerRush POS or its 40-report catalog; the section sits under a heading marked 'Coming Soon' for including tips in payroll, so the payroll leg is not yet shipped; partner-led setup that may require a plan upgrade. https://kb.7shifts.com/hc/en-us/articles/47411446289171-HungerRush-POS · retrieved 2026-09-03 adversarially verified

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

Payroll Details keeps a per-employee, per-shift tip record: its columns are defined as 'Date', 'In Time', 'Out Time', 'Labor Type', 'Tips = Cash tips entered for the shift', 'CC Tips = Credit card tips received' and 'Total Tips = The combined total of cash and credit card tips', and the Employee Credit Card Tips report adds CC Sales and CC Tip % per employee and labor type. Both are exportable - Exporting Reports covers any report and the Payroll Export Report exports the labor data in a selectable format. Shortfall: this is a tips-RECEIVED ledger only. No contribution-to-pool or distribution-from-pool amount exists anywhere in the reporting surface because no tip pooling or tip-out feature is documented in the help centre at all (tip pool / tip out return no hits), so two of the three quantities the claim requires are absent. https://support.hungerrush.com/hc/en-us/articles/39832807252365-Payroll-Details · retrieved 2026-08-08

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

The payroll reports do separate cash from charged tips at shift level - Payroll Details defines 'Tips = Cash tips entered for the shift', 'CC Tips = Credit card tips received' and 'Total Tips = The combined total of cash and credit card tips', while Payroll Summary reports 'Reported Tips = Cash and Credit Card tips received' - and every row carries 'Labor Type = The role or job code worked (e.g., Insider, Driver)'. Shortfall: that job code is an operator-defined labor type created in Config > System > Labor (Creating a New Labor Type), not a Treasury tipped-occupation code, and nothing in the help centre or in the release notes through Rush Hour Updates March 2026 mentions qualified tips, W-2 Box 12 code TP or Box 14b; the documented export (Payroll Export Report) names no payroll format at all, so the carriage of an occupation code into a payroll file is unevidenced. https://support.hungerrush.com/hc/en-us/articles/39832807252365-Payroll-Details · retrieved 2026-08-08

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

No payroll product appears in the vendor's product catalog or pricing tiers; labor stops at scheduling, pay rates and reporting. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

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

'Using the Payroll Export Feature (Payroll Export Report)' documents a dedicated export: Mgmt > Reports > Employee Labor tab > Payroll Export Report, then 'Select your date range', 'Select an employee or all employees', 'Select the format your want to export the report in', click the payroll export icon and choose the file location. The underlying data is complete for payroll - Payroll Details carries In/Out times, Labor Type, Reg Hours, OT Hours, Reg Rate, OT Rate, Amt, Tips and CC Tips per shift. Shortfall: the article names no format and no destination system, and the only payroll-adjacent partner published on www.hungerrush.com/products/integrations/ is 7Shifts (category 'LABOR, SCHEDULING, PAYROLL'); no ADP, Gusto, Paychex or QuickBooks format or connector is documented anywhere in the 313-article help centre, so the claim's bar of documented formats or integrations for at least two major payroll providers is not met. https://support.hungerrush.com/hc/en-us/articles/19248750674445-Using-the-Payroll-Export-Feature-Payroll-Export-Report · retrieved 2026-08-08 adversarially verified

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

Via the 7shifts partner integration, not native. The HungerRush help centre's 7Shifts pointer (2026-06-11) directs operators to the 7shifts knowledge base for 'Scheduling and shift management' and 'Manager and employee app guides', and 7shifts' own HungerRush POS article documents the integration syncing employees, sales and labor, with published 7shifts shifts pushed to the HungerRush POS under Schedule Enforcement. Shortfalls: the swap/open-shift workflow is 7shifts' employee app, not a HungerRush surface; HungerRush's native scheduler documents only printing or emailing a manager-authored schedule; the integration is partner-led and may need a plan upgrade. https://support.hungerrush.com/hc/en-us/articles/46580858814477-7Shifts-Knowledge-Base-Support-Resources · retrieved 2026-09-03 adversarially verified

Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.

labor-digital-onboarding-i9

Hiring in this product is a five-tab form that ends at a button: 'Navigate to People > Employees > Add/Edit... When the Add New Employee screen opens, enter all employee detail you are able to complete at this time on the tabs provided' - General, Address Info, Driver Info, Security Info, Labor Types - 'Once finished adding the pertinent employee information, click ADD.' There is no documents tab, no tax-forms tab, no signature step and no verification step. 'I-9', 'W-4', 'E-Verify' and 'new hire' return zero hits across all 313 articles of the closed census, and every one of the 20 'onboarding' hits is a restaurant onboarding to a delivery or ordering integration ('The HungerRush Onboarding Team will handle most of the setup for you', Uber Direct and DoorDash Drive) or SMS billing setup - never employee onboarding. The nearest marketing sentence does not reach the claim either: the RMS data sheet's HUB bullet 'Document repository for compliance and governance' is a generic store of documents, not collection of W-4 and I-9 data and not E-Verify submission, and no help-centre article documents such a repository holding hiring paperwork. https://support.hungerrush.com/hc/en-us/articles/30912363407629-Adding-New-Employees · retrieved 2026-09-04 adversarially verified

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

'Over 200 reports to track everything from sales and revenue to labor data' implies per-employee reporting; average check, attachment rate and void/comp rate by server are not named. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

'Creating Recipes In The POS' documents a 'Batch' item type that is itself composed of other inventory items ('Pizza sauce would include Tomatoes, herbs, other ingredients') -- a sub-recipe within a recipe, satisfying the multi-level requirement. Shortfall: no article states that plate cost recalculates automatically when a component ingredient's purchase cost changes; the article only describes cost assignment at setup time. https://support.hungerrush.com/hc/en-us/articles/19248781181581-Creating-Recipes-In-The-POS · retrieved 2026-08-04

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

'Adding an Inventory Item' documents separate Order/Stock/Prep unit types per item and a 'factor' defined as 'the number of each unit contained in the yield, stock, and prep categories', and 'Unit Conversion' documents defining conversion rules between units (e.g. 12 inches = 1 foot). Together this matches purchase/recipe/count units with explicit conversion factors and a yield concept. https://support.hungerrush.com/hc/en-us/articles/19248813106573-Unit-Conversion · retrieved 2026-08-04

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

CLAIM: per-item theoretical-vs-actual usage variance for a count period (theoretical = sales x recipe; actual = counts + receipts; variance in units and currency). VERDICT: yes/B. NEW SURFACE: the Zendesk Help Center API attachments endpoint (support.hungerrush.com/api/v2/help_center/en-us/articles/<id>/attachments.json) over all 313 live articles returned 2,421 attachments, 51 non-image, 39 distinct PDFs. Article 25386625695245 'User Guides' (section 'Legacy POS', category 'HungerRush'; body: 'User Guides listed here are for Legacy HungerRush/Revention POS') attaches 'Reporting Guide.pdf' (6,077,960 B, sha256 801f355a...53a4fc, footer 'HungerRush2021 ... Updated September 13, 2021'). EVIDENCE, pp.164-167 'Inventory Usage Reports' -> 'Daily Inventory Usage Report': 'displays the following data for a daily counted inventory items for a specified date range' with columns 'Item Number', 'Item Name', 'Unit (Unit as counted)', 'Cost (Item Cost)', 'Beginning Dollar Amount (Previous day end count)', 'Purchase Dollar Amount (purchases during date range)', 'Xfer (Items transferred to another store)', 'Total (Beginning + Purchases - Transfers)', 'End (Ending dollar amount)', 'Actual (Total - End Count)', 'Ideal (What was rung into the POS)', 'Waste (Any bulk waste items)', 'Adjusted Ideal (Ideal + Waste)', 'Variance and Variance % (Actual - Adjusted Ideal)', 'Ideal Dollar (Adj Ideal X Cost)', 'Variance Dollar (Variance X Cost)', 'On Hand $ (End Count X Cost)'; the Weekly and Monthly Inventory Usage reports 'display the same information as the Daily Inventory Usage Report' for items counted weekly/monthly. Every conjunct: per item (Item Number/Name rows); count period (daily/weekly/monthly counted items); theoretical from POS sales ('Ideal (What was rung into the POS)'; recipes per size/modifier are documented in the help article 'Creating Recipes In The POS'); actual from counts plus receipts (Beginning + Purchases - Transfers - End Count); variance in units ('Variance', a quantity, since 'Variance Dollar (Variance X Cost)') and in currency ('Variance Dollar'). CURRENCY OF THE FEATURE: the guide is filed under Legacy POS and dated 2021, but the live 'Releases by Category' article 31480284698765 (updated 2025-02-14) fixes a defect in the same report with the same three ranges: 'There are 3 Report Range Options presented for Inventory Usage Reports, Daily Inventory, Weekly Inventory, and Monthly Inventory'. WEAKER THAN IDEAL: the column definitions are published only for the legacy (v1/Revention) POS; no HungerRush 360 / Restaurant Management guide restates them (the RM 'Securities in Restaurant Management.pdf' only grants Inventory recipe/item/count/transfer permissions). The prior note ('Neither half of the claim is documented') was written without these attachments. Retrieved 2026-09-16. https://support.hungerrush.com/hc/article_attachments/25386767287949 · retrieved 2026-09-16 adversarially verified

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

The vendor affirmatively severs the availability counter from inventory: 'Item Countdown is Independent from the inventory and the item counts in inventory do not reflect in Item Countdown.' Item Countdown is also a hand-typed number — 'Enter the current quantity of the item then it OK and you will see a small yellow box on the left side on the button. Once this hits zero you are unable to ring this up in the POS anymore' — and it 'does not work correctly for online orders and is used for in store application only'. The other 86 path, Menu Control (Set Menu Items Out of Stock), is manual checkboxes pushed on demand: 'To mark an entry as out of stock and remove it from ordering temporarily, select the checkbox next to that entry in the table', then 'use the Upload OOStock button at the bottom right to commit your changes to your other stations and online menu.' Inventory itself is documented as period-based, not event-based on sale: Explaining the Options in the Inventory Screen defines Require Daily as items that must 'be counted at the end of the day', and the only usage report ranges are Daily/Weekly/Monthly Inventory. Immediate writes are documented on exactly two non-sale paths — receiving ('Any item that gets added within the purchase order will make all the counts of that item in inventory go up') and voids ('Verify Inventory Waste for Voids ... it will automatically set the items to the waste in inventory'). Against the closed 313-article census plus 45 datasheets, sale-driven near-real-time ingredient depletion is not documented anywhere, and the one live availability counter is stated not to read inventory at all. Scored absent rather than unresolved. https://support.hungerrush.com/hc/en-us/articles/19248802268301-Configuring-and-Using-Item-Countdown · retrieved 2026-09-04 adversarially verified

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

Cross-channel 86 propagation is documented and current: Menu Control (updated 2026-07-28) marks items, modifiers and preferences out of stock and 'use the Upload OOStock button at the bottom right to commit your changes to your other stations and online menu', and an online-ordering release note dated 8.14.24 adds that 'HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd for online ordering since the last menu update' plus notification when they return, with 'a new API that allows third parties to check the current status of items marked as Out of Stock (OOS) at any time'. Shortfall: the trigger is manual. Menu Control is an operator checkbox per item/size/style, and the only quantity-driven mechanism is Item Countdown, a hand-entered par that blocks the item at zero but is 'Independent from the inventory and the item counts in inventory do not reflect in Item Countdown' and 'does not work correctly for online orders'. No article documents an ingredient-level or threshold-driven automatic 86. https://support.hungerrush.com/hc/en-us/articles/47634977612429-Menu-Control-Set-Menu-Items-Out-of-Stock · retrieved 2026-08-08

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

Each inventory item can be flagged for 'Daily, Weekly, Monthly or Prep' required counts ('more than one can be selected'), and the Inventory Screen options force those counted items before closing the relevant period -- scheduled recurring cycle counts by frequency. Shortfall: an ad-hoc spot-count-of-a-subset mode and separate, non-overwriting variance history per count are not documented. https://support.hungerrush.com/hc/en-us/articles/19248781491341-Adding-an-Inventory-Item · retrieved 2026-08-04

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

The Hub App data sheet lists among Key Features: 'Inventory Counts: Record on-the-go quantities directly from your phone.' That establishes a mobile counting surface in HungerRush's only first-party mobile app. SHORTFALL, on two of the claim's three elements: (1) no barcode or QR scanning — across the closed 313-article census the only barcode reference is receipt printing ('Prt Ord Num Barcode will print the order number as a barcode at the bottom of the receipt'), and QR appears only as Scan to Pay; (2) no offline capture or sync-on-reconnect behaviour is stated in the data sheet or anywhere in the census — the only 'offline' reference to a HungerRush client is the opposite behaviour, in Sync to Store: 'If the selected store is offline, there will be a warning reminding the user that we are unable to connect to the selected store, and the Sync Now button will be disabled.' Note also a documentation conflict: the HUB App: How-To and Permissions Guide (updated 2026-07-06), which walks every screen of the app, contains no inventory or counting screen at all — the counting feature is asserted only by marketing. Grade C accordingly. https://www.hungerrush.com/wp-content/uploads/HungerRush-Hub-App-Data-Sheet.pdf · retrieved 2026-09-04

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

Purchase Orders documents an electronic path, not just keying: 'Download Invoice: This option only applies if there is a direct Inventory Integration that's set up in Config> Business Info> Inventory Integration. This option downloads the invoice from the vendor set in that integration'; 'Upload PO ... uploads the current purchase order to the integrated platform that's configured for reporting and cost tracking'; and 'Import Invoice: Use this feature to import invoices given by the vendor to minimize the amount of input. *This will only work in .rif file formats*'. So a configured vendor integration can deliver invoices electronically and a PO can be transmitted out. Shortfall: no broadline distributor is named anywhere - the only inventory partners published on www.hungerrush.com/products/integrations/ are Craftable (INVENTORY, PROCUREMENT) and Restaurant365 (INVENTORY, ACCOUNTING), no Sysco/US Foods/PFG catalog is documented, the PO upload target is described as a reporting and cost-tracking platform rather than the distributor, and nothing describes a vendor item catalog being synced into the POS. https://support.hungerrush.com/hc/en-us/articles/19248781338765-Purchase-Orders · retrieved 2026-08-08

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

Purchase Orders documents two ways to bring a supplier invoice in without keying every line: 'Import Invoice: Use this feature to import invoices given by the vendor to minimize the amount of input. *This will only work in .rif file formats*', and 'Download Invoice ... downloads the invoice from the vendor set in that integration' where a direct Inventory Integration is configured in Config > Business Info > Inventory Integration; imported PO lines post to stock ('Any item that gets added within the purchase order will make all the counts of that item in inventory go up'). Shortfall: ingestion is limited to a structured .rif file supplied by the vendor or a pre-configured integration - no photo, PDF or emailed-invoice capture and no extraction of item/quantity/unit/price from an unstructured document is documented anywhere in the help centre, and the article's enumeration of the Purchase Order screen's bottom options (Download Invoice, Upload PO, Import Invoice, Export, Print, Delete, Copy to New) contains no capture or scan action. https://support.hungerrush.com/hc/en-us/articles/19248781338765-Purchase-Orders · retrieved 2026-08-08

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

326th, CELL MOVED unknown -> no/B, and the prior note's framing needs CORRECTING: purchasing is NOT routed outward - HungerRush 360 ships a native purchasing module, and its screens are documented field by field, which is what lets this cell close. The video enumeration run this pass (125 Loom ids from the 313 article bodies, all 125 resolved through Loom oEmbed, 0 errors) names the module's own tutorials - 'HR360-Purchase-order', 'Add-a-Vendor', 'inventory-transfers', 'Inventory-adding-units-and-conversions', 'Inventory-Recipe', 'Inventory-Options' - and each maps to its article. EVIDENCE: 'Vendors' (https://support.hungerrush.com/hc/en-us/articles/19248813367821-Vendors) is a contact record only - 'This page will display the vendors you work with/purchase your inventory from... You will fill in the fields with the information that you have for each vendor' - with no price list and no contracted price. 'Purchase Orders' (19248781338765) walks the PO screen in full: add the Vendor, add items by Item# or Item, 'The Unit field will auto-populate to whatever is set to the Order By unit in the Items section of Inventory', enter the amount ordered, 'validate the amount received in the Rec column', Post All, and 'If you are also doing Vendor Invoices, you would input an Invoice Number from the vendor at the top right'. The PO carries QUANTITIES and an invoice number; no received price, no prior price, no variance and no alert appears in the screen walkthrough, and 'Adding an Inventory Item' carries one current cost ('Enter the cost for the Order unit'). CONTROLS over the complete, re-derived corpus (313 articles / 948,472 B, count re-checked today; the 39 PDF attachments / 1,561 pages; and now the 125 video titles): 'price history' 0, 'cost history' 0, 'last cost' 0, 'previous cost' 0, 'contract price' / 'contracted price' 0, 'price increase' 0, 'price variance' 0. POISON NAMED: 'price change' = 1 article, the Menufy transaction-fee note ('we moved our default transaction rate from $1.50 to $1.75'); 'alert' = 8 articles, all KDS order/item alerts; 'threshold' = 3, all release notes about SIGNATURE thresholds and an order-total threshold. CAVEAT KEPT: Config > Business Info > Inventory Integration can upload the PO to Craftable or Restaurant365, whose own alerting is out of scope for this cell and is scored at inventory-native-not-partner. Retrieved 2026-09-18. https://support.hungerrush.com/hc/en-us/articles/19248781338765-Purchase-Orders · retrieved 2026-09-18 adversarially verified

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

Ordering is entirely manual with no suggestion step: 'The Unit field will auto-populate to whatever is set to the Order By unit in the Items section of Inventory. You will then put the amount ordered of that unit.' The only auto-population is the unit of measure and the item name. The item record that would have to hold a par has none - Adding an Inventory Item walks the inventory grid row column by column in screen order and closes with save, covering name, item number/SKU/PLU, Category, Group, 'Has Recipe?', Order/Stock/Prep unit types, order-unit cost, the factor, stock and prep storage locations and the required-count frequency, with no par, min, max or reorder-point field. Across the closed census 'par level', 'min/max' and 'suggested order' return zero hits, and 'forecast' returns zero hits in any context, so the sales-forecast-driven mode the claim requires as a minimum has no substrate. The one integration route is outbound only and does not carry pars: Purchase Orders documents a Config > Business Info > Inventory Integration whose Upload PO 'uploads the current purchase order to the integrated platform that's configured for reporting and cost tracking'; the partner named on www.hungerrush.com/products/integrations/, Craftable (INVENTORY, PROCUREMENT), is described as linking 'sales, inventory, recipes, purchasing, and invoices' with no mention of par levels or forecasting. https://support.hungerrush.com/hc/en-us/articles/19248781491341-Adding-an-Inventory-Item · retrieved 2026-09-04 adversarially verified

Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.

inventory-waste-logging

Voiding/comping a prepared item captures a reason ('for reporting purposes'), and, when the Menu tab's 'Verify Inventory Waste for Voids' is enabled, 'will automatically set the items to the waste in inventory' -- a reason-coded workflow that debits inventory. Shortfall: no report was found that states waste cost as a line item separate from usage variance. https://support.hungerrush.com/hc/en-us/articles/19248804443661-Manager-Functions-On-The-Order-Screen · retrieved 2026-08-04

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

'Inventory Transfer' documents creating a Transfer Order with a vendor/destination, item, quantity, and a Post/UnPost state that moves items out of the originating store's inventory. Shortfall: the article describes only the sending location's Transfer Order screen; a corresponding automatic entry crediting the receiving location's inventory is not documented. https://support.hungerrush.com/hc/en-us/articles/19248780998797-Inventory-Transfer · retrieved 2026-08-04

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

Store-to-store movement exists and is valued. Inventory Transfer: 'Transfers are used for moving items out of the store, usually to another store'; the destination is chosen as a counterparty — 'When creating a new transfer order, select the appropriate store/vendor from the drop-down menu' — and the line grid carries money, not just quantity: 'A list of each item on the selected transfer order is displayed, along with the item's quantity transferred, unit, cost, quantity recorded, post status and date, and total amount.' The production half also exists: Creating Recipes In The POS documents batch items — 'A batch item is something that is made in bulk for use throughout the day. (ex. Pizza sauce)'. SHORTFALL: no article ties the two together into a commissary model. There is no documented receipt side at the destination store (the transfer is one-sided, posted out of the sending store, and the receiving store is modelled as a Vendor), no production-order or issue relationship between locations, and the line cost is presented as operator-entered rather than computed — the New-transfer steps say only 'Verify the price'. 'Commissary' and 'central kitchen' return zero hits across the closed 313-article census, no report in the Report Purpose and Metric Guides covers transfers, and no article states how the transfer cost is derived from a batch recipe. https://support.hungerrush.com/hc/en-us/articles/19248780998797-Inventory-Transfer · retrieved 2026-09-04

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

Receiving captures no lot. Purchase Orders walks the entire receiving flow — vendor selection, 'You can use either Item# or the Item field to search for and input the items that was received from the vendor', the auto-populated Unit, the ordered quantity, then 'validate the amount received in the Rec column which would normally be the same number that was input in the Qty column' — and the only supplier-side identifier anywhere in it is a document-level one: 'If you are also doing Vendor Invoices, you would input an Invoice Number from the vendor at the top right.' The item master has no lot attribute either; Adding an Inventory Item's identifiers are 'the item number, SKU or PLU if any'. In this product 'batch' means a prep recipe, not a supplier lot. Across the closed census (313 of 313 articles, Zendesk API and /hc/sitemap.xml agreeing exactly, plus 45 vendor PDFs) the strings 'lot number', 'batch number', 'traceab' and 'recall' in a food sense return zero hits. A pizza-delivery POS with an eight-article inventory section that never once mentions lots is not silent-by-oversight; scored absent. https://support.hungerrush.com/hc/en-us/articles/19248781491341-Adding-an-Inventory-Item · retrieved 2026-09-04 adversarially verified

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

The Inventory screen's Options page is where a date-driven view would be surfaced and it contains only count-frequency and display settings: 'Required Counts has the options for Require Daily – requires the items marked daily on the item screen to be counted at the end of the day. Require weekly ... Require Monthly ...', then 'Display fields in count sheet sets by default the field to be checked when viewing report in Counts tab', 'This option allows for only waste items with a recipe to be shown on the waste tab', and 'To import and to export files click the ( … ) three dots'. That is the complete option list — no expiring-soon view, no rotation report. The item record has no date attribute, and receiving captures no per-line date — Purchase Orders records only Qty, Rec and an invoice number. Across the closed 313-article census 'shelf life', 'shelf-life', 'use-by' and 'expiry' return zero hits and every occurrence of expiration/expire belongs to coupons, ValCodes, text-marketing campaigns or portal password links. Scored absent. https://support.hungerrush.com/hc/en-us/articles/19248797010829-Explaining-the-Options-in-the-Inventory-Screen · retrieved 2026-09-04 adversarially verified

Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.

inventory-bar-partial-bottle

Generic multi-unit counting reaches partial containers; nothing bar-specific does. Adding an Inventory Item has the operator 'Select the unit type that is stored in the Order, Stock, and Prep locations' and set 'the factor... the number of each unit contained in the yield, stock, and prep categories', and Unit Conversion documents liquid conversions directly -- 'it can be used to break down a single large unit into multiple single use units (1 Foot = 12 inches, 1 cup = 8 ounces...)'. An item stocked as a bottle and counted in its prep unit is therefore countable as a fraction. Shortfalls: no weight-based counting -- the item record has no tare or container weight and the product's only scale is an order-entry pricing type ('Price by Weight... This Requires you to have a scale set up'); no pour-cost or variance reporting; and no bar or beverage inventory documentation of any kind -- 'pour cost' and 'partial bottle' return zero across all 313 articles and 45 PDFs, and 'liquor' returns one menu-group sequencing example. https://support.hungerrush.com/hc/en-us/articles/19248781491341-Adding-an-Inventory-Item · retrieved 2026-09-04 adversarially verified

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

MERGE CALL (330th): proposed no/B, landed partial/B. The GL-mapping conjunct is met outright (GL accounts linked to Sales, Report Categories, Coupons, Adjustments; GL Accounts Report), so a no overstates; the shortfall is that no COGS or AP export exists and the only named accounting format (QuickBooks .iif) carries payroll fields only. 330th, CELL MOVED unknown -> no/B. The prior hold rested on 'the Restaurant365 and Craftable connector payloads remain unpublished'; that hold is now answered from the other side, because the vendor's OWN accounting-export surface is fully enumerated and it is payroll-only. NEW EVIDENCE, the field list of the one named accounting format HungerRush ships: 'System Configuration Guide.pdf' (https://support.hungerrush.com/hc/article_attachments/25386797512845, attached to article 25386625695245, Updated September 13, 2021) enumerates every payroll-export target and its file format - 'QuickBooks is a payroll export option. The file format is an iif. Data includes Date, Labor Type, Employee Name, and Daily Time'; 'Advantage ... The file format is .txt'; 'Gevity ... file format is .xls'; plus Accountants World, ADP, PCS. That is a closed field list: the only QuickBooks import file the product writes carries labour hours, not COGS and not AP invoices. GL mapping DOES exist and is the one conjunct met: 'Accounting Config is used to set up General Ledger accounts that can be linked to Paid Ins and Paid Outs ... Additional General Ledger accounts can be created and linked to Sales, Report Categories, Coupons and Adjustments. These General Ledger totals will then appear on the GL Accounts Report under Cash/Adjustments reports section' (same guide p.92-96 and 'Cash Management.pdf'; carried into HUB as 'Accounting Cats (Formerly Accounting Config)', 'Comparing Restaurant Management to Legacy POS.pdf' p.25, and as a HUB security right, 'Securities in Restaurant Management.pdf' p.7) - i.e. GL totals surface as an ON-SCREEN report, never as an accounting-system import file, and 'Reporting Guide.pdf' still reads 'General Ledger Accounts are an Upcoming Feature.' BOUND: the 313-article Zendesk Help Center API census re-derived today (articles.json?per_page=100, count 313 / page_count 4, 4,032,659 B of bodies) + all 39 distinct PDF attachments (1,561 pages) + the 63-item wp `resources` corpus. CONTROLS, tokenised, case-insensitive, non-word-character boundaries, over all 348 corpora: cogs 0, 'cost of goods' 0, 'accounts payable' 0, 'journal entry/entries' 0, 'chart of accounts' 0, sage 0, netsuite 0, intacct 0, restaurant365 0, craftable 0 (both are named ONLY on the marketing integrations page, never in any product document), iif 1 (the payroll line quoted above), 'general ledger' 8 (all the Accounting-Config paragraph above), quickbooks 7 (all payroll). POISON NAMED: 'food cost' returns 4 hits and none is a costing feature - two are the same CC-tip config paragraph ('decrease labor and food cost percentage') and two are loyalty ROI arithmetic. CENSUS HOLE DISCLOSED: an href fixpoint over the 313 bodies finds 72 referenced article ids, 14 of them outside the listing; 12 return 404 RecordNotFound (deleted) and 2 return 401 (38746931822733, 40694212678285 - the second is linked from 'Printer Ticket Configuration Settings' as 'See this article for more information on Scan to Pay', i.e. payments content, not accounting). Retrieved 2026-09-18. https://support.hungerrush.com/hc/article_attachments/25386797512845 · retrieved 2026-09-18 adversarially verified

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

Inventory is native and bundled — 'all systems include restaurant management, reporting, payment processing, inventory' — but Craftable and Restaurant365 are offered as integrations, implying serious costing depth comes from partners. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

The sales-mix reports are cost-free and their columns are authoritatively enumerated: the 'Report Purpose and Metric Guides' section holds 40 articles, 38 of which carry an explicit 'Metric Definitions' list. For Menu Mix By Report Group that list is complete and reads 'Qty = Number of items sold / Total $ = Total Sales Amount before adjustments and coupons, excluding Delivery Fees / Net $ = Net Sales Amount after adjustments, coupons, and tax, excluding Delivery Fees / Sales %= Net Sales Amount divided by the Store's Net Sales.' The same four appear for Menu Mix By Group/Size, By Group/Size/Style, By Group/Size/Style/Preference and By Item/Size, and Product Mix adds only 'Avg Price = Net Sales / Total Quantity'. No cost column, no margin column, no threshold flag in any of the six. Recipe costing exists on the setup side - Creating Recipes In The POS is introduced as 'very useful for Cost management' and gives per-size and per-modifier ingredient quantities - but nothing joins it to sales mix in a report. Across the closed 313-article census 'contribution margin', 'menu engineering' and 'food cost' return zero hits, and no alerting surface of any kind is documented for cost movements, so the claim's threshold-flag half has no substrate at all. Disclosed against the finding: HungerRush documents a Config > Business Info > Inventory Integration hook whose Upload PO 'uploads the current purchase order to the integrated platform that's configured for reporting and cost tracking', and names Craftable on its integrations page as linking 'sales, inventory, recipes, purchasing, and invoices for accurate costs' - an undocumented partner route to margin reporting outside the POS. The finding is about HungerRush's own reporting surface, where the columns are enumerated and the cost is not there. https://support.hungerrush.com/hc/en-us/articles/39832800633485-Menu-Mix-By-Report-Group · retrieved 2026-09-04 adversarially verified

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

Cloud-based platform with a central dashboard and 200+ reports; a mobile app for off-premise viewing and near-real-time latency are not documented. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

'How to Close the Day' documents the nightly close procedure (batch credit cards, close all drawers/deposits), and the 'Daily Performance Report (DPR) -- Single Store' documents one report covering 'Daily Sales & Revenue, a labor summary, a payment summary, daily statistics, sales by order counts and totals by order type, sales by category, paid-ins, and paid-outs' -- matching gross/net sales, tax, tips, discounts, tender types and cash figures in one document. https://support.hungerrush.com/hc/en-us/articles/19248804394381-How-to-Close-the-Day · retrieved 2026-08-04

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

'Menu Mix By Group, Size, Style, Preference' reports quantity and net sales down to the preference level, and sibling reports break out by Group/Size/Style. Shortfall: the report family is documented at the item/size/style/preference level; a report explicitly broken out by discrete modifier (as opposed to preference) was not found by name, and daypart/revenue-center filtering on this report is not confirmed. https://support.hungerrush.com/hc/en-us/articles/39832804791565-Menu-Mix-By-Group-Size-Style-Preference · retrieved 2026-08-04

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

'Adjustments Details' documents a report of Adjustments/Coupons/Voids with 'Date, Ord Time, Adj Time... Reason... Emp/Apv Emp: Employee that applied the adjustment and the approver (if one needed)' -- attribution to both the applying employee and approving manager, with reason codes and timestamps, matching the claim. https://support.hungerrush.com/hc/en-us/articles/39832752030349-Adjustments-Details · retrieved 2026-08-04

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

'Understanding Employee/Station Cash Drawers' documents the Balance Drawer reconciliation workflow comparing counted cash to expected, and the 'Reports FAQ' directly references a 'DPR Over/Short Troubleshooting Guide' for when 'the numbers on my DPR don't look right / I am short or over money' -- confirming a per-drawer/per-employee over/short report exists. https://support.hungerrush.com/hc/en-us/articles/26957285782285-Understanding-Employee-Cash-Drawers · retrieved 2026-08-04

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

Labor data is explicitly among the 200+ reports; sales-per-labor-hour and labor % by hour/department/employee are not individually named. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

'Sales by Employee - Labor Type' reports Ticket Count, Head Count, Avg Ticket, and PPA per employee, and 'Employee Credit Card Tips' separately reports CC Tip % per employee. Shortfall: items-per-check and an attachment rate for named categories are not documented as a report metric, so the full scorecard set is only partly evidenced. https://support.hungerrush.com/hc/en-us/articles/39832838813965-Sales-by-Employee-Labor-Type · retrieved 2026-08-04

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

'Sales by Channel' reports Gross/Net/Total Sales, order count, guest count and PPA broken out by channel (POS, DoorDash, UberEats, etc.). Shortfall: no documented netting of marketplace commission/marketing fees against channel revenue to arrive at a margin-by-channel figure. https://support.hungerrush.com/hc/en-us/articles/39832823387533-Sales-by-Channel · retrieved 2026-08-04

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

'DPR -- Multi Store' is described as 'a brand level report to compare Sales, Labor, and Payment information across all of your stores at the same time' -- matching side-by-side location comparison. Shortfall: no article documents drilling from the group/brand total down through an individual location to an individual transaction within the same report. https://support.hungerrush.com/hc/en-us/articles/39832797323021-Daily-Performance-Report-DPR-Multi-Store · retrieved 2026-08-04

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

Mgmt > Marketing in the POS is a self-service query builder: it 'allows you to query the customer data base with over 40 different parameters', with a Parameters panel covering Date Range, Items ordered (item/menu group/size/style), Customer Info, Location Info (location type, zip, zone), Items not ordered, Orders and Adj/Cpn; a 'Save Query' button stores the query and its parameters under User-Defined Queries alongside seven prebuilt ones (All Customers, New, Lazy, Customers That Require Offers, Special Dates, Increasing, Decreasing); results can be printed, mapped, label-printed or exported to .csv. Shortfalls: this builder emits customer records for marketing selection, not arbitrary measures and dimensions -- the operator cannot define a new metric, pivot or grouping; and the actual reporting module (Restaurant Management vNext, ~40 named reports each with a fixed column list documented in the 'Report Purpose and Metric Guides' section) is a fixed catalog with date/store/employee filters and Excel/CSV/PDF export, with no article documenting user-created reports there. https://support.hungerrush.com/hc/en-us/articles/19248790708109-Marketing-On-The-POS-Overview · retrieved 2026-08-08

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

'Reports FAQ' documents a 'Daily Close Day Package' that emails automatically every night, configurable Report Packages with a Report Period, and an Email tab for maintaining the recipient address list -- a defined recurring cadence and recipient list, matching the claim. https://support.hungerrush.com/hc/en-us/articles/19248751177613-Reports-FAQ · retrieved 2026-08-04

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

Restaurant Management release note dated May 4, 2022: 'Reports: FTP -- The ability to establish a File Transfer Protocol (FTP) server is now available in Restaurant Management. This feature will send a file containing extensive data in a format that can be easily used to insert into a preestablished report of their own creation. Once a customer inputs their server information, Restaurant Management can be configured to send data nightly.' It is configured in Reports as a grid listing every store the user has access to, with a General tab for server credentials and the nightly-upload option, toggleable 'additional data options', a Test FTP button, and a Data Upload tab that generates an on-demand upload for a chosen date. A June 2024 release note confirms it is still live: close-day now refreshes vNext report data 'whether saving to file system or sending via email or ftp'. Shortfalls: the payload is never specified as transaction-level and no schema or field list is published anywhere -- it is described only as 'extensive data' with unnamed toggles; the only documented destination is plain FTP (no SFTP, S3, Snowflake or BigQuery connector); and delivery cadence is fixed at nightly/close-day with no documented backfill beyond one date at a time. https://support.hungerrush.com/hc/en-us/articles/19248754915469-Release-Notes-05-04-2022 · retrieved 2026-08-08

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

There is no public API. The only public evidence is one marketing sentence on the integrations page; developer.hungerrush.com returns HTTP 403 unauthenticated (re-verified by me). No endpoints, auth model, self-serve credentials, rate limits or versioning. 'Partial' credits a partner-gated portal as a public API, and contradicts the dossier's own extensibility-public-api-docs = no. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01 adversarially verified

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

325th, CELL MOVED unknown -> partial/B. HungerRush DOES emit outbound webhooks and says so in its own release notes, inside the anonymous Zendesk Help Center API census this record already rests on (313 articles, 4,078,437 B of bodies, re-derived 2026-09-17 from /api/v2/help_center/en-us/articles.json?per_page=100 over 4 pages). Verbatim, under the heading 'Third Party API 8.14.24': 'HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd for online ordering since the last menu update. Additionally, this webhook will notify when items previously marked as OOS are available again, ensuring third parties can keep menus synchronized between daily updates. HungerRush has introduced a new API that allows third parties to check the current status of items marked as Out of Stock (OOS) at any time. This new API endpoint is designed to integrate seamlessly with existing endpoints, including GetMenu and ProcessOrder'. SHORTFALL (why partial): the event class is menu availability, not the order and payment lifecycle the claim names; no retry behaviour is documented anywhere in the 313 articles (tokenised 'retry' returns 1 hit and it is retrying a DoorDash dispatch); and no payload signature scheme is documented for the webhook - the only signing mechanism named in the corpus is being retired ('a token process for Restaurant Management backend calls... effectively deprecating the old HMAC signature/IP verification process'), and it secured RM backend calls, not webhook payloads. Retrieved 2026-09-17. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-09-17 adversarially verified

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

This is a commercial-entitlement claim and HungerRush publishes no pricing of any kind. There is no developer host (three 404s), so no access tier or rate card exists to read. Across all 313 help-centre articles the only bulk data-access feature documented is the Restaurant Management FTP export (release note 05/04/2022, article 19248754915469): 'The ability to establish a File Transfer Protocol (FTP) server is now available in Restaurant Management... Once a customer inputs their server information, Restaurant Management can be configured to send data nightly.' The note attaches no fee, no entitlement statement and no tier, so it evidences neither inclusion nor upcharge. The 33 Report Purpose and Metric Guides describe report content only and never mention entitlement. Absence of a published price cannot be read as evidence of inclusion, and scoring 'no' would assert an upcharge that no source states. Unresolved. CORRECTED 2026-09-15, TWICE OVER. An earlier pass recorded the developer subdomains as 404 and inferred an absence from that. A first correction observed they return 403 behind Cloudflare and concluded the hosts exist. BOTH READINGS ARE WRONG, because *.hungerrush.com IS A CLOUDFLARE WILDCARD: nonsense-xyzzy-42.hungerrush.com resolves to the SAME A records (104.18.38.171, 172.64.149.85) as developer., developers., api., docs. and partners.hungerrush.com and returns the same ~5.7 KB "Just a moment..." interstitial. Those probes are therefore VOID EVIDENCE - they establish neither the presence nor the absence of a developer portal, and nothing may be inferred from them in either direction. What does bound the question: a domain-wide Wayback CDX sweep of hungerrush.com (5,500+ rows) holds no capture of any developer portal, so nothing public was retired. A STANDING CORPUS HOLE also caps any text-only zero on this vendor: an earlier note claimed `iframe` returns zero across the 313 articles; on raw bytes it is 266 hits in 111 articles, every one a Loom or YouTube-nocookie embed, so a large share of this help centre's real content sits inside videos no text census can read. ALSO CORRECTED: the note asserted that HungerRush publishes no pricing of any kind. It does - https://www.hungerrush.com/pricing/ (200, 285,338 B, re-fetched 2026-09-15) prices an entry tier at "3.09% + 15 cents per transaction flat rate" and carries the entitlement sentence "All systems include restaurant management, reporting, payment processing, inventory, and more." That page is NOT scored here, for two reasons: API and raw-data access appear in neither the included list nor the Custom tier's add-on list, and the add-on list closes with "and more...", making it an open enumeration that cannot carry an absence. The cell stays unknown, but on the correct ground - the published rate card is silent on the API, not nonexistent. || 320th: NEW SURFACE: legacy 'Reporting Guide.pdf' (article 25386625695245, Sept 2021) pp.172-175 documents data export inside the standard reporting module: Report Packages 'FTP tab ... used when you would like to send report results via FTP each time a report package is run', and 'The Data Upload area is used to Generate or Upload Files. These files contain general information like employees time stamps, sales by labor types and other generic information that is then store in an easy to query xml file. The process can be manually controlled and or automated to be sent to a FTP server ... Enabling Auto Upload at close of day will send a xml file to the FTP Server'; plus a FranConnect FTP/email feed. None of the 39 PDFs or 313 articles states a price, tier or add-on fee for this export or for the Third Party API. Entitlement remains unpublished; left unknown. Retrieved 2026-09-16. || 325th: 325th, NEW SURFACE, CELL NOT MOVED, same page and same defect as extensibility-api-access-cost. The live pricing page (52,372 B, 2026-09-17, nonsense control returns the 404 shell) does settle one half of the neighbouring question - reporting itself is in the entry tier: 'All systems include restaurant management, reporting, payment processing, inventory, and more', with Starter from $0/month. But API and raw-data access are not named in either the Starter inclusions or the Custom '+' list, whose integration entries are third-party ORDERING and DELIVERY connectors rather than data access, and the 'and more' clause leaves both lists open, so neither inclusion nor exclusion can be published. No per-location API fee, revenue share or enterprise-only clause appears on /pricing/, /terms/ (60,491 B, fetched with it) or /products/integrations/. Retrieved 2026-09-17. || 326th: 326th: the corpus-hole caveat carried in this note is retired - the help centre's video layer is now enumerated (125 distinct Loom ids parsed from the 313 re-derived article bodies, all 125 resolved via Loom oEmbed with title and duration, 0 failures, plus 5 third-party YouTube embeds), and tokenised over those titles api 0, partner 0, export 1 ('Payroll Export'), so no entitlement or rate-card content hides in the videos. The commercial position is unchanged: /pricing/ names no API or raw-data line in either tier and closes both lists with 'and more', an open enumeration that cannot carry an absence. Retrieved 2026-09-18. || 327th: NEW CORPUS, NO MOVE. The WordPress custom post type `resources` (63/63 items, plus the 59 PDFs they link; 758,099 chars - see extensibility-api-access-cost for the census and the `api` inside `rapid`/`capital` tokenisation trap) is the vendor's whole 2025 sales library and it contains no word-boundary `API` hit, no pricing table, no tier list and no entitlement language of any kind. The two 2025 solution two-pagers and the RMS datasheet describe reporting as a bundled capability but attach no price or tier to data access. No published rate card exists on any host, so inclusion cannot be established and an upcharge cannot be asserted. Retrieved 2026-09-18. || 330th: 330th, CELL NOT MOVED. The customer contract at www.hungerrush.com/terms/ (41,945 characters, read in full today) contains no occurrence of 'API' and no data-access fee of any kind, while it does price a $500 cancellation/rescheduling fee and hourly support rates - so the absence is not an artefact of a thin document. Separately, the vendor's data-service hosts (rpt-reportingapi-prod, rm-reporting-api, rm-reportpackages-api, posreporting.hungerrush360.com) are live to curl (/health, /robots.txt 200) but 404 at every doc path, so no tier or quota statement exists to read. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). Tokenised APIs? across all 481 docs outside designer-docs: 36 hits in 13 docs, none attaches a fee, tier or inclusion to API or raw-data access (they are release notes, loyalty/LevelUp key fields and the Menufy 'certificate we use to verify access to HR APIs'). The INFI kiosk KB prices INFI's own add-ons (SMS receipts '$10', premium slider slots), never HungerRush data access. Merge rule: an API-cost verdict needs a STATED fee or stated inclusion; neither exists. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): SwaggerHub. HungerRush's own SwaggerHub organisation, HungerRushLLC (anonymous registry listing https://api.swaggerhub.com/apis/HungerRushLLC = totalCount 2, both X-Published=true, X-Private=false), publishes two OpenAPI 3.0 specs no prior pass found (nothing in claims.jsonl or .cache mentions swaggerhub): (1) 'HungerRush Online Ordering API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 (created 2018-10-15, modified 2021-10-27): 'The HungerRush API allows you to post orders to a ReventionPOS through HungerRush', exactly three operations - POST /api/v1/order/processorder 'Submit an order object to HungerRush for validation and submission to the store', GET /api/v1/order/getmenu 'Gets the current online HungerRush menu for the store', GET /api/v1/order/getesttime; (2) 'HungerRush Loyalty API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushLoyalty/1.0.0-oas3 (modified 2022-02-28; the 'Honeycomb' loyalty module, renamed in release note 06/28/2022, 19248755436045), 14 POST operations on hub.hungerrush.com/Api/v1/Honeycomb/* (CreateOrder, CreateCustomer 'Create or Update a Customer', GetCustomerDetails, SearchCustomers, VoidOrder, Redeem, UndoRedeem, ValidateReward, ValidatePointsToAdd, AddPoints, CreateReward, IsStoreEnrolled, GetStores, GetPoints). CURRENCY: the Online Ordering spec is the live Third Party API, not a retired one - the 2024 KB release note (31480284698765, 8.14.24) names 'existing endpoints, including GetMenu and ProcessOrder', the exact operation names of this spec; and hub.hungerrush.com still routes the Loyalty API (GET /api/v1/honeycomb/GetStores = 405 'does not support http method GET', nonsense sibling /api/v1/honeycomb/zzqnope = 404 'No HTTP resource was found'). Auth in both specs: 'The API Key, API Secret, and store number are provided by Revention' / 'by HungerRush', requests signed HMAC-SHA256 over key+timestamp+store+URI+method+body (headers X-PSK, X-Stamp, X-Signature, X-Store). Three further HungerRush-named specs on a personal account (szischerk: Inventory API, Order API, Store API, 2022-06/07, X-Published=false, servers virtserver.swaggerhub.com/HungerRushLLC/* mocks and api2.hungerrush.net, which is NXDOMAIN today) are unpublished drafts and are NOT used as evidence; 'Hungerrush2/GetActivePromotions' is the SwaggerHub IoT template (POISON). Bearing on this cell: neither published API is a reporting or raw-data API (order submission, menu read, estimated time, loyalty), and neither attaches a fee, tier or inclusion statement to access (cost, plan, tier, subscription, free all 0; the only fee/price tokens are order-schema fields). Unknown. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the retired independent-operator pricing pages, now 301 to the homepage live, read from Wayback: https://web.archive.org/web/20221125162724/https://www.hungerrush.com/independent-operators-pricing/ ('Every Plan Includes Online Ordering Menu Management Inventory Management Employee Management Labor Scheduling Real-time Reporting Coupon Management Multi-store Management Caller ID Payment Processing 24/7 US Support Professional Installation'; Starter Monthly $99, Advanced Monthly $199; 'Additional hardware packages available for $99/month'), and the two form thank-you pages (20230326031555 / 20230326035527) with competitor tables (Implementation Fee $674 / $1,399 / $2,000 / $2,000; rows Terminal Bundle, Delivery & Curbside, Online Ordering, Branded Website, Real-Time Reporting, Loyalty, Marketplace, Google Page, Automated Marketing, Customer Support). Word-boundary API 0 and 'integration' 0 on all three (only 'fully integrated' in a testimonial). VERDICT: unknown. 'Real-time Reporting' is included in every plan, but that is the reporting UI, not API/raw-data access; no API or data-export line is priced or included. Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: no entitlement statement for API or raw-data access exists in any spoken or text layer. Unknown. Retrieved 2026-09-18. adversarially verified

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

Pricing page states all systems include reporting, so basic reporting is in the $0 Starter tier; whether PMIX, comps/voids audit and multi-location comparison are also included is not documented. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

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

The claim's operative verb is 'Documents a historical retention window of at least 24 months', which makes this a publication question, and the publication surface was measured: 313 of 313 help-centre articles (Zendesk API and /hc/sitemap.xml agreeing exactly), all five www sitemaps, 45 PDFs, /terms/ and /terms-of-use/. No article and no www page states a retention window, a truncation or roll-up policy, or an archive-retrieval fee; 'retention', 'archive' and 'how far back' return zero relevant hits corpus-wide. The place a retention commitment would live was read and points the other way: the Terms make archiving the merchant's obligation - 'appropriate measures are implemented to properly and securely back up and archive data from the Products and Services on a periodic basis' - and disclaim it for the vendor, 'you are solely responsible and the Company has no responsibility for: a) properly and securely backing up, archiving and storing information and data that is captured, stored or transmitted by the Products and Services.' The three statements that bear on retention all fall short of 24 months of transaction-level detail: the RM(HUB) Dashboard's '13 Month Sales is a graph showing sales monthly for 13 months of sales'; the Sales Summary guide's 'Last Year Net = Comparative net sales for the same day and same week of last year'; and Order Lookup's 'you can look up current days orders or past orders, by selecting the date from the drop down menu' with no stated floor. Documented caps are on range length, not age - 'up to 31 days of data at once'. None of the 40 Report Purpose and Metric Guides states a retention limit. https://www.hungerrush.com/terms/ · retrieved 2026-09-04 adversarially verified

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

Operator-facing configuration against a closed 313-article census plus 45 datasheets. 'anomaly' and 'unusual' return zero hits and all three occurrences of 'threshold' are payments settings (signature-capture dollar threshold, the Force CC 'order total threshold', the merchant-slip signature threshold). The only push mechanism in reporting is Report Packages, which the Reports FAQ documents as unconditional and scheduled: 'Under Selected Package, select the Daily Close Day Package that you have set to run every night' and 'Select the Report Package in the dropdown list next to Selected Package. Select your email address in the dropdown list under Email Address and click the Add > button.' Nothing conditions delivery on a value. Every other notification is event-driven on a customer or operational action, not a metric breach: the CC Manager login notice for unbatched card batches, the Feedback survey email, Order Notifications texts to consumers, and KDS ticket-age colouring. The one threshold-triggered notice anywhere in the corpus is a single defect line, 'Max Cash Alert was not working' - an on-screen cash-drawer safety prompt with no configuration article, not a push or email on a reporting metric. The HUB App guide enumerates every app screen and states 'The Settings tab allows you to log out of the app and sets your preference for Dark Mode, Light Mode, or the same as your phone's settings' with no alert configuration. Of the 40 Report Purpose and Metric Guides, 38 carry an explicit Metric Definitions column list and not one defines a threshold, flag or exception column. https://support.hungerrush.com/hc/en-us/articles/19248751177613-Reports-FAQ · retrieved 2026-09-04 adversarially verified

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

'natural language' and 'machine learning' return zero hits across all 313 articles and all 45 PDFs. Reporting is delivered as a fixed named grid-report set plus the HUB mobile dashboard, and both surfaces are now fully enumerated: I read all 33 Report Purpose and Metric Guides, each of which is a fixed 'Report Purpose / PDF Example / Metric Definitions' template with a closed column list (e.g. Sales by Hour: 'Hour... Order Count... Net Sales... Labor Hrs = Total number of labor hours scheduled/used during that hour... $/Hr = Net sales per labor hour'), and the HUB App guide, which enumerates every screen of the mobile app and its RM report equivalent and describes its Settings tab as offering only logout and Dark/Light mode. Neither surface contains a question box, assistant, copilot or generated chart; the only chart documented is a fixed one ('The below graph shows order volume by day for all stores selected', Order Details 39832819594893). Every AI reference in the corpus is OrderAI / OrderAI Talk, an AI phone- and text-ordering agent that takes guest orders, not a data-query assistant. Operator-facing feature, closed census, silent - scored absent. https://support.hungerrush.com/hc/en-us/articles/46550421835149-HUB-App-How-To-and-Permissions-Guide · retrieved 2026-09-04 adversarially verified

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

Central customer dashboard with order history and loyalty status, and loyalty 'identifies repeat orders'; new-vs-returning counts and lifetime-spend cohorts are not documented as reports. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

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

The 'Report Purpose and Metric Guides' section holds 40 articles and 38 carry an explicit 'Metric Definitions' column list; the DPR - Single Store guide goes further still, a numbered field-by-field breakdown with table-level derivations. Every metric in every one is realised or comparative, and 'forecast' and 'projection' return zero hits across all 313 articles. The nearest report is Scheduled vs Actual Time: 'The Scheduled vs. Actual Time Report compares the hours and labor costs employees were scheduled to work against the hours they actually worked... Scheduled Hours = The total number of hours the employee was scheduled to work' - it grades a manually built schedule against punches; it does not generate one from projected demand. The strongest forward-looking metric in the set is Sales Summary's 'Last Year Net = Comparative net sales for the same day and same week of last year', which is history. Contradicting marketing exists and is disclosed rather than relied on: the Business Management Solution datasheet bullets 'Forecast labor needs based on sales & historical data', two buyer's guides say 'Labor management--efficiently create and manage schedules and forecast labor needs to meet budget', and www.hungerrush.com/products/integrations/ attributes labor forecasting to the 7Shifts integration, 'streamline scheduling, payroll, and labor forecasting'. Those are marketing claims about a labor forecast, one of them belonging to a named partner, not a forward sales forecast at daypart or hourly granularity exposed in the reporting UI. https://support.hungerrush.com/hc/en-us/articles/39832870284941-Scheduled-vs-Actual-Time · retrieved 2026-09-04 adversarially verified

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

Payroll Details/Summary/by Labor Type reports separately show 'Tips' (cash) and 'CC Tips' (credit card) fields per employee per period, and Reg/OT hours and rates for payroll. Shortfall: no documented tip-pool distribution detail (no tip-pooling feature itself was found -- see labor-tip-pooling-rules) and no jurisdictional tax-liability summary for tips. https://support.hungerrush.com/hc/en-us/articles/39832807252365-Payroll-Details · retrieved 2026-08-04

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

Three named tiers exist as first-class objects. The Feedback 'Monitoring Performance' article: 'As a Brand Admin you can monitor total responses of all locations and groups under the brand', with an explicit Store/Group toggle -- 'Store: Visibility into all locations under the brand'; 'Group: Visibility into all Groups under the brand and the total responses associated with all the locations nested inside the group' -- and group-level averages in the Total Stores Table; the Inbox article adds 'Groups & Stores: Filter by designated groups & stores ... This filter will dynamically update the stores nested inside of individual groups.' In Restaurant Management the same grouping is administered at 'Manage > Stores & Groups' (release notes 05/04/2022 and 09/20/2022, the latter adding a broadcast message 'to all stores in a group' and a Timestamps & Audit Trails report for the Stores & Groups section), permissions are scoped by tier via Company Admin versus Store Admin roles ('Store Admin can view the menu and override pricing for stores they are associated with, but cannot edit and change the brand-level default pricing'), menus carry a brand-level default price with per-store override, and coupons can be brand-offer or per-Franchisee-Group. Shortfalls: the sales reporting surface is not group-aware -- the HUB App store selector is a flat checkbox list of stores ('check the boxes next to each store you want to include') whose drill-ins produce a 'By Store' breakdown, and the DPR -- Multi Store is described as 'a brand level report to compare Sales, Labor, and Payment information across all of your stores', with no documented region/group rollup or group filter in any of the 40 report guides. https://support.hungerrush.com/hc/en-us/articles/32067274937229-Monitoring-Performance · retrieved 2026-08-08

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

Upheld and slightly strengthened: 'Multi-location menu management' appears verbatim on the online-ordering page. Still no publish/version history, no override model, and a multi-store reviewer complaint pointing the other way. https://www.hungerrush.com/products/online-ordering/ · retrieved 2026-08-01 adversarially verified

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

'Menu Security: Company Admin and Store Admin' documents that the Store Admin role 'can view the menu and override pricing for stores they are associated with, but cannot edit and change the brand-level default pricing' -- while Company Admin 'has full access to Menu Editor, Pricing, and Syncing to Stores.' A per-field override model: price is store-editable while other menu attributes remain corporate-locked. https://support.hungerrush.com/hc/en-us/articles/38746875117453-Menu-Security-Company-Admin-and-Store-Admin · retrieved 2026-08-04

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

'Individual Store Price Override' documents overriding the brand-level default price for a specific store without duplicating the item record ('When brand-level default prices change, they will not affect the store price override'), and the same Pricing section separately supports Time-Based Pricing -- matching per-location and per-daypart pricing without item duplication. Per-order-channel price variance specifically was not separately confirmed. https://support.hungerrush.com/hc/en-us/articles/38746480618765-Set-Up-Pricing-Setting-Brand-Default-Price-and-Individual-Store-Price-Override · retrieved 2026-08-04

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

The Menu tab's 'Start Date' and 'Expiration Date' fields schedule when an entire menu version activates/deactivates, and 'Sync to Store' pushes the change to selected or all subscribing stores. Shortfall: no article confirms interpretation in each store's own timezone, and no rollback-after-activation mechanism is documented -- 'Sync to Stores' only shows In Progress/Success/Failed status, not a revert action. https://support.hungerrush.com/hc/en-us/articles/19248779094413-Menu · retrieved 2026-08-04

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

'Getting Started: Create or Copy Menu' documents creating a new store's menu by copying 'from an existing store menu' or 'from an existing menu' rather than building from scratch. Shortfall: this covers only the menu; cloning the full store configuration template (taxes, roles, printers, tenders) and a published expected time-to-open are not documented. https://support.hungerrush.com/hc/en-us/articles/38715670283661-Getting-Started-Create-or-Copy-Menu · retrieved 2026-08-04

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

Company Admin vs Store Admin roles are documented for menu/pricing permissions, and the Feedback platform's 'Dashboard Overview' documents a Brand > Group > Manager visibility hierarchy where 'Managers are nested inside of Groups to allow a user visibility into several locations but not the full Group Level.' Shortfall: neither article establishes that a franchisee tenant owns its own employees, banking, or labor data separately from corporate visibility -- the documented hierarchy is a viewing/editing permission model, not a distinct-legal-entity tenancy model. https://support.hungerrush.com/hc/en-us/articles/38746875117453-Menu-Security-Company-Admin-and-Store-Admin · retrieved 2026-08-04

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

'The Sales and Royalties Report shows total sales performance for each store and calculates royalties and advertisement contributions owed, for stores with a configured Royalty or Advert Rate ... giving operators and franchisors visibility into financial obligations.' Its metric definitions fix the basis: Gross Sales = Total Sales less Adjustments and Coupons; 'Net Sales = Gross Sales minus Tax; represents the taxable royalty base'; 'Royalty = The calculated franchise royalty fee based on Net Sales'; 'Adv = The calculated advertising fee based on Net Sales.' Release notes confirm it is a live vNext report with Excel and CSV export (decimal-formatting fixes, 4/2024 and 5/2024). Shortfalls: the royalty basis is not configurable -- only the rate is; the report hard-codes net-of-discounts-and-comps, net-of-tax, and says nothing about excluding or including third-party-marketplace sales; and nothing documents a defined remittance schedule, automatic ACH draw, or franchisee statement generation -- the output is a report the franchisor runs, not a billing run. https://support.hungerrush.com/hc/en-us/articles/39832833801357-Sales-and-Royalties · retrieved 2026-08-08

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

'Sales and Royalties' documents a report that 'calculates royalties and advertisement contributions owed, for stores with a configured Royalty or Advert Rate' -- royalty calculation is confirmed. Shortfall: no article documents automated ACH/debit collection of the calculated amount from franchisee accounts, or a franchisee-visible charge statement; only the calculation/reporting side is evidenced. https://support.hungerrush.com/hc/en-us/articles/39832833801357-Sales-and-Royalties · retrieved 2026-08-04

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

Feedback dashboard monitors sentiment across multiple locations and marketing serves 50+ location brands, implying above-store rollup; store-vs-store ranking and variance flags are not documented. https://www.hungerrush.com/products/feedback/ · retrieved 2026-08-01

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

Menu Manager defines items once centrally and subscribes stores to a shared menu, and the Coupon Editor Glossary states 'the internal Item Name in the menu editor must be exactly identical. Item names cannot be changed without deleting and remaking an item' -- confirming a stable canonical item identity distinct from the store-facing 'Button Name', which can be renamed per store/size/style without breaking the underlying item record used for rollups. https://support.hungerrush.com/hc/en-us/articles/47045403019661-RM-HUB-Coupon-Editor-Settings-Glossary · retrieved 2026-08-04

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

The gift-card feature page offers 'digital and physical gift cards for a single site or multiple stores' with reloadable e-gift cards, i.e. a multi-store programme is sold. Shortfalls: a marketing page, not documentation; nothing states that a card sold at one store is redeemable at another; the 40-report catalog has no outstanding-liability report and the help centre has no inter-store settlement or redemption-reconciliation article; the processor-side 'Express' integration suggests balances sit with the gift-card processor rather than the POS, which is inferred rather than stated. https://www.hungerrush.com/products/gift-cards/ · retrieved 2026-09-03 adversarially verified

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

Marketed brand-wide, not documented at the profile level. The enterprise page (6+ locations) sells 'Unify your customer experience across all ordering platforms and loyalty programs, for all locations' and 'Synchronize customer data from every touchpoint', with Hungry Howie's (500+ stores) quoted on 'a fully-integrated ordering and loyalty solution that could work across all locations' and a 75% redemption rate. Shortfalls: this is a feature page, and the help centre still configures loyalty per store and issues Surprise & Delight rewards 'on a store-by-store basis'; no document states that one profile, balance and order history spans every store or how a franchisee-to-franchisee redemption is settled. https://www.hungerrush.com/enterprise/ · retrieved 2026-09-03 adversarially verified

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

'virtual brand', 'ghost kitchen' and 'multi-brand' return zero hits across all 313 articles and all 45 PDFs, and the four hits for 'concept' are 'proof of concept' and 'delivery concept'. The documented model is one menu assigned to many stores, never two brands inside one store: Brand Menu Manager 'gives you full control over creating menus for any store within your franchise... you can create multiple menus for your franchise and assign them to your various stores based on pricing tiers, regional availability, and more', and store subscription is one-directional - 'you will see all individual stores in your group/brand listed here, and you can select which stores you want to subscribe to the new menu'. Receipt identity is singular per store: 'Changing Company Info on Customer Receipts' says 'The business info located in the sample picture above is pulled from the business info section in the POS located in config then Business info' - one Business Info record per POS. On the reporting side I read all 33 metric guides: the available breakdown dimensions are order type, channel, category/report group, daypart, employee, zipcode, account, item/size/style and store - there is no brand or concept dimension anywhere, and the multi-store reports aggregate stores, not brands (Product Mix 'is a multi-store report used to analyze Menu performance across all your stores at the same time'; the DPR - Multi store 'is a brand level report to compare Sales, Labor, and Payment information across all of your stores', where 'brand' means the whole company). The closest intra-store revenue separation is the previously uncited Revenue Centers article (19248765641101): 'Configuring Revenue Centers is a great way for a site to get a systematic breakdown of sales from specific stations by order type, day part, taxes, and category... these Revenue Centers are attached to stations' - that separates revenue by station, with no separate menu and no separate receipt branding, so it does not satisfy the claim. https://support.hungerrush.com/hc/en-us/articles/47576567131405-RM-HUB-Brand-Menu-Manager-Overview · retrieved 2026-09-04 adversarially verified

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

Multiple simultaneous taxes are explicit: 'List Each Tax Type will list out all applicable tax types on an order instead of combining them into one tax line. Example: If your store uses both a State and City tax, and this setting is Enabled, the taxes will both print as separate lines on receipts' (Printer Configuration; the same setting is described elsewhere with an 'Alcohol and Sales' example). Configuration is per store -- release notes give the navigation as 'Manage > System > Tax Types' and 'Manage > System > Business Info' with a store selector, and warn the user if a Tax Type in use by a menu is made inactive. Category-level differentiation is handled by assigning a Tax Type to every item, modifier, preference member and coupon (Items, Modifiers, Coupon Editor articles), and the Tax by Type report breaks 'gross sales, taxes, and net sales by report category and tax type (e.g., Sales Tax, DoorDash, UberEats)'. Rate can vary geographically and by channel: release notes document a 'TAX RATE BY ZONE' screen and a 'Tax Rate by Order Type' setting, and rates are stored to three decimal places. Shortfalls: no article documents tax-inclusive (tax-in) pricing as an option -- every documented receipt and report treats tax as added on top; and the only exemption mechanism documented is a per-customer tax-exempt flag on the customer record, not a per-location exemption or a jurisdiction rule table (nothing addresses prepared-food versus grocery thresholds beyond the operator hand-assigning tax types to items). https://support.hungerrush.com/hc/en-us/articles/19248778146445-Printer-Configuration · retrieved 2026-08-08

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

Restaurant Management release note dated September 20, 2022, under enhancements: 'Added a "Timestamps & Audit Trails" report for both Timeclock and Stores & Groups sections.' Change tracking also exists in the menu pipeline -- a 2024 bug note describes a 'Publish Change Log table' recording Published flags per menu PLU, and the Payroll/timeclock reports flag edited punches ('Notes = Shows if the timeclock entry was for a break or was edited'). Shortfalls, all material: the release note names the feature without describing it, so there is no documented field list, no statement of who/what/when granularity, and no export or query mechanism; its stated scope is Timeclock and Stores & Groups only -- nothing covers menu price, tax type, coupon/discount or role/permission changes, which is most of what the claim asks about; the report does not appear in the 40-article 'Report Purpose and Metric Guides' catalog at all; and no source asserts immutability. Graded C rather than B because a release note that only names a feature is not a description of the mechanism. https://support.hungerrush.com/hc/en-us/articles/19248740010637-Release-Notes-09-20-2022 · retrieved 2026-08-08

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

Scored on the claim's operative verb, 'Publishes a documented multi-location API (or data warehouse/BI export)' - a publication claim, which the measured publication surface settles; no finding is made about whether such an interface exists privately. There is no developer host: developer.hungerrush.com and docs.hungerrush.com return IIS 404s, www.hungerrush.com/developers/ 404s, api.hungerrush.com returns a 1.4KB ASP.NET default page titled 'Home Page', and every sitemap named by www.hungerrush.com/robots.txt has been walked. An API is marketed but not documented: www.hungerrush.com/products/integrations/ says 'HungerRush API provides secure, direct access to key business data, opening new opportunities for connection and insight... restaurant brands can transform their POS data into custom workflows, dashboards, and reporting', and the call to action is an 'I'm interested' lead form, not a reference. The only technical description anywhere is a release note's Third Party API section naming GetMenu, ProcessOrder and an out-of-stock status endpoint plus an OOS webhook - three named endpoints, all menu/order integration, no schema, no auth model, no location-scoping semantics, nothing transaction-level. The bulk alternative does not meet the claim either: the RM FTP export is configured per store and its payload is never described as transaction-level, and the warehouse in release notes is internal ('the vNext report data in ADX is refreshed via the RM POS agent every 5 minutes'). No documented multi-location API or BI export is published. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-04 adversarially verified

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

Terminal-enforced labor rules are documented and are store-level settings: 'Allowing Early/Late Clock-in' sets, in Config > System, 'how many minutes you will allow employees to clock in early and or late'; 'Automatically Clocking Out Employees at Close Day' adds an 'Auto Clock-Out Employees on Close day' checkbox in the same screen; 'Creating a Break Type' creates break types in Config > System > Labor and then enables 'Use Break Types?' per labor type, so the employee must pick a break type at clock-out; and clock-in/out and timeclock access are gated by per-labor-type securities (Config > Security > Choose Labor Group). Overtime is modelled with daily and weekly OT (a 2024 fix: 'Weekly OT when Daily OT is active should only consider Regular Hours worked when calculating Weekly OT') and surfaces as OT Hours/OT Rate in Payroll Details and Payroll by Labor Type. Shortfalls: overtime is calculated for payroll after the fact, not blocked or warned at the terminal; nothing enforces a required break after N hours -- break types are a reporting and selection construct; predictive-scheduling compliance (advance-notice, clopening, change premiums) appears nowhere in the corpus; and every one of these settings lives in an individual store's Config > System, with no documented way to define a labor policy once on a group or region in Restaurant Management and push it down. https://support.hungerrush.com/hc/en-us/articles/19248798329101-Allowing-Early-Late-Clock-in · retrieved 2026-08-08

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

The station software is a Windows desktop application running on commodity PC hardware, evidenced repeatedly in support articles rather than asserted in marketing: 'When adding a new printer you will need to link it to an existing printer installed in windows (installed in "Devices and Printers")' and 'set the default windows printer' (Printer Configuration); 'you may need to be logged into the Revadmin windows account for this to work' (Troubleshooting Printers); printers attach by 'COM 1-4 or USB' or Ethernet; the cash drawer is opened by running POPCD5685.exe; and 'Error Fix - Reboot and Select proper Boot Device' walks the user through a standard PC BIOS boot-order screen. So the software does not require a proprietary embedded terminal. Shortfalls: no HungerRush page states that an operator may buy a PC or tablet from a third party and install on it, and no minimum spec, model compatibility list or self-install procedure is published; the commercial model runs the other way -- www.hungerrush.com/products/hardware/ says 'With HungerRush, your hardware is included in your monthly subscription', and www.hungerrush.com/terms/ (updated April 27, 2026) states that 'all equipment, hardware, software ... belong to the Company and are provided to you to use on a subscription basis'. New printers must be configured by HungerRush Support ('contact HungerRush Support for assistance with configuring a new printer with a station'), which suggests the same for stations. https://support.hungerrush.com/hc/en-us/articles/19248778146445-Printer-Configuration · retrieved 2026-08-08

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

One client OS pair is named outright: 'The HungerRush HUB App is a mobile application (iOS and Android) that gives restaurant operators a fast, on-the-go view of their business performance' (updated 2026-07-06). The POS station OS is Windows, established indirectly but unambiguously by support articles -- linking POS printers to printers 'installed in windows (Devices and Printers)', the 'Revadmin windows account', 'set the default windows printer', a .exe cash-drawer command, and an article on recovering a station from a Windows boot-device error. Restaurant Management and the Online Ordering Admin Portal are browser-based. Shortfalls: this is documentation-by-implication, not a supported-platform statement -- no article or page names a Windows edition or version, an iOS/iPadOS or Android minimum, a browser matrix for RM, or any device spec (CPU, RAM, screen size, storage), and www.hungerrush.com/products/hardware/ lists devices (POS terminal, POS tablet, KDS with bump bar, Citizen printer, Lane/3000 reader) without naming an operating system at all. The KDS 'control box' OS is nowhere stated. https://support.hungerrush.com/hc/en-us/articles/46550421835149-HUB-App-How-To-and-Permissions-Guide · retrieved 2026-08-08

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

First-party POS Tablet, water-resistant, for tableside order and payment. No drop rating and no IP ingress rating are published. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

'8 full hours of battery life' is a marketing bullet on a product page, not a published spec sheet, and hot-swap is explicitly absent. Scoring 'documented' off a marketing page inverts the evidence hierarchy. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01 adversarially verified

Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.

hardware-handheld-lte

325th, CELL MOVED unknown -> no/B. The claim needs a DOCUMENTED cellular fallback, built in or vendor-supplied. BOUND, two corpora: (a) the complete anonymous Zendesk Help Center API census - 313 articles, 4,078,437 B of bodies, re-derived 2026-09-17 - in which TOKENISED \bLTE\b, \b4G\b, \b5G\b, \bSIM\b, \bhotspot\b and \bwi-?fi\b all return ZERO; (b) www.hungerrush.com/products/hardware/ fetched today (52,801 B, nonsense control /zzq-nope-control/ returns the site's 404 shell at 46,628 B), which describes the handheld as 'The point of sale in the palm of your hand. Our POS tablet is a mobile extension of the HungerRush POS system, so you can do everything you would in the POS, on the go. Take orders and payments tableside' and names no connectivity option at all. CONTROL POISON, and it is severe here: a naive substring search for 'LTE' returns 292 hits in the KB and 3 on the marketing site, and every one is inside 'alter', 'altered', 'alternative' or 'filtered' - tokenising takes it to zero. The one cellular reference in the whole corpus is about the guest's and driver's phones, not a handheld: 'Both the driver and guest need an active internet or cellular connection to complete payment. If service isn't available, the driver can accept cash instead' (Scan to Pay). Retrieved 2026-09-17. https://www.hungerrush.com/products/hardware/ · retrieved 2026-09-17 adversarially verified

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

'Forcing Credit Cards is a method to be able to accept Credit Cards when the internet has failed and without verifying availability of the funds against the credit card processor at the time of the transaction' -- the operator hits Force, keys any 4-digit approval code, and 'These transactions will be stored, and will need to be manually batched from each station'. Setup requires 'Store and Forward enabled at the processor level'; forcing is gated by a per-employee or per-labor-type 'Force Credit Cards' security; and the TriPOS variant adds an Auto Force toggle, a configurable test site the POS pings 'if it detects a loss of connection', and 'the amount of time that Revention will try for a connection before rolling over to force mode'. The vendor also states the risk plainly: 'HungerRush does not suggest forcing credit card transactions', it will not reimburse failed forced transactions, forced cards get no pre-authorization and may decline at batch, and forces are held only up to 72 hours. www.hungerrush.com/products/hardware/ claims the capability at the marketing level: 'Shorten disruptions and downtime with offline operations mode.' Shortfalls: card auth is the ONLY degradation the vendor documents. No article states which other functions survive an outage -- kitchen printing, cash tender, loyalty and customer lookup, refunds, deferred/online order intake and Restaurant Management sync are each described only in the connected case, and the RM sync articles show the opposite behaviour for cloud features ('If the selected store is offline ... the Sync Now button will be disabled'). So there is no published degradation matrix, and the claim's 'documents explicitly which functions degrade' is met for payments only. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-08

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

First-party KDS with bump-bar interface and automated dish sequencing and timing, sold as HungerRush hardware and bundled in the Custom plan. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

No kiosk in the first-party hardware catalog; kiosk is supplied by integration partner INFI. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

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

No lane hardware and no lane timer. www.hungerrush.com/products/hardware/ (re-fetched 2026-09-04) markets five devices -- POS terminal with optional rear display, POS tablet, KDS with bump bar, Citizen printer, Lane/3000 card reader -- with no outdoor menu board, confirmation display, speaker or headset; the three published spec sheets (6100, KDS, P400) are those same indoor devices. The page is a selling catalogue rather than a supported-hardware matrix, so the decisive evidence is the report set: all 40 Report Purpose and Metric Guides were enumerated and speed-of-service measurement exists only for delivery (Delivery Out-The-Door Time, Driver Delivery Details) -- there is no lane or order-timer report, which is the claim's documented-timer requirement. Across all 313 articles 'drive thru' appears four times and every one is a software label (an order-type prompt, a station excluded from checks, a KDS Order Display filter). The corpus's only order-confirmation-screen sentence is buyer-education advice in the Restaurant POS Buyer's Guide, not a HungerRush capability. https://www.hungerrush.com/products/hardware/ · retrieved 2026-09-04 adversarially verified

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

Ships a Citizen printer with USB/Serial/Ethernet — a third-party manufacturer, so not vendor-branded-only. But no multi-manufacturer ESC/POS compatibility list (e.g. Epson, Star) is published. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Cash drawer, credit card reader and optional customer/rear display are catalogued. No barcode scanner, no by-weight scale, no multi-drawer support, and no published compatibility list. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Card entry is on an Ingenico Lane/3000, a PCI PTS-listed pinpad, described as 'PCI compliant'. No validated P2PE listing reference and no merchant SAQ type stated. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

HungerRush's own answer to the reader-less contactless question is the guest's phone, not the staff's, and the article says so where the capability would have to be stated. Scan to Pay's FAQ asks 'Do I need special hardware?' and answers 'No. Scan to Pay works with your existing printers and the Driver Track app. Guests simply use their own smartphones to scan and pay', and then classifies the result as 'card-not-present transactions because the payment happens on the guest's device rather than at a physical terminal'. Card-present acceptance in the documented stack runs through a dedicated reader: the hardware catalog's Lane/3000 'taking all payment types and methods through insert, tap, or swipe' and the P400 spec sheet's 'PCI PTS 5.x approved' EMVCo L1 contactless unit with two SAM slots. Across the closed census -- 313 of 313 articles, 45 PDFs, the 43-URL page sitemap, and the 2024-2026 release notes read through March 2026 -- 'Tap to Pay on iPhone', 'Tap to Pay on Android', softPOS and NFC acceptance on a staff device occur zero times, and NFC appears only as a payment type the RPS gateway processes. https://support.hungerrush.com/hc/en-us/articles/40694219875981-Scan-to-Pay · retrieved 2026-09-04 adversarially verified

Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator

hardware-pricing-transparency

No hardware price is published per SKU anywhere; hardware is folded into an unpublished monthly subscription figure. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Hardware page states equipment is 'included in your monthly subscription' and warranty is 'covered by your service agreement'. No outright-purchase alternative is offered or priced publicly. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

HungerRush Terms and Conditions, last updated April 27, 2026 (the URL that resolves: /terms-of-service/ 404s). 'Unless the Agreement provides otherwise: a) all equipment, hardware, software, training, programming, and other products and services that you receive from the Company (the "Products and Services") belong to the Company and are provided to you to use on a subscription basis; ... c) the Company shall, at all times, retain exclusive ownership of the Products and Services, and shall enjoy all rights incident to such ownership (including the right to inspect, exchange and take possession of the Products and Services); ... f) the initial term of your agreement shall be 4 years'. On revocation the Company is entitled to 'b) disable all Products and Services you are using; c) enter any premises where the Products and Services are located and take immediate possession thereof, without notice to you, and without a need to make a demand or obtain any court order'. The only return path is a 30-day window after delivery, at the operator's expense, with a '20% of the list price' usage and return fee if the unit shows use. OrderAI Talk carries an explicit lock: 'you shall not use OrderAI Talk with any point-of-sale other than a system that you acquire from the Company.' So the premise of the claim does not hold -- hardware is not purchased, title never transfers, and the vendor reserves both remote disablement and repossession. Recorded as no rather than partial because the ownership clause is unconditional, not a limitation on an otherwise-present capability. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

Warranty coverage is asserted ('covered by your service agreement') but no warranty term and no advance-exchange turnaround time are published. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.

hardware-byod

Driver-side only, and without a documented device-security model. HungerRush's two staff apps are distributed through the public App Store and Google Play (the developer pages list exactly Driver Track and HUB Mobile as staff apps); the Driver Track listing describes 'an app used by your delivery drivers to receive all order and customer information along with turn-by-turn navigation', it collects location, and the Scan to Pay article has guests pay by scanning a QR code 'from the Driver Track app', so drivers collect payment on a phone that leaves the store; a Play reviewer (May 2025) complains about having to risk their own phone. Shortfalls: no article states the app is supported on personal devices or documents enrolment, PIN, remote wipe or session policy; there is no order-entry or card-acceptance app for a personal phone; HUB Mobile is a reporting app with two permissions, not an ordering surface. https://play.google.com/store/apps/details?id=com.hungerrush.hungerrushdeliverydriver · retrieved 2026-09-03 adversarially verified

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

'Troubleshooting Printers' documents a remote 'Restart Printer' action available under Utilities (locally managed) or Tools (HungerRush HUB-managed) -- a remote-reboot capability for at least printers. Shortfall: no article documents a console showing every terminal/printer/KDS online-or-offline status, software-version visibility, or staged rollout of updates. https://support.hungerrush.com/hc/en-us/articles/19248785340557-Troubleshooting-Printers · retrieved 2026-08-04

Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.

hardware-callerid-integration

Verified verbatim on the POS page: 'Process delivery orders faster by reducing call times with integrated Caller ID.' Genuine differentiator, correctly scored. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01 adversarially verified

Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.

extensibility-public-api-docs

developer.hungerrush.com returns HTTP 403 to unauthenticated requests. The only public API description is a single marketing paragraph. No self-serve reference exists. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator

extensibility-api-access-cost

CAPABILITY/commercial-terms reading: the claim asks whether API access is included at no extra fee, not whether pricing is published. Re-fetched www.hungerrush.com/products/integrations/ on 2026-09-04: the API block reads 'HungerRush API provides secure, direct access to key business data, opening new opportunities for connection and insight' and its only call to action is 'I'm interested' - no price, no tier, no docs link. Re-fetched www.hungerrush.com/partners/ the same day: it is a channel-RESELLER page, and its plan-inclusion lines ('Free for all plans' for Payment Processing, Online Ordering, Loyalty; 'Add-on' for Voice & Text Ordering; 'With Advanced Plan Only' for Automated Marketing) enumerate resellable products, not API entitlements - the API's absence from a reseller product table is not evidence it carries a fee. www.hungerrush.com/terms/ contains no API fee provision, all 313 help-centre articles price nothing about API access, and there is no developer host (developer./docs./api.hungerrush.com and /developers/ all fail). Cost is quoted privately; neither yes nor no is available. || 325th: 325th, NEW SURFACE, CELL NOT MOVED - and the reason it cannot be moved is worth recording, because the page looks like it should settle it. www.hungerrush.com/pricing/ is live and real (52,372 B fetched 2026-09-17; the nonsense control www.hungerrush.com/zzq-nope-control/ returns the site's 404 shell at 46,628 B) and publishes two named tiers. Starter, 'Great for restaurants with one location', '*From $0 / Month', lists 'Cloud-based System, 1 POS Terminal, 1 Cash Drawer, 1 Credit Card Reader, 1 Receipt Printer, 24/7 Live Support' with '*Must meet qualification criteria' and a card rate of '3.09% + 15 cents per transaction flat rate (Including Card Present and Card Not Present transactions)'. Custom, 'Customized to your needs', adds '+ Online Ordering, + Loyalty, + Automated Marketing, + Self-Serve Website Editor, + 3rd Party Ordering Integrations, + 3rd Party Delivery Integrations, + Delivery Management, + Driver Track, + Gift Cards, + Ordering tablet, + Rear display terminal, + KDS and more...'. API access is named in NEITHER list, and the inclusion sentence is explicitly open-ended - 'All systems include restaurant management, reporting, payment processing, inventory, and more' - so this is not a closed enumeration and cannot carry a no; meanwhile the vendor's only public API statement (www.hungerrush.com/products/integrations/) routes through an 'I'm interested >' sales form with no price. Retrieved 2026-09-17. || 327th: THE VENDOR'S WHOLE RESOURCE LIBRARY WAS CENSUSED FOR THE FIRST TIME (327th) AND IT DOES NOT CONTAIN THE WORD API AT ALL; NO MOVE. www.hungerrush.com is WordPress and /wp-json/wp/v2/types declares a custom post type `resources` that no prior pass paged. It was fetched to 100%: 63 of 63 items (page 2 returns HTTP 400 rest_post_invalid_page_number, so 63 is the whole type), 63 HTML pages text-extracted (261,416 chars) plus every wp-content PDF they link, 59 distinct files downloaded and pdftotext'd (454,305 chars); combined corpus 758,099 chars. This set includes documents no earlier corpus held: three HARDWARE SPEC SHEETS (Kitchen-Display-System-KDS-Specifications-1.pdf, 6100-POS-Terminal-Specifications-1.pdf, P400-Credit-Card-Reader-Specifications-2.pdf), the 2025 solution two-pagers, the 360/RMS/POS/Pizza/Delivery datasheets and 2025-12 case studies. TOKENISED CONTROL, AND THE POISON IT FOUND: a naive case-insensitive substring search for `api` returns 16 hits over the corpus; EVERY ONE is inside `rapid` or `capital` - a word-boundary search (`\bAPI\b`, case-insensitive) returns ZERO. So the vendor's complete 2025-vintage sales library never once names an API, let alone prices one. `webhook` 0, `open API` 0, `integration` 186 (all marketplace/partner prose). This is a stronger absence than the prior note's, but it is still an absence of PRICING, and an unpriced capability is neither included nor upcharged. Held unknown. Retrieved 2026-09-18. || 328th: 328th: TWO ROUTES CLOSED, NO MOVE - recorded so no later pass spends time on them. (a) THE 'UNREAD MSA SETTLES COMMERCIAL CELLS' ROUTE DOES NOT EXIST HERE: /legal/, /msa/, /master-service-agreement/, /eula/, /sla/, /terms-of-service/ and /terms-and-conditions/ all return www.hungerrush.com's 404 shell (46,489-46,629 B, byte-comparable to the nonsense control /zzq-nonsense-q328/ at 46,628 B). The only live agreements are /terms/ (200, 41,865 chars stripped) and /privacy-policy/ (200). Tokenised \bAPI\b over the whole terms text = ZERO, as are 'per-location fee', 'revenue share' and 'integration fee'; the 10 'subscription' and 9 'fee' hits are billing mechanics (recurring fees, RMA restocking) with no data-access entitlement. (b) THE HUBSPOT /_hcms/search ROUTE DOES NOT APPLY: www.hungerrush.com is WordPress with Yoast (sitemap_index.xml lists post/page/resources/category/resource-category sitemaps; 84 wp-content references), and HubSpot appears only as two hs-scripts tracking tags - it is not a HubSpot-hosted site, so there is no /_hcms search index to sweep. Retrieved 2026-09-18. || 330th: 330th, NEW SURFACE, CELL NOT MOVED: the BINDING CUSTOMER CONTRACT was read end to end for fees and it never mentions the API. www.hungerrush.com/terms/ extracts to 41,945 characters of Terms and Conditions and is a real contract - it prices other things explicitly ('pay a cancellation/rescheduling fee of $500', 'will charge you an hourly fee, at the then standard rates' for support services, a liquidated-damages formula on the Processing Agreement, 'the agreed upon monthly subscription fee'). Tokenised controls over that text: api 0, webhook 0, integration-fee 0, surcharge 0; the only 'Integration' hits are the site navigation chrome. So the one document that could state an API fee states none - which is still not evidence of inclusion, because the fee schedule itself is by quote ('Products and Services are provided to you to use on a subscription basis' with the amount left to the signed order). No stated fee and no stated inclusion: neither verdict is available. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). Tokenised APIs?: 36 hits in 13 docs, zero with a price, tier or inclusion statement. NEW SURFACE (third party, grade D): the kiosk partner's Zendesk category 'Hunger Rush Onboard' (support.infi.us/hc/en-us/categories/50029294248219, 14 articles via /api/v2/help_center/en-us/categories/50029294248219/articles.json, count 14, linked from HungerRush article 47771523037837). Article 52711536878875 'How do I update my menu for a HungerRush location?': 'Your menu content - items, prices, categories, and modifiers - is managed in HungerRush ... In the INFI Console you can only choose which menus are imported here; you cannot edit the menu itself' and 'Menu changes made in HungerRush sync to the kiosk in real time via webhooks'. Also from the on-disk 2023 Throttling guide (q324 pdfall.txt, 'Updated February 16, 2023'): 'Not Supported: Mobile App, Third Party API (i.e.: OrderAi, It's A Checkmate), Next-Gen API (i.e.: DoorDash), On premise (POS)' - HungerRush runs at least TWO unpublished partner API families (Third Party API and Next-Gen API). Neither source states who pays for partner API access. No stated fee and no stated inclusion, so the cell cannot move under the API-cost merge rule. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): SwaggerHub. HungerRush's own SwaggerHub organisation, HungerRushLLC (anonymous registry listing https://api.swaggerhub.com/apis/HungerRushLLC = totalCount 2, both X-Published=true, X-Private=false), publishes two OpenAPI 3.0 specs no prior pass found (nothing in claims.jsonl or .cache mentions swaggerhub): (1) 'HungerRush Online Ordering API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 (created 2018-10-15, modified 2021-10-27): 'The HungerRush API allows you to post orders to a ReventionPOS through HungerRush', exactly three operations - POST /api/v1/order/processorder 'Submit an order object to HungerRush for validation and submission to the store', GET /api/v1/order/getmenu 'Gets the current online HungerRush menu for the store', GET /api/v1/order/getesttime; (2) 'HungerRush Loyalty API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushLoyalty/1.0.0-oas3 (modified 2022-02-28; the 'Honeycomb' loyalty module, renamed in release note 06/28/2022, 19248755436045), 14 POST operations on hub.hungerrush.com/Api/v1/Honeycomb/* (CreateOrder, CreateCustomer 'Create or Update a Customer', GetCustomerDetails, SearchCustomers, VoidOrder, Redeem, UndoRedeem, ValidateReward, ValidatePointsToAdd, AddPoints, CreateReward, IsStoreEnrolled, GetStores, GetPoints). CURRENCY: the Online Ordering spec is the live Third Party API, not a retired one - the 2024 KB release note (31480284698765, 8.14.24) names 'existing endpoints, including GetMenu and ProcessOrder', the exact operation names of this spec; and hub.hungerrush.com still routes the Loyalty API (GET /api/v1/honeycomb/GetStores = 405 'does not support http method GET', nonsense sibling /api/v1/honeycomb/zzqnope = 404 'No HTTP resource was found'). Auth in both specs: 'The API Key, API Secret, and store number are provided by Revention' / 'by HungerRush', requests signed HMAC-SHA256 over key+timestamp+store+URI+method+body (headers X-PSK, X-Stamp, X-Signature, X-Store). Three further HungerRush-named specs on a personal account (szischerk: Inventory API, Order API, Store API, 2022-06/07, X-Published=false, servers virtserver.swaggerhub.com/HungerRushLLC/* mocks and api2.hungerrush.net, which is NXDOMAIN today) are unpublished drafts and are NOT used as evidence; 'Hungerrush2/GetActivePromotions' is the SwaggerHub IoT template (POISON). Bearing on this cell: the specs say only that credentials 'are provided by Revention' / 'by HungerRush'; tokenised word-boundary over both spec JSONs cost 0, plan(s) 0, tier(s) 0, subscription 0, free 0; fee 1 and price 16 are POISON (the order schema's 'sum of subtotal, tax, and delivery fee' and item Price fields). No stated fee and no stated inclusion, so the API-cost merge rule leaves this unknown. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the retired independent-operator pricing pages, now 301 to the homepage live, read from Wayback: https://web.archive.org/web/20221125162724/https://www.hungerrush.com/independent-operators-pricing/ ('Every Plan Includes Online Ordering Menu Management Inventory Management Employee Management Labor Scheduling Real-time Reporting Coupon Management Multi-store Management Caller ID Payment Processing 24/7 US Support Professional Installation'; Starter Monthly $99, Advanced Monthly $199; 'Additional hardware packages available for $99/month'), and the two form thank-you pages (20230326031555 / 20230326035527) with competitor tables (Implementation Fee $674 / $1,399 / $2,000 / $2,000; rows Terminal Bundle, Delivery & Curbside, Online Ordering, Branded Website, Real-Time Reporting, Loyalty, Marketplace, Google Page, Automated Marketing, Customer Support). Word-boundary API 0 and 'integration' 0 on all three (only 'fully integrated' in a testimonial). VERDICT: unknown. 2022-23 retired pricing names no API line, fee or inclusion; the API-cost merge rule needs a STATED fee or inclusion, and neither exists. Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: no priced or included API line exists in any spoken or text layer. No stated fee and no stated inclusion. Unknown. Retrieved 2026-09-18. adversarially verified

The vendor publishes its partner/marketplace commercial terms (referral fee, revenue share percentage, or per-location partner fee) in public documentation.

extensibility-partner-revshare

HungerRush publishes a dollar-denominated referral fee schedule with its own Terms & Conditions on pos.hungerrush.com (reached via the advertised /customer-lead-referral path, which 302s to /pos-referral-program): 'Earn up to $2000!' -- 'Receive $500 via gift card or check when the referral attends a demo', 'Receive $1,500 via gift card or check if they become a paying HungerRush customer', 'Payment will be issued upon system installation', 'There is no cap with the number of referrals or payout', and 'Referrals must sign up for the starter package ($99/month) or greater for you to qualify the full $2,000 payout'. Shortfall: this is a lead-referral bounty open to anyone, not marketplace or integration-partner commercial terms. The dedicated partner page at www.hungerrush.com/partners/ lists only non-monetary benefits under 'Why partner with us?' ('Dedicated contact', 'Access to co-branded sales collateral', 'Partner-dedicated customer success team', 'Discounted rates') for its three partner categories (Integration, Hardware, Software) and routes applicants to a channel-team contact form; no revenue-share percentage or per-location partner fee is published for any of them. Separately, the master Terms at /terms/ disclose that a processor rev-share exists without quantifying it: 'The Company is a beneficiary of the Processing Agreement between you and any such Processor because, among other things, the Company receives payments from the Processor based upon the transactions you send to the Processor.' https://pos.hungerrush.com/pos-referral-program · retrieved 2026-08-08

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

325th, CELL MOVED unknown -> no/B. NEW SURFACE that closes this: www.hungerrush.com/products/integrations/ (63,059 B, fetched 2026-09-17, nonsense control 404) carries the vendor's only public statement about its API, and the route it offers is a sales enquiry, not a signup: 'The API That Powers What's Next. HungerRush API provides secure, direct access to key business data, opening new opportunities for connection and insight. Technology partners can deliver stronger experiences through powerful integrations, while restaurant brands can transform their POS data into custom workflows, dashboards, and reporting. Whatever your goal, our focus is helping you create the connections that matter most.' followed by a single call to action, 'I'm interested >'. There is no developer portal, no registration, no seeded test tenant. BOUND, four corpora: tokenised 'sandbox' returns ZERO across the complete 313-article Zendesk Help Center API census (4,078,437 B, re-derived 2026-09-17) and ZERO across the 25-page designer-docs.hungerrush.com corpus (276,945 B, censused in the 324th with a passing nonsense control); the crt.sh certificate-transparency listing of %.hungerrush.com (31 distinct names) holds a SANDBOX certificate but sandbox.hungerrush.com does NOT RESOLVE (NXDOMAIN, re-verified 2026-09-17); and the marketing site's own product and pricing pages offer only 'Get A Demo' and 'I'm interested'. Retrieved 2026-09-17. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-17 adversarially verified

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

325th, CELL MOVED unknown -> no/B, on POSITIVE evidence of the mechanism actually used rather than on absence. HungerRush's own release notes name the partner-API authentication scheme twice and neither is OAuth: 'This ticket will apply the decisions and patterns from previous Create proof of Concept feature to Restaurant Management back-end calls, effectively deprecating the old HMAC signature/IP verification process' - i.e. a shared HMAC signature plus an IP allowlist, being replaced by an unspecified 'token process' - and, in an incident note about a third-party ordering partner, 'Around 14 orders couldn't make it to HR POS from Menufy because the certificate we use to verify access to HR APIs expired', i.e. a client certificate. Neither is an operator-granted, individually revocable, scoped grant. BOUND: tokenised case-insensitive \bOAuth\b returns ZERO across all 313 articles (4,078,437 B) of the Zendesk Help Center API census (the publisher's own listing, re-derived 2026-09-17, every slug the record cites present in it), and zero across the 25-page designer-docs.hungerrush.com corpus (276,945 B) censused in the 324th. The only OAuth 2.0 discovery documents on any hungerrush.com host are hr-mcp and sf-mcp, which the 324th established are corporate MCP servers, not the POS. Retrieved 2026-09-17. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-09-17 adversarially verified

The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.

extensibility-webhooks-push

Under 'Third Party API' the release index states: '8.14.24: HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd for online ordering since the last menu update. Additionally, this webhook will notify when items previously marked as OOS are available again, ensuring third parties can keep menus synchronized between daily updates.' A first-party outbound push channel to third parties therefore exists and is dated. Shortfall: the only documented webhook carries menu availability, not order lifecycle -- no created, modified, paid, voided or refunded order event is documented as a push anywhere in the 313-article help centre, and there is no public API reference to check. Third parties are told to poll a status endpoint for OOS 'at any time', which is the polling pattern the claim contrasts with. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-08-08

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

CAPABILITY reading: signing, retry/backoff and replay are delivery semantics of an unpublished partner interface. Exactly one webhook is documented corpus-wide, in the 'Third Party API' subsection of support.hungerrush.com/hc/en-us/articles/31480284698765: '8.14.24: HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd for online ordering since the last menu update. Additionally, this webhook will notify when items previously marked as OOS are available again, ensuring third parties can keep menus synchronized between daily updates.' That is a statement about payload CONTENT only - it names no HMAC or signature scheme, no retry or backoff behaviour, and no replayable event log. The string 'webhook' occurs exactly once in the whole 313-article census and nowhere in the 82 www pages or 45 PDFs, and no developer host exists to carry delivery guarantees. A one-sentence release note is not an enumeration of a webhook contract. || 320th: NEW SURFACE bound: CORPUS: all 39 distinct PDF attachments returned by support.hungerrush.com/api/v2/help_center/en-us/articles/<id>/attachments.json over the 313 live articles (43 PDF attachment rows; some PDFs attached to two articles), text-extracted with pdftotext: 1,561 pages, only 6 low-text pages (all covers), so the text layer is complete; plus the 313 article bodies (comments stripped). Legacy-POS guides are dated Sept 2021; 360/RM guides 2022-2025. webhooks?|HMAC|retry|retries|backoff|idempoten* = 0 hits in all 39 PDFs; in articles only the known OOS webhook (31480284698765), the 'HMAC signature/IP verification process' being deprecated for RM back-end calls (30757777604621), and 'retry dispatching' a DoorDash driver (34696393367949). No signing/retry semantics published. Left unknown. Retrieved 2026-09-16. || 326th: 326th, CELL NOT MOVED, one more layer bound. The video layer of the help centre is now enumerated (125 distinct Loom ids from the 313 re-derived article bodies, 125/125 resolved through Loom oEmbed, 0 failures): tokenised over the titles, webhook 0, api 0, retry 0, signature 0. The single documented webhook (the 8.14.24 out-of-stock payload in Releases by Category) therefore remains the entire public record of HungerRush's webhook contract in every readable layer - text, PDF and video - and it states payload content only, with no HMAC, retry/backoff or replay semantics. ALSO PROBED THIS PASS, and it is not the partner interface: HungerRush runs two anonymous OAuth 2.1 authorization-server metadata documents, https://hr-mcp.hungerrush.com/.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource (issuer, /authorize, /token, /revoke, /register, S256 PKCE), but their resource_name values are 'Hungerrush Knowledge' and 'HungerRush Salesforce' and their scopes are the Microsoft Entra set (openid, profile, email, User.Read, offline_access) and the Salesforce set (api, refresh_token) - internal MCP servers fronting the vendor's own knowledge base and CRM, not a POS partner API; a tools/list POST answers 401 'Missing Authorization header'. Retrieved 2026-09-18. || 330th: 330th, CELL NOT MOVED. Two additions. (1) The help-centre corpus this cell's zero rests on is NOT a perfect census: an href fixpoint over the 313 re-derived bodies finds 14 referenced article ids outside the listing, of which 12 are 404 RecordNotFound (deleted) and 2 answer 401 (38746931822733, 40694212678285) - a named, two-article gated hole. (2) The vendor's live API hosts were re-probed with curl today and none publishes a spec (brandmenuapi.hungerrush360.com 401s even a nonsense path; eleven sibling *.hungerrush360.com service hosts 404 at every doc path while /health and /robots.txt answer 200). Signing, retry and replay semantics of an unpublished partner interface stay unreadable. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). Tokenised webhooks?|callbacks?|HMAC|signature|retr(y|ies)|backoff|event log|replay: the only webhook statements are the known 8.14.24 OOS payload (31480284698765) and the new third-party line below; 'HMAC' occurs once, in POS release notes (30757777604621) 'deprecating the old HMAC signature/IP verification process' for Restaurant Management BACK-END calls (internal service auth, not webhook signing); 'Event Log' is the 2021 online-ordering Admin Portal log (14 days of order events), not a webhook delivery log. NEW SURFACE (third party, grade D): the kiosk partner's Zendesk category 'Hunger Rush Onboard' (support.infi.us/hc/en-us/categories/50029294248219, 14 articles via /api/v2/help_center/en-us/categories/50029294248219/articles.json, count 14, linked from HungerRush article 47771523037837). Article 52711536878875 'How do I update my menu for a HungerRush location?': 'Your menu content - items, prices, categories, and modifiers - is managed in HungerRush ... In the INFI Console you can only choose which menus are imported here; you cannot edit the menu itself' and 'Menu changes made in HungerRush sync to the kiosk in real time via webhooks'. Also from the on-disk 2023 Throttling guide (q324 pdfall.txt, 'Updated February 16, 2023'): 'Not Supported: Mobile App, Third Party API (i.e.: OrderAi, It's A Checkmate), Next-Gen API (i.e.: DoorDash), On premise (POS)' - HungerRush runs at least TWO unpublished partner API families (Third Party API and Next-Gen API). So menu-change webhooks to partners exist, and their signing/retry/replay semantics are unpublished behind two partner API families - a capability no is not bounded (merge rule). Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): SwaggerHub. HungerRush's own SwaggerHub organisation, HungerRushLLC (anonymous registry listing https://api.swaggerhub.com/apis/HungerRushLLC = totalCount 2, both X-Published=true, X-Private=false), publishes two OpenAPI 3.0 specs no prior pass found (nothing in claims.jsonl or .cache mentions swaggerhub): (1) 'HungerRush Online Ordering API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 (created 2018-10-15, modified 2021-10-27): 'The HungerRush API allows you to post orders to a ReventionPOS through HungerRush', exactly three operations - POST /api/v1/order/processorder 'Submit an order object to HungerRush for validation and submission to the store', GET /api/v1/order/getmenu 'Gets the current online HungerRush menu for the store', GET /api/v1/order/getesttime; (2) 'HungerRush Loyalty API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushLoyalty/1.0.0-oas3 (modified 2022-02-28; the 'Honeycomb' loyalty module, renamed in release note 06/28/2022, 19248755436045), 14 POST operations on hub.hungerrush.com/Api/v1/Honeycomb/* (CreateOrder, CreateCustomer 'Create or Update a Customer', GetCustomerDetails, SearchCustomers, VoidOrder, Redeem, UndoRedeem, ValidateReward, ValidatePointsToAdd, AddPoints, CreateReward, IsStoreEnrolled, GetStores, GetPoints). CURRENCY: the Online Ordering spec is the live Third Party API, not a retired one - the 2024 KB release note (31480284698765, 8.14.24) names 'existing endpoints, including GetMenu and ProcessOrder', the exact operation names of this spec; and hub.hungerrush.com still routes the Loyalty API (GET /api/v1/honeycomb/GetStores = 405 'does not support http method GET', nonsense sibling /api/v1/honeycomb/zzqnope = 404 'No HTTP resource was found'). Auth in both specs: 'The API Key, API Secret, and store number are provided by Revention' / 'by HungerRush', requests signed HMAC-SHA256 over key+timestamp+store+URI+method+body (headers X-PSK, X-Stamp, X-Signature, X-Store). Three further HungerRush-named specs on a personal account (szischerk: Inventory API, Order API, Store API, 2022-06/07, X-Published=false, servers virtserver.swaggerhub.com/HungerRushLLC/* mocks and api2.hungerrush.net, which is NXDOMAIN today) are unpublished drafts and are NOT used as evidence; 'Hungerrush2/GetActivePromotions' is the SwaggerHub IoT template (POISON). Bearing on this cell: the published specs document HMAC-SHA256 signing only for INBOUND partner requests to HungerRush (the partner signs with the API Secret), not for webhooks HungerRush sends; neither spec defines a webhook, callback, retry/backoff or event log (tokenised word-boundary over both spec JSONs: webhook(s) 0, retry 0, retries 0, replay 0; callback 5 and HMAC 2 are POISON - the NodeJS sample's 'function callback' and the inbound request-signing recipe). The 8.14.24 OOS webhook (31480284698765) remains the only documented outbound event, still with no signing or retry statement. Unknown. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the CAPTIONS of the help centre's Loom videos, which the 326th could only title. Each anonymous share page https://www.loom.com/share/<id> embeds a signed cdn.loom.com/mediametadata/captions/<id>-1.vtt URL; GET of those VTTs for the 125 Loom ids embedded in the 313-article KB returned captions for 104 (97,672 chars; 21 have no caption track). Plus the vendor YouTube channel @HungerRush re-derived today: 26 videos + 10 shorts, captions pulled for 35 of 36 (roCqawSJ7Z4 has none). CLAIM: webhooks signed AND retried with backoff AND replayable log. VERDICT: unknown. Controls over 104 Loom captions + 35 YouTube captions: webhook 0, retry 0, signature 0, API 0; WP site search (www.hungerrush.com/wp-json/wp/v2/search?search=webhook) = 0 results. The 8.14.24 OOS webhook (31480284698765) remains the only documented outbound event, with no signing/retry statement; the unpublished partner interface still governs (327th rule). Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: webhook/signature/retry vocabulary cannot hide in the 20 silent recordings; the 8.14.24 OOS webhook remains the only documented outbound event. Unknown. Retrieved 2026-09-18. adversarially verified

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

The 'Third Party API' section names the existing endpoint set directly: a new out-of-stock endpoint 'is designed to integrate seamlessly with existing endpoints, including GetMenu and ProcessOrder'. The same release index records an incident in which 'Around 14 orders couldn't make it to HR POS from Menufy because the certificate we use to verify access to HR APIs expired', confirming externally originated orders are injected into the POS over that API in production, and third-party orders carry a 'Third Party Delivery' order-type category and appear in POS reporting (Sales by Channel). Shortfall: the API is not public -- there is no reference documentation on any host (developer./docs. 404, api. serves a Cloudflare challenge), and www.hungerrush.com/products/integrations/ gates it behind an 'I'm interested' contact form, so injection is available only to contracted integration partners. No document states that injected orders fire to KDS or kitchen printers. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-08-08

Menu items, modifiers, and prices can be written and updated via API, not just read. differentiator

extensibility-menu-write-api

CAPABILITY reading. The only public naming of third-party endpoints is article 31480284698765: 'This new API endpoint is designed to integrate seamlessly with existing endpoints, including GetMenu and ProcessOrder'. 'including' is explicitly non-exhaustive, and GetMenu is a read. The documented menu-write path in the closed census is entirely UI - the RM/HUB Menu Editor, 'Sync to Store: Push Menu Updates to Stores', the Menu Validator, and an .rmf import/export written to C:\Revention\Export - and a 2025 release entry describes 'RM Menu: Brand Menu API Work - Work includes backend architecture and API work necessary to complete a proof-of-concept demonstration', i.e. internal and non-GA. Two named endpoints out of an admittedly partial list cannot establish that no menu-write endpoint exists in a partner API whose reference is unpublished. || 325th: 325th, NEW SURFACE, CELL NOT MOVED, and the reason is now specific rather than 'no docs are public'. HungerRush's release notes name its third-party API endpoints, and the named set is read-menu / write-order: 'This new API endpoint is designed to integrate seamlessly with existing endpoints, including GetMenu and ProcessOrder' (Third Party API, 8.14.24), the new endpoint itself being a read - 'allows third parties to check the current status of items marked as Out of Stock (OOS) at any time' - alongside a 'delivery-api Dispatch Order endpoint' and a 'void API' amended 'to accept clientTransID for voiding transactions'. A menu-writing API appears once and only as unfinished work: 'RM Menu: Brand Menu API Work - Work includes backend architecture and API work necessary to complete a proof-of-concept demonstration.' Menu maintenance in the shipped product is done in the Restaurant Management Menu Editor and pushed store-to-store ('Manage > Menu Manager > Enter the Menu Editor. Go to the Sync To Stores page'), not over an API. This is a named-endpoint list from release notes, not an API census, so it cannot carry a no; but no evidence of writable menu items, modifiers or prices exists. Bound: complete 313-article Zendesk Help Center API census, 4,078,437 B, re-derived 2026-09-17. Retrieved 2026-09-17. || 326th: 326th, CELL NOT MOVED. New layer bound: the help centre's 125 embedded Loom videos are now enumerated by title (parsed from the 313 re-derived article bodies, 125/125 resolved anonymously via Loom oEmbed, 0 failures). The menu-maintenance titles are all UI procedures in the shipped product - 'Menu Price Edit Tutorial', 'Menu-Editortabs', 'Menu--Menu-edit', 'Creating an Item in V3 local', 'Creating an item in v3 RM', 'Creating a Menu group', 'ImportExportMenu', 'Import-menu', 'Preselected modifiers in RM', 'Creating sizes in v3 local' - i.e. menu writes happen in the Restaurant Management editor or through a file import, never over an API; tokenised over the 125 titles api 0. This does not make a no: HungerRush publishes no API reference, so the named-endpoint list in the release notes (GetMenu, ProcessOrder, an OOS read, a delivery-api Dispatch Order endpoint, a void API) is still not a census. Retrieved 2026-09-18. || 330th: 330th, NEW SURFACE, CELL NOT MOVED, and it argues AGAINST a no. Certificate transparency lists a production host named brandmenuapi.hungerrush360.com; re-probed today with curl and a browser UA (not node fetch), it answers 401 with a zero-length body on /, on /swagger/v1/swagger.json AND on the nonsense control /zzq-nonsense-q330 - a blanket authentication gate in front of a live brand-menu service, so nothing may be inferred about its operations in either direction. Ten sibling production service hosts were probed the same way and return hard 404s at every doc path (rm-reporting-api, rm-reportpackages-api, rm-posagent-api, posgateway, posreporting, rpt-reportingapi-prod, storeconfigapi, hub-jsonconfig-api, loyalty-api, delivery-api, legacydatasync .hungerrush360.com); maketime-api times out. So HungerRush's menu service exists as a running, authenticated API whose contract is published nowhere: a no on menu writes remains unavailable. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). NEW SURFACE (third party, grade D): the kiosk partner's Zendesk category 'Hunger Rush Onboard' (support.infi.us/hc/en-us/categories/50029294248219, 14 articles via /api/v2/help_center/en-us/categories/50029294248219/articles.json, count 14, linked from HungerRush article 47771523037837). Article 52711536878875 'How do I update my menu for a HungerRush location?': 'Your menu content - items, prices, categories, and modifiers - is managed in HungerRush ... In the INFI Console you can only choose which menus are imported here; you cannot edit the menu itself' and 'Menu changes made in HungerRush sync to the kiosk in real time via webhooks'. Also from the on-disk 2023 Throttling guide (q324 pdfall.txt, 'Updated February 16, 2023'): 'Not Supported: Mobile App, Third Party API (i.e.: OrderAi, It's A Checkmate), Next-Gen API (i.e.: DoorDash), On premise (POS)' - HungerRush runs at least TWO unpublished partner API families (Third Party API and Next-Gen API). That is one partner's integration being read-only for menus (grade D), not a bound on HungerRush's partner APIs; the 330th's brandmenuapi.hungerrush360.com 401 gate and 'RM Menu: Brand Menu API Work' (30758253591821) still argue against a no. The newest menu article, 'RM/HUB - Brand Menu Manager: Overview' (47576567131405, updated 2026-07-25), describes UI editing only. Hold unknown. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): SwaggerHub. HungerRush's own SwaggerHub organisation, HungerRushLLC (anonymous registry listing https://api.swaggerhub.com/apis/HungerRushLLC = totalCount 2, both X-Published=true, X-Private=false), publishes two OpenAPI 3.0 specs no prior pass found (nothing in claims.jsonl or .cache mentions swaggerhub): (1) 'HungerRush Online Ordering API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 (created 2018-10-15, modified 2021-10-27): 'The HungerRush API allows you to post orders to a ReventionPOS through HungerRush', exactly three operations - POST /api/v1/order/processorder 'Submit an order object to HungerRush for validation and submission to the store', GET /api/v1/order/getmenu 'Gets the current online HungerRush menu for the store', GET /api/v1/order/getesttime; (2) 'HungerRush Loyalty API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushLoyalty/1.0.0-oas3 (modified 2022-02-28; the 'Honeycomb' loyalty module, renamed in release note 06/28/2022, 19248755436045), 14 POST operations on hub.hungerrush.com/Api/v1/Honeycomb/* (CreateOrder, CreateCustomer 'Create or Update a Customer', GetCustomerDetails, SearchCustomers, VoidOrder, Redeem, UndoRedeem, ValidateReward, ValidatePointsToAdd, AddPoints, CreateReward, IsStoreEnrolled, GetStores, GetPoints). CURRENCY: the Online Ordering spec is the live Third Party API, not a retired one - the 2024 KB release note (31480284698765, 8.14.24) names 'existing endpoints, including GetMenu and ProcessOrder', the exact operation names of this spec; and hub.hungerrush.com still routes the Loyalty API (GET /api/v1/honeycomb/GetStores = 405 'does not support http method GET', nonsense sibling /api/v1/honeycomb/zzqnope = 404 'No HTTP resource was found'). Auth in both specs: 'The API Key, API Secret, and store number are provided by Revention' / 'by HungerRush', requests signed HMAC-SHA256 over key+timestamp+store+URI+method+body (headers X-PSK, X-Stamp, X-Signature, X-Store). Three further HungerRush-named specs on a personal account (szischerk: Inventory API, Order API, Store API, 2022-06/07, X-Published=false, servers virtserver.swaggerhub.com/HungerRushLLC/* mocks and api2.hungerrush.net, which is NXDOMAIN today) are unpublished drafts and are NOT used as evidence; 'Hungerrush2/GetActivePromotions' is the SwaggerHub IoT template (POISON). Bearing on this cell: the only published HungerRush API that touches the menu is READ-only (GET /api/v1/order/getmenu, 'Gets the current online HungerRush menu for the store'; no create/update operation on items, modifiers or prices among its 3 operations), and the Loyalty API has no menu object. Not a no: the published specs are a census of these two APIs only, and the vendor runs an unpublished, auth-gated brand-menu service (brandmenuapi.hungerrush360.com, 401 everywhere; 2025 'Brand Menu API' POC) whose operations cannot be read - the 327th merge rule (unpublished partner API) governs. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the CAPTIONS of the help centre's Loom videos, which the 326th could only title. Each anonymous share page https://www.loom.com/share/<id> embeds a signed cdn.loom.com/mediametadata/captions/<id>-1.vtt URL; GET of those VTTs for the 125 Loom ids embedded in the 313-article KB returned captions for 104 (97,672 chars; 21 have no caption track). Plus the vendor YouTube channel @HungerRush re-derived today: 26 videos + 10 shorts, captions pulled for 35 of 36 (roCqawSJ7Z4 has none). CLAIM: menu items/modifiers/prices writable via API. VERDICT: unknown (327th unpublished-partner-API rule still governs; brandmenuapi.hungerrush360.com 401). EVIDENCE: the menu tutorials show menu writes are UI + an internal publish job, not an API: 'Menu Price Edit Tutorial' (Loom oEmbed description: 'edit the price of an item on the menu from $4.99 to $6.99, sync the changes to the POS system'); caption 'it is now being synced to the POS ... the syncing to the POS has now been successful'; 'Creating an item in v3 RM': 'to get these items to sync to the store you're going to have to click on View, slash Publish, to Store'. Controls over 104 Loom + 35 YouTube captions: API 0, webhook 0, integration(s) 0 in Loom; YouTube 'integrates' only for Uber Eats/DoorDash marketplace (ehp-dQNlgZM). certspotter re-run on hungerrush360.com (18 current issuances, 12 hosts) found no host outside the q323 crt.sh census. Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: the gated article 38746931822733 is the one KB page whose title touches menu distribution to third parties ('Use Menu for 3rd Party Marketplaces'), and it is login-walled, so no reading of it is possible; the silent 'ImportExportMenu' recording is a file import/export, consistent with the UI/file menu-write path already recorded. The unpublished-partner-API rule still governs. Unknown. Retrieved 2026-09-18. adversarially verified

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

332nd: MOVED unknown -> no. CLAIM: every core object the API can read can also be written/updated via the SAME API. NEW SURFACE (332nd): SwaggerHub. HungerRush's own SwaggerHub organisation, HungerRushLLC (anonymous registry listing https://api.swaggerhub.com/apis/HungerRushLLC = totalCount 2, both X-Published=true, X-Private=false), publishes two OpenAPI 3.0 specs no prior pass found (nothing in claims.jsonl or .cache mentions swaggerhub): (1) 'HungerRush Online Ordering API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 (created 2018-10-15, modified 2021-10-27): 'The HungerRush API allows you to post orders to a ReventionPOS through HungerRush', exactly three operations - POST /api/v1/order/processorder 'Submit an order object to HungerRush for validation and submission to the store', GET /api/v1/order/getmenu 'Gets the current online HungerRush menu for the store', GET /api/v1/order/getesttime; (2) 'HungerRush Loyalty API' https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushLoyalty/1.0.0-oas3 (modified 2022-02-28; the 'Honeycomb' loyalty module, renamed in release note 06/28/2022, 19248755436045), 14 POST operations on hub.hungerrush.com/Api/v1/Honeycomb/* (CreateOrder, CreateCustomer 'Create or Update a Customer', GetCustomerDetails, SearchCustomers, VoidOrder, Redeem, UndoRedeem, ValidateReward, ValidatePointsToAdd, AddPoints, CreateReward, IsStoreEnrolled, GetStores, GetPoints). CURRENCY: the Online Ordering spec is the live Third Party API, not a retired one - the 2024 KB release note (31480284698765, 8.14.24) names 'existing endpoints, including GetMenu and ProcessOrder', the exact operation names of this spec; and hub.hungerrush.com still routes the Loyalty API (GET /api/v1/honeycomb/GetStores = 405 'does not support http method GET', nonsense sibling /api/v1/honeycomb/zzqnope = 404 'No HTTP resource was found'). Auth in both specs: 'The API Key, API Secret, and store number are provided by Revention' / 'by HungerRush', requests signed HMAC-SHA256 over key+timestamp+store+URI+method+body (headers X-PSK, X-Stamp, X-Signature, X-Store). Three further HungerRush-named specs on a personal account (szischerk: Inventory API, Order API, Store API, 2022-06/07, X-Published=false, servers virtserver.swaggerhub.com/HungerRushLLC/* mocks and api2.hungerrush.net, which is NXDOMAIN today) are unpublished drafts and are NOT used as evidence; 'Hungerrush2/GetActivePromotions' is the SwaggerHub IoT template (POISON). VERDICT: the vendor's own published partner API reads the menu and cannot write it. The Online Ordering spec is a complete contract for that API (3 operations, all enumerated above): the menu is exposed by GET getmenu (schemas Menu, MenuGroup, MenuItem, MenuSize, MenuGroupMod, MenuItemReqMod, MenuItemPref, MenuCpn, MenuTax ...) and no operation creates or updates a menu object, item, modifier or price. That is a documented read-only core object in the same API, which falsifies 'every'. Corroborated by the KB: the 2024 additions to this API are reads (the OOS status endpoint 'allows third parties to check the current status of items marked as Out of Stock') plus an outbound OOS webhook, and menu maintenance is documented only through the RM/HUB Menu Editor and .rmf file import; and by the kiosk partner INFI (support.infi.us article 52711536878875, third party D): 'Your menu content - items, prices, categories, and modifiers - is managed in HungerRush ... you cannot edit the menu itself'. Customers are symmetric in the Loyalty API (CreateCustomer 'Create or Update' + GetCustomerDetails), so the asymmetry is specific to the menu. CAVEAT stated: a separate, unpublished brandmenuapi.hungerrush360.com (401 on every path) and a 2025 'Brand Menu API ... proof-of-concept' exist; they are a different API and cannot make the menu writable via THIS one. Grade B (vendor-published OpenAPI on the vendor's own SwaggerHub org; arguably A). Retrieved 2026-09-18. https://api.swaggerhub.com/apis/HungerRushLLC/HungerRushAPI/1.0.0 · retrieved 2026-09-18 adversarially verified

API rate limits are published as specific numeric quotas with documented throttling behavior and headers.

extensibility-published-rate-limits

PUBLICATION reading - the claim's own verb is 'are published as specific numeric quotas with documented throttling behavior and headers', which is a fact about what a buyer or integrator can obtain, and that is directly measurable. Re-fetched www.hungerrush.com/products/integrations/ on 2026-09-04: HungerRush's entire published API surface is one paragraph - 'HungerRush API provides secure, direct access to key business data, opening new opportunities for connection and insight' - terminating in an 'I'm interested' contact form. There is no API documentation of any kind to carry a quota: developer.hungerrush.com, docs.hungerrush.com and api.hungerrush.com all 404 at /robots.txt, /developers/ 404s, and the 43-URL page-sitemap.xml names no developer or API page. Grepping the closed census (313 of 313 help-centre articles, Zendesk API and /hc/sitemap.xml agreeing exactly - 0 articles in one and not the other) plus 82 www pages plus 45 vendor PDFs for 'rate limit', 'throttl' and 'quota' returns only two operator-facing hits about order throttling ('Throttling for Online Ordering allows merchants the ability to control the number of orders accepted at any time from online ordering'), nothing about API request quotas, and www.hungerrush.com/terms/ contains no API provision at all. Scope of this no: nothing is published. It is NOT a finding that no rate limits exist or that limits are undocumented to contracted partners - that capability question remains unobservable. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-04 adversarially verified

The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator

extensibility-doordash-preferred

DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `hunger_rush_production`, rendered as 'HungerRush', with qualityStatus CERTIFIED and 3 of the 8 high-quality features built. CERTIFIED and AT_RISK are the program's other two tiers, so this is positive evidence of non-membership rather than a failure to find the vendor: it is present in the registry and carries a status that is not PREFERRED. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11

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

Uber Eats Integration Overview (PDF linked from this article, hc/article_attachments/45528874629261): "HungerRush Uber Eats integration allows merchants to directly integrate their Uber Eats marketplace orders with their HungerRush POS system"; onboarding is OAuth begun in Restaurant Management by selecting the store, menus/inventory/pricing sync POS-to-Uber Eats with separate in-store and Uber Eats menus, and Uber Eats commission is recorded in the POS. Prerequisites are HungerRush 360 V3 RM plus a Restaurant Management subscription with Menu Management - no third-party middleware. DoorDash is documented identically (article 28873927209229) and Grubhub is a native Ordering Channel under Restaurant Management > Manage > System > Ordering Channels (article 36740618341389). Documented limit is scheduling pauses in advance, not the integration path. https://support.hungerrush.com/hc/en-us/articles/25386194280333-UberEats · retrieved 2026-08-06

The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).

extensibility-middleware-compatibility

Confirmed by direct enumeration: Checkmate is the only aggregator in the catalog; Otter, Chowly and Deliverect are absent. Correctly refuses the two-platform bar. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01 adversarially verified

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

Verified: Restaurant365 and Craftable are listed under Inventory & Accounting; QuickBooks appears nowhere in the catalog. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01 adversarially verified

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

Stronger than the labor twin: the catalog has an explicit 'Labor, Scheduling & Payroll' category containing only 7shifts and HotSchedules, both scheduling. That is an affirmative enumeration of the alternative, so 'no payroll connector' survives. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01 adversarially verified

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

CAPABILITY reading, and the capability is documented by the vendor, superseding the prior 'no scheduled destination is documented anywhere' rationale. Release Notes 05/04/2022, 'Reports: FTP': 'The ability to establish a File Transfer Protocol (FTP) server is now available in Restaurant Management. This feature will send a file containing extensive data in a format that can be easily used to insert into a preestablished report of their own creation. Once a customer inputs their server information, Restaurant Management can be configured to send data nightly.' It continues: 'The General Tab allows for the FTP server configurations as well as the options to establish if the file should be uploaded nightly... Pressing the Test FTP button will initiate a test to see whether the credentials used were correctly inputted... The Data Upload Tab can be used to generate an FTP on demand.' Corroborated by a later release note on report packages sending 'whether saving to file system or sending via email or ftp'. So a scheduled push of a data file to a customer-controlled destination exists and is per-store configurable - the 'not only viewed in the vendor's reporting UI' half of the claim is met. SHORTFALL naming why this is partial and not yes: (1) the payload's granularity is never stated - 'extensive data' aimed at 'a preestablished report of their own creation' is not documented as raw transaction-level rows, and no schema, data dictionary or field list is published; (2) the destination family is FTP only - 'S3', 'SFTP', 'Snowflake', 'BigQuery' and 'data warehouse' return zero hits across all 313 articles, 82 www pages and 45 PDFs; (3) the feature is documented once, in a 2022 release note, with no user guide in the 313-article census to confirm current scope. Every other documented export is manual and UI-bound. https://support.hungerrush.com/hc/en-us/articles/19248754915469-Release-Notes-05-04-2022 · retrieved 2026-09-04

The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.

extensibility-app-marketplace

A public integrations catalog listing ~20 named partners exists and is browsable, but it is a marketing directory — there is no self-install flow or operator-granted app authorization. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.

extensibility-custom-fields-scripting

OPERATOR-FACING reading: operator-defined fields and self-service custom logic are things a merchant configures on a screen and would be trained on, so the closed census is the right instrument. All 313 of 313 help-centre articles were read (Zendesk API and /hc/sitemap.xml enumerations agree exactly, 0 diff either way) and 'custom field' returns zero hits; of 62 non-'customer' occurrences of 'custom' the constructs are all vendor-defined settings - Custom Date Range, custom tip amount, custom roles, Custom Valcode, Custom Group Sequence ('allows the user to configure role-specific and/or time-based menu group layouts'), custom-created payment types, and custom HTML order-confirmation email templates. The nearest operator-authored objects are saved marketing queries - 'User-Defined Queries - Stores saved queries and when selected will all you to choose the one you like to run' - which are filters over a fixed 40-parameter customer schema, not fields added to a POS object. 'script', 'formula', 'plugin', 'extensib', 'low-code', 'no-code', 'workflow builder', 'app store' and 'app marketplace' return nothing across ALL.txt, the 82 www pages and the 45 PDFs. Re-fetched www.hungerrush.com/products/integrations/ on 2026-09-04, the vendor's own extensibility page: it offers pre-built featured integrations plus an API paragraph with an 'I'm interested' form, and names no custom-field capability, no scripting or app platform and no developer program. Grade C rather than B because the anchor is a marketing/product page plus census silence, not a positive doc enumerating the configurable surface. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-04 adversarially verified

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

One certified third-party front end is documented, not a general headless mode. HungerRush's help centre (2026-07-30) points customers to INFI's 'Hunger Rush Onboard' knowledge-base category (14 articles, July 2026), where INFI documents its kiosk taking the full menu from HungerRush (items, prices, modifiers, availability; 'menu changes made in HungerRush sync to the kiosk in real time via webhooks'), accepting card and contactless payment on a HungerRush-mounted payment device, and posting orders into the POS, with the menu editable only in HungerRush. Shortfalls: it is a single partner integration onboarded by HungerRush, not a published API or embedded-mode offer open to other UIs; cash is 'Not Allowed for current HR integration'; loyalty and coupons on the kiosk are 'coming soon'. https://support.hungerrush.com/hc/en-us/articles/47771523037837-INFI-Knowledge-Base-Support-Resources · retrieved 2026-09-03 adversarially verified

The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.

extensibility-api-versioning-deprecation

PUBLICATION reading, and the strongest of the API-family cells because HungerRush's changelog IS published and IS fully enumerated: the claim asks whether the vendor 'publishes an API changelog and a stated deprecation/notice policy'. The Release Notes seams comprise 39 articles - the dated 'Rush Hour Updates' series running through 2026, the per-product release notes, and this 'Releases by Category' index - and across the whole closed census (313 of 313 articles, sitemap and Zendesk API agreeing with 0 diff) the heading 'Third Party API' appears EXACTLY ONCE, here, carrying a single dated entry: '8.14.24: HungerRush will send a webhook payload detailing items that were marked Out of Stock (OOS) or 86'd... HungerRush has introduced a new API that allows third parties to check the current status of items marked as Out of Stock (OOS) at any time.' One entry in one article inside a changelog that otherwise runs monthly for every other product line is not a recurring API changelog. Separately, no article and no legal document states a version policy, a deprecation window or a notice period for breaking changes: 'versioning' returns zero hits corpus-wide, the five 'deprecat' hits concern legacy vNow reports, an HMAC/IP verification process, a Dual MID feature and the retired HungerRush payment gateway, and www.hungerrush.com/terms/ carries no API provision. Scope: HungerRush publishes no API changelog or deprecation policy. It is NOT a finding that partners receive no private breaking-change notice. https://support.hungerrush.com/hc/en-us/articles/31480284698765-Releases-by-Category · retrieved 2026-09-04 adversarially verified

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

The master Terms and Conditions state: 'You have an ownership interest in all information or data about you and your business that is generated by the Products and Services.' In practice the operator can extract data on demand: 'Creating a Manual Backup' shows the POS database is backed up to an operator-chosen path (default This PC\Local Disk (C:)\Revention\Backup, or an external drive) and 'should be automatically backing up the Database each day'; menus export to an .rmf file; reports export to Excel, CSV and PDF. Shortfalls: the agreement states no export format, no data-return obligation and no exit assistance -- the only termination mechanics are that on non-renewal you must 'deliver back to the Company, at your expense, all of the Products and Services covered by the Agreement within 3 business days', and on default the Company 'may enter any premises where the Products and Services are located and take immediate possession thereof'. The database backup is a proprietary file with no published schema, and no complete, documented machine-readable export of orders, customers and payments metadata exists. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.

reliability-offline-order-entry

Order entry and tender continue with no internet: 'Once you try to collect payment with no internet you will get a declined error on screen as the system is unable to communicate with the credit card server. After that error you will need to hit the force button... and click Authorize. These transactions will be stored, and will need to be manually batched from each station.' The TriPOS install settings expose an 'Auto Force' toggle, 'the test site that Revention will try to reach if it detects a loss of connection', and 'the amount of time that Revention will try for a connection before rolling over to force mode' -- an internet outage is a designed-for state, not a stoppage. The architecture is local (the POS keeps its database on the station: 'The POS should be automatically backing up the Database each day' to C:\Revention\Backup). Shortfall: no article states what happens to kitchen ticket routing or check printing specifically during an internet outage, and the vendor publishes no degraded-function matrix; the marketing 'offline operations mode' phrase is never defined. https://support.hungerrush.com/hc/en-us/articles/19248816115725-Forcing-Credit-Cards-TriPOS · retrieved 2026-08-08

Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator

reliability-offline-card-auth

Card acceptance while offline is documented, not cash-only fallback: 'During initial Datacap setup, they must have Store and Forward enabled at the processor level. It is then enabled in the EMVUSClient, which by default is enabled.' The POS side is 'Forcing Credit Cards... a method to be able to accept Credit Cards when the internet has failed and without verifying availability of the funds against the credit card processor at the time of the transaction'; forced transactions 'will be stored, and will need to be manually batched from each station'. Permission is a per-employee or per-labor-group security flag (Securities > Orders > Force Credit Cards), and the TriPOS variant adds an Auto Force toggle with a connection-test host and a rollover timeout. Shortfalls: no authorization occurs at the time of sale, so 'it is possible to see declined transactions at the time of batching'; batching is manual and per-station; and the vendor disclaims the path -- 'HungerRush does not suggest forcing credit card transactions' and 'is not able to provide troubleshooting support or reimbursement for failed transactions due to forcing credit cards'. Decline liability sits with the operator. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-08

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

'Forcing Credit Cards - DataCap/TriPOS' documents that HungerRush 'is not able to provide troubleshooting support or reimbursement for failed transactions due to forcing credit cards' and that forced transactions 'will only be authorized when batched, which means it is possible to see declined transactions at the time of batching' -- this documents who bears the loss for forced/store-and-forward-style declines. Shortfall: no article states a per-transaction or cumulative offline cap, which the claim also requires. https://support.hungerrush.com/hc/en-us/articles/19248754401421-Forcing-Credit-Cards-DataCap · retrieved 2026-08-04

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

Shared state is LAN-hosted, not cloud-hosted: 'In most configurations, Kitchen and Label Printers will be connected over the network to Station 1, while Customer Receipt printers will usually be connected to the station they print orders for', and restarting Station 1 'will leave your other stations unable to take orders until that station reboots' -- other stations depend on Station 1, not on the internet, to take orders. The database is local ('The POS should be automatically backing up the Database each day' to C:\Revention\Backup), and with no internet the POS still reaches payment and stores forced transactions per the Forcing Credit Cards articles. Shortfalls: LAN-degraded operation is contingent on Station 1 being up -- it is a single point of failure, not a peer mesh -- and no article states explicitly that check or table state continues to be shared between terminals during an internet outage, so the finding rests on the local-server architecture rather than a statement about a partition. https://support.hungerrush.com/hc/en-us/articles/46676112728077-System-Printers-Configuration · retrieved 2026-08-08

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

'The POS should be automatically backing up the Database each day, however if this function fails and a manual backup needs to be performed in order to close the business day...', with the backup path given as 'This PC\Local Disk (C:)\Revention\Backup' on the station itself -- the ordering path runs against an on-premise database, not a cloud request/response. The local-server role is explicit in System Printers Configuration: kitchen and label printers 'will be connected over the network to Station 1', and restarting Station 1 'will leave your other stations unable to take orders until that station reboots'. Menu changes are pushed down to stores ('Sync to Store: Push Menu Updates to Stores', with a warning and a disabled Sync Now button 'if the selected store is offline'), and offline-forced card transactions 'will be stored, and will need to be manually batched from each station'. Menu exports write to C:\Revention\Export. https://support.hungerrush.com/hc/en-us/articles/19248750777869-Creating-a-Manual-Backup · retrieved 2026-08-08

Kitchen display and/or kitchen printer routing continues to function while offline.

reliability-offline-kds-printing

The only vendor sentence containing 'offline' is www.hungerrush.com/products/hardware/, 'Shorten disruptions and downtime with offline operations mode' - the third bullet of the page's customer-support block ('24/7 US-based customer support', '93% first-call resolution rate'), not of its Kitchen Display block, and the phrase is nowhere defined. The architecture is documented and points the right way: kitchen and label printers are 'connected over the network to Station 1' (System Printers Configuration, 46676112728077), KDS is a station role with a local control box and a local alert file (C:\Revention\KDSAlert.wav), reporting falls back to on-device Crystal reports 'in case of network connectivity issues', and Forcing Credit Cards documents order entry and payment continuing 'when the internet has failed'. But every use of 'offline' in the 313-article census means severed from Station 1, not from the internet - 'restarting Station 1... THIS WILL TAKE ALL OTHER STATIONS OFFLINE' - and no article in the Kitchen Display, Printers/Printing or Printer and Print Ticket Configuration sections states what happens to kitchen routing during a WAN outage. Concluding yes requires an architectural inference the vendor never makes. || 319th: NEW (Help Center API attachments, not previously read): Legacy POS 'Getting Started Guide.pdf' (article 25386625695245, 'Updated September 7, 2021'), p.47 'Config - Offline': 'The Offline tab allows you to set automated messages that will display to customers if there is a disruption in Internet Connectivity to the store, but the store is still open and accepting phone and walk-in orders.' FAQ p.145: 'HungerRush requires ports 7777 and 12230 to be forwarded ... to Station 1. A hardware reset or replacement will cause these ports to be closed and all HungerRush communication will stop' (online-order delivery into the store). 'Orders Guide.pdf': when the processor is unreachable, 'Force will take a digital carbon copy of the card and wait for approval at a later time'. This is vendor text that in-store order taking continues through an internet outage, but it never names kitchen printers or the KDS; 'Printer Kitchen Display Configuration.pdf' (3,992,341 B) and the 360 'Kitchen Display System Basics.pdf' contain no offline/internet/outage statement. Left unknown. Retrieved 2026-09-16. || 320th: ADDITION to the q319 attachment note: 'Printer Kitchen Display Configuration.pdf' states 'Kitchen Printers that have an IP connection is set up from Station1' (in-store routing through Station 1, consistent with article 46613116747021 'restarting Station 1. THIS WILL TAKE ALL OTHER STATIONS OFFLINE'). Also in the article bodies: POS release notes (article 30757777604621) 'system will now fall back to existing crystal reports-based POS reports, so customers can still access on-device reporting in case of network connectivity issues' - reporting, not kitchen. Across all 1,561 PDF pages no sentence ties kitchen printing or KDS to an internet outage. The topology implies local routing, but unstated behaviour is not documented capability; left unknown. Retrieved 2026-09-16. || 325th: MERGE HOLD (proposed partial/B, held unknown): an architectural inference plus a marketing phrase; no document says kitchen tickets keep printing through a WAN outage. The agent flagged it as its weakest row. PROPOSAL AS WRITTEN: 325th, CELL MOVED unknown -> partial/B. The evidence is architectural and first-party. (1) Ticket printing is served by a LOCAL station, not the cloud: 'For Kitchen Printers, this means restarting Station 1. THIS WILL TAKE ALL OTHER STATIONS OFFLINE, so we recommend only making kitchen ticket format adjustments after business hours' and, for customer printers, 'restarting all stations that you updated format settings on... If you adjust the format of Delivery orders on Station 3, you will need to restart Station 3' (Printer Ticket Configuration Settings, inside the 313-article Zendesk Help Center API census, 4,078,437 B, re-derived 2026-09-17). (2) The POS is documented as trading through a WAN outage in two other respects: card capture uses Datacap 'Store and Forward... enabled at the processor level. It is then enabled in the EMVUSClient, which by default is enabled', with a per-labour-group 'Force Credit Cards' setting that 'only needs to occur one time, and not every time the internet goes down'; and reporting degrades locally - 'if vNext Reporting Report fails to produce a report in the POS, system will now fall back to existing crystal reports-based POS reports, so customers can still access on-device reporting in case of network connectivity issues or Restaurant Management vNext Reporting outages'. (3) The vendor advertises the mode by name: 'Shorten disruptions and downtime with offline operations mode' (www.hungerrush.com/products/hardware/, fetched 2026-09-17, nonsense control 404). SHORTFALL (why partial): no HungerRush document states in terms that kitchen tickets continue to be routed and printed while the internet is down - tokenised 'offline mode' and 'without internet' return ZERO across all 313 articles, and the two \boffline\b hits are the station-restart warning and a store being unreachable for a menu sync. Retrieved 2026-09-17. || 326th: 326th: the 325th's merge hold is not disturbed, but the corpus behind it is now complete in one more dimension. The help centre's embedded video layer is enumerated for the first time: 125 distinct Loom ids parsed out of the 313 article bodies, all 125 resolved through Loom oEmbed (title + duration, 0 errors), plus 5 third-party YouTube embeds (Uber Eats, Menufy). Tokenised over the 125 titles: offline 0, internet 0, outage 0, network 0; the printer titles are configuration ('Printer Routing in the POS', 'Printerconfiguration local', 'PrinterConfiguration RM', 'Add_RenameKPC_POS', 'Add_RenameKPC_RM'). The vendor therefore says nothing about kitchen printing during a WAN outage in text, in the 39 attached PDFs, or on video - the architectural inference remains an inference. Retrieved 2026-09-18. || 327th: NEW VENDOR HARDWARE SPEC SHEET + A STATUS-PAGE INCIDENT CENSUS (327th), NO MOVE, BUT THE ARCHITECTURE IS NOW SPECIFIED DOWN TO THE PART NUMBER. (1) https://www.hungerrush.com/wp-content/uploads/Kitchen-Display-System-KDS-Specifications-1.pdf (c 2025 HungerRush, reached via the previously-unpaged `resources` WordPress post type) specifies the KDS as an ON-PREMISE WINDOWS PC driving a local monitor: 'Lenovo ThinkCentre M93p Tiny Desktop PC / Operating System Windows 10 Pro 64-bit / Intel Core i5-4507 (or i7) ... Ethernet: LAN (RJ45)', a '24" Monitor ... Input Signal HDMI, VGA', and a wired bump bar ('Keys Stainless-steel dome disks', 'Lifecycle > 5 million tactile operations', 'Input Voltage (from PC) 5 V DC', 'Manual, programming cables and software, and mounting bracket supplied'). Nothing in the KDS path is a cloud client. (2) NEW SURFACE: status.hungerrush.com is an Atlassian Statuspage (page id ns25wtt69c7g) that no prior pass touched. Its component list and its FULL incident history were fetched (api/v2/summary.json, api/v2/incidents.json = 50 incidents back to 2022-11-16, plus history.json pages 1-40 = 72 more month-indexed incidents; 50,776 chars of incident prose). The 13 published components are Customer Support (Email, Phone), Online Ordering, Management Console, Loyalty, Payment Processing (FirstData/CardConnect, WorldPay Express heritage Revention, WorldPay Integrated heritage CRS, WorldPay Core), Third Party Integrations (Google Maps, DoorDash) and HungerRush POS Hardware - THERE IS NO KDS OR KITCHEN-PRINTING COMPONENT, and tokenised controls over the whole incident corpus return `KDS` 0, `kitchen` 0, `printer` 0, `offline` 0. Consistent with kitchen routing being local and outside the cloud blast radius, but a status page enumerates what the VENDOR hosts, not what survives an outage, so this corroborates and does not assert. No vendor sentence anywhere yet says kitchen routing continues while offline. Retrieved 2026-09-18. || 328th: 328th: A PER-CELL RE-GREP OF THE ON-DISK CORPORA (.cache/q312,q319,q320,q323,q324,q325,q326,q327/hungerrush, 642 text files) SURFACED ONE VENDOR SENTENCE NO NOTE HAS CITED, AND IT POINTS AGAINST A YES RATHER THAN FOR IT. support.hungerrush.com/hc/en-us/articles/19248759495437 (Printer FAQ), in the 'did not print' troubleshooting branch: 'Kitchen Printers should be connected to the internet. Check all the cables in the ...'. Read literally that is the opposite of an offline-capable kitchen path; read charitably 'the internet' is the store LAN (the same article repeats 'kitchen printers are usually connected over the network to Station 1'). Either way no vendor sentence anywhere in the corpus says kitchen routing survives a WAN outage, and the one sentence that touches the question is ambiguous against the claim. The 'Store and Forward' hits in the census are processor-side card capture ('they must have Store and Forward enabled at the processor level'), not print queuing. Held unknown. Retrieved 2026-09-18. || 330th: 330th, CELL NOT MOVED (previously held at merge as an architectural inference; nothing found this pass changes that). NEW: the two printer troubleshooting articles were read individually rather than by control - 'Printer FAQ' (19248759495437) and 'Troubleshooting Printers' (19248785340557). Both diagnose printing purely as a local cabling/station problem ('Trace the cable from the back of the printer to either the station, an ETHERNET port either in the wall or on your network switch'; 'If your printer is plugged into your station, it is either connected via USB OR Serial Connection'), and 'Troubleshooting Printers' distinguishes the two deployment modes in the vendor's own words - 'navigate to Utilities > Restart Printer if you are a locally managed customer. If you are above store managed (using HungerRush HUB for configurations) it will be under Tools > Restart Printer.' The nearest thing to a WAN-outage statement in the whole corpus remains an online-ordering one: 'The Offline tab allows you to set automated messages that will display to customers if there is a disruption in Internet Connectivity to the store, but the store is still open and accepting phone and walk-in orders' (Getting Started Guide p.47). It says orders keep being taken; it still does not say the kitchen ticket prints. Retrieved 2026-09-18. || 331st: 331st, CELL NOT MOVED; the 325th MERGE HOLD is not re-proposed. KB freshness re-derived: /api/v2/help_center/en-us/articles.json?sort_by=updated_at&sort_order=desc count=313, page_count 4, newest updated_at 2026-08-07 (46763710763533), so no article is newer than the 330th census; 38746931822733 and 40694212678285 still answer 401 (gated hole unchanged, KB is not a census). Corpora grepped (481 docs): q328 articles-all.json (313 bodies), q327 pdftxt (59) + restxt (63), q323 designer-docs dd, q324 pdfall.txt (39 KB PDFs), q330 incidents.txt, q327 status_corpus, q328 terms text, plus the new INFI category (14 articles). New only: full-resolution screenshots of 'System Printers Configuration' (46676112728077: printer = Computer 'Station1' + 'Windows Printer' name) and 'Kitchen Printer Configuration Settings' (46556738700429: 24 kitchen-ticket options, none about connectivity or fallback) - they confirm station-local print queues but state nothing about a WAN outage. The only other 'offline mode' sentence in the corpora is generic content-marketing ('a tablet POS that runs on a hybrid cloud solution will minimize downtime by supporting offline mode', HungerRush 6-Benefits PDF), not a statement about HungerRush's kitchen routing. Retrieved 2026-09-18. || 332nd: 332nd: the 325th merge hold is not re-proposed. New surfaces checked: the Revention Inc. App Store publisher census (lookup?id=396756103, 2 apps: Driver Track, HUB Mobile) and Google Play search (no KDS or POS-station app) - neither offers a kitchen-routing app or any offline statement; HungerRush's SwaggerHub org (2 published APIs) has no printer/KDS surface. No new behaviour statement. Retrieved 2026-09-18. || 333rd: NEW SURFACE (333rd): the CAPTIONS of the help centre's Loom videos, which the 326th could only title. Each anonymous share page https://www.loom.com/share/<id> embeds a signed cdn.loom.com/mediametadata/captions/<id>-1.vtt URL; GET of those VTTs for the 125 Loom ids embedded in the 313-article KB returned captions for 104 (97,672 chars; 21 have no caption track). Plus the vendor YouTube channel @HungerRush re-derived today: 26 videos + 10 shorts, captions pulled for 35 of 36 (roCqawSJ7Z4 has none). CLAIM: kitchen display/printer routing continues while offline. VERDICT: unknown (325th merge hold not re-proposed). EVIDENCE: 'Printerconfiguration local' caption: 'printer configurations in V3 local. First, log into the POS. Then click on config. Next, select printers ... if we go to local, this allows you to select printer that you want to print each of these separate categories on for each of the stations'; 'PrinterConfiguration RM' shows the same routing edited in the cloud back office. So routing is defined both in-store (V3 local) and in RM, but no caption says what happens to routing during a WAN outage. Controls over 104 Loom + 35 YouTube captions: outage 0, connectivity 0, offline 3 (online-ordering item availability only), internet 1 (web browser). Enterprise page marketing (C): 'offline functionality when you need it' - generic, not kitchen routing. Retrieved 2026-09-18. || 334th: 334th: THE HELP-CENTRE VIDEO LAYER IS NOW CLOSED 125/125. The 333rd pulled caption .vtt files for 104 of the 125 Loom ids embedded in the 313-article KB and left 21 with no caption track. Each of those 21 share pages (https://www.loom.com/share/<id>, GET, anonymous) carries a transcription_status field and a signed cdn.loom.com/mediametadata/transcription/<id>-2.json URL (the 333rd's regex looked only for captions/): for 20 of the 21 the status is 'success' and the transcription JSON is {"phrases":[],"schemaVersion":"1.1.3"} - Loom's own speech recogniser found NO SPEECH, i.e. they are silent screen recordings; the 21st, a3a3e813860c494e8199604f01e5f4ee 'Update DeliveryFee_DriverComp By Zone', has transcription_status 'failed' and no transcript URL. The 20 silent titles: Setting and Removing Holidays, CreateAManualBackup, CreatingDayParts_RM, CreatingDayParts_POS, Add_RenameKPC_RM, Add_RenameKPC_POS, ImportExportMenu, Changing Order Type, HowToSplitOrder, Add Item and Order notes, Making Event Questions, CreateALaborType_POS, PrintingExportingSchedulesinPOS, EnableDeferredInDisp, Reassigning Delivery Orders, Delivery Options, Enabling_Disabling 10Digit Phone Lookup_In RM, Batching Previous Days, Apply Charge to Same Credit Card, ExportingCoupons. So the spoken layer of the KB is 104 captioned videos and nothing else; every word-boundary zero the 333rd measured over those captions now covers the whole spoken layer. ALSO RE-PROBED, the KB's two-article gated hole: 38746931822733 is titled (from its inbound href in 47576567131405 'RM/HUB - Brand Menu Manager: Overview') 'Use Menu in 3rd Party Channels / Use Menu for 3rd Party Marketplaces' and its HTML page 302s to hungerrush.zendesk.com/access (sign-in); 40694212678285 'Scan to Pay' answers a Cloudflare 403 to curl with full browser headers, and both still return 401 from /api/v2/help_center/en-us/articles/<id>.json. Wayback CDX holds ZERO captures of either id. The KB is therefore still not a census (2 gated ids), unchanged. ON THIS CELL: the silent printer recordings (Add_RenameKPC_RM / Add_RenameKPC_POS = kitchen printer categories) add no statement; the 325th merge hold (architectural inference) still governs. Unknown. Retrieved 2026-09-18. 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

Same evidence as kitchen-printer-fallback: 'Printer Routing' documents manually rerouting tickets to a different printer when one 'stops functioning', requiring an admin to reconfigure Config > Printer > Printer Routing and restart the POS on all stations -- not an automatic failover with staff alerting. https://support.hungerrush.com/hc/en-us/articles/19248751341965-Printer-Routing · retrieved 2026-08-04

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

This is a documentation claim ('The vendor documents its conflict-resolution behavior'), and the publication surface is now a closed census: 313 of 313 help-centre articles read (Zendesk API and /hc/sitemap.xml agree exactly, zero diff either way), plus 45 vendor PDFs and the 43-URL page sitemap. The single article describing synchronisation is 'Sync to Store: Push Menu Updates to Stores', and it documents a one-way push with three job states and an outright refusal rather than any merge semantics: 'If the selected store is offline, there will be a warning reminding the user that we are unable to connect to the selected store, and the Sync Now button will be disabled.' Nothing in the corpus states last-write-wins, merge, or an operator prompt, and 'conflict', 'last write' and 'overwrite' return only unrelated bug-fix lines. Above-store vs local management is itself an enumerated split ('navigate to Utilities > Restart Printer if you are a locally managed customer. If you are above store managed (using HungerRush HUB for configurations) it will be under Tools > Restart Printer'), so the docs do address the two-writer topology and still say nothing about partition conflicts. https://support.hungerrush.com/hc/en-us/articles/38746840228493-Sync-to-Store-Push-Menu-Updates-to-Stores · retrieved 2026-09-04 adversarially verified

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

A publication claim, now settled by the closed census: all 313 help-centre articles (API and sitemap agreeing exactly, 0 articles in one not the other), all 45 vendor PDFs and the 43-URL www page sitemap contain no degraded-function or offline feature list. The only outage documentation in the entire corpus is the Forcing Credit Cards pair (DataCap and TriPOS), which covers card authorization alone -- 'Forcing Credit Cards is a method to be able to accept Credit Cards when the internet has failed and without verifying availability of the funds against the credit card processor at the time of the transaction' -- and even it enumerates only caveats ('Forcing credit cards does not include pre-authorization ... it is possible to see declined transactions at the time of batching'), never gift cards, loyalty lookup, refunds, manual card entry or text-to-pay. The vendor's one offline claim, /products/hardware/'s 'Shorten disruptions and downtime with offline operations mode', is a single undefined phrase with no accompanying list, which is precisely the shortfall this claim tests. https://www.hungerrush.com/products/hardware/ · retrieved 2026-09-04 adversarially verified

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

Independently verified: status.hungerrush.com is login-free, per-component (including four discrete processor backends, DoorDash, Google Maps, POS Hardware, Support/Email/Phone), publishes 90-day uptime percentages and a public /history incident log. The strongest verified 'yes' in the dossier. https://status.hungerrush.com/ · retrieved 2026-08-01 adversarially verified

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

The published standard Terms and Conditions contain no uptime percentage and no service-credit remedy anywhere. They state the reverse: 'all Products and Services are provided by the Company "AS IS," and the Company makes no express, implied, or other representations, warranties, or guarantees of any kind', and 'Under no circumstances shall the Company be responsible, or liable to you... for, or because of, any: a) loss of profits, loss of use, lost sales... d) failure of the Products and Services to work or to comply with any applicable governmental or industry standards.' The only performance commitment is hardware: the Company 'shall repair or replace any physical Product that becomes defective in material or workmanship during the first 12 months after it is installed'. Support is chargeable ('will charge you an hourly fee, at the then standard rates') and discretionary as to hours. status.hungerrush.com publishes rolling 90-day uptime percentages, but a status page is not a contractual remedy. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

The vendor publishes written post-incident reports or root-cause summaries for major outages.

reliability-incident-postmortems

Status page exposes incident history and a 'view historical uptime' link, so incidents are disclosed. Whether written root-cause postmortems accompany major outages could not be confirmed. https://status.hungerrush.com/ · retrieved 2026-08-01

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

'24/7 Live Support' is an itemized inclusion of the $0 Starter tier on the pricing page, so it is genuinely base-tier and not an upsell. The reviewer caveat about email latency belongs in complaints, not the score. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01 adversarially verified

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

The Terms and Conditions make first-party on-site installation the default: 'All costs associated with delivering and installing Products and Services, including travel expenses incurred by Company personnel, shall be paid by you'; 'If you cancel or do not allow a scheduled delivery and installation... pay a cancellation/rescheduling fee of $500.' The contract term commences 'on the earlier of the scheduled Delivery & Installation date or the day that Products and Services are first delivered to your location', with the D&I date defaulting to 'the 60th day after the Agreement is signed'. The customer is responsible for site readiness ('the installation location is suitable for installing and using the Products and Services, including... cabling, data lines, connections, utility services') and must give the Company the data it needs 'to program, integrate, deliver and install the Products and Services, to train you and your staff'. Note the cost model: installation, travel and training hours are billed to the operator, not bundled. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

The vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. differentiator

reliability-menu-build-service

The Terms and Conditions define the service and then exclude it from price: 'no price quoted or stated in any Agreement includes programming (programming includes all data inputs made to any software programs to design and create such things as menus, displays, reports, functionality, structure, and other features for use by you) or training for you or your employees.' The customer must ensure 'the Company timely receives such information and data as it deems necessary to enable it to program, integrate, deliver and install the Products and Services' -- so HungerRush performs the menu data entry, from operator-supplied content, ahead of the Delivery & Installation date. Shortfalls: menu programming is never included in the subscription or quoted price and is billed separately; and the self-serve path is what the help centre documents -- 'Getting Started: Create or Copy Menu' directs operators to build or copy their own menu in Restaurant Management. OrderAI Talk customers are further restricted to 'a standardized menu submitted and agreed to by the Company'. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.

reliability-hardware-replacement-sla

Hardware is 'covered by your service agreement', so a replacement program exists, but no turnaround time is stated publicly. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.

reliability-backup-restore

'Creating a Manual Backup' documents an operator triggering their own database backup from Utilities > Backup > Backup Now, satisfying the 'operators can trigger... their own data backup' half of the claim. Shortfall: no article documents an operator-initiated restore process, or published RPO/RTO figures. https://support.hungerrush.com/hc/en-us/articles/19248750777869-Creating-a-Manual-Backup · retrieved 2026-08-04

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

This is a publication claim, and the publication surface is measured: the homepage footer's legal set is exactly two links (/privacy-policy/ and /terms/), /security/, /trust/, /compliance/ and /pci/ all 404, a Wayback CDX query over hungerrush.com* filtered to legal terms returns 32 rows across all history whose only legal documents are /terms, /terms-of-use and /terms-of-use.htm, and the 313-of-313 help-centre census plus 45 vendor PDFs contain zero occurrences of P2PE, AoC, attestation or SAQ. The vendor's only compliance page, read in full, publishes no Attestation of Compliance, no PCI DSS version, no assessor, no date and no validated P2PE listing; it is headed 'PCI Compliancy - Point of Sale (PA-DSS)' against a standard retired in October 2022 and claims only that the HungerRush Payment System 'provides a secure, robust integration allowing users to process multiple payments ... while maintaining end to end encryption', and it explicitly routes the reader off-site to third parties for validation: 'The quickest way to find out if your online ordering company has been approved by Visa and/or Mastercard as a PCI-DSS certified service provider is to check their websites.' The nearest thing to an attestation in the corpus is device-level, not DSS: the P400 reader is 'PCI PTS 5.x approved', a PIN-transaction-security device approval. Scored no on publication only; this says nothing about whether HungerRush holds an unpublished AoC. https://www.hungerrush.com/payment-security/ · retrieved 2026-09-04 adversarially verified

Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.

reliability-mfa-role-based-access

Role/permission control exists via per-employee 'security settings' at the POS. MFA on back-office or admin logins is nowhere documented. https://www.hungerrush.com/products/pos/ · retrieved 2026-08-01

A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.

reliability-self-serve-training

support.hungerrush.com is fully public (no login; all 313 articles readable), and its 'Role Based Training' section publishes six ordered curricula -- Owners/Admin, Manager, Kitchen, Server, Driver, Cashier. The Manager curriculum links, in sequence, How to Clock In and Out, How to Start a Cash Drawer, How to Take an Order, Changing Order Type, How to Add Item and Order Notes, How to Look Up an Order, How to Split an Order, Order Lookup Screen Functions, Inputting Customer Information, Manager Functions On The Order Screen, How to Close the Day and Basic Credit Card Reader Troubleshooting, then Employee Manager and Menu & Coupon Manager tracks. Shortfalls: the curricula are link lists of illustrated step-by-step articles -- the article bodies contain no embedded video or LMS enrolment -- and no practice or training mode on the terminal is documented in any of the 313 articles (grepped for 'training mode', 'practice mode', 'demo mode', 'test mode': zero hits). Instructor-led training is a separately purchased service under the Terms: 'no price quoted or stated in any Agreement includes... training', charged hourly beyond the contracted hours. https://support.hungerrush.com/hc/en-us/articles/26715246144653-Manager · retrieved 2026-08-08

Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator

reliability-failover-terminal-role

The vendor states the failure behaviour directly: 'After any change to a printer's setting, the station that printer is connected to must be restarted. For kitchen and label printers, this means restarting Station 1. Be advised that this will leave your other stations unable to take orders until that station reboots. We recommend avoiding any adjustments to System Printers during store business hours.' The same warning is repeated in Kitchen Printer Configuration Settings, Label Printer Configuration Settings and Printer Ticket Configuration Settings ('THIS WILL TAKE ALL OTHER STATIONS OFFLINE, so we recommend only making kitchen ticket format adjustments after business hours'). No other station picks up the role: the documented remedy for a downed station is manual reconfiguration, as in 'Changing What Station is Being Used as a KDS' ('In the case that your kitchen display screen goes down and you need to set another station to be the new kitchen display screen there are certain steps that need to be followed'), performed from Config > Kitchen Display. This is a statement of behaviour by the vendor, not an inference from silence. https://support.hungerrush.com/hc/en-us/articles/46676112728077-System-Printers-Configuration · retrieved 2026-08-08

Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.

reliability-cellular-backup

The terminal has no cellular radio and the documented outage response is a payment fallback, not a connectivity one. The 6100 POS Terminal spec sheet's Specifications table enumerates the full I/O and its Network row reads '1 x RJ45 (10/100/1000 Mbps), 1 x M.2 Key E (2230) for Wi-Fi' -- the two other M.2 slots are SATA storage -- with no WWAN slot and no SIM tray; the P400 reader sheet likewise lists 'Supports Ethernet, USB, Wi-Fi, and Bluetooth'. Across 313 articles, 45 PDFs and every fetched page, 'cellular' occurs once and concerns the driver's own phone off-premise ('Both the driver and guest need an active internet or cellular connection to complete payment. If service isn't available, the driver can accept cash instead'), and 'LTE', '4G', '5G', 'SIM' and 'failover' return zero. Affirmatively, Forcing Credit Cards - TriPOS configures 'the test site that Revention will try to reach if it detects a loss of connection' and 'the amount of time that Revention will try for a connection before rolling over to force mode' -- a design that presupposes there is no second path. https://www.hungerrush.com/wp-content/uploads/6100-POS-Terminal-Specifications-1.pdf · retrieved 2026-09-04 adversarially verified

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

HungerRush Terms and Conditions (last updated April 27, 2026), the document the Terms themselves name as part of the Agreement: 'Unless the Agreement provides otherwise: ... b) you shall pay the Company ... the agreed upon monthly subscription fee for the entirety of the temporal term of the Agreement, including any renewal terms; ... f) the initial term of your agreement shall be 4 years; ... i) the temporal term of the Agreement shall automatically renew for successive 3 year renewal terms if you do not provide written notice of non-renewal at least 30 days, but not more than 90 days, prior to end of the then current term.' The published default is a 4-year term auto-renewing in 3-year blocks, not month-to-month. The pricing page's 'From $0 / Month' Starter tier states a monthly PRICE, not a monthly term, and carries '*Must meet qualification criteria'. Note this is the governing commercial document: /terms-of-service/ returns HTTP 404, and /terms-of-use/ (last modified January 29, 2024) governs website use only, not the product subscription. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

HungerRush's published Terms and Conditions (last updated April 27, 2026) state the opposite of the claim. The subscription is term-locked: "the initial term of your agreement shall be 4 years", it "shall automatically renew for successive 3 year renewal terms" absent written non-renewal notice 30-90 days out, and "you shall pay the Company ... the agreed upon monthly subscription fee for the entirety of the temporal term of the Agreement, including any renewal terms." Early exit is priced: the Terms set out a liquidated-damages calculation payable "in a lump sum within 10 days after the time that you cease to process with the Processor" (average monthly processor fees excluding interchange x months remaining in the longer of the two terms x 0.90); should you "prematurely terminate an Agreement", your licence is "immediately and automatically revoked" and the Company may collect "any or all sums that you may owe to it (not just overdue sums)". Separate clauses claw back any signing inducement in full and recover remaining-term revenue for unauthorised continued use. Also a $500 cancellation/rescheduling fee for a missed installation. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

HungerRush Terms and Conditions (last updated April 27, 2026) publishes both the auto-renewal and the notice window verbatim: 'the temporal term of the Agreement shall automatically renew for successive 3 year renewal terms if you do not provide written notice of non-renewal at least 30 days, but not more than 90 days, prior to end of the then current term'. The initial term is stated in the same list: 'f) the initial term of your agreement shall be 4 years'. CORRECTED 2026-08-11 from 'no'. The previous note read 'No publicly accessible terms of service or MSA exists - hungerrush.com/terms-of-service/ and /legal/ both return 404... Auto-renewal and notice windows are therefore not published at all.' Both 404s are real and still 404 (confirmed with and without the trailing slash), but the conclusion drawn from them was wrong: the merchant agreement is published at /terms/, which three sibling cells in this same record already cite as 'the merchant agreement' (digital-guest-data-ownership, hardware-usable-after-churn, commercial-month-to-month-contract). A claim about PUBLICATION was decided by the absence of two guessed URLs rather than by the presence of the document, and the record contained the refutation the whole time. https://www.hungerrush.com/terms/ · retrieved 2026-08-11

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

Multiple processor backends run behind the platform (WorldPay Express/Integrated/Core, FirstData CardConnect) and Datacap is integrated — but pricing bundles processing into every plan at one blended rate and no merchant-choice program is documented. https://status.hungerrush.com/ · retrieved 2026-08-01

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

Only a blended flat rate is published (3.09% + $0.15, card-present and card-not-present). No interchange-plus option with a stated bps + per-transaction markup appears anywhere. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

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

The published Terms and Conditions (April 27, 2026) neither cap increases nor grant penalty-free exit. Card processing is not HungerRush's own agreement -- the Terms require the operator to sign a "Processing Agreement" with "a payment processor ... approved by the Company and to which you are referred by the Company", and that document is not published, so no cap on processing rates is discoverable. What the Terms do impose is the opposite of a penalty-free exit: "your contractual obligation to the Company includes the duty to process all of your card transactions with the Processor for the longer of the term of the Processing Agreement and the term of the Agreement", with liquidated damages of average monthly processor fees (excluding interchange) x months remaining x 0.90, due in a lump sum within 10 days of ceasing to process. The nearest protection is for software pricing only, and it is not an exit right: prices are fixed through the first year of the initial term, after which the Company may revise them "at any time"; an operator who objects in writing within 30 days keeps the previous pricing, but "the Company may terminate the Agreement upon providing you 30 days written notice" in response. https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

Starter is 'From $0/Month*' with unpublished qualification criteria; Custom is quote-only; a third 'Advanced Plan' is referenced on the loyalty page with no price. No per-terminal or per-additional-location figure is published. https://www.hungerrush.com/pricing/ · 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

Two modules are separately contracted with independent cancellation, but the rest are bundled into fixed tiers under the 4-year master subscription. The published Text Marketing Agreement & Billing Authorization at /text-marketing-terms/ (a module addendum that 'Amend[s] our subscription agreement with HungerRush, LLC to include access to HungerRush's Text Marketing platform') states 'usage of the Text Marketing platform is entirely optional', prices it purely on usage ('Campaign-level usage is pay-as-you-go', tiered SMS rates $0.039 to $0.023 by subscriber count, re-evaluated monthly), and grants cancellation at will: 'disabling the product will prevent future billing but does not void charges already incurred'. The master Terms at /terms/ separately allow terminating OrderAI Talk alone -- 'you may terminate your use of, and cease paying for, OrderAI Talk, but no other Products or Services, after the first 3 months ... during the 10-day period prior to the expiration of the initial 3-month period' and thereafter only in a 10-day window before each annual anniversary. Shortfall: none of the other modules the claim names carries such a right. The Terms define 'all equipment, hardware, software, training, programming, and other products and services that you receive from the Company' as one subscription and require payment of 'the agreed upon monthly subscription fee for the entirety of the temporal term of the Agreement, including any renewal terms', and /pricing/ gates modules by tier ('Free for all plans' for online ordering and loyalty, 'Add-on' for Voice & Text Ordering, 'With Advanced Plan Only' for Automated Marketing) while advertising 'HungerRush provides it all at one low monthly cost'. https://www.hungerrush.com/text-marketing-terms/ · retrieved 2026-08-08

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

Terminals, tablets, KDS and printers are all described as included in the monthly subscription with warranty under the service agreement. No outright-purchase price is published for any device. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

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

Two non-proprietary devices are in the stack — a Citizen thermal printer and an Ingenico Lane/3000 reader — but the POS terminal and tablet are HungerRush-built and no BYO-hardware support is documented. https://www.hungerrush.com/products/hardware/ · retrieved 2026-08-01

One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.

commercial-implementation-fee-published

The pricing page publishes no implementation, menu-build, onboarding or training fee, and does not state $0 for any of them. https://www.hungerrush.com/pricing/ · retrieved 2026-08-01

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

'Exporting Reports' documents running any report (Mgmt > Reports) and exporting it directly from the POS to a chosen file location with no fee or support-ticket step described, and the 'Payroll Export Report' likewise offers a self-serve, choose-your-own-format export -- covering self-serve export of transactional/labor detail without contacting support. https://support.hungerrush.com/hc/en-us/articles/19248765736077-Exporting-Reports · retrieved 2026-08-04

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

'Marketing On The POS Overview' (updated 2024-08-22) documents a Marketing module that lets the operator 'query the customer data base with over 40 different parameters', including a prebuilt 'All Customers' query, and on the results screen: 'Export - This button allows you to export the query results to a .csv file that can be opened in Excel or Notepad.' So guest/customer records are operator-exportable in machine-readable form. Loyalty balances are reportable but weaker: HungerRush release notes name a 'Customer Points Loyalty report' and a 'Customer Count Loyalty report' in Restaurant Management (Release Notes 11/2/2022) and state 'Existing loyalty reporting can be done ... under our normal reports section of Restaurant Management' (Release Notes 11/29/2022); RM grid reports are documented as exportable to Excel/CSV, but no article shows a point-ledger export specifically. SHORTFALL: gift-card LIABILITY (outstanding balances) is not an exportable artifact anywhere in the 313-article help centre -- the only gift-card figures documented are period ACTIVITY, i.e. Sales Summary's 'Gift Cards (In/Out) = Value of gift cards sold or redeemed' and the Daily Performance Report's 'Gift Cards ... based on ActiveTotal field from OrderGiftCards table'. Neither is an outstanding-liability balance. https://support.hungerrush.com/hc/en-us/articles/19248790708109-Marketing-On-The-POS-Overview · retrieved 2026-08-08

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

The published Terms and Conditions (April 27, 2026) address termination and data ownership directly and specify no post-termination retrieval period. Cutoff is immediate: on premature termination, default or non-payment "your license to use all Products and Services shall be immediately and automatically revoked, and the Company may enter any premises where the Products and Services are located and take immediate possession thereof, without notice"; on non-renewal the operator must "deliver back to the Company, at your expense, all of the Products and Services covered by the Agreement within 3 business days of the end of the then current term" -- a return deadline, not an export window. The Terms grant the operator "an ownership interest in all information or data about you and your business that is generated by the Products and Services" but attach no delivery, extract or retention obligation to it, and instead make the operator "solely responsible" for "properly and securely backing up, archiving and storing information and data that is captured, stored or transmitted by the Products and Services", with the Company disclaiming liability for any "loss, corruption, or interception of any data". https://www.hungerrush.com/terms/ · retrieved 2026-08-08

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

CORRECTION of a self-contradicting cell. The prior verdict was `no` on the premise 'No public MSA or terms of service exists to contain such a clause' — a premise this record already refuted elsewhere, since sixteen other claims cite https://www.hungerrush.com/terms/ and the adjacent commercial-post-termination-export-window quotes this very sentence. HungerRush's published Terms and Conditions (last updated April 27, 2026) DO contain a merchant data-ownership clause, verbatim: 'You have an ownership interest in all information or data about you and your business that is generated by the Products and Services.' SHORTFALL that holds this at partial rather than yes: the same bullet immediately takes most of it back, granting HungerRush a broad irrevocable licence over the same data — 'to the extent that the Company receives or otherwise has access to such information or data, or to information or data about your customers, through the Products or Services, or otherwise, the Company may use such information and data to develop, provide and to support the Products and Services, and for such other business purposes as it reasonably desires, and you hereby grant the Company an irrevocable license to do so; provided, however, that the Company shall not disclose any personal, confidential or proprietary information to third parties other than in an anonymized format that protects the identities of you and your customers.' So the operator gets an 'ownership interest', not exclusive ownership; the vendor's own use is unrestricted in purpose and perpetual in duration; and the clause attaches no delivery, extract or retention obligation, while the Terms elsewhere make the operator 'solely responsible' for backing up their own data. A published but heavily qualified ownership clause is partial, not absent. https://www.hungerrush.com/terms/ · retrieved 2026-09-04

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

Proprietary cloud SaaS with vendor-supplied hardware and a 403-gated developer portal. No source is published and no self-hosting option exists. https://www.hungerrush.com/products/integrations/ · retrieved 2026-08-01

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

The vendor's dedicated 'Regulatory Compliance and Payment Security' page states 'The HungerRush Payment System (RPS) provides a secure, robust integration allowing users to process multiple payments including credit cards, gift cards, and mobile/NFC Payments while maintaining end to end encryption', and the March 2026 security-incident page adds 'HungerRush does not store any credit card data within our systems.' SHORTFALL: that is the whole of it. The page frames POS compliance as 'PCI Compliancy - Point of Sale (PA-DSS)' -- PA-DSS was retired by the PCI SSC in October 2022 -- and names no PCI-listed validated P2PE solution, no tokenization mechanism, and no merchant SAQ type (neither SAQ A nor SAQ P2PE-HW appears). A site-wide WordPress search of www.hungerrush.com (wp-json/wp/v2/search) returns zero results for 'P2PE' and zero for 'tokenization', and none of the 313 support.hungerrush.com help-centre articles (fetched complete via the Zendesk articles.json API) contains 'P2PE', 'SAQ' or 'tokeniz'. Merchant PCI scope reduction is therefore implied by hardware encryption but not documented or quantified by the vendor. https://www.hungerrush.com/payment-security/ · retrieved 2026-08-08

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

Nothing published documents the v4.0.1 future-dated controls. www.hungerrush.com/payment-security/ is the vendor's only compliance page and it still frames the product on 'PCI Compliancy - Point of Sale (PA-DSS)' and 'the 12 requirements of the PCI Data Security Standards (PCI-DSS)' generically, names no v4.0.1 requirement, no MFA obligation and no payment-page script-integrity monitoring, and assigns the duty outward: 'it is your responsibility to confirm that the online ordering company you use is PCI-DSS compliant.' Across 313 help-centre articles, all 45 PDFs and every fetched www page, 'MFA', 'multi-factor', 'two-factor', 'authenticator', 'password policy' and 'script integrity' return zero; the sole one-time-code hit belongs to HighRadius, HungerRush's own invoicing portal ('A ONE-TIME ACCESS CODE (OTAC) will be emailed to the address you register'), not the cardholder data environment. Scope: this is a finding about what is documented. It is NOT a finding that MFA or script-integrity monitoring is absent from HungerRush's environment -- those are controls a help centre would not necessarily carry. https://www.hungerrush.com/payment-security/ · retrieved 2026-09-04 adversarially verified

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

PUBLICATION reading - the claim's verb is 'Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation'. HungerRush has exactly one compliance page and it enumerates its compliance posture in terms of payment-card regimes only, under the two headings 'PCI Compliancy - Point of Sale (PA-DSS)' and 'PCI Compliancy - Online Ordering (PCI-DSS)': 'The HungerRush Payment System (RPS) provides a secure, robust integration allowing users to process multiple payments including credit cards, gift cards, and mobile/NFC Payments while maintaining end to end encryption.' The rest of the page is merchant education that turns the obligation outward - 'It is our goal to educate all of our clients about PCI compliancy' and 'it is your responsibility to confirm that the online ordering company you use is PCI-DSS compliant' - and it never names SOC 2, SOC 1, ISO 27001, an attestation, an auditor or an NDA process. This is reinforced by a measured legal set: the footer links exactly /privacy-policy/ and /terms/, /terms-of-use/ answers 200 but is unlinked, and /security, /trust, /compliance, /pci, /dpa, /msa, /sla and /eula all 404 on a host that 404s fabricated paths honestly, with a Wayback CDX query over hungerrush.com* confirming no trust-centre or attestation document has ever existed on the host. 'SOC 2', 'SOC2' and 'ISO 27001' return zero hits across all 313 help-centre articles, all 82 www pages and all 45 vendor PDFs including the buyer's guides. Scope of this no is precise and deliberate: HungerRush makes no public statement of holding SOC 2 Type II or ISO 27001 and offers no trust centre or documented request path. It is NOT a finding that no such attestation exists inside the company. https://www.hungerrush.com/payment-security/ · retrieved 2026-09-04 adversarially verified

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

Privacy policy documents access, correction, deletion, opt-out and portability rights with intake via legal@hungerrush.com or phone — a manual process covering HungerRush's own processing. No in-app operator DSAR tooling and no published DPA. https://www.hungerrush.com/privacy-policy/ · retrieved 2026-08-01

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

PUBLICATION reading - the claim's verb is 'Vendor publishes an accessibility conformance report (VPAT/ACR)'. Nothing is published. 'WCAG', 'VPAT', 'accessibility conformance', 'screen reader' and 'tactile' return zero across the 313-article help centre, the www pages and all 45 vendor PDFs; www.hungerrush.com/accessibility/ 404s, and so does /regulatory-compliance/ despite 'Regulatory Compliance' appearing in the site nav and footer - it resolves to /payment-security/, which is PCI-only. The site's own WordPress search index (wp-json/wp/v2/search) returns nothing for VPAT or WCAG, and Wayback CDX over the full host shows no such document has ever existed. The published legal set is /privacy-policy/, /terms/, /terms-of-use/ and /payment-security/; none mentions accessibility conformance. The vendor's only ADA statement points the duty at the merchant - /terms/: 'You are solely responsible and the Company has no responsibility for: ... using the Products and Services in compliance with the Americans with Disabilities Act (ADA)' - which is liability allocation and corroborates that no conformance posture is published rather than being the finding itself. On the kiosk half: HungerRush builds no kiosk of its own but does resell one - www.hungerrush.com/products/integrations/ (retrieved 2026-09-04) lists under KIOSK 'INFI - Self-order kiosks powered by INFI', and help-centre article 47771523037837 is a two-line pointer to support.infi.us - so any kiosk ACR would sit with the partner. The no rests on the half HungerRush indisputably owns, its consumer web-ordering surface, for which no ACR is published either. Scope: no ACR is published. It is NOT a finding that the surfaces fail WCAG 2.1 AA. https://www.hungerrush.com/products/integrations/ · retrieved 2026-09-04 adversarially verified

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

Same evidence as payments-surcharge-guardrails: surcharging is a documented, configurable feature (percentage or flat, assignable by payment type/order type) with a required 'Surcharge Liability form' process before setup. Shortfall: no documented automatic exclusion of debit/prepaid cards from the surcharge, and receipt/menu-board disclosure is discussed as the merchant's own responsibility in the article's background text rather than a system-enforced disclosure control. https://support.hungerrush.com/hc/en-us/articles/19248742111757-Creating-and-Using-Surcharges · retrieved 2026-08-04