UrbanPiper

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

REPLACES a placeholder rationale that said nesting depth, min/max counts and forced selection "are not documented". Depth and the forced flag are documented; the counts are not. Nesting is stated as a supported feature with its depth named in the label: the Zomato, Swiggy and Keeta feature matrices all carry "Nested Option Group (L2) -- Manage options within options for maximum flexibility." Forced selection is the documented distinction between the two group types -- "Add-ons: Optional modifications such as extra onion or extra chicken" versus "Variants: Mandatory selections that you want an end user to make while buying an item. For example, size is a mandatory selection... it has to be one of regular, medium, or large." SHORTFALL on both remaining limbs: the documented nesting is L2, which is two levels and not the three this claim requires, and no min/max selection count appears anywhere in the modifier documentation -- the only per-modifier field the article edits is "the default sales price". https://help.urbanpiper.com/business-manager/creating-a-menu/adding-modifier-groups-and-modifiers · retrieved 2026-08-31

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

The full menu-push payload schema gives an option exactly one scalar price field — 'price (float): The option price specific to the platform' — with no per-parent or per-size override structure; an option attaches to its parents only via opt_grp_ref_ids. The menu architecture page (downstream/menu/architecture.md) models size as an option group ('Size' holding 'Personal' and 'Medium' options) whose options carry nested option groups, so pricing the same topping differently per size means creating it again as a separate ref_id under each size branch — duplication, which the claim excludes. The Atlas help article on modifiers likewise shows a single 'default sales price' per modifier. Item prices can vary store-wise, but no price matrix by parent item and size exists in the data model. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-04

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

menu-pricing-fractional-placement

Documented absence in the data model, not silence. The Add/Update Menu endpoint defines the whole menu as six object types -- 'A menu is considered to comprise of the following objects: Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes, Charges' -- and then enumerates every attribute of each. The Option object's complete field list is ref_id, ref_title, title, description, price, food_type, sold_at_store, available, sort_order, images/img_url, weight, translations, opt_grp_ref_ids, nested_opt_grps, key_value_groups, recommended and code. There is no placement, position, section, half, portion or fraction attribute anywhere in it, and no per-section price; an option carries exactly one scalar price. The Option Group object likewise offers only min_selectable, max_selectable, multi_options_enabled, display_inline, active and sort_order -- quantity constraints, not geometry. The merchant-side Atlas modifier article (help.urbanpiper.com/business-manager/creating-a-menu/adding-modifier-groups-and-modifiers) matches: modifier groups are typed only as 'Add-ons' or 'Variants' and the only price field it edits is 'the default sales price'. A pizza half cannot be expressed, so it cannot be priced. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

Entailed by the same schema enumeration that refutes fractional placement, and independently by the absence of any pricing-rule object. The Add/Update Menu endpoint states the menu comprises exactly Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes and Charges, and enumerates every attribute of each. Nothing in that model represents a portion of an item, so there is no pair of halves to price; and nothing in it represents a calculation rule -- prices are literal floats on items (price, external_price, markup_price, platform_pricing) and on options (price), with no highest-half, averaging or fractional-topping selector, and no configuration surface for one. The Atlas menu and modifier help articles (help.urbanpiper.com/business-manager/creating-a-menu/*) show the same: sections, items, add-on and variant modifier groups, and a single default sales price per modifier. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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 complete menu-push schema enumerates every field on option groups and options: groups are typed only as variants or add-ons, and options carry ref_id, title, price, availability, sort_order and nested groups. No tier construct (light/regular/extra/double) and no per-tier price multiplier exists anywhere in the model. Order payloads and the Option-wise Order Transactions Report do carry an option quantity, but that is repeat-selection counting — the mechanism the claim explicitly distinguishes from tiering. Tiers can only be faked as separate options, each with its own flat price. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · 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

The menu architecture page documents exactly the size x crust case as a nested structure: 'Inside the Subcategory "Veg Pizza", the item - "Spiced Paneer" has an Option Group - "Size". This Option Group has 2 Options - "Personal" and "Medium". Each one of the Options has a different Nested Option Group called - "Base". Each Nested Option group has a Nested Option called - "San Francisco Style Crust".' Because each size option owns a distinct nested group, the crust options under each size can be given different prices, so a per-combination price is reachable. SHORTFALL: it is not a grid and there is no per-cell override of the item base price. In the menu-push schema (api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md) an item has one price per store/platform and every option has one scalar price, so a combination price is the sum of item price plus option price plus nested option price; there is no two-axis price table and no cell that overrides the base. Differing a crust price by size requires duplicating the crust as a separate ref_id under each size branch -- the same duplication already recorded against menu-pricing-modifier-price-by-parent-size. https://api-docs.urbanpiper.com/downstream/menu/architecture · retrieved 2026-09-01

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

The Option Group object's documented attributes are ref_id, ref_title, title, description, min_selectable, max_selectable, multi_options_enabled, display_inline, active, sort_order, item_ref_ids, opt_grp_ref_ids, translations and the clear_* flags. The two count fields are constraints, not allowances: 'min_selectable (integer): The minimum number of options belonging to this group, that need to be selected when placing an order. Defaults to 0' and 'max_selectable (integer): The maximum number of options belonging to this group, that can be selected when placing an order. Defaults to -1'. There is no free-quantity, included-count, overage-price or substitution-credit attribute on the group, on the option, or on the item, and no rule object anywhere in the model to carry one -- the endpoint defines the whole menu as Categories, Items, Option Groups, Options, Taxes and Charges. An option's price is a single scalar that applies to every selection, so 'three toppings included, charge for the fourth' cannot be expressed; the nearest construct is a separate zero-priced group capped at three, which is a modelling workaround, not the capability. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-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

Construction is reachable but the automatic half of the claim is absent. In the menu-push schema an item can carry a zero base price with option groups whose options each carry their own price -- the worked payload does exactly this for 'Chicken BBQ Pizza' (price 0) with option group 'Choose Your Pizza' -- so a meal with swappable components at a price delta is expressible, and aggregator constraint pages assume combos exist as items ('Description is mandatory for items with keywords such as meals, platter, combo, box, thalis'). SHORTFALL, two parts. First, the endpoint defines the menu as exactly Categories, Items, Option Groups, Options, Taxes and Charges: there is no combo, bundle or meal-deal object, so a combo is only a hand-built item. Second, nothing in the model or in the order path detects eligible a-la-carte lines and converts them to a combo price -- UrbanPiper does not own the aggregator cart, and its own Meraki promotion engine offers only fixed-amount and percentage discounts and Buy-X-Get-Y (help.urbanpiper.com/direct-ordering/configuring-coupons), which discount qualifying items rather than substituting a combo. The Foodics setup guide is blunter still for that POS: 'In the group section for UrbanPiper, avoid using the subgroup or combos option as they are not supported.' https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

325th, CELL MOVED unknown -> partial/B on a NEW SURFACE: the Atlas back-office app at atlas.urbanpiper.com ships PUBLIC SOURCE MAPS. /asset-manifest.json enumerates the whole file set (main.2199edb3.js + 5 chunks + 6 .map files, no chunk loader beyond it); all 6 maps fetched, each begins {"version":3, and the nonsense control /static/js/zzz-nonsense.js.map 404s. 5,354 sources, 1,585 first-party after excluding node_modules, 11.8 MB of sourcesContent. The prior note's 'upsell returns ZERO hits' was true of the two GitBook doc hosts and is FALSE of the product: 'upsell' occurs 298 times in this app. EVIDENCE, two channels. (1) Orderline, UrbanPiper's AI phone agent, has a first-class upsell analytics section: services call POST ${ORDER_LINE_API_URL}/api/v1/analytics/calls/upsell, /calls/upsell/items and /calls/upsell/missing-items, the analytics metric-group selector lists 'Orders & Upsell' (value orders_upsell) beside 'Call Volume' and 'Deals & Promotions' (deals_promo), and reducers/orderLineAnalytics.js initialises upsell:{metrics, items sorted by revenue, missingItems sorted by asks, dealsFunnel, deals}. So attach-rate-style upsell reporting DOES exist, for the phone channel. (2) On the Meraki storefront the Meraki Web editor config exposes a single boolean per page: field 'recommendedItems' on item_detail, tooltip 'Show recommended items related to the current item on the page. The recommendations are also shown on the checkout page to upsell items', plus the same boolean on the menu page. SHORTFALL (why partial, not yes): the storefront prompt is one brand-wide on/off switch, not configurable per item; there is no POS-side or kiosk prompt configuration anywhere in the app (UrbanPiper ships no kiosk); and the attach-rate reporting is confined to Orderline call analytics, with no upsell/attach metric on the Meraki storefront or in the seven Central Reports. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 adversarially verified

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

One 86 action does propagate outward from a single control, and the propagation latency is stated for one platform. From Prime Order Tracker's Stock Control an operator toggles an item or a modifier and saves "to switch off the particular item or modifier on the aggregator's UI"; Keeta's article gives the latency plainly -- "Updates are real-time. Changes take effect immediately on Keeta" and "Out-of-stock is effective immediately when triggered." SHORTFALL is the claim's enumeration of destinations. The documented propagation reaches connected marketplaces; nothing documents an 86 reaching a KDS, a kiosk, or the vendor's own first-party ordering channel (Meraki). CORRECTED WITHIN THIS SESSION: an earlier draft of this note said Meraki has no article in the help centre, which was false and was an artefact of reading only page 0 of a paginated llms-full.txt. Meraki has eight articles -- getting started, custom domain, payment gateway, Google Maps, banner images, SMS mask ID, coupons and campaigns -- and none of them mentions item availability, stock or 86 propagation to the Meraki storefront, so the shortfall stands on a read of the actual articles rather than on their supposed absence. Latency is also documented for only one of the four marketplaces, and the general figure that IS published applies to menu publishes rather than 86s: "Menu updates typically take up to 5-10 minutes to appear on the UI." https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

Scheduled auto-restore is documented, the countdown is not. The Prime app inventory flow ends with 'Step 6: Set Snooze Duration -- Return to the inventory section and click on snooze. Choose a time period to turn the item off, either indefinitely or for a specific duration. For a custom duration, set a date, click OK, and choose a time', and 'The items and modifiers will be snoozed until the selected date and time', with the same flow available for modifiers. SHORTFALL: there is no par count that depletes on sale. The item attribute the schema offers is `current_stock`, documented only as 'The stock of the item at the outlet. If the item is never supposed to go out of stock, set this to -1' (api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md) -- a value the integrating POS pushes, with no documented decrement on order and no documented auto-86 at zero. Availability is otherwise an explicit on/off action: 'Using this API an item or option can be toggled off if unavailable and toggled on when available. However, if you turn off an item/option and do not explicitly turn it on, the item/option will continue to stay out of stock on all the aggregator platforms' (downstream/availability/item-option). Restore is also channel-dependent -- the Keeta guide states 'Auto stock-in by Keeta is not supported. Items do not automatically restock at the start of the day or at store closing time.' https://help.urbanpiper.com/store-manager/prime-app/86ing-an-item-or-modifier · retrieved 2026-09-01

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

Time-based menu availability is a first-class object with its own app. Schedules are created under All Apps > Schedules with "daily, weekdays, weekends, or custom timings", noting "timings should be in multiple of 30 minutes", and are then attached in Catalog > Categories via "Associate Category Timing" -- the worked examples being "a Breakfast-only category or a Chinese menu that is available only during dinner hours". A second schedule type covers location operating hours and is associated to a list of locations. SHORTFALL on two of the claim's three limbs. The unit of scheduling is the CATEGORY, not the item and not the price: no article schedules an individual item or a price change, and inheritance is explicitly absent -- "If there are any subcategories under the parent category, you need to assign timings for each subcategory as well." And no documentation states that schedule times are interpreted in the location's own timezone, which for a platform marketed across 14-plus countries is a real gap rather than a pedantic one. https://help.urbanpiper.com/business-manager/setting-up-schedules-for-locations · retrieved 2026-08-31

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

Two documented price axes, neither of them the one this claim names, and no markup engine. Fulfilment-mode pricing exists -- "Can an Item have different pricing for different Fulfilment Modes? Yes. Some DSPs allow different pricing for items based on the selected fulfilment mode", with a worked table pricing Pizza Margherita at $10.00 for delivery and $9.00 for pickup -- and location pricing exists ("Location-Based Pricing -- Apply different prices for different locations"). SHORTFALL: per-CHANNEL price books are documented only as a facility of the connected POS, not of Atlas -- the Foodics article "Enabling Price Tags on Foodics - Aggregator-Specific Pricing" describes assigning "different prices for the same product based on the delivery channel, without duplicating the item... between channels such as Talabat, Careem", configured in the Foodics console. And no percentage-markup rule exists in any documentation: every documented price is entered per item. Fulfilment-mode pricing is also conditional on the marketplace -- "Support for fulfilment mode-specific pricing varies by DSP." https://help.urbanpiper.com/business-manager/creating-a-menu/understanding-fulfilment-mode-for-an-item · retrieved 2026-08-31

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

The menu-push schema enumerates every price an item can hold and all four are channel prices, not tender prices: `price` (the base, used for Meraki web/apps), `external_price` ('The aggregator online price of the item at the store for aggregator platforms'), `markup_price` ('For promotional purposes, the merchant might desire to show an original higher price alongside the current price... appear as struck-out') and `platform_pricing` (a per-aggregator price list). Options carry one scalar `price`. Nothing keys a price to the tender the guest uses. The phrase 'Cash Discount' does appear once in the corpus, in the Meraki coupon documentation, and it is a different thing: 'Cash Discount -- Applies a fixed amount discount on the order subtotal... cannot be applied to specific items -- it apply to the total bill value before taxes and delivery' (help.urbanpiper.com/direct-ordering/configuring-coupons), a flat-value coupon, not a card-price/cash-price pair. Consistent with the record's existing payments-processor-choice finding that UrbanPiper takes no processing position -- Meraki payments run through the merchant's own third-party gateway -- so there is no card price for a base price to be set to, and no receipt on which two totals could print. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

Staging and preview are documented; rollback is not. A menu change can be held as a "Scheduled Publish... used to update the menu at a later point in the future", where the operator selects locations and platforms, the internal validation runs, and a date and time are chosen before submitting. Preview is separate and explicit: "select the location and platform whose menu you want to preview. Our internal verification engine runs checks on your menu. If there are no errors or warnings, the menu is ready to publish." A pending schedule can be withdrawn -- "You'll see a Cancel Scheduled Publish button instead in that case." SHORTFALL, and it is the claim's last limb: everything documented happens BEFORE the menu goes live. No prior menu version is retained, no version list appears in any article, and no rollback after publish is documented -- the only documented way back is to change the menu again and republish. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

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

The central template and the field-level override list are both documented explicitly. 'In our system, the menu is handled in a federated structure. For each of the menu entities, a master record is maintained and then for each store, references are set to the master menu entities. The master menu can be considered to be the universal set of all menu entities available across all stores... NOTE: At present, categories and option groups are maintained only at the master level, since there aren't many scenarios where the metadata for these entities would vary between stores. For an item, the metadata that varies between stores are: price, current_stock, sort_order, recommended and availability. And for an item option, this can be price and availability.' The architecture page adds that the same item ID must be reused across every store ('the same item should be used based on the availability... the item should not be created again and again for different stores'). Publishing is a one-to-many push: 'Select the locations you want to publish to. Select the platforms you want to publish to' (help.urbanpiper.com/business-manager/publishing-your-menu), on demand or scheduled to a future date and time. SHORTFALL: the override set is a platform constant, not brand-configurable governance. A corporate operator cannot choose which attributes a given location may or may not change -- categories and option groups are simply not store-varying for anyone, and every store may vary exactly price, stock, sort order, recommended and availability. No per-brand, per-field or per-location permission surface over menu attributes is documented on either host; Atlas roles gate who may edit the catalogue at all, not which fields a location may override. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

Nutrition publishes and allergens do not. The Zomato and Swiggy menu matrices both carry "Nutritional Info -- Display nutritional information for your products", so per-item nutrition values are stored in the catalog and pushed to the marketplace with the menu. SHORTFALL on the other two limbs, both absences in a set of documentation that is otherwise exhaustive about item attributes: no allergen field, flag or tag is documented anywhere -- the only item tag the help centre describes is the India-specific "packaged goods" tax tag -- and there is no recipe or bill-of-materials construct in the product at all, so nutrition cannot be derived from components and must be entered by hand. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

REPLACES an unknown that rested on doc-host silence; the marketing host refutes the premise that no ingredient-level inventory exists. Prime holds stock at the INGREDIENT level and an ingredient's level drives the linked menu item: 'Now you can set a minimum stock level for your ingredients in the stock levels module', configured by navigating to 'the Stock levels tab within each of the ingredient's settings' to set their 'Critical Stock Level', whereupon 'you will get a notification and your item status will be updated'. Depletion is transactional -- 'we have revised our stock deductions to occur only after you acknowledge an order, rather than solely after order placement' -- and the Prime Manager role 'handle[s] inventory transactions' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, retrieved 2026-09-01). An ingredient threshold cannot change an item's status without an item-to-ingredient mapping, so the first limb is met in substance. SHORTFALL, and it is most of the claim: no recipe or bill-of-materials structure, and no per-item component QUANTITY, is documented on any readable first-party surface -- 'recipe', 'bill of material' and 'food cost' return zero hits across all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01, and the menu-push schema's complete object enumeration ('A menu is considered to comprise of the following objects: Categories, Items, Item Option/Modifier Groups, Item Options/Modifiers, Taxes, Charges') carries no component object; modifier-level linkage is therefore unevidenced. And there is NO COST FIELD ANYWHERE -- no ingredient cost, no item cost, no margin, and no costing report among the eight documented -- so the claim's second limb, item-level theoretical food cost, is wholly unevidenced. The one vendor page that appears to describe recipe setup, support.urbanpiper.com/support/solutions/articles/12000092223-preparing-recipe-at-a-location, is on a DECOMMISSIONED host: probed 2026-09-02, every URL there including /robots.txt 301-redirects to itself in an infinite loop, so it could not be read and is NOT scored from -- and a search-engine summary of it is not a page I read. Grade D because the single readable source is a product-update post on the marketing host; neither documentation host mentions ingredients at all. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-02

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

The certified-direct-integration half is met: menus publish from Atlas to Zomato, Swiggy, Uber Eats and Keeta over the vendor's own integrations, each with its own authorisation flow, and the published entities are enumerated per platform ("Product names and descriptions / Prices, taxes, and charges / Modifier groups, options, and variants / Product images / Product availability"). Errors are surfaced BEFORE publish: "Our internal verification engine runs checks on your menu. If there are no errors or warnings, the menu is ready to publish", and the scheduled-publish flow runs the same validation. SHORTFALL: the claim asks for PER-ITEM sync status and rejection errors, and after a publish the only documented feedback is elapsed time -- "Menu updates typically take up to 5-10 minutes to appear on the UI." No per-item status list or rejection report is documented; when a publish silently fails, the troubleshooting article sends the operator to a log line and then to the marketplace's own point of contact. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

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

menu-pricing-dynamic-pricing

The channel axis of the claim is met with dedicated schema fields. `price` is the base used for Meraki web/apps, `external_price` is 'The aggregator online price of the item at the store for aggregator platforms', and `platform_pricing` is an explicit per-aggregator price array, with precedence documented: 'platform_pricing only ever sets or updates the price for the platforms explicitly listed in it... Platform with no platform-specific price configured: that platform falls back to the item's base price.' Fulfilment mode is a second axis -- the Atlas help article on fulfilment modes gives the worked example of Pizza Margherita at $10.00 delivery and $9.00 pickup, noting 'Support for fulfilment mode-specific pricing varies by DSP'. SHORTFALL on the rest of the claim: every one of these is a value an operator or POS sets and the platform then applies, not a rule the platform evaluates. Nothing in the menu model varies price by time of day, by day of week or by demand -- schedules exist in the system but attach to menus, sections and categories to control availability, not price -- and no floor, ceiling, minimum or maximum price attribute exists on the item, the option or anywhere else in the schema, so there are no guardrails to configure. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

This is the strongest form of the claim: the operator brings their own gateway account and UrbanPiper takes no processing position at all. "You can configure payment gateways on Meraki to enable online payments for your customers. Multiple payment methods, such as credit/debit cards, UPI, wallets, and COD, can be supported depending on the gateway." Configuration is Atlas > Meraki > Payments > Add Gateway, where the operator selects from a list and pastes credentials they obtain themselves -- "Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard." The supported list is published as a region matrix of twelve gateways across India, MENA, KSA, UK, LATAM and USCAN: RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO and FREEDOMPAY. Scope stated plainly: this governs the vendor's own first-party ordering channel (Meraki), which is the only channel where UrbanPiper handles a payment at all -- on marketplace orders the marketplace collects. No in-house processing product exists anywhere in the documentation. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-08-31

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

payments-published-rates

The vendor does not sell card processing, so the question of publishing a rate does not arise. On its only first-party ordering channel, Meraki, payment acceptance is delegated: 'Click Add Gateway. Select your preferred payment gateway from the list (e.g., Stripe, Razorpay, PayU, Paytm, etc.)... Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard.' The supported set is published as a twelve-provider region matrix (RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO, FREEDOMPAY across India, MENA, KSA, UK, LATAM and USCAN). The rate is therefore a matter between the merchant and Stripe or Razorpay, and no flat rate, interchange-plus markup or per-transaction card fee appears anywhere in either documentation host. This is the same evidence on which this record already scores payments-processor-choice yes: UrbanPiper takes no processing position, and on marketplace orders the marketplace collects. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

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

The menu-push schema enumerates every price an item may hold: `price` (base, used for Meraki), `external_price` (aggregator price), `markup_price` (a struck-out promotional higher price) and `platform_pricing` (per-aggregator price array). Every one is keyed to a channel; none is keyed to a tender, and options carry a single scalar `price`. There is consequently no second price for the system to store, let alone print. On the receipt limb, UrbanPiper does not process cards -- Meraki payments run through the merchant's own gateway account (help.urbanpiper.com/direct-ordering/configuring-payment-gateway) -- and the order payload it relays records how the guest already paid rather than driving a tender: 'payment (array[object]): A list of payment objects... option: The payment option used. Can be one of: prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator.' Note that Meraki's 'Cash Discount' coupon is not this capability: it is 'a fixed amount discount on the order subtotal', not item-specific (help.urbanpiper.com/direct-ordering/configuring-coupons). https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-09-01

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: surcharging engine that excludes debit and prepaid via BIN/product-code detection, enforces the network percentage cap, and is enable-able per location. VERDICT no. EVIDENCE: the store-level POS is now censused and its fee machinery is fully visible: 'Create Service Fee', 'Create Charge', 'Delete charge', 'On Fee {{fee}}', `/company-admin/service-fees`, and charges are per-location configurable objects. Not one of them is aware of card type. BOUND/CONTROLS: tokenised `surcharg` = 0 in the whole Prime app; `\bBIN\b` 0; `product code` 0; `debit` 0 as a card type; `prepaid` 0; `network cap` 0; `card brand` 0. The payment model distinguishes only `payment_mode` online vs offline and `method` (cash, gift-card, card via `online_payment_id`, e.g. pinelabs `allowed_payment_modes`); there is no issuer-BIN or card-product field anywhere in it. In the help corpus the sole `Surcharge` hit is a CHARGE TITLE an operator must create to mirror an aggregator's line. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

payments-emv-nfc

Replaces an inference-only rationale with the vendor's own hardware document. The page opens 'Please find below the minimum specification requirements for buying hardware to use UrbanPiper products' -- the merchant buys the hardware, the vendor ships none -- and enumerates the entire supported surface: Android handhelds, phones, tablets and terminals by RAM/storage/CPU/screen/OS; iOS phones and tablets; receipt printers by command mode (ESC/POS, STAR LINE, STAR GRAPHIC), interface (USB, Bluetooth, Ethernet, parallel, serial) and paper width; and Chrome on a laptop. It closes with the completeness statement 'Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products.' No card reader, PIN pad or payment terminal appears anywhere in it, and no EMV or NFC certification, Apple Pay or Google Pay reference occurs anywhere on either documentation host. This matches the payment model: UrbanPiper takes no processing position -- Meraki payments go through the merchant's own gateway account, and marketplace orders are collected by the marketplace -- so there is no first-party terminal line for this claim to be true of. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-09-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

Claim: contactless acceptance on the phone itself with no separate reader. The Prime Android app cannot read a card, and its only card path is a separate EDC terminal. Binary examined: com.urbanpiper.satellite_prime version_name 69.0.0, version_code 457 (Play listing https://play.google.com/store/apps/details?id=com.urbanpiper.satellite_prime, updated Jul 8 2026), fetched 2026-09-15 from the APKPure mirror. The cited URL is a moving 'version=latest' pointer, so the build is pinned by hash: base apk sha256 a004144399be5f2c163dda1d62aa682decf6a36add24e4f2fb0590b5becd8a37 (re-hashed by the verifier); xapk 19fdd26ccfaa9a52888e83d933fe7cd1e1c11f8213806542b2429a501f45c49d; assets/index.android.bundle 3a0dbb19ccf258c089a6bdda2fa524dff906c012b6ed5b1cbbf3b873600d2d4e. The APK signing block names a Google Inc./Android certificate, which fits Play App Signing, but nobody compared it with the Play-served certificate. That is why this is graded B and not A. Named alternative, from the Hermes string table (54,497 strings, byte offsets): @1515058 'Select the EDC machine to Pay', @1515084 'Paytm EDC', @1541662 'Select EDC machine to add', @1946720 'Please select an EDC machine in Session Settings', @1171143 '/api/v1/integrations/external-payment/pinelabs/devices/', @1411259 'sendPineLabsPaymentCancelRequest'. The dex holds 'com.paytm.pos', 'isPayTMPOSAvailable', 'openPayTMEDC' and 'paytmedc://paymentV2?&stackClear=true&callbackPkg=', so the app hands the payment to the separate Paytm POS app or a Pine Labs device. Absence checks: the binary AndroidManifest.xml was parsed through its string pool (253 strings) and lists 46 permission and hardware entries, including CAMERA, BLUETOOTH_* and usb.host. It has no android.permission.NFC, no android.hardware.nfc and no HCE or tech-list entry. The bundle has zero word-boundary hits for tap to pay, tap-to-pay, softpos, tap on phone, NFC, IsoDep, Stripe, Adyen, Razorpay, Plutus, SmartPOS, soundbox, Ezetap or mswipe. False positives, all non-payment: 'contactless' only appears as Contactless Delivery, 'New contactless order received at Table', isModuleContactlessMenuEnabled and oms_contactless (QR menu and ordering). 'swipe' is gesture-library code. The single dex string 'android.nfc.action.NDEF_DISCOVERED' sits among framework constants. The arm64 native libraries contain no payment kernel. Limits: (1) Only the Android app was examined. The iOS app (App Store id1535451930) was not, and Metro builds leave iOS-only modules out of the Android bundle, so the Android census does not cover a Tap to Pay on iPhone module. The shared JS still has no tap-to-pay UI strings. (2) Prime can run on a Paytm or Pine Labs Android EDC device whose partner app reads cards over NFC. That device is itself a dedicated card terminal, so it is the separate reader the claim excludes and does not satisfy the claim. This agrees with payments-emv-nfc no/B. https://d.apkpure.com/b/APK/com.urbanpiper.satellite_prime?version=latest · retrieved 2026-09-15 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 first limb fails outright: UrbanPiper ships no handheld. Its hardware page states 'Please find below the minimum specification requirements for buying hardware to use UrbanPiper products' and lists Handheld, Phone, Tablet and Terminal purely as merchant-purchased device classes with RAM, storage, CPU, screen and OS minima, adding 'Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products' -- a specification, not a product. No card reader, PIN pad or EMV/NFC capability appears in it. The second limb fails too: UrbanPiper processes no cards, since Meraki payment acceptance is the merchant's own gateway account and marketplace orders are collected by the marketplace. Prime does have a dine-in surface -- 'Captain: Perfect for your front-of-house team. Captains take customer orders, especially for dine-in. Please note, they cannot settle bills; that's handled by Cashiers' (help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas) -- but nothing in it accepts a card at the table, and no tip prompt or check splitting is documented on either host. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-09-01

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

UrbanPiper's own November 2023 product-update post (grade C, product blog), section 'Make Payments Faster and Easier with UPI QR Codes on Bills': the UPI QR Code "on Prime allows your customers to scan a QR code on their bill and pay the" exact amount "with any UPI payment app." Set-up: "This feature is free for all Prime users and easy to set up." The merchant configures a UPI ID/VPA per location in the print template, and "Our system will form a UPI URL and generate a QR code in the bill’s footer." (Quotes checked against raw HTML with comments removed; the <strong> spans around 'UPI QR Code', 'exact amount' and 'Print Templates' are not crossed.) A table-tent variant is also claimed in the October 2023 post (www.urbanpiper.com/blog/october-2023-product-updates-whats-new-in-our-restaurant-tech-platform): "Now, your customers can simply scan QR codes at their tables to see the menu, order, and pay." SO THE FIRST CONJUNCT HOLDS: the guest scans a QR code on the printed check and pays from their own phone. SHORTFALL: (1) nothing says the payment closes the check in the POS automatically. The mechanism described is a static UPI deep link to the merchant's VPA printed in the bill footer. That is a peer-to-merchant UPI transfer, and no payment-confirmation callback into Prime is described, so settlement in Prime is not shown to be automatic. (2) This is India-only UPI, not card pay-at-table. (3) The evidence is a grade-C product blog on a differentiator claim, so it cannot support `yes`. The fd KB articles (2022-2024 captures) and the current GitBook help do not document the feature: 'QR' = 0 in fd, and 'UPI' = 0 in help-llms-full. https://www.urbanpiper.com/blog/november-2023-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-12

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

UrbanPiper's Prime POS web client production bundle (read 2026-09-15) was searched in full, together with its vendors bundle, and has no tip anywhere in the cashier's payment flow. The word tip, tips or tipping appears zero times in the main bundle, and so does gratuity. There is no pre-authorisation, no incremental authorisation, no adjust window and no screen for unadjusted tips. The only authorisation in the POS is the manager PIN, described as 'PIN can be used for Void, Discount, Unlock Bill authorization in POS'. Card terminals are integrated: the client registers Pine Labs devices through '/api/v1/integrations/external-payment/pinelabs/devices'. It sends each device a payment for a fixed amount, and records the payment as a payment_mode, amount and status against the bill. Its log line reads 'Added a payment of {{amount}}. Total outstanding is {{outstandingAmount}}'. Nothing in the payment record holds a tip, and nothing adjusts a payment after it is taken. Tipping does exist elsewhere in UrbanPiper, but it is neither of the two flows this claim asks about. On Meraki web ordering, the guest picks a tip at checkout before paying. Order payloads from aggregators carry a 'Driver Tip' charge. If a Pine Labs terminal offers its own tip prompt, that is the terminal's feature, and Prime has no record of it. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-15 adversarially verified

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

The only tip object in the Atlas back-office client is a guest tip on Meraki online orders. Its settings card is headed "Tipping Configuration" with the subtext "Manage tipping settings effortlessly to enhance the tipping experience for your customers". It holds an on/off switch and up to three tip options, and the release card says "Merchants can configure up to three preferred tip values, which are shown as quick-select options". Once collected, the tip is an order charge: the customer bill reads it with "Tip"===e.title and shows it as field:"totalTip",label:"Tip",type:"debit", and the FAQ says "No. Tips do not attract taxes or charges." The client has no pool, tip-out, share, allocation or payroll setting and no employee object. Its staff screens only manage users ("Manage permissions for your staff here"). This bundle loads just five lazy chunks, all non-business libraries or the template editor. The Prime POS web client has no tip or gratuity field, so tips are never tied to a captain or cashier, and neither client records clock-ins or timesheets. Tips therefore cannot be pooled or split by hours, sales, role or points, and no per-employee tip amount exists to export to payroll. https://atlas.urbanpiper.com/static/js/main.550329ed.js · retrieved 2026-09-15 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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: card payments can be CAPTURED while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. VERDICT no -- and this is a mechanism census, not an absence of a statement. Prime genuinely has an offline mode and it is now readable, so what it does can be stated: `window.navigator.onLine` gates register verification; a Workbox service worker is registered after `getServiceWorkerState({version, offline_result:1})`; two lists are pre-cached for offline use (`/api/v1/customers/offline-list`, `/api/v1/products/location/:id/offline-top-selling-list`); and completed bills are queued and retried (`billSyncRequests`, `BILL_STATUS_SYNCING`, 'Retry to Sync Bill'). The payment record it writes offline is `{method:'cash', payment_mode:'offline', status:'success'}` -- the status is set client-side with no authorization, and the code comments the homonym itself: `isPaymentOffline = e => 'offline' === e.payment_mode`, i.e. offline means NOT-VIA-GATEWAY, which includes a card swiped on a separate terminal. Integrated card capture is the other branch and requires connectivity: it needs an `online_payment_id` and posts `allowed_payment_modes` to the terminal (pinelabs). EVIDENCE OF THE MISSING GUARDRAIL: tokenised `store and forward` 0, `deferred capture` 0, `offline limit` 0, `cumulative` 0 across the whole app -- there is no per-transaction or cumulative offline ceiling to configure because no card auth is stored for forwarding. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: 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. VERDICT no. This is a publication claim, so a bounded doc corpus settles it: help.urbanpiper.com taken from the publisher's OWN llms.txt manifest (llms-full.txt, 240 KB, the vendor's declared article set) plus the urbanpiper.helpjuice.com sitemap. EVIDENCE: `offline` returns 8 hits in that corpus and not one concerns payment capture -- a location taken offline from a delivery platform (permanent closure), a printer 'offline or unreachable', aggregator menu mapping 'carried out offline with assistance from the Zomato/Swiggy team', and the generic 'online and offline operations' intro. Tokenised `decline` 0, `who bears` 0, `chargeback` 0; `liability` scores 9 hits and every one is POISON -- they are the Zomato tax-liability rules ('5% Tax - Aggregator's Liability (Default)', '5% Tax - Merchant's Liability (with Tag)'), nothing to do with payment loss. In the app the only post-reconnect failure surface is a BILL sync banner ('Retry to Sync Bill', 'Sync Void Bill') and an 'Error Report' / 'View Error Report' over bills, not over payments; there is no failed-offline-payment report. Retrieved 2026-09-18. https://help.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

UrbanPiper's Prime POS web-app production bundle (read 2026-09-14) includes first-party gift cards: 'Allows you to manage Gift Cards and redeem them at outlets', a 'Gift Cards' list with 'New Gift Card' and bulk import, and a 'gift-card' tender looked up from /api/v1/sales/gift-cards/for-redemption and capped at the card amount. The list tracks a single redeemed bill per card ('Redeemed <amount>' or 'Not Redeemed') and an expiry, so it shows no running real-time balance. Nothing shows redemption scoped to every location in a group or through online ordering. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

payments-house-accounts

UrbanPiper's Prime POS web-app production bundle (read 2026-09-14) supports settling bills to a customer on credit (permission p/settle-bill-credit), with a per-customer credit_limit (editable under p/credit-limit-customer, and a 'Default credit limit when customers are created' setting), a running total_outstanding and a credit balance log API. The client refuses credit when the limit is zero ('Credit not approved for customer'). Its 'Customer has reached or crossed the allowed credit limit' check compares against a misspelled field (credit_limitt), so this build never triggers that warning; server enforcement is not shown. No periodic customer statement or invoice generation was found. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

The multi-tender half is documented in the order schema and stated in as many words: 'payment (array[object]): A list of payment objects. A customer can use more than one mode of payment to pay for an order (commonly, seen in Meraki orders)', each object carrying 'amount (float): Amount paid through given payment option' and 'option (string): The payment option used. Can be one of: prepaid, payment_gateway, cash, card_on_delivery, paytm, wallet_credit, simpl, aggregator.' The array is unbounded, so no cap below eight ways is imposed. SHORTFALL on the splitting half: nothing splits a check. There is no seat, cover or guest-position concept anywhere in the order model, no even-share or by-item split function, and no split-check article on either documentation host -- the payment array records how a single order was paid for, not a division of one check among several payers. Prime does settle bills (cashiers 'process bills, and complete settlements') but that screen is undocumented, and it is amounts paid rather than a splitting engine that the API exposes. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-01

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

UrbanPiper's Prime POS web-app production bundle (read 2026-09-14) gates line and bill voids (p/d-bill), open and fixed discounts (p/apply-bill-open-discount, p/manage-discounts-pos), FOC and credit settlement (p/settle-bill-foc, p/settle-bill-credit) and payment reversal (p/reverse-payment) behind a 'Needs manager approval' modal: 'Authorize with Pin' or 'Authorize with store manager credentials', checked server-side per location. No permission gate was found for refunds, and no no-sale/drawer-open control was found. A voided line writes a 'Line item voided' bill-log entry carrying the authorizing user, but later voids on the same bill overwrite that entry's description and timestamp, so the log is neither immutable nor a complete record of each approver. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

payments-chargeback-tooling

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: in-product dispute/chargeback dashboard listing open disputes with evidence submission assembled from the POS transaction record. VERDICT no. EVIDENCE: tokenised `chargeback` = 0 and `dispute` = 0 across the entire Prime store-level app (110 KB literals, 300 API paths, ~540 routes) and 0 across the 240 KB help llms-full corpus. Prime's payment objects are bills, payments, refunds and 'Reverse payment' / 'Reversed a payment of {{amount}}.' -- a refund is issued by the merchant, not contested with an issuer. This closes the 325th hold from the other direction: the Atlas back-office 'Disputes' app contests MARKETPLACE deductions (Uber Eats, DoorDash, Grubhub), and the store-level POS, now censused, has no card-dispute surface at all, so neither app carries the claim. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · 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

UrbanPiper's web ordering bundle ships a saved-card vault for signed-in guests. A vault session is opened per customer ('customer_ref' is the guest's userbiz_id) and store. Cards are added only as a processor token: 'e.gateway.tokenizeCard({publicKey:e.vault.public_key||""', then 'e.addCard(n.gateway_token,t)', which posts '{gateway_token:t,is_default:...}' to '/vault/cards'. Later payments either charge a saved 'card_id' or offer 'Save card for later', and the card picker reads 'No saved cards yet.' when the guest has none. The checkout only uses the vault when the store turns on the 'useVault' checkout setting and the guest is not a guest checkout ('em&&!!ex&&!ex.is_guest_checkout'). Shortfall: vault sessions are keyed to one customer and one store, and nothing shows the card being reused for phone orders or in-store at the POS; the no-PAN property comes from token-only code, not from a vendor statement. https://gen-korean-bbq-house.order.urbanpiper.com/_next/static/chunks/pages/_app-b86f7092032d0f65.js · 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

The vendor never holds merchant funds, so it has no deposit schedule of its own to publish and nothing to advance. Meraki payments are taken by a gateway the merchant owns: 'Click Add Gateway. Select your preferred payment gateway from the list (e.g., Stripe, Razorpay, PayU, Paytm, etc.)... Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard' -- twelve providers across India, MENA, KSA, UK, LATAM and USCAN -- so settlement timing is set by Stripe or Razorpay under the merchant's own contract with them. Marketplace orders are collected and remitted by Zomato, Swiggy, Talabat and the rest under their own payout terms, which is why UrbanPiper's reports frame the money side as reconciliation (the order transactions report's wallet-credit field exists 'for payment reconciliation, especially with aggregator-specific wallet systems'). Nothing resembling a deposit schedule, settlement window, next-day funding or instant-payout product appears anywhere across the 116 help.urbanpiper.com pages or the 87 api-docs.urbanpiper.com pages retrieved 2026-09-01. The vendor's own billing direction runs the other way: the Atlas Billing role handles the restaurant's invoices and credit purchases from UrbanPiper. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-01

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

The per-location half is documented as a supported configuration: "You can configure gateways globally for all outlets, or per outlet if needed", so two outlets can settle through two different gateway accounts while both report into one Atlas tenant, and consolidated reporting across those locations exists in Central Report. SHORTFALL: everything downstream of the gateway is outside what the vendor documents. No article mentions bank accounts, MIDs, legal entities or split settlement; where the money lands is a property of the gateway account whose credentials were pasted in, and UrbanPiper documents neither a settlement destination nor a split-settlement construct of its own. The claim is satisfied in effect for a merchant willing to run one gateway account per entity, and is nowhere stated as a feature. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-08-31

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

CLAIM: the vendor provides P2PE and a current PCI DSS 4.x AoC / P2PE listing available to merchants on request. VERDICT: no. THIS ANSWERS THE 325th HOLD ('payments run in Prime, which is unbounded, and a list of certificates held is not a statement about the payment path') WITH THE PAYMENT PATH ITSELF AND THE AUTHORITATIVE REGISTRY, not a vendor certificate list. (1) THE PATH, IN-STORE: the complete Prime bundle (326th census, no lazy loader) sends card payments to an external acquirer device - /api/v1/integrations/external-payment/{devices, payments, payments/{id}/status}, a Pine Labs branch (INTEGRATION_PINELABS, /external-payment/pinelabs/devices, /pinelabs/store-pos-code, sendPineLabsPaymentCancelRequest) and a Paytm branch (isPaytmPayment, online_payment_id.includes('paytm')); Prime stores only method, amount and reference. (2) THE PATH, ONLINE (new): payments.svc.urbanpiper.com/openapi.json, the production payments-service contract (29,613 B, 20 paths, served anonymously), takes cards only as a gateway token - AddCardRequest = {gateway_token, is_default, billing_details}; SavedCardResponse = {card_id, brand, last4, exp_month, exp_year}; checkout is /v1/txn/checkout-url (a gateway-hosted page) - with no PAN, track, CVV or encryption field anywhere; its AppEnum = meraki, prime, atlas, codex, order-line, qubriux. (3) THE REGISTRY (new, re-derived today through the PCI SSC page's own public listing call, admin-ajax action get_p2pe_solutions_data with the page nonce): 136 Valid + 59 Expired P2PE solutions = the complete PCI SSC P2PE register; 'UrbanPiper' 0 in both. The two acquirers Prime drives DO hold listed solutions - 'Plutus P2PE Solution', Pine Labs Pvt. Ltd, P2PE v3.1, ref 2024-00680.001, reassessment 2028-01-24; 'Paytm All-in-One Payment Suite', Paytm Payments Services Ltd., P2PE v3.1, ref 2025-01333.001 - so the P2PE on this path is the ACQUIRER'S product, not UrbanPiper's (the 331st rule: an acquirer's terminal is not the vendor's device). (4) Visa's Global Registry of Service Providers, queried through its own public company-name lookup (www.visa.com/splisting/api/company?companyName=): 'UrbanPiper' [] and 'Urban Piper' [] against positive controls 'Heartland' (2 hits), 'Pine Labs' ('Pine Labs Limited', 'Pine Labs Payment Services Provider LLC') and 'Razorpay' (3 hits). The vendor's own privacy policy says the same thing in prose: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS)'. READING: UrbanPiper is designed out of the cardholder-data path and provides neither a P2PE solution nor a listed PCI DSS validation; a Prime merchant gets P2PE only by contracting Pine Labs or Paytm. WEAKNESS NAMED: an AoC 'on request' is never publicly enumerable and the Visa registry is a floor; the `no` rests on the P2PE conjunct, which the PCI SSC register bounds completely, and on the vendor having no card data to attest for. Retrieved 2026-09-18. https://www.pcisecuritystandards.org/assessors_and_solutions/point_to_point_encryption_solutions/ · retrieved 2026-09-18 adversarially verified

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

UrbanPiper has no driver entity. The only rider representation in the published partner API is a per-order payload the POS sends to UrbanPiper: 'rider_data' with exactly 'rider_data.rider_name' (Rider contact name) and 'rider_data.rider_phone_number' (Rider contact phone number), plus a status enum (ASSIGNED / UNASSIGNED / AT-STORE / OUT-FOR-DELIVERY / RIDER-REACHED / DELIVERED / NO-RIDER-FOUND) that UrbanPiper relays onward -- 'Currently, Swiggy is the sole user of this feature.' There is no rider object to create, no clock-in/out, no assignment state held by UrbanPiper and no per-rider run history: riders are named per order and discarded. The staff model confirms it from the other side -- 'Prime offers 6 standard roles' (Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator) at help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas, none of them a driver. On aggregator orders rider assignment is the marketplace's: the Zomato matrix marks 'Dispatched (UrbanPiper -> Zomato)' unsupported while relaying Zomato's own rider statuses inward. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/self-delivery-rider-management/rider-status-updates · retrieved 2026-09-01

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

Prime's Order Tracker is a real dispatch-adjacent board: orders move New -> Accept -> In Progress -> Food Ready -> Awaiting Pickup -> 'When picked up by the rider, the order moves to Dispatched. View dispatched orders under Dispatch Status', and the Filter option lets you 'view orders for a specific location, platform, or sort by delivery time or time left to deliver' -- i.e. undispatched orders and per-order elapsed/remaining time. SHORTFALL on the other two limbs: there is no driver availability view, because UrbanPiper holds no driver roster, and nothing anywhere batches 2+ orders into one run. Assignment belongs to the marketplace -- the Zomato capability matrix (help.urbanpiper.com/ordering-channels/zomato/manage-your-orders) marks 'Dispatched (UrbanPiper -> Zomato)' as NOT supported while 'Rider Status Updates' and 'Rider Reassignment' are inbound relays only, and for self-delivery the POS pushes rider identity to UrbanPiper rather than the reverse. https://help.urbanpiper.com/store-manager/prime-app/manage-orders-on-order-tracker · retrieved 2026-09-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

324th, CELL MOVED unknown -> no/B. CLAIM: a live map view with geocoded stops AND system-generated route sequencing (turn-order optimisation) for a multi-stop run. VERDICT: no. EVIDENCE: UrbanPiper's only mapping surface is the Direct Ordering > Google Maps help page, which enumerates every use: 'Google Maps is integrated into multiple parts of your Meraki website' -- Store Selection ('the system checks if a store is available within the selected radius'; 'All available stores are also displayed on a map on the Store Locator page'), Adding or Updating Customer Address (autocomplete, drag a pin) and the Order Success Page, where 'A static map is displayed on the order confirmation page'. Its prerequisite list is exactly three Google APIs -- Maps JavaScript API, Places API, Geocoding API -- with no Directions, Routes or Distance Matrix API, which turn-order optimisation would require. The rider surface is a single-order coordinate relay (see delivery-driver-tracking). CONTROLS: 'route optimi' = 0/0, 'multi-stop' = 0/0, 'dispatch map' = 0/0; 'sequencing' = 1/0 and it is API request sequencing, 'stops' = 1/2 and every hit is the verb ('your team stops juggling tablets'). BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/google-maps · retrieved 2026-09-17 adversarially verified

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

delivery-driver-tracking

324th, CELL MOVED unknown -> no/B. CLAIM: captures live driver GPS position FROM A DRIVER-FACING MOBILE APP and surfaces it back to THE DISPATCH SCREEN. VERDICT: no -- both conjuncts fail, and the one coordinate endpoint runs in the opposite direction. EVIDENCE: the Self-Delivery Rider Management section (three pages: section index, Rider Live Tracking, Rider Status Updates) holds UrbanPiper's only rider-coordinate surface, POST /ext/api/v1/generic/pos/rider-location/ with body {order_id, location:{latitude, longitude}}, documented as 'This endpoint is used to send the rider updates to the aggregators for self-delivery orders... it is exclusively utilized by Swiggy' -- the MERCHANT'S POS pushes the coordinate INTO UrbanPiper, which forwards it to Swiggy. Its parameter table is the entire payload: order_id 'UrbanPiper order ID', location.latitude 'latitude of the rider carrying the order', location.longitude. UrbanPiper ships no driver-facing app: the first-party apps in the census are Prime Store Manager (app and web) and the Meraki guest site/app, and the Prime pages enumerate its whole screen set (86ing, printer connection, wifi, auto-print, paper, login, order tracker, notifications, pause/resume; web: 86ing, printers, cloud printing, notifications, store status, print automations, KOT printing, scan-and-pack) with no dispatch map. CONTROLS: 'driver app' = 0/0, 'rider app' = 0/0, GPS = 0/0, 'dispatch screen' = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/self-delivery-rider-management/rider-live-tracking · retrieved 2026-09-17 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

The store schema's zip_codes field carries the platform's deliverability rule verbatim: 'A set of Zip codes to which the store can deliver. NOTE: if this is set for even one store, the platform will only consider Zip codes on all stores for checking deliverability. The logic of delivery based on distance or an area polygon will not be considered. This applies for the merchant's own website and apps.' That names three mutually exclusive deliverability modes -- postcode list, distance, and area polygon -- so first-party delivery areas are not solely a radius or a ZIP list. Two caveats worth recording: the polygon EDITOR is not documented anywhere on either host (help.urbanpiper.com/direct-ordering/google-maps describes only the consumer-side radius check at store selection), and no drive-time isochrone is mentioned; the claim is satisfied by the polygon limb alone. https://api-docs.urbanpiper.com/downstream/api/endpoints/stores/add-update-stores · retrieved 2026-09-01

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

The store object is the platform's full configuration surface for a location and it carries exactly one of each: 'min_order_value (float) -- Mininum amount for an online order to be accepted at this store' and 'min_delivery_time (integer) -- Minimum time (in seconds) required to deliver an order', both per store, not per area. Delivery fee is a Charge, and the Charges model is likewise zone-free: the API's menu/charges page says 'delivery charges are generally at the order level' and the sample menu payload titles one 'Delivery Charge' / 'Fixed Delivery Charge on order', while the Atlas guide (help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-charges) gives a charge three modes -- Item Quantity, Order Subtotal, Item Price -- and scopes it by pairing an Item Group with a LOCATION Group. SHORTFALL: the platform does have area-polygon/distance/zip deliverability (see delivery-zones-polygon) but no fee, minimum or promise time hangs off that area -- vary any of the three and you are varying it per store or per location group, not per zone, and nothing applies a zone-specific value from the validated customer address. https://api-docs.urbanpiper.com/downstream/api/endpoints/stores/add-update-stores · retrieved 2026-09-01

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

Validation and geocoding are documented and mandatory: on the Meraki storefront 'Customers can search for their address using autocomplete' or 'drag a pin on the map to select their exact location', and the merchant must enable Maps JavaScript API, Places API and Geocoding API in their GCP project or 'Maps-related functions on your website will not work'. A serviceability test runs at the same moment -- 'When a customer searches for a location, the system checks if a store is available within the selected radius and assigns it.' SHORTFALL: the documented check is a store-radius assignment, and no page states the guest-facing outcome when the address falls outside it -- no rejection message, no out-of-zone flag, no checkout behaviour is described on either host. Related evidence that out-of-radius is at least a recognised state, though on the aggregator leg rather than first-party: the order-status API lists 'out_of_delivery_radius' among the cancellation reasons allowed for merchant-delivery orders. https://help.urbanpiper.com/direct-ordering/google-maps · retrieved 2026-09-01

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: tracks per-delivery driver compensation inputs -- mileage/distance per run, per-delivery flat reimbursement, driver-retained tips -- and exports them to payroll as separate reimbursement vs wage lines. VERDICT no. EVIDENCE: Prime's rider objects are aggregator-side ('Rider Temperature was', `/zomato/request-additional-rider`, 'Driver Tip' as one of the relayed charge titles), and the platform has no payroll export at all -- which the 326th already landed as labor-payroll-export-formats = no on this same census. BOUND/CONTROLS over the whole app: tokenised `mileage` 0, `reimbursement` 0, `distance` 0 in a compensation sense, `payroll` 0. Every conjunct shortfalls, so this is a no rather than a partial. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

CLAIM: a driver cash bank / settle-up flow reconciling cash collected, orders assigned and tips owed at end of shift, producing a per-driver over/short figure. VERDICT: no. EVIDENCE: Prime's cash reconciliation is per-REGISTER-SESSION, never per driver. The Register Session detail screen's complete tab list is Overview, Petty Cash and Payment Receipts; Petty Cash is a movements ledger (Name, Method, Amount, Note, Created On, with a Withdraw/Deposit Cash action, GET /api/v1/locations/registers/sessions/), and the settings prose is "Payment methods will be used at bill settlement. Reconcile expected vs actual balance when closing register" and "your staff will be prompted to close their registers and reconcile day's sales and cash". Riders in Prime are an assignment object only -- Assign Rider, Additional Rider Assigned, /delivery/agents/assign/, /delivery/agents/unassign, /delivery/dash/request, /swiggy/request-rider-eta, /zomato/request-additional-rider -- with third-party logistics (Dash) or self-delivery (Comet). `cash bank`, `settle up`, `over/short`, `over and short` are 0 across every corpus, and there is no per-rider money object of any kind (and no tip, so the "tips owed" conjunct is unreachable too). PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

The vendor states it integrates on-demand courier networks and names providers: the partner table's Logistics Partners row reads "Access a network of delivery providers to ensure your orders get to your customers efficiently" against "Dunzo, Shadowfax, and others." SHORTFALL, and it is most of the claim: this is a first-party marketing page inside the help centre (it closes with "Book a demo"), graded C accordingly, and it is the ONLY place logistics dispatch is mentioned. No article documents handing an order to a courier, and nothing describes a courier quote or courier status returning into the order record. The rider status fields that ARE documented -- "Rider Status Updates... Assigned, Arrived, and PickedUp" and "Rider Reassignment" -- belong to the MARKETPLACE's own rider on a marketplace order, which is a different thing from dispatching a first-party order to a DaaS courier. https://help.urbanpiper.com/basics/partner-with-us · retrieved 2026-08-31

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

324th, CELL MOVED unknown -> no/B. CLAIM: 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. VERDICT: no. EVIDENCE: UrbanPiper does have a DaaS arm -- the Order Relay payload carries dash_config, 'Information about the third-party delivery logistics platform called Dash. Note: Merchants who opt-in for the Dash platform will have an option to get their orders delivered through a collection of delivery partners that we partner with (like a Hub of Delivery partners)' -- but the object is a CLOSED TWO-FIELD ENUMERATION, {"auto_assign": false, "enabled": false}, and the guide defines both fields exhaustively: enabled opts the merchant in, and auto_assign is 'POS do not need show any UI component to initiate a dispatch. The system will auto-trigger a dispatch through Dash. POS only need to indicate that a rider will be auto-assigned', the alternative being 'POS should show the required UI components to allow the operator to request for the order's dispatch through Dash (an API endpoint will be made available soon).' Dispatch is therefore all-Dash or operator-initiated; there is no in-house-first rule and no condition on which to overflow. CONTROLS: 'delivery zone' = 0/0, 'wait threshold' = 0/0, overflow = 0/0, 'route optimi' = 0/0, geofence = 0/0; 'fallback' = 1/0 and it is a backup printer path. The only rider-unavailability construct in the corpus is the store-off reason code rider_not_available (beside out_of_delivery_radius), which turns the STORE off rather than rerouting the order. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-17 adversarially verified

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

UrbanPiper documents first-party marketplace integrations it operates itself rather than reselling, with per-platform authorisation flows, feature matrices and a stated activation timeline ("typically takes up to 48 hours to go live"). Uber Eats has its own documented integration section (getting started, menu update and publish, menu timings, order prep time), as do Zomato, Swiggy and Keeta. SHORTFALL, and it is the claim's own named list: of DoorDash, Uber Eats and Grubhub, only Uber Eats is documented. DoorDash and Grubhub appear once each, in the Business Manager introduction's prose -- "organize menus across various online food delivery platforms such as DoorDash, Grubhub, and Uber Eats" -- with no integration guide, no feature matrix and no authorisation flow for either anywhere in the help centre. A marketing sentence naming a marketplace is not a certified integration. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

The per-platform feature matrices in the help centre answer this directly and identically for every marketplace documented. Zomato and Swiggy both carry "Real-Time Order Push -- Orders are sent to your system the moment they are placed" and "Auto-Acceptance -- Automatically accept new orders without manual intervention", with "Order with Options -- Orders with custom options are fully supported and relayed correctly"; the Keeta matrix adds "Orders placed on Keeta are pushed to your UrbanPiper-integrated system instantly." The integration overviews state that "You can receive orders from Zomato and have them sent directly to your POS." Firing to kitchen hardware is documented in the Scan and Pack article, whose test procedure reads "Head to the Live Orders section and acknowledge an incoming order. A KOT and a barcoded bill are generated automatically. Go to the KDS -- the order will appear there." No tablet re-keying and no manual accept step appears anywhere in the order path. Read from help.urbanpiper.com/llms-full.txt (231,780 bytes, retrieved 2026-08-31), sections "Zomato / Integration Overview", "Swiggy / Integration Overview", "Keeta / Manage Your Orders" and "Prime web / Scan and Pack Workflow". https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

The master-menu-out-to-marketplaces half is documented in full and the channel-markup half is not. Menus are imported from the connected POS ("If you have a live POS integration on Urban Piper, you can make menu changes on the POS and import them to be published on the DSPs directly... manage your menu from a single platform") and published by selecting locations and platforms, so no separate menu is maintained in each portal. What publishing updates is enumerated per marketplace: "Product names and descriptions / Prices, taxes, and charges / Modifier groups, options, and variants / Product images / Product availability", with "Menu updates typically take up to 5-10 minutes to appear on the UI." SHORTFALL: the claim also requires channel-specific price markups, and UrbanPiper's own documented pricing axis is the LOCATION ("Location-Based Pricing -- Apply different prices for different locations"). Per-channel prices are documented only as something configured in the connected POS (Foodics Price Tags) or as a DSP-dependent fulfilment-mode price, never as a markup rule in Atlas. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

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

Documented at both item and modifier level, in two products, against named marketplaces. In the Prime app: "To mark an item in stock or out of stock, click on the toggle", "Select modifiers and toggle them on or off", then a snooze duration -- "Choose a time period to turn the item off, either indefinitely or for a specific duration." In Prime Order Tracker's Stock Control: "Toggle the top button and hit Save to switch off the particular item or modifier on the aggregator's UI", verified through "the Logs to verify if the item was successfully turned off." Latency and scope are stated for Keeta: "Updates are real-time. Changes take effect immediately on Keeta", "Bulk updates are supported", for items and, identically, for modifiers. Zomato and Swiggy both list "Product Inventory Snooze -- Toggle items as out-of-stock for a set period." RECORDED LIMIT, which does not defeat the claim but belongs with it: automatic restoration is a snooze timer, not a stock signal, and on Keeta it does not exist at all -- "Auto stock-in by Keeta is not supported. Items do not automatically restock at the start of the day or at store closing time. Stock in must be triggered either manually in UrbanPiper." Read from help.urbanpiper.com/llms-full.txt, sections "86'ing an Item or Modifier" (Prime app and Prime web) and "Keeta / Manage Item Availability" and "Manage Modifier Availability". https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

Per-platform pause from inside the product is documented twice. In the Prime app: "Click on the platform toggle option... After selecting the store, you will see the different platforms that the store is associated with. To pause or unpause the store on any desired platform, simply click on the toggle for the respective platform." In Prime Order Tracker the same action runs through Session Settings and is confirmed in a log. Zomato and Swiggy both list "Store Availability -- Manage your store's availability directly from UrbanPiper." SHORTFALL, which is the claim's own second half: no timed auto-reactivation exists. The only timing construct is a location operating-hours schedule, and the docs warn that the two interact badly -- "Any manual override of store availability will disable store timing. The store time will need to be synced again." The Zomato troubleshooting article documents further platform-side overrides the operator must undo by hand: after a menu publish Zomato re-enables a store automatically, so "if the store was already turned off before the menu was published, you will need to manually turn it off again", and a rejected order can make Zomato close the store, after which it must be "manually turned back on within 4-5 minutes." https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

The report is documented field by field and several fields exist precisely for 3P reconciliation: 'External Platform ID ... Provides an additional reference point for reconciling with the aggregator'; 'Payment Transaction ID ... Essential for matching online payments with your bank statements'; 'Aggregator Discount -- the part of the discount that was funded by the online platform' split from 'Merchant Discount'; 'Wallet credit amount ... For payment reconciliation, especially with aggregator-specific wallet systems'; plus Charges, Merchant Taxes and a per-order Delivery Type of Partner or Self. It exports to CSV/XLSX and can be scheduled daily by email. SHORTFALL, and it is the heart of the claim: nothing matches a marketplace PAYOUT DEPOSIT to these orders, because no payout or settlement file is ingested anywhere on either host; commission is explicitly out of scope -- 'Merchant Total ... the amount your restaurant is expected to receive from the order, after aggregator discounts but BEFORE aggregator commissions'; and there is no marketing-fee, refund/adjustment or missing-and-unpaid-order identification. The merchant is given the sales side and must do the matching. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-09-01

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

Integration health is surfaced to the operator through two documented mechanisms. A public per-component status page covers "Integrations (e.g., with POS and delivery platforms) / Dashboard performance / API availability / Scheduled maintenance / Known incidents or outages", posts "Issue identification and investigation / Ongoing resolution progress / Final incident resolution and root cause (post-mortem)", and takes email or SMS subscriptions. Inside the product, Prime Order Tracker writes a Logs entry for store-status and stock actions that the operator is told to check to confirm the change landed, and the Zomato troubleshooting article teaches operators to read a specific log message -- "All items are in inactive state" -- as the signature of a lapsed GST registration. SHORTFALL: all of that is CHANNEL and CONFIGURATION health. Nothing in the help centre documents a failed or rejected ORDER injection surface -- no failed-order queue, no per-order retry, and no alert on an injection failure -- which is the specific thing this claim asks for. https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

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

Branding is real and first-party: the Mask ID guide covers configuring 'a custom Mask ID for SMS communications (OTP, ORDER UPDATES, and marketing campaigns) on the UrbanPiper Meraki platform' -- DLT template registration, PE-TM bonding with Gupshup, then 'you can now send all SMS (OTP, order updates, campaigns) via Meraki using your Mask ID' -- and the storefront itself sits on the merchant's own domain (help.urbanpiper.com/direct-ordering/configuring-a-custom-domain). SHORTFALL: no page documents a guest-facing status or tracking PAGE. The only post-order screen described anywhere is static -- 'Order Success Page: a static map is displayed on the order confirmation page' (help.urbanpiper.com/direct-ordering/google-maps) -- and since UrbanPiper holds no driver state for first-party orders beyond what a POS or aggregator relays to it, nothing documents a page or link driven by live driver state. What the order-update SMS contains is also unspecified: the templates are the merchant's own, registered on the DLT portal. https://help.urbanpiper.com/direct-ordering/setting-up-your-own-mask-id-for-sms · retrieved 2026-09-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

The quoted time does vary, but only between two hand-set constants and only when a human says so: in Atlas, 'Settings -> Platforms -> Automations Tab -> Food Preparation Time', you enter a 'Normal Prep Time' and a 'Busy Prep Time' ('Busy time must be greater than the normal prep time'), apply them at 'Location level or Business level', and 'Save and Sync' to push them to the channel. The article then states the switch explicitly: 'The active prep time mode (Normal or Busy) is controlled from Prime -- not Atlas. Atlas is used only for configuring and syncing prep time values.' SHORTFALL: that is a manual two-state toggle, not a dynamic quote. The delivery half is a flat constant too -- the store schema carries a single 'min_delivery_time (integer) -- Minimum time (in seconds) required to deliver an order' per store (api-docs .../api/endpoints/stores/add-update-stores) -- and no page on either host describes kitchen load, order volume, rider availability or zone drive time feeding the quoted time. The aggregator-side prep_time bounds relayed in the order payload (prep_time.min / .max / .adjustable) are the marketplace's constraints on what the store may set, not an automatic adjustment by UrbanPiper. https://help.urbanpiper.com/ordering-channels/uber-eats/manage-order-prep-time · retrieved 2026-09-01

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

delivery-offline-behavior

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: vendor documents explicit offline behaviour for delivery -- whether cash delivery orders, driver assignment and driver settlement continue during an internet outage. VERDICT no. Publication claim, bounded corpus: help.urbanpiper.com from the publisher's own llms.txt manifest (240 KB) + the helpjuice sitemap corpus. EVIDENCE: all 8 `offline` hits are store-status toggles, a printer 'offline or unreachable', and aggregator menu mapping 'carried out offline with assistance from the Zomato/Swiggy team' -- the last being a homonym for 'out of band', not 'network down'. Tokenised `driver.{0,30}offline` 0, `dispatch.{0,30}offline` 0, `outage` 0. In the app itself delivery is aggregator-mediated (`/zomato/request-additional-rider`, 'Rider') and the offline queue that does exist covers bills only (`billSyncRequests`), with no driver-assignment or settlement branch. Retrieved 2026-09-18. https://help.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

Meraki is explicitly sold as self-branded ordering websites and apps, positioned against marketplace commissions. https://www.urbanpiper.com/ · 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

Hub markets updating all online menus in real time with one click across Swiggy, Zomato, UberEats and Talabat, driven from the existing POS. https://www.urbanpiper.com/hub · 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

A branded app is a documented product, not an inference. Meraki is "UrbanPiper's self-branded, commission-free online ordering platform for restaurants. It allows you to build and launch your own website and mobile app -- complete with customizable menus, discounts, analytics, and marketing tools -- without relying on third-party aggregators", under "Full brand control: Tailor store design, menus, and customer experience under your own identity", and the app is corroborated elsewhere as a real running artefact: push-notification campaigns reach "users who have your app installed" and "will only be received by users who are logged into your app". SHORTFALL, and it is what separates this claim from a mobile web page: nothing documents publication to the App Store or Play Store -- not the listing process, not who owns the developer account, not review handling, and not whether iOS and Android are both delivered. The custom-domain article covers the WEBSITE only (Atlas > Meraki > Editor > Domain, CNAME/A records, 24-48 hour propagation). Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-08-31

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

Accounts are real: campaign messages personalise from the customer record with {{user_name}}, {{user_phone}}, {{user_email}}, {{user_points}} ('the customer's current loyalty points balance') and {{user_wallet_balance}}, and push notifications 'will only be received by users who are logged into your app'. Addresses are held per customer -- the Meraki Google Maps article documents 'Adding or Updating Customer Address' with Places autocomplete and pin drag (help.urbanpiper.com/direct-ordering/google-maps). SHORTFALL on the other two limbs. Saved/tokenized payment: the payment-gateway article enumerates twelve gateways in a region matrix (Razorpay, Paymentos, PhonePe, Instamojo, Paystack, Paytabs, Stripe, Paytm Blink, Paytabs v2, PayU Latin America, Mercado Pago, FreedomPay) and lists the enable/disable options as Online Payments, Cash on Delivery and 'Wallets or Loyalty Points (if configured)' -- no card vaulting, tokenization or saved instrument anywhere in that configuration surface. One-tap reorder: absent from all 116 help pages and all 87 API pages; the word reorder does not occur on either host. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-01

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

UrbanPiper's own ordering storefront code shows suggested items at checkout, based on what is in the cart. The Next.js checkout page runs 'let e=null==ew?void 0:ew.map(e=>e.id);d.Ay.getRecommendedItems(e)' and lists the results under the cart, using the GraphQL query 'getRecommendedItems(item_ids: $itemIds, fulfillment_mode: $ffMode ...)'. The older Meraki web cart and the QR cart do the same, calling 'v2/items/<ids>/recommendations/'. If the cart-based list comes back empty, they fall back to a general list ('getRecommendedItems(null,...)'). Each merchant can switch the cart widget on or off with the menu-page setting "recommendedItems", read through 'showRecommendedItemsWidget', and clicks send a 'RECOMMENDED_ITEM_CLICKED' analytics event. Not shown: the server picks the suggestions, so nothing says whether the merchant sets the rules or an algorithm (such as order history) chooses them. The bundles also show no upsell rule set-up and no attach-rate reporting, and the words 'upsell' and 'cross-sell' never appear in them. https://gen-korean-bbq-house.order.urbanpiper.com/_next/static/chunks/pages/checkout-29f5664186180ebe.js · retrieved 2026-09-15 adversarially verified

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

Scheduled ordering is supported end to end: the order-relay reference has a 'Future/Scheduled Order' section -- 'A few aggregators allow the customers to place the orders for future date-time (ex: A customer can place an order for tomorrow)' -- with the flag the POS partner must read; certification requires testing an 'Order with Is future order? toggle enabled' (api-docs .../integration-certification/testing-and-validation); the reporting layer exposes 'Request Delivery Time' plus 'Time Slot Start / Time Slot End ... If the customer chose a specific delivery window' (help.urbanpiper.com/data-and-reports/order-transactions-report); and the Lightspeed K-Series integration exposes a 'Food prep time (in minutes): Set-up to establish the delay in relay of Future orders (only) to POS'. SHORTFALL: there is no pacing. No per-slot or per-daypart capacity, order cap or item cap appears on either host, and nothing closes a slot when the kitchen saturates -- the only load controls documented are manual (the Normal/Busy prep-time toggle switched by staff in Prime) or blunt (store pause/resume, item 86ing). 'Throttle' on these hosts refers exclusively to API request rate limits. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-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

Two of the four modes are documented with mode-specific pricing and item eligibility. "A Fulfillment Mode defines how a customer receives their order", with delivery and pickup as the standard pair; delivery is on by default and pickup is enabled per outlet; an item can be priced differently per mode (the worked table gives Pizza Margherita at $10.00 delivery and $9.00 pickup) and can be restricted to one mode -- "Ice Cream Sundae -> Pickup only (not available for delivery)." SHORTFALL on the rest of the claim. Curbside with arrival check-in and dine-in or QR table ordering are absent from the help centre entirely. Mode-specific PREP timing is not a documented setting here (prep time appears only as a value relayed on marketplace orders). And the whole mechanism is delegated rather than owned: enabling pickup means "Contact your DSP Point of Contact (POC)", and both the per-mode pricing and the per-item restriction carry the same caveat -- "Support for fulfilment mode-specific pricing varies by DSP", "Item-level fulfilment restrictions depend on DSP support." https://help.urbanpiper.com/business-manager/creating-a-menu/understanding-fulfilment-mode-for-an-item · retrieved 2026-08-31

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

UrbanPiper product-update post (October 5, 2023, live on www; grade C): "Now, your customers can simply scan QR codes at their tables to see the menu, order, and pay." and "also integrated table number recognition and introduced staggered ordering processes, ensuring a seamless fit for your dine-in restaurant". The March 2024 update post (www.urbanpiper.com/blog/march-2024-product-updates-whats-new-in-our-restaurant-tech-platform) repeats that customers can "scan a QR code to access your restaurant’s menu, place an order, and pay for a meal", calls it "an add-on feature for your existing plan", available for India & MENA partners. Scan-to-order and scan-to-pay at the table are therefore claimed by the vendor. SHORTFALL: (1) splitting the check from the QR flow is not described anywhere in the corpus; (2) tipping is not described for QR ordering in fd or www; (3) attaching to the existing POS check is only implied by 'staggered ordering', never stated; (4) paid add-on limited to India & MENA; (5) evidence is marketing-grade C, no help or KB article for QR Code Ordering exists in the fd or current GitBook corpora (changelog.urbanpiper.com is robots-barred and was not read). Generic QR advice posts (5-advantages-of-using-qr-codes, digital-menu-design) were NOT used. https://www.urbanpiper.com/blog/october-2023-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-12

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

324th, CELL MOVED unknown -> no/B. CLAIM: the vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. VERDICT: no. EVIDENCE: the census names every first-party surface UrbanPiper ships and a kiosk is not among them -- Atlas/Business Manager, Prime Store Manager (app and web), Hub, Meraki, Data & Reports, Orderline AI, and the POS/aggregator integrations; the site's product navigation is 'Orderline AI / Hub / Meraki' on every regional variant. The only hardware UrbanPiper issues is defined in the Merchant Agreement: 'Hardware: means the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper under this Agreement', priced on exit at '$350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem' -- an order-receiving kit, not a guest-facing terminal. CONTROLS: kiosk = 0/0, 'self-order' = 0/0, 'self-ordering' = 0/0, EMV = 0/0, unattended = 0/0, ADA = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-17 adversarially verified

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

324th, CELL MOVED unknown -> no/B. CLAIM: 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. VERDICT: no. EVIDENCE: the Meraki guest flow is documented end to end by the Direct Ordering section (getting started, custom domain, banner images, coupons, payment gateway, Google Maps, campaigns, SMS mask ID) and is a single-cart, single-payer checkout: store selection by radius, address by autocomplete or pin, coupon code, one payment gateway. CONTROLS: 'group order' = 0/0, 'group ordering' = 0/0, 'shareable link' = 0/0, participant = 0/0, 'split payment' = 0/0, 'split the bill' = 0/0, 'spend cap' = 0/0, 'per-person' = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-09-17 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

324th, CELL MOVED unknown -> no/B. CLAIM: 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. VERDICT: no. EVIDENCE: the Meraki fulfilment model is delivery or pickup against one published menu ('Understanding Fulfilment Mode for an item'), and the charge types an order can carry are a closed enumeration in the Order Relay payload -- 'Packaging Charge', 'Delivery Charge', 'Service Charge', 'Driver Tip', 'Surcharge', 'Deposit Charge', 'Other Charges' -- so a Deposit Charge line exists while none of the catering machinery the claim requires does. CONTROLS: catering = 0/0, caterer = 0/0, 'lead time' = 0/0, proposal = 0/0, 'house account' = 0/0, ACH = 0/0; 'quote' = 0/1 and it is the sales page's 'we will scope your requirements and provide a clear, tailored quote', 'invoice' = 12/5 and every hit is the printed KOT/customer invoice or UrbanPiper's own billing invoice, 'vendor' = 1/0 and it is UrbanPiper itself. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay · retrieved 2026-09-17 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

324th, GRADE UPGRADED D -> B, VALUE HELD AT partial. The existing note's shortfall stands and is unchanged: no POS is named among the '250+', no order payload or integration contract is published, and neither documentation host carries an Orderline page ('orderline' = 0 hits across the 115-page help.urbanpiper.com census and the 86-page api-docs.urbanpiper.com census, both re-derived 2026-09-17). WHAT IS NEW IS THE EVIDENCE CLASS. The grade D rested on a marketing page being the only proof the product is real. UrbanPiper now proves it in a legal document: the Data Processing Agreement's sub-processor table at https://www.urbanpiper.com/legal/data-processing-agreement (SCHEDULE A, 'Name of the Sub-processor / Purpose / Location') names, alongside Amazon Web Services, Sentry, Datadog and Ably, three entries that exist only for a live speech pipeline -- 'ElevenLabs | Speech-to-text models | United States', 'Deepgram | Text-to-speech models | United States' and 'OpenAI | Inference modelling | United States'. A sub-processor is by definition a party actually processing merchant and guest Personal Data 'on a continuous basis during the term of the Merchant's account', so this is the vendor warranting in a contract that speech-to-text, text-to-speech and model inference are in production inside the Services -- shipped, not roadmap. Corroborating, the product now leads the site's own navigation on every regional variant ('Products: Orderline AI -- Handle all customer calls, reservations and orders, with AI') and has dedicated US and UK pages, https://www.urbanpiper.com/us/orderline and /uk/orderline, retrieved 2026-09-17: 'Orderline AI by UrbanPiper -- Reduce Labor Costs with AI Voice Ordering', 'Orderline handles your entire phone experience through natural conversation.' CONJUNCT BY CONJUNCT against the full claim text: (1) 'AI voice phone ordering (native or a named certified partner)' -- SATISFIED, natively, by the /us/orderline page plus the DPA's speech sub-processors. (2) 'answers inbound calls' -- SATISFIED by /us/orderline, 'Instant call answering -- No missed calls or busy lines, every call is picked up instantly.' (3) 'injects the completed order into the POS' -- NOT SATISFIED at better than a vendor assertion: the only sentence carrying it is the feature bullet 'Direct POS integration -- Connects with 250+ POS systems for real-time order routing', which names no POS, not even UrbanPiper's own Prime, and no injection path is documented on either doc host. (4) 'without staff transcription' -- SATISFIED as far as it goes, by (2) together with 'Seamless AI-to-human handoff -- Smooth transfer to your team with full context', which frames human involvement as the exception. Conjunct (3) is the whole point of the claim and it fails, so this may not become a yes; the differentiator grade floor is not the binding constraint here, the missing conjunct is. Retrieved 2026-09-17. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-17 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

324th, CELL MOVED unknown -> no/C, and the record gains a PRODUCT IT DID NOT KNOW ABOUT. CLAIM: AI voice ordering AT THE DRIVE-THRU LANE, integrated with the POS menu/modifiers and with escalation-to-human handoff. VERDICT: no -- UrbanPiper does ship AI voice ordering, but it is a PHONE product, not a lane product. EVIDENCE: www.urbanpiper.com/us/orderline (and /uk/orderline) launches 'Orderline AI by UrbanPiper -- Reduce Labor Costs with AI Voice Ordering... A smarter way to manage restaurant calls, reservations, and food orders all in one place', and it is now the first item in the site's product navigation ('Orderline AI: Handle all customer calls, reservations and orders, with AI'). Its own feature enumeration is the whole product: 'Instant call answering -- No missed calls or busy lines', 'Concierge & Guest Support', 'Seamless AI-to-human handoff -- Smooth transfer to your team with full context', 'Direct POS integration -- Connects with 250+ POS systems for real-time order routing', 'Call logs and transcripts', 'Analytics & Insights'. Every one of those is framed around the telephone ('Orderline handles your entire phone experience through natural conversation'; 'Up to 62% of calls go unanswered'; 'Up to 30% of calls are reservation-related'). The escalation and POS-integration conjuncts are therefore satisfied and the CHANNEL conjunct is not. CONTROLS over both corpora: 'drive-thru' = 0/0, 'drive thru' = 0/0, drivethru = 0/0, lane = 0/0, headset = 0/0; 'speech' = 0/2, both in the subprocessor list (ElevenLabs 'Speech-to-text models', Deepgram 'Text-to-speech models'), which independently confirms the voice stack is real and is not attached to a lane. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://www.urbanpiper.com/us/orderline · retrieved 2026-09-17 adversarially verified

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

digital-sms-ordering

324th, CELL MOVED unknown -> no/B. CLAIM: conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS. VERDICT: no. EVIDENCE: two dedicated pages enumerate every use of SMS and ordering is not among them. 'Setting up Your Own Mask ID for SMS' is 'a guide [to] configure and use a custom Mask ID for SMS communications (OTP, order updates, and marketing campaigns) on the UrbanPiper Meraki platform', closing 'You can now send all SMS (OTP, order updates, campaigns) via Meraki using your Mask ID.' Manage Campaigns lists the campaign channels as SMS, Email and App Push, all outbound broadcast. The send path is one-way through Gupshup under India's DLT template regime and the guide is explicit that free text is impossible: 'SMS content must exactly match the approved DLT template. Any mismatch can lead to delivery failures.' UrbanPiper's conversational ordering product is voice on the telephone (Orderline AI), not text. CONTROLS: 'text to order' = 0/0, 'text-to-order' = 0/0, conversational = 0/0, chatbot = 0/0, keyword = 0/0. POISON: 'WhatsApp' = 0/13 and all thirteen are UrbanPiper's own 'Chat with us on whatsapp' sales link in the country picker -- a vendor sales channel, not a guest ordering channel, and the single likeliest way to mis-score this cell. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/setting-up-your-own-mask-id-for-sms · retrieved 2026-09-17 adversarially verified

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

324th, CELL MOVED unknown -> no/B. CLAIM: Order with Google / Google Business Profile ordering-link provisioning. VERDICT: no. EVIDENCE: the one help page devoted to Google enumerates every use UrbanPiper makes of it -- Store Selection (radius check plus the Store Locator map), Adding or Updating Customer Address (autocomplete, pin drag) and the Order Success Page static map -- and states the prerequisites as exactly three APIs: 'Maps JavaScript API, Places API, Geocoding API', with 'Without these APIs enabled, Maps-related functions on your website will not work.' Ordering links, place actions and Business Profile provisioning appear nowhere in it or in the rest of the census. CONTROLS: 'Order with Google' = 0/0, 'Google Business Profile' = 0/0, 'Reserve with Google' = 0/0, 'food ordering link' = 0/0; 'Google My Business' = 0/3 and all three are the card for one 2023 marketing blog post, 'Mastering Google My Business for Restaurants', surfaced on resource listing pages -- an SEO guide about a free Google tool, not a UrbanPiper provisioning feature. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/google-maps · retrieved 2026-09-17 adversarially verified

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

324th, CELL MOVED unknown -> no/B. CLAIM: an 'Order Food' custom action on an Apple Maps place card via Apple Business Connect. VERDICT: no. EVIDENCE: Apple occurs twice in the entire 201-page documentation census and neither hit is a channel: the App Store link for the store-manager app ('iOS (App Store): Download Prime for iPhone & iPad') and the macOS Apple menu in 'Connecting a printer on macOS'. It does not occur at all in the 73-page site corpus. UrbanPiper's publishing surfaces are its own Meraki website and app, the four aggregators (Zomato, Swiggy, Uber Eats, Keeta) and the phone (Orderline AI). CONTROLS: 'Apple Maps' = 0/0, 'Business Connect' = 0/0, 'place card' = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/readme · retrieved 2026-09-17 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

Redemption is in the checkout: the Meraki payment configuration lists the methods a merchant enables as 'Online Payments (UPI, cards, net banking, wallets)', 'Cash on Delivery (COD)' and 'Wallets or Loyalty Points (if configured)'. The balance lives on the guest's own account rather than a separate enrollment -- campaign messages personalise from {{user_points}}, 'the customer's current loyalty points balance', and {{user_wallet_balance}} alongside {{user_name}}, {{user_phone}} and {{user_email}} (help.urbanpiper.com/direct-ordering/manage-campaigns). SHORTFALL on both remaining limbs: no page on either host documents ACCRUAL -- there is no earn rate, tier, points-per-currency or reward-rule article, and the 'if configured' qualifier is never expanded, so whether points are earned in Meraki or imported from a partner loyalty platform (partner-with-us names Gupshup under 'Marketing & Loyalty') is unstated. And there is no in-store identity to share: UrbanPiper sells no till, and nothing documents the Meraki guest identity being recognised by the merchant's POS at the counter. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-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

324th, CELL MOVED unknown -> no/B. CLAIM: guest subscription/membership programmes (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform. VERDICT: no. EVIDENCE: the Meraki guest-commerce surface is a single-purchase checkout -- one payment gateway page, coupons, a points balance and a wallet balance -- and the loyalty model carries no tier (see guest-loyalty-tiers). THE POISON IS THE WHOLE SIGNAL HERE: 'subscription' returns 9 documentation and 6 site hits and every one is the MERCHANT'S own SaaS subscription, never a guest's. The documentation hits are all one page, 'Cancel your subscription -- How to cancel your UrbanPiper subscription through Atlas... You can cancel from the current billing month or a future one'; the site hits are all the Merchant Agreement's 'Subscription Term' and 'Merchants can cancel their subscription... at any time by providing UrbanPiper a 30 days prior notice'. CONTROLS: 'recurring billing' = 0/0, 'delivery fee waiver' = 0/0, entitlement = 0/0, 'paid loyalty' = 0/0; membership = 0/1 (trade-union membership in the privacy policy). BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-09-17 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

Parity holds within the first-party estate and stops at the channel boundary. A Meraki coupon is defined once in Meraki and applies to the storefront the operator publishes to both web and app, with a single engine covering cash discounts, item and subtotal percentages and BXGY, plus mandatory redemption codes and start/end date-times. SHORTFALL: promotions are NOT defined once across channels, and the documentation makes that structural rather than incidental -- marketplace discounts are configured on the marketplace side and have their own per-platform articles (Running Discounts on Keeta), while what UrbanPiper receives from Zomato, Swiggy and Keeta is discount INFORMATION relayed onto the order ("Order Discount Info", "Order-Level Discount", "Item-Level Discount", split into aggregator-funded and merchant-funded on the transaction report). There is no shared offer object, no channel eligibility control, and no kiosk or POS channel to be consistent with. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-coupons · retrieved 2026-08-31

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

The vendor asserts operator ownership of first-party guest data as a selling point of the channel -- Meraki gives "Valuable customer insights: Access customer and order data, enabling loyalty programs and marketing automation (email, SMS, social)" -- and the data is demonstrably reachable: order exports carry Customer Name and Customer ID, campaigns address customers by {{user_phone}} and {{user_email}}, and the export route is self-serve CSV/XLSX with no fee or approval documented. SHORTFALL on the claim's specific requirements. No article documents a BULK export of guest records as such, consented marketing status is never mentioned as a stored or exportable field, and no terms or contractual statement of ownership is published in the help centre -- what exists is a marketing sentence about access plus a report that happens to carry two customer columns. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-08-31

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

The ordering storefront's payment code has a closed list of nine gateways: 't.PaymentOS="PaymentOS",t.Phonepe="PhonePe",t.Razorpay="Razorpay",t.MercadoPago="MercadoPago",t.PayULatinAmerica="PayULatinAmerica",t.PhonepeV2="PhonePeV2",t.Stripe="Stripe",t.FreedomPay="FreedomPay",t.Payarc="Payarc"'. In each case the card number is entered on the payment provider's side, not in the storefront's own form fields. Payarc loads 'https://portal.payarc.net/js/iframeprocess.js' into placeholder divs such as '<div id="card-number" data-payarc="CARD_NUMBER" data-placeholder="Card Number"></div>' and reports 'Payarc hosted fields did not finish loading within 5s'. Stripe uses Elements with 'confirmPayment({elements:c,confirmParams:{return_url:a}})', Razorpay loads 'https://checkout.razorpay.com/v1/checkout.js', MercadoPago uses its 'cardPayment' brick, PayU posts a '<form name="payu" ... method="POST">' and FreedomPay redirects ('FreedomPay Payment URL not found'). The only card-related input in the storefront's own markup is a cardholder-name text field. Not shown: no PCI DSS or PCI DSS 4.0 statement appears anywhere, and there is no evidence of script integrity (no integrity= attributes in the storefront HTML, and the only nonce is Partytown copying it onto scripts; response headers were not examined). 3-D Secure/SCA is never named, although Stripe's confirmPayment with a return_url would let Stripe run a challenge. https://gen-korean-bbq-house.order.urbanpiper.com/_next/static/chunks/pages/_app-b86f7092032d0f65.js · retrieved 2026-09-15 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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: 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. VERDICT no. EVIDENCE: the conjunct is unsatisfiable at the source. With the store-level POS now censused, no dual-pricing or card-surcharge configuration exists in the POS to mirror: tokenised `surcharg` 0, `dual pric` 0, `cash discount` 0, `non-cash adjustment` 0 across the whole Prime app. What both surfaces share is a merchant-authored CHARGE (Service Charge, Delivery Charge, Packaging Charge, Surcharge as a title) applied to the order and printed on the bill; no jurisdiction table, no card-brand exclusion and no prescribed disclosure text field appears on either side. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

UrbanPiper's Atlas console (Meraki customers module; source map of main.550329ed.js, and the same strings are in the 2026-07-30 Wayback capture of main.11fd3553.js) has a customer detail timeline, src/components/CustomerDetails/Timeline.js: 'Browse through the complete timeline of interactions with the customer from the time they signed up.' Its event map puts 'Online order' (ORDER_PLACED, linked to /orders/online/<id>), 'In-store purchase' (CUSTOMER_PURCHASE, linked to /orders/in-store/<id>), 'Wallet transaction' and 'Loyalty points transaction' on the same customer record. In-store and first-party online transactions on one guest record is met. Kiosk, the identity key (phone or email match) and any documented dedup or merge behaviour are absent from the shipped source. The code shows transactions attached to one record, not how that attachment is made. https://web.archive.org/web/20260730213022/https://atlas.urbanpiper.com/static/js/main.11fd3553.js · retrieved 2026-09-14 adversarially verified

Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator

guest-loyalty-thirdparty-identity-attach

The vendor's own API reference asserts the negative pole of this claim for marketplace orders: 'While the aggregators generally do not share most of the customer-related information, we share whatever is made available to you. For instance, in most cases, the phone number is not shared and hence you can expect a dummy number to be sent from our side. However, in the case of orders delivered by the restaurant themselves, aggregators share the delivery location and in such cases, it would be shared with you in customer info.' The Order Relay payload's customer block is therefore name/email/phone of largely synthetic values, plus an aggregator-scoped hashed id in ext_platforms.extras (zomato_customer_id). The help centre's Order Transactions Report reference repeats it for reporting: 'customer details are suggested to the information passed by DSP. Most of the DSP/Aggregators do not share the customer details. Data might be dummy', and describes Customer ID as 'a unique code for the customer on the online platform... though often masked by aggregators for privacy'. Marketplace orders thus arrive without usable guest identity, and nothing in the 87-page API reference attaches such an order to a native UrbanPiper guest profile. The one documented exception is restaurant-self-delivered orders, where a delivery location is passed. https://api-docs.urbanpiper.com/downstream/order/order-components · retrieved 2026-09-01

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

Retired UrbanPiper Freshdesk KB article 'Loyalty Programs — Instore' (article modified 28 Sep 2020, Wayback capture 2020-10-31; a 2020 description, not verified as current). Under POINTS ACCUMULATION it lists an absolute purchase-amount ratio ('1 point on every Rs.100 purchase'), a differential purchase amount scale, and a tier-based accrual: "Gold Slab (Rs.5001-Rs.15000), 2 Points for every Rs.100 purchase." with "(e.g: silver, gold, platinum membership based on the amount spent in a year)"; under REDEMPTION it lists "Rewards on the number of visits" "(e.g: 10th visit = freebie etc)". That is points-per-spend plus spend-tier accrual, with visit-count rewards, natively in UrbanPiper loyalty. SHORTFALL: (1) the article is a capability list with no configuration steps, so the claim's configurable-without-custom-development conjunct is not demonstrated; (2) it is a 2020 capture and the only later first-party description (March 2024 product-update post, www.urbanpiper.com/blog/march-2024-product-updates-whats-new-in-our-restaurant-tech-platform, grade C) describes the Prime Loyalty Module solely as 'For each in-store purchase at your restaurant, customers earn loyalty which points they can redeem for cashback', a paid add-on available in India, so the multi-model accrual is not shown to be in today's product. https://web.archive.org/web/20201031214357/https://support.urbanpiper.com/support/solutions/articles/12000070493-loyalty-programs-instore · retrieved 2026-09-12

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

guest-loyalty-tiers

324th, CELL MOVED unknown -> no/B. CLAIM: status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. VERDICT: no. EVIDENCE: the Meraki guest model is exposed field by field in the Manage Campaigns placeholder table, the complete set of customer attributes a merchant can address: {{user_name}} 'Inserts the customer's first name', {{user_points}} 'Shows the customer's current loyalty points balance', {{user_wallet_balance}} 'Displays the customer's current wallet balance', {{user_phone}}, {{user_email}}. There is no tier, level, status or rank attribute. The discount engine targets 'specific customer groups using the Rules section' -- operator-defined groups, not earned status -- and the Merchant Agreement's Loyalty Program clause 12 describes the programme only as one 'which You may offer to Your Customers', with no tier construct. CONTROLS: tier = 0/0, tiers = 0/0, VIP = 0/0, silver = 0/0, demotion = 0/0, 'rolling window' = 0/0; 'tiered' = 1/0 (the menu tag tiered-cake), 'gold' = 1/0 (a cake tag), 'membership' = 0/1 (trade-union membership in the privacy policy's special-category definition). BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-17 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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: documents explicitly what loyalty lookup, accrual and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). VERDICT no on the documentation conjunct, with the underlying behaviour now partly VISIBLE but nowhere stated. What the app shows: guest LOOKUP survives an outage, because Prime pre-caches `/api/v1/customers/offline-list` and resolves a bill's customer through `offlineCustomer(id)` inside a try/catch that only logs 'Error in offlineCustomer'. What it does not show or say: nothing distinguishes loyalty accrual or redemption offline -- 'Customer Loyalty Points Updated', `loyalty_points`, `loyalty_text:'No Loyalty'` and `/api/v1/customers/loyalty-programs` are all server calls with no offline branch, and no queue, no reconcile step and no blocked-state message exists for them. BOUND: the 240 KB help.urbanpiper.com llms-full manifest corpus has 8 `offline` hits, none about loyalty; tokenised `accrual` 0, `redeem.{0,20}offline` 0 -- and Prime's loyalty is NATIVE, not a partner bolt-on: `accrual` returns 3 hits, 'Accrual Basis', 'Accrual Value' and 'Point Accrual' alongside 'Point Redemption'. So the feature exists in the censused app and its offline branch simply does not, and the vendor publishes no statement either way, which is what the claim asks for. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 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

324th, CELL MOVED unknown -> no/B. CLAIM: the offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. VERDICT: no. EVIDENCE: Configuring Coupons is a complete settings enumeration of the Meraki discount engine. 'Meraki provides two types of discounts you can configure' -- Cash Discount and percentage, the latter with two action types, Item Specific and 'Buy X Get Y (BXGY) Specific' -- and one closed list of mandatory rules: 'While setting up any coupon type in Meraki, these rules must be configured: Redemption Code... Date & Time Validation... Bulk Coupons'. The full parameter set is given in the worked BOGO/BXGY/B3G2 tables: Items to Check, Items to Discount, Number of Items to Check, Number of Items to Discount, Max No of Discounts, Coupon Value. No exclusivity flag, no combinability flag and no order-of-application setting appears in any of them, and the only conflict rule published is a value rule rather than a stacking rule: 'If both items to check and to discount are the same and multiple items are in the cart (e.g., Dosa Rs.200 and Rs.150), the lower-priced item (Rs.150) will get the discount.' CONTROLS: stacking = 0/0, stackable = 0/0, combinable = 0/0, priority = 0/0; 'stack' = 0/1 (a marketing 'tech stack'), 'exclusive' = 3/14 (tax-exclusive pricing, a Prime-exclusive feature, and the licence grant's 'non-exclusive' right), 'precedence' = 2/1 (category_id precedence in the menu payload). BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/configuring-coupons · retrieved 2026-09-17 adversarially verified

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

Audience targeting is a documented construct on both the offer and the campaign. Coupons: "You can target specific customer groups using the Rules section", over a discount engine with real depth -- cash discounts on subtotal, percentage discounts on selected items or the whole subtotal, and Buy X Get Y with Items to Check and Items to Discount lists, worked through BOGO, Buy-X-Get-Y and B3G2 examples with parameter tables and stated tie-breaking ("the lower-priced item will get the discount"). Campaigns: "define your target audience." SHORTFALL: what the audience rules can express is never documented. No article names a targetable attribute, and the specific dimensions this claim requires -- recency, frequency, spend, items purchased -- appear nowhere, so a dynamically defined audience is asserted by the product and unevidenced in its documentation. Redemption codes, start and end date-times, and bulk generation ARE documented as mandatory coupon configuration. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/configuring-coupons · retrieved 2026-08-31

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

UrbanPiper May 2025 product-update post (live www; grade C): "Our new Customer Analytics tab in Atlas reveals key customer behavior trends right from your dashboard." and lists "New vs. Repeat vs. Lapsed customers". So Atlas automatically classifies customers into new/repeat/lapsed lifecycle groups without the operator building queries. Supporting but older: fd Reports article 12000070770 (2020) exposes 'days since the last orders' per customer, and fd segments article 12000070595 (2020) has operator-built filter segments. SHORTFALL: (1) only three lifecycle states; no VIP/at-risk or monetary dimension; (2) shown as an analytics view, with no evidence those groups are available as auto-maintained targetable segments (the documented segments are operator-built filters); (3) lapse threshold undefined; (4) marketing-grade C evidence only. https://www.urbanpiper.com/blog/may-2025-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-12

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

324th, CELL MOVED unknown -> no/B. CLAIM: ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends. VERDICT: no -- the documented product is precisely the one-off manual send the claim excludes. EVIDENCE: Manage Campaigns enumerates the whole campaign surface as three operator-initiated channels. SMS: a DLT compliance chain ('Register Your Templates on DLT... Bond Your Account... Share with UrbanPiper... Launch Your Campaign: After whitelisting is complete, you can create and launch your personalized SMS campaigns directly from the Meraki platform'). Email: 'Design Your Email... Host Your Images... Embed in Your HTML... Send a Test Email... before sending to your entire list'. Push: 'Define Audience & Message: Decide who you want to reach and what you want to tell them... Create Your Campaign... Launch: You're ready to send a quick, impactful message'. Personalisation is the five merge placeholders only. CONTROLS: 'win-back' = 0/0, winback = 0/0, 'abandoned cart' = 0/0, 'first visit' = 0/0, 'always-on' = 0/0, drip = 0/0; 'birthday' = 2/1 and every hit is the menu tag birthday-cake, 'lapsed' = 1/0 and it is a lapsed GST registration, 'automation' = 11/43 and every documentation hit is Prime's PRINT automations (Store Manager > Print Automations) -- three homonyms that would each have faked a positive. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-17 adversarially verified

Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator

guest-loyalty-native-email-sms

Both channels are native to the platform, plus a third. "The Meraki suite allows you to send dynamic messages across multiple channels", documented one section each: SMS campaigns ("you can create and launch your personalized SMS campaigns directly from the Meraki platform"), Email campaigns (HTML content, images hosted through Atlas > Meraki > Gallery for public URLs, test send before broadcast) and App Push Notifications ("Create your push notification campaign directly within the Meraki platform, define your target audience, and set the message content"). Personalisation is a documented feature rather than an inference, with a placeholder table -- {{user_name}}, {{user_points}} ("the customer's current loyalty points balance"), {{user_wallet_balance}}, {{user_phone}}, {{user_email}}. Gupshup appears as the underlying SMS carrier, which is what "natively" means in this claim: the campaign is composed, targeted and launched in the vendor's product rather than by exporting a list to an ESP. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-08-31

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

CLAIM: per-channel marketing consent captured with timestamp and source, and revocation honoured by any reasonable means across all channels. VERDICT: no. EVIDENCE: the two censuses together cover both halves of the platform -- the complete Prime POS app (which owns the customer record: /api/v1/customers, /customers/groups, /customers/details/:id, /api/v1/customers/loyalty-programs) and the Atlas source-map set, which DOES include the campaign/marketing module (components/CreateCampaign/TemplateEditor.js, CampaignList, CampaignDetail, CampaignModal, campaignExecutionType, graphql/segments.js). Across both: `consent`, `opt-out`, `unsubscribe`, `revocation`, `TCPA`, `GDPR`, `blacklist`, `suppression`, `subscription preference`, `communication preference`, `marketing preference`, `do not disturb`, `erasure`, `data deletion` are 0 once de-poisoned. The Prime customer record has no consent, opt-in, opt-out or channel-preference field, and the Atlas campaign builder targets segments (saveSegment {title, filters, isImplicit, isActive}) with no suppression or consent predicate. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-18 adversarially verified

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 vendor does exactly what this claim asks -- documents the carrier-registration regime the operator must complete before it will send their SMS -- but for a different jurisdiction than the one the claim names. The documented regime is India's DLT: "Before sending any message, you must get your templates approved on a DLT portal (e.g., Vodafone, Jio, Airtel). Once approved, you will receive a Template ID and a PE ID (Principal Entity ID)", then "bond your PE ID with our SMS provider, Gupshup" by adding three named Telemarketer IDs, then "email your Template ID and PE ID to our support team. Our team will then work with Gupshup to get your templates whitelisted in our system." SHORTFALL: A2P 10DLC, the US regime this claim names, is not mentioned anywhere in the help centre, and neither is any US carrier, brand registration or campaign-vetting step -- which matters for a vendor that markets across 14-plus countries including the US. Partial rather than no: the vendor demonstrably handles SMS compliance registration where it operates, and is silent rather than negative on the US. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-08-31

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

guest-loyalty-campaign-attribution

Redeemed offers are tied to actual check totals at row level. The Order Transactions Report's documented column reference carries, under Payment & Financials, 'Coupon applied -- Indicates if a coupon or promo code was used for the order. It will show "None" if no coupon was applied, or the coupon code itself... Why it's useful: Helps you track the effectiveness of your marketing promotions', beside Total Amount ('Sub-total Amount + Total Taxes + Charges - Discount'), Sub-total, Discount, Aggregator Discount, Merchant Discount and Wallet credit amount, one row per order. help.urbanpiper.com/data-and-reports/getting-started documents filtering by brand, location, aggregator, order status and Meraki channel, export as CSV or XLSX, email delivery and a daily 8 a.m. schedule. SHORTFALL: this is raw data the operator must aggregate themselves, not attribution reporting. No documented column or filter identifies the Meraki SMS/email/push campaign an order came from -- only the coupon code -- so campaign-level redemption is not reported; nothing summarises redemption counts or cost; and no incremental-sales, lift or control-group measure appears anywhere in the 116-page help centre. The report suite documented on that host is order-, item- and option-level plus menu snapshots and a store action log; there is no marketing or campaign report. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-09-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 without a support ticket is established for order and transaction data: Central Report exports to "CSV or XLSX formats" on demand, with filters by brand, location and aggregator, or by email link, or on a daily schedule, and no fee or approval step appears anywhere in the article. Guest identity is carried on those rows -- the Order Transactions Report defines Customer Name and Customer ID fields. SHORTFALL on both of the claim's halves. There is no guest-list export: no article documents exporting the customer table itself, only orders that happen to carry customer columns. And the PII on marketplace rows is disclaimed by the vendor -- "customer details are suggested to the information passed by DSP. Most of the DSP/Aggregators do not share the customer details. Data might be dummy" -- so usable contact data exists only for first-party Meraki orders, where Meraki's own pitch is "Access customer and order data, enabling loyalty programs and marketing automation." Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

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

A documented, self-configurable outbound event stream exists. 'At present, the following event types can be configured to trigger a webhook callback' enumerates fourteen: User feedback (10005), Order placed (18), Order status update (60008), Order delivery status update (60012), Catalogue Create/Update (60013), Store Create/Update (60014), Store Actions (60015), Items Actions (12004), Options Actions (12005), Category Timing Groups (60016), Hub Menu Publish (12002), Mark Order Items Stock-out (60018), Order Feature Action (60017) and Webhook Order Retry (60019). Each outbound request carries X-UPR-Event-Type and X-UPR-Biz-Id headers; subscriptions are created in Atlas (Settings > Webhooks) or via POST https://pos-int.urbanpiper.com/external/api/v1/webhooks/ with the subscriber's own url, custom headers and retry interval, and api-docs.urbanpiper.com/downstream/api/endpoints/order-management/order-relay documents the full order JSON delivered. SHORTFALL: it is an order and catalogue stream, not a guest stream. That enumeration contains no customer-created, profile-updated, loyalty-balance or consent event, so a CDP can subscribe to order events only; the guest identity carried inside those order events is expressly unreliable for marketplace orders ('in most cases, the phone number is not shared and hence you can expect a dummy number to be sent from our side'); and the whole surface is documented as a POS-partner integration reached through UrbanPiper onboarding, sandbox and certification rather than a self-serve subscription. No named CDP or marketing platform (Olo, Punchh, Bridg, Klaviyo) appears anywhere in the 87-page reference. https://api-docs.urbanpiper.com/downstream/api/references/webhook-event-headers · retrieved 2026-09-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

Guest feedback is captured and is available as an event. The API reference's webhook event catalogue carries 'User feedback' with unique code 10005 as a configurable outbound event, with the note 'User feedback is only for white-label websites/app (Meraki) ordering integration', so feedback is collected against first-party orders and can be pushed to an external system. help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas confirms it is a product surface, not just a payload: the Atlas Support role is 'tailored for customer service and feedback handling in Atlas. Support users can access customer details, manage feedback, and analyze NPS (Net Promoter Scores)'. SHORTFALL: the routing half of this claim is undocumented on both hosts. Across all 116 help pages and all 87 api-docs pages retrieved 2026-09-01 there is no score threshold, no split of detractors to private service recovery versus promoters to public review sites, no Google/Yelp/TripAdvisor destination, and no description of when or how a post-transaction feedback request is sent to the guest -- only that a score is collected and can be read or forwarded. Capture and NPS analysis are present; score-based routing is not shown. https://api-docs.urbanpiper.com/downstream/api/references/webhook-event-headers · retrieved 2026-09-01

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

UrbanPiper's Atlas console ships a Meraki referral module (source map of atlas.urbanpiper.com main.550329ed.js; the same strings are in the 2026-07-30 Wayback capture of main.11fd3553.js). src/containers/Referrals.js is headed 'Meraki Referrals' / 'Central repository of your customer referrals'. graphql/referrals.js lists referrer and referred customers (id, phone, fullName) with codeOrLink, status, channel and platform, and components/Referrals/List.js shows a 'Referral Link / Code' column. components/Meraki/Apps.js configures 'Validity for a referral to be active (in secs)' and 'Referral share text', and MerakiWeb/Apps.js has 'Configurations of Referral via Branch.io'. Per-guest codes or links are met. Attribution is short: a referred customer and a claimed/unclaimed status are recorded, but no link to the referred guest's first order. Two-sided rewards are not configured anywhere in the shipped source: the card says 'incentivising your existing customers' and a page is labelled 'Refer & Earn', but no reward, credit or points field exists. https://web.archive.org/web/20260730213022/https://atlas.urbanpiper.com/static/js/main.11fd3553.js · retrieved 2026-09-14 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

324th, CELL MOVED unknown -> no/B. CLAIM: issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. VERDICT: no, and Meraki's own positioning is the opposite -- 'Meraki is UrbanPiper's self-branded, commission-free online ordering platform for restaurants. It allows you to build and launch your own website and mobile app', with the third campaign channel explicitly app-gated: 'App Push Notifications... notifications will only be received by users who are logged into your app.' THE POISON IS WHAT DECIDES THIS CELL: 'wallet' returns 10 documentation hits and 12 site hits and every one is a stored-value balance, not a pass -- the placeholder {{user_wallet_balance}} 'Displays the customer's current wallet balance', the order payment method wallet_credit (listed beside prepaid, payment_gateway, cash, card_on_delivery, paytm, simpl), and the Meraki feature line 'email marketing, a free loyalty program, SMS marketing and wallet to increase ticket sizes and repeat orders'. CONTROLS: 'Apple Wallet' = 0/0, 'Google Wallet' = 0/0, pkpass = 0/0, passbook = 0/0; 'Apple' = 2/0, the App Store link for Prime and the macOS Apple menu in a printer guide. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/direct-ordering/getting-started · retrieved 2026-09-17 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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: admin tooling to fulfil guest data access AND deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records. VERDICT partial. EVIDENCE: the DELETION half is shipped and permissioned in the store-level POS: 'Delete Customer', 'Are you sure you want to delete Customer?', 'Customer Deleted', and a distinct permission string 'You do not have permission to delete customers' alongside 'You do not have permission to edit customers' -- so an operator admin can erase a guest record without emailing vendor support, which is the substance the claim is testing. SHORTFALL: no data-ACCESS/subject-export tooling exists (the customer export paths are bulk analytics exports, not a per-subject package), and nothing states that the deletion propagates to loyalty balances or marketing lists -- `Customer Loyalty Points Updated` and `loyalty_points` live on the same record but no propagation is asserted. BOUND/CONTROLS: tokenised `GDPR` 0, `CCPA` 0, `CPRA` 0, `erasure` 0, `right to be forgotten` 0, `consent` 0 across the whole Prime app and 0 across the 240 KB help corpus, so the unstated behaviour stays unstated and this cannot reach yes. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

331st: CELL MOVED unknown -> partial/B. This cell had NEVER been checked against the 326th's census of the store-level Prime app (prime.urbanpiper.com; main.877fb1f9292d7b25014a.js 4,860,546 B + vendors.a82de318208444ce3a4e.js, no lazy-chunk loader, hashes re-checked today and unchanged; grade B, production JS). Prime ships its OWN loyalty module (isModuleLoyaltyEnabled; /api/v1/customers/loyalty-programs) and it enforces redemption controls in code: (1) OTP-VERIFIED REDEMPTION: at settlement, `isModuleLoyaltyEnabled() && bill.loyalty.redeem && bill.cashback` opens a modal 'Verify Your Mobile to get cashback' / 'OTP sent to {mobile}' (generateLoyaltyOtp -> POST /api/v1/customers/{id}/loyalty/generate-otp); the redemption is posted to /api/v1/customers/{id}/loyalty/cashback with amount '-{total_cashback}' and `pin: otp`, errors 'Invalid OTP, please try again', and only then 'Cashback successfully applied' -- i.e. points cannot be burned on a bill without a code sent to the member's own phone, which is the control against staff redeeming onto unattached checks. (2) PER-TRANSACTION REDEMPTION CAP: cashback = Math.min(bill amount, balance net of prepaid, loyaltyConfig.max_transaction_value); program config also requires 'Minimum Points needed to redeem' (config.redeem_minimum) and per-condition switches 'Can Loyalty be Redeemed?' on bills with discounts / gift cards. (3) POINTS LEDGER: each member has a 'Loyalty Changes' tab, 'Customer loyalty points history' (GET /api/v1/customers/{id}/loyalty-changes), columns Date, Description + type, Object (linked bill), Points with signed change -- a per-customer history of every accrual/redemption. SHORTFALL (why partial, named): no per-period VELOCITY limit (the cap is per transaction); no MANAGER-APPROVAL step on manual point adjustments (an 'Adjust Customer Loyalty Points' modal exists -- Set/Add/Remove with a REQUIRED Remark, POST /loyalty-adjustment -- but has no approval gate, and in this build its onAdjustLoyalty handler is defined without a rendered trigger); no employee self-redemption FLAG; and the points ledger has no acting-user column, so it is a balance history rather than a user-attributed audit log. Tokenised over the Prime literals: `fraud` 0, `velocity` 0, `approval` 0 in any loyalty context. The Atlas/Meraki side (q325 source maps) carries the online-channel analogues pointUseThreshold, maxPrepaidTransactionAmt and bypassOtpCheckForPrepaid, consistent with OTP being the vendor's default guard. WEAKNESS: OTP verification and a per-bill cap are loyalty fraud controls in the claim's 'such as' sense but are not any of its three named examples verbatim. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

CLAIM: vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing, as a shipped feature. VERDICT: partial. EVIDENCE: Atlas ships a recommended-target-audience feature, in shipped code, not a roadmap page. components/Campaign/SuggestedTargetCampaign.js renders the header "Suggested target audience for your campaign" / "List of customer segments that can be targeted by running a campaign", and actions/segments.js fetches it by sending `suggested = true` on the SUGGESTED_SEGMENTS GraphQL query when the selected group is "Recommended Segments" -- i.e. the server, not the operator, chooses the segments. SHORTFALL: nothing in either census attributes that selection to AI or ML, and the vendor's own AI language is attached to other products entirely -- the Disputes booster ("AI-powered automated dispute filing & recovery") and Call Insights ("Enable AI-powered call insights and configure the judges that evaluate your calls"; judge kinds scorecard / violations / moments / upsell / customer_sentiment / script_adherence). No offer-content generation and no send-time optimisation exists (`send time`, `best time` = 0). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-18 adversarially verified

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

A native stored-value balance held against the guest exists and is spendable. Under 'Choose Payment Options' the article tells the merchant to 'Enable/disable the methods you want to accept: Online Payments (UPI, cards, net banking, wallets); Cash on Delivery (COD); Wallets or Loyalty Points (if configured)', so wallet credit and points are first-class Meraki checkout tenders rather than gateway wallets. That the balance is per guest rather than per order is documented at help.urbanpiper.com/direct-ordering/manage-campaigns, where {{user_wallet_balance}} 'Displays the customer's current wallet balance' as a personalization merge field beside {{user_points}}. SHORTFALL, on two limbs of the claim. First, no gift card: nothing on either complete first-party corpus (116 help pages, 87 api-docs pages, retrieved 2026-09-01) documents issuing, selling, activating, reloading or redeeming a gift card or e-gift, and no card number, PIN or barcode surface exists. Second, scope is unstated: the article says gateways may be configured 'globally for all outlets, or per outlet if needed' but never says a wallet balance is redeemable across all locations of a brand, and the wallet is documented only for Meraki first-party ordering -- marketplace orders relay a payment option of wallet_credit meaning the aggregator's own wallet (Swiggy Money, Zomato Wallet, per the Order Transactions Report), not this one. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-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

The Prime POS web client has no employee clock-in or clock-out. Its code contains no time clock, timecard, attendance, payroll, wage or overtime logic, and it has no staff or labour module. The terminal's PIN is a permission check, not a time punch: a form field labelled 'Authorize with Pin' posts to '/api/v1/users/auth/authorize-scoped-pin' to approve a restricted action. The shift the terminal tracks is the cash register session, which is opened and closed with a balance check ('Reconcile expected vs actual balance when closing register.'). The word 'punch' refers only to entering orders ('Punch a bill'). The Atlas back office has no hours or timecard record either, and the help centre describes staff roles and store PIN resets but no time capture. Scope: this covers the Prime web client and the Atlas back office. The native Prime Android/iOS apps and the Captain App were not decompiled, but none of the merchant-side code that would manage their time entries has any. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-15 adversarially verified

Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator

labor-photo-punch-verification

There is no punch or timecard entry for a photo to be attached to. In the Prime POS web client, employees exist only as people assigned to orders: the employee functions are createEmployee, updateEmployee, getEmployeesForLocation, assignEmployee and addEmployeeBeforeOrder, and the audit event is "Captain assigned". The store's module settings list 19 module keys, from module_multibiz to module_loyalty, and none of them is an attendance or time-clock module. The Captain App setting describes its scope as "Start a bill, adding items to existing bills, managing customers, voiding items etc." Tokenised, clock in/out, timesheet, timecard, attendance, getUserMedia, facingMode, biometric, face recognition and selfie all count zero. The five punch hits are all order entry, such as "Punch a bill". The native Prime Android and iOS apps were not decompiled. The help centre's overview of what those apps cover lists orders, menu availability, store availability and notifications, with no time clock. That prose, not code, is why this is graded B. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-15 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

CLAIM: mobile clock-in restricted by geofence or location validation. VERDICT: no. EVIDENCE: there is no clock-in at all to fence. `geofence`, `geo-fence`, `clock in`, `punch in` (in the time sense) are 0 across every corpus; Prime's only location binding on a person is the Employee detail screen's per-location enable toggle (POST /api/v1/employees/{id} location_id/enabled), which gates which outlet an employee may be selected at, not a punch. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

There is no time punch for Prime to buffer offline. The Prime POS web client names what its offline mode keeps on the device, and it is register sessions and bills only: its Offline data settings tab says "We store register and bills locally on your browser to support offline mode." and its clear action warns "This will clear all local bills in your browser and unlink any open register". In the served client, the only route flagged for offline use is the register-bound sell screen, "/pos/app":{offline:!0}. The bundle's main module carries no clock-in, clock-out, time sheet, time card, time clock, attendance, payroll or hours-worked string. Every occurrence of punch is order entry: "Punch a bill", "Point of sale system for billing and order punching." and "From here, you can change the location to punch in-store orders." Every shift is a keyboard key or Array.shift. The PIN form is labelled "Authorize with Pin" and is a scoped permission check, not a time entry. This cell follows from the absence of any clock-in at the terminal and stands or falls with labor-clock-in-at-pos. The native Prime Android and iOS apps and the Captain App were not decompiled. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-15 adversarially verified

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

Split model. Prime, the store side, ships six standard roles (Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator) plus custom roles — 'Prime gives you the flexibility to create custom roles tailored to your specific needs. With custom roles, you can assign very specific permissions, giving you granular control over what each team member can do' — with location-based restriction. The shortfalls: Atlas, the management console, offers only ten fixed standard roles with no custom-role option, and 'location-level access is not available in Atlas'; and the article asserts granularity generically without enumerating discrete-action permissions of the kind the claim names (void, comp, discount, refund, drawer open, price change), so per-action grantability is not documented. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-08-04

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

UrbanPiper's Prime POS Android app (com.urbanpiper.satellite_prime 69.0.0, Hermes string table read 2026-09-15) puts voids, discounts and bill unlocks behind a separate manager authorization step. The strings include '[[Authorize Item Void]]', '[[Authorize Void Bill]]', '[[Authorize Apply Discount]]' and 'AuthorizedActionModal', checked against '/api/v1/users/auth/authorize-scoped-pin'. The approver's name is recorded and shown on the bill: 'Bill unlock authorized by ' and '[[<0>Voided:</0> <1>{{voidedAt}}</1><2> by </2><3>{{voidedBy}}</3>]]'. This matches the Prime web bundle, where a void log entry carries the authorizing user when a manager PIN is used (see payments-refund-void-controls and reporting-comps-voids-audit). SHORTFALL: approvals are named per bill, but there is no immutable, queryable override audit trail. The web bundle shows that a later void on the same bill overwrites the earlier log entry's description and timestamp, so the log is neither immutable nor a complete record of every approver. The app has no whole-word 'audit' string among its 54,497 strings. Its only log screens ('Activity Logs', 'Inventory and location toggle logs for last 15 days') cover stock and store toggles. In the Atlas back office, the Periscope Activity Log and the Activity History list are scoped to item, location and platform, and contain no void, discount, bill or approval terms. https://d.apkpure.com/b/APK/com.urbanpiper.satellite_prime?version=latest · retrieved 2026-09-15 adversarially verified

Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator

labor-native-scheduling

324th, CELL MOVED unknown -> no/B. CLAIM: native shift scheduling. VERDICT: no -- UrbanPiper publishes no labour surface of any kind. EVIDENCE: the help centre's own section structure is the product census (Basics; Business Manager/Atlas; Data & Reports; Direct Ordering/Meraki; Ordering Channels; POS Integrations; Store Manager Prime app; Store Manager Prime web) and contains no labour, staff, time or payroll section. The only page whose title contains 'schedule' is 'Setting up Schedules for Locations', which is store opening hours, and the other schedule hits are Zomato and Swiggy category schedules (48/59 hits, all store-hours or menu-timing). The only employee construct in the whole corpus is Atlas User Access -- invite, role, archive, PIN reset. CONTROLS: roster = 0/1 ('client roster' in a press release), rostering = 0/0, timesheet = 0/0, attendance = 0/0, 'clock in' = 0/0, wage = 0/0, overtime = 0/0, 'shift swap' = 0/0; 'shift' = 1/3, none a labour shift ('a significant shift in the restaurant industry'); 'punch' = 2/22, and every site hit is a customer quote about manually punching ORDERS into the POS. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/readme · retrieved 2026-09-17 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

CLAIM: recommended staffing levels / labor hours by daypart from the operator's own sales history. VERDICT: no. EVIDENCE: `forecast` and `staffing` are 0 in every corpus including the Atlas analytics module; Prime's analytics endpoints are the complete set /api/v1/analytics/sales/{analytics-by,analytics-summaries,dashboard-summaries,revenue-trend,sales-count-trend,sales-trend,top-selling} and /api/v1/analytics/inventory/analytics-summaries -- all historical sales and stock, none labour, none predictive. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

CLAIM: labor cost as a percentage of sales in real time on a manager view or POS. VERDICT: no. EVIDENCE: Prime holds no wage, no clocked hour and no labour cost of any kind (`wage`, `labor`, `hours worked` = 0), so the numerator does not exist. The live manager surface is /home/sales-dashboard + /api/v1/analytics/sales/dashboard-summaries, whose contents are sales, orders and top-selling items. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

An overtime warning has to fire at clock-in, and the Prime POS web client has no clock-in to attach it to. The served main bundle (4,860,517 characters, with no lazy chunk loader: 'r.e=function(){return Promise.resolve()}' occurs once) contains the word overtime zero times, and has no clock-in, clock-out, attendance, timesheet or payroll strings. The PIN prompt it does carry, 'Authorize with Pin', is a permission check. Its punching is bill entry ('Punch a bill'), and its employees are staff assigned to an order ('Captain assigned'). The only near-match is chart copy, 'Select a value from above to see the trend over time', which is not overtime. The vendors bundle and the Atlas back-office bundle also contain overtime zero times. The native Prime Android and iOS apps and the Captain App were not decompiled, so this absence is bound to the web client and the vendor's help centre. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-15 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

CLAIM: per-jurisdiction meal/rest break rules, break attestation prompts, missed-break premium flags. VERDICT: no. EVIDENCE: `rest break`, `meal break`, `attestation` = 0; the 132 `break` hits in Prime main.js are the JS break statement and Tailwind break-words (poison, see above). BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

CLAIM: advance-notice tracking for published schedules and predictability pay. VERDICT: no. EVIDENCE: `workweek`, `predictive scheduling`, `predictability pay` = 0, and there is no schedule to publish -- the 27 `schedule` hits in Prime main.js are order scheduling / timing groups (/catalogue/timing-groups, advance orders), not staff scheduling. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

CLAIM: age-based maximum hours, prohibited time windows and school-day limits enforced at scheduling and clock-in. VERDICT: no. EVIDENCE: the Employee record carries no date of birth, no age and no hour limit -- its complete field list is Name/Created/Updated/locations. `minor` is 0 in Prime app code (the 111 hits are vendors.js library code). BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

No tip pooling or tip-out engine. In the Atlas back-office bundle the only tip rule a merchant can set is the guest-facing tip prompt on Meraki web ordering. The settings card 'Tipping Configuration' ('Manage tipping settings effortlessly to enhance the tipping experience for your customers') has an 'Enabled' toggle, three options entered as percentages and validated with 'Value must be between 0 and 100' and 'All 3 options must be configured', and one default flag. The release note says to 'Enable Tipping and configure:' 'Three preferred tip values' and 'One preselected default value'. Everything else that mentions tips in the bundle is a customer bill line (label 'Tip', type 'debit'), a 'driver_tip' order key or UI component names. The bundle has zero tokenised hits for tip pool, tip-out, tip share, tip distribution, gratuity, payroll or hours worked. The Prime POS web client has no tip vocabulary at all. Its one per-employee rule engine is sales commission on items (Percentage of Margin, Fixed per Quantity, with a criteria filter), and that engine takes no tip input. There is also no timesheet or clock-in data to allocate against. The web clients were checked, but the native Captain and Prime apps were not decompiled. https://atlas.urbanpiper.com/static/js/main.550329ed.js · retrieved 2026-09-15 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

CLAIM: per-shift, per-employee record of tips received, pooled and distributed, exportable. VERDICT: no. EVIDENCE: Prime CAPTURES NO TIP. `tip`, `tips`, `tip pool`, `tipout`, `tip share`, `gratuity` are all 0 as word-boundary tokens across the 21,343 Prime literals (the 68 substring hits are `multiple`, `description`, `Order Multiple`). The bill's monetary add-ons are the generic Charges entity (Add Charge / Charge Type / Charges on Bill, /api/v1/sales/fees), which is a merchant charge, not an employee-attributed tip. The one tipping feature UrbanPiper ships is on Meraki, its consumer ordering channel, not the POS: changelog 2026 "Turn appreciation into tips on Meraki" -- "Merchants can configure up to three preferred tip values" -- and it is configured in Atlas under Meraki > Settings > Apps, with no employee attribution or pooling. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

CLAIM: payroll export separating cash from charged qualified tips with a Treasury tipped-occupation code for W-2 Box 12 code TP / Box 14b. VERDICT: no. EVIDENCE: two independent absences -- there is no payroll export at all (`payroll` = 0 across every corpus; no payroll endpoint among the 300) and no tip capture at all (previous cell). The 402 `W-4` and 17 `W-2` hits in Prime main.js are Tailwind w-4 / w-2 classes. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

324th, CELL MOVED unknown -> no/B. CLAIM: native payroll processing. VERDICT: no, for the same bound as labor-native-scheduling: there is no labour module anywhere in the 201 documentation pages or the 73 site pages, and UrbanPiper describes itself throughout as aggregator order integration (Hub), self-branded ordering (Meraki), store operations (Prime) and phone AI (Orderline). CONTROLS: payroll = 0/0, wage = 0/0, 'W-2' = 0/0, 'tax filing' = 0/0, 'pay run' = 0/0, 'direct deposit' = 0/0, QuickBooks = 0/0, Xero = 0/0, 'I-9' = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/readme · retrieved 2026-09-17 adversarially verified

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

CLAIM: timecards, wages and tips exported in documented formats or via integration for at least two major payroll providers. VERDICT: no. EVIDENCE: Prime's integrations are a closed, enumerable set in main.js: QuickBooks Online (/api/v1/integrations/accounting-qb-online/*), Tally (/api/v1/integrations/accounting-tally/*), external payment terminals incl. Pine Labs (/api/v1/integrations/external-payment/*), plus the UrbanPiper catalogue-publish channel. Both accounting integrations are ACCOUNTING, not payroll: the Tally setup wizard's complete question list is ledger_location, ledger_location_type, ledger_brand, ledger_platform, ledger_floor, tally_prime_item_map, export_modifiers, export_payments, export_transfer_receives. `Gusto`, `ADP`, `Paychex`, `Paylocity` = 0. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

CLAIM: self-service shift swap / open-shift claim with manager approval enforcing overtime and role eligibility. VERDICT: no. EVIDENCE: no shift entity exists (`shift` in Prime is the keyboard Shift key and Array.shift; `open shift`, `swap`, `roster` = 0). Prime does ship approval workflows -- stock counts, adjustments, contracts, transfer requests, petty-cash withdrawals -- which shows the absence is of the labour object, not of workflow machinery. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

labor-digital-onboarding-i9

CLAIM: digital new-hire onboarding collecting W-4 and I-9 with E-Verify. VERDICT: no. EVIDENCE: the Employee create/edit form and detail screen enumerate the whole record -- Name, Created, Updated, per-location toggle. `I-9`, `E-Verify` = 0; the 4 `onboarding` hits in Prime are the merchant's own signup flow (/onboarding/urbanpiper, /signup), not staff onboarding. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

Both complete first-party corpora on disk were re-grepped 2026-09-02 (help.urbanpiper.com, all 116 llms.txt pages, 479,604 chars; api-docs.urbanpiper.com, all 87 pages, 924,046 chars). NEW THIS PASS: www.urbanpiper.com was read by hand -- sitemap.xml (38,984 bytes, ~239 URLs, fetched 2026-09-02) enumerated in full, plus /meraki, /integrations, /legal/privacy-policy, /legal/data-processing-agreement and eight individually chosen blog posts (Nov and Dec 2024, Feb, Mar, Apr and May 2025 product updates, prime-latest-design-upgrade-top-6-exciting-highlights, upgraded-industry-leading-analytics-module-for-restaurants). All seven report articles were re-read. help.urbanpiper.com/data-and-reports/order-transactions-report says 'each row in this report represents a single order, and each column (or field) provides specific information about that order' and then names every column -- ID, order ref ID, brand, brand ID, external platform ID, channel, created at, order state, requested delivery time, time slots, payment mode, payment transaction ID, coupon, totals, discounts (aggregator and merchant), taxes, charges, wallet credit, customer name and ID, store name/ID/ref, city, fulfilment mode, delivery type -- with no cashier or server field. data-and-reports/store-action-report does carry 'username' and 'user_first_last_name' but logs store-level platform actions (publish, enable, disable), not per-employee sales, and no report exposes average check, attachment rate or void/comp rate by staff member. New this pass: www.urbanpiper.com/blog/upgraded-industry-leading-analytics-module-for-restaurants and the April 2025 post describe the analytics module as heatmaps, line/area charts and shareable reports, naming no per-employee metric -- grade D and not an enumeration. Left unresolved because data-and-reports/getting-started calls the list 'order transactions, item-wise transactions, item summaries, and more'. changelog.urbanpiper.com was NOT fetched: its robots.txt is a named allowlist and 'User-agent: *' gets 'Disallow: /'. 2026-09-12 (263rd sweep, new corpus): NEW CORPUS searched 2026-09-12: .cache/q263-urbanpiper/corpus.txt, of which 380 docs were usable -- 141 Wayback-recovered Freshdesk articles from the retired support.urbanpiper.com (captured 2017-2024, incl. the 48 PRIME POS articles captured March 2023) and 239 live www.urbanpiper.com sitemap pages. The 30 changelog.urbanpiper.com docs in that file were NOT used: changelog.urbanpiper.com is robots-barred (robots.txt ends 'User-agent: *' / 'Disallow: /'; listed in data/robots-bars.json). Word-boundary, case-insensitive counts are given as fd/www. Nearest evidence read, none sufficient: fd 'Open a table and manage orders' (captured 2023-03-27) describes assigning an opened table's order to a waiter via a Server section (paraphrase; not quotable as a contiguous raw-HTML substring) -- orders ARE attributed to a waiter in Prime; fd 'Sales settings' (captured 2023-03-27) 'Enable this module if you want to give sales commission to your staff' (under the bolded setting heading 'Enable Sales Commission?'); fd 'Reports' (captured 2021-10-28, Quint loyalty) 'In-store purchase transactions report ... Details include the customer details, amount, discount, store details, POS operator'; www june-2024 product update adds 'cashier's name' as an optional bill row. None describes average check, attachment rate or void/comp rate BY server or cashier. 'staff wise'/'user wise'/'sales by user' 0/0. Attribution exists; the per-employee metrics are not documented. Unresolved. || 325th: MERGE HOLD (proposed no/B, held unknown): Prime POS, the store-level product, is NOT bounded: the Atlas source-map set is a census of the back office only, and Prime is covered by 27 release-note posts, which are a floor. The same gap already falsified two 324th no verdicts on Prime Inventory. A no on a store-level feature needs a census of Prime itself. PROPOSAL AS WRITTEN: 325th, CELL MOVED unknown -> no/B. The claim needs per-employee average check, attachment rate and void/comp rate by server or cashier. BOUND as on multi-location-central-labor-policy (complete Atlas app by asset-manifest + all 6 source maps, 1,585 first-party sources, 11.8 MB sourcesContent, nonsense-map control 404; 27 monthly product-update posts fetched entire, 230,818 chars; 116 help and 87 API pages on record). The app enumerates every analytics view it ships - Home, Revenue, Orders, Operations, Catalogue, Customers, Compare, plus topPerforming - and none is keyed by a person. The ONE per-agent leaderboard in the product is Orderline's, over AI phone agents: reducers/orderLineAnalytics.js carries agentsLeaderboard, agentsHeatmap and agentDetail beside scriptAdherence and violations, i.e. conversation-quality scoring of the voice bot, not a human server's attach rate; UrbanPiper has no server, waiter or cashier dimension in its order model (the nearest attribution anywhere is the Store Action Report's username). Retrieved 2026-09-17. || 326th: NEW SURFACE, still unknown. The complete Prime app census (see below) shows the platform DOES attribute sales to an employee: the Sales Commission ledger at /api/v1/commissions/employee/{id} lists Date, Commission, Bill Number, Item, Quantity, Applicable amount and Commission amount per employee, and receipts print "Cashier:" and "Server: {{server}}". So the attribution the claim needs exists. What I cannot settle is whether the named metrics (average check, items or category attachment rate, void and comp rate BY server) are reported: Prime's report catalogue is server-side behind /api/v1/reporting/, /api/v1/reporting/v2 and /reports/preview/:id/:reportId and is not enumerable from the bundle. No screen in the 1,854-module app renders such a report. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. || 327th: NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. NEW BOUND (327th): same gate as the reporting cells -- the report catalogue is `GET /api/v1/reporting/v2` and it returns HTTP 400 'Access Token is required for this request' anonymously (probed 2026-09-18); no report names or ids are embedded in the bundle. What the censused app does show: bills carry an employee (`le.employee = getEmployees().find(...)`, 'cashier:{id,name}'), voids are first-class and logged ('BILL VOID', 'VOID LINE', 'Line item voided', 'This bill cant be voided. Reason:'), and per-employee money exists as Sales Commission (`/api/v1/commissions/employee/`). Tokenised `average check` 0, `items per` 0, `attachment rate` 0, `comp rate` 0, `void rate` 0. The attribution exists; the named METRICS do not appear client-side and may live in the gated catalogue, so a no cannot be published. Retrieved 2026-09-18. || 331st: 331st NEW SURFACES, still unknown. (a) The Prime report catalogue's only public picture: changelog post 296721's image (cloud.headwayapp.co/changelogs_images/images/big/000/130/598-...png, read as an image; 'original' size 403s) shows Prime > Reports > Sales > Day Summary Reports (Summary, Summary Detailed, Bills, Register Session Payment Summaries, Payments, Products), then Product Sales Report and Period Sales Reports -- a cropped view of ONE category, not a census, and no employee/server report is in frame. changelog.urbanpiper.com is a Headway CNAME (account x9bqE7) and still lists the same 29 posts as the 326th. (b) 331st NEW SURFACE: the Prime ANDROID app unpacked (com.urbanpiper.satellite_prime v69.0.0, versionCode 457, XAPK 43,935,331 B fetched anonymously via d.apkpure.com; base APK + config splits; never executed). It is React Native with a Hermes bytecode bundle (assets/index.android.bundle, 8,696,000 B, magic c61fbc03, version.txt 1.10.0_ed1d888b); its i18n table holds 863 [[key]] entries and 40 /api paths, a strict SUBSET of the web app (order tracker, KOTs, bills, register sessions, external-payment devices incl. /pinelabs/devices). Its keys add 'Select Server', 'Add Server', 'Server: {{server}}', 'Cashier: {{cashier}}' (bill attribution again) and `average` 0 / `report` 0 as i18n keys: the mobile app has no reports module. The gated /api/v1/reporting/v2 catalogue remains the blocker. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. report.svc.urbanpiper.com/openapi.json (20,642 B, 14 operations) is the report service behind Prime/Atlas 'All Reports': GET /v1/reports returns ReportListViewResponseModel = [Group{group, reports:[ReportType{id, name, description, filters, supported_formats, preview_available}]}], and every /v1/reports* operation carries security HTTPBearer. So the catalogue is DATA returned per tenant, not part of the contract: the spec names no report, and the catalogue stays unread (no call was made). ON THIS CELL: this confirms the 327th finding from the server side - the per-server metrics question sits entirely in the tenant's report catalogue, which the contract does not enumerate and which answers only to a bearer token. No report-list surface is public anywhere else either: the Webflow site search on www.urbanpiper.com/search swept for report, reports, staff, employee and waiter returned only pages already in the 239-URL sitemap. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: tokenised word-boundary, case-insensitive controls over all 15 contracts: employee 0, staff 0, cashier 0, waiter 0; server 5, all POISON (atlas-chat/iris/order-line 'server' = MCP/HTTP server). None of the services is keyed by a person, so the per-server metric question still sits in the bearer-gated tenant report catalogue (report.svc GET /v1/reports). Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: 'What are the reports that are available? Prime has extensive reports in the following categories: Sales, Online Ordering, Employee Reports, Restaurant Operations, Payments, Taxes and Fees, Inventory, and Transfers and Purchasing. All of the reports can be downloaded as excel files'. ON THIS CELL: the vendor names an 'Employee Reports' CATEGORY in Prime's report catalogue - the server-side catalogue the 326th/332nd could not enumerate (report.svc /v1/reports returns it per tenant). That argues directly against the 325th's proposed no and supports its merge hold; it does not say what the employee reports contain (average check, attachment, void/comp by server), so it cannot carry a partial either. Unknown. Retrieved 2026-09-18. adversarially verified

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

Freshdesk KB 'Recipe details', in the Prime > Recipe folder; Wayback capture 2024-04-15, article modified 17 Feb 2023. MET (sub-recipes): a recipe can be made for a final product, a product modifier, or an intermediate product ('This is the intermediate product like, a cake sponge, to be used while preparing a cake.'). Its ingredients are raw materials or intermediate products. 'Intermediates details' (12000092219, same folder tree): 'Intermediates are products that are prepared from a group of raw materials, but aren't directly sold.' Selling a product depletes its ingredients: 'When the recipes are associated with certain locations, then the ingredient stock gets reduced when a product is sold at that location.' SHORTFALL (costing): no recipe or plate cost is documented. Cost exists only per material, as a Standard Cost Price plus 'A separate weighted average cost will be automatically calculated as you receive stock.' (12000092219/12000092220). No article says a recipe cost rolls up from its components or recalculates when an ingredient cost changes. DATING: the Freshdesk KB (support.urbanpiper.com) is retired and was read only through Wayback. The Prime inventory articles carry 'Modified on Fri, 17 Feb 2023' and were captured between 2023-03-27 and 2024-06-22. The current help.urbanpiper.com GitBook help centre has zero occurrences of recipe, raw material, intermediate, par level, wastage, purchase order or stock count; its Prime 'inventory' pages cover only marking menu items in or out of stock (86'ing). The only later first-party mentions are grade C www product-update posts. November 2023 adds delivery-date filters to Transfer Requests. January 2024 says 'Low Inventory Stock Alerts are part of Prime' (the Stock Automation Module, enabled on request to support). December 2024 announces batch and expiry tracking in 'Prime Inventory’s Batch Production module', then 'currently being piloted'. So the inventory module was still being marketed in December 2024, but the only documentation of this workflow is the 2023 archive, and current docs are silent. Not asserted current. https://web.archive.org/web/20240415221826/https://support.urbanpiper.com/support/solutions/articles/12000092224-recipe-details · retrieved 2026-09-12

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

UrbanPiper's Prime POS web-app production bundle (read 2026-09-14) stores several units per item ('Standard Item. Support multiple UOMs.'), each with a scale to the base unit and flags for 'Default Unit', 'Purchase Unit' and 'Transfer Unit'; quantities convert via unit_quantity x scale. Recipes record ingredient units and an output yield (yield_unit, yield_unit_quantity). No separate count-unit designation is named. No yield or waste percentage exists: the bundle has zero tokens for waste, wastage or shrinkage, and recipe 'Yield' is an output quantity, not a loss factor. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator

inventory-theoretical-vs-actual

REOPENED CELL, now moved on new evidence the 324th and 325th did not hold. CLAIM: theoretical-vs-actual usage variance per item for a count period, showing theoretical usage from POS sales x recipe, actual usage from counts plus receipts, and the variance in BOTH units and currency. VERDICT: partial. EVIDENCE: Prime's Stock Count detail screen is a per-item variance report and its column list is complete in the bundle: Item, Status, Unit, Batch Number, Expiry Date, **Expected** (dataIndex opening_unit_quantity), **Counted** (closing_unit_quantity), **Variance** (difference_unit_quantity, rendered with the signed percentage of expected, green above / red below, and +/-INF when expected is zero) and **Variance Value** (formatMoney(difference_value)), with a bold footer row "Total Variance Value". The variance is therefore reported in units AND in currency, per item, for the count period -- both halves of the claim's final conjunct. It is exportable: Download Stock Count PDF takes a Categories filter and an Options checkbox "Only Items with Variances" (/api/v1/inventories/stock-counts/, downloadStockCountPdf). The expected figure is real book stock: Prime carries recipes (/api/v1/products/recipes, Prepare Recipe, Recipe Auto Prepared), purchases and receives, transfers, batch production and adjustments, and the in-app alert states "Expected & variance values will now be shown after approval to ensure higher accuracy." SHORTFALL that keeps it at partial, not yes: the report is expected-ON-HAND versus counted-on-hand, and nothing in the app decomposes the expected figure into theoretical USAGE from sales x recipe versus receipts, so the claim's middle conjuncts are not shown. This supersedes the 324th no (which rested on the premise that the platform holds no stock quantity -- false) and goes past the 325th finding of bare stock tracking. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

PARTIAL. Event-driven ingredient depletion is documented, but only in a product-update post and only as an opt-in module. The January 2024 product update states that stock deductions were 'revised ... to occur only after you acknowledge an order, rather than solely after order placement in your online order tracker' -- so depletion is tied to the order event, not an end-of-day batch, which is the axis this claim turns on. The same post establishes that the units being depleted are ingredients: 'you can set a minimum stock level for your ingredients in the stock levels module', and 'Low Inventory Stock Alerts are part of Prime's comprehensive Stock Automation Module'. SHORTFALLS, all three named: (1) the Stock Automation Module is not standard -- 'To enable this Module, reach out to us at support@urbanpiper.com'; (2) the post states availability only 'for all our restaurant partners in India'; (3) no source anywhere states that modifier/option selections drive depletion, and the claim requires that limb explicitly. Note also that the POS-partner API models item stock as a single integer 'current_stock' pushed BY the POS (add-update-menu: 'The stock of the item at the outlet. If the item is never supposed to go out of stock, set this to -1') with no ingredient entity, so in an integrated deployment the depletion is the POS's, not UrbanPiper's. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

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

PARTIAL. The threshold-to-86 link is documented, but only in a product-update post. January 2024: 'Now you can set a minimum stock level for your ingredients in the stock levels module. When your stock reaches or falls below the minimum stock level, you will get a notification and your item status will be updated', with the threshold set as a 'Critical Stock Level' on each ingredient's 'Stock levels' tab. Pushing that item status outward to third-party delivery menus is UrbanPiper's core documented function (api-docs downstream/availability/item-option and the Item/Option action API's enable/disable/stock-in/stock-out actions). SHORTFALLS: (1) the auto-86 on threshold appears nowhere in the 116-page help centre -- only in a grade-D blog post -- and belongs to the Stock Automation Module, which must be switched on by emailing support and was announced for India only; (2) the claim's 'on the POS' limb is unestablished: in an integrated deployment the POS is the source of item stock (it pushes 'current_stock' to UrbanPiper), so the documented flow runs outward to aggregators rather than back into a third-party till. https://www.urbanpiper.com/blog/january-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

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

Freshdesk KB 'Stock taking guide', in the Prime > Inventory folder; Wayback capture 2023-03-27, modified 17 Feb 2023. MET (separate history): each stock count is its own record, created for a Location and a Date Time 'when you want to start stock taking'. Creating one says 'This will create a new entry, with status is' counting. It then passes 'Send for Review' and 'Approve Stock Count', and each approved count yields its own downloadable PDF report, so counts accumulate as separate entries rather than overwriting each other. PARTLY MET (full vs subset): the counter builds the count line by line, adding products 'until you've added all the product that you'll counting', or fills a downloaded CSV. The article does not name distinct full and spot-count modes; that both use this one workflow is an inference from the line-item design. SHORTFALL: no scheduled or recurring cycle count is documented. The companion article 12000092191 leaves cadence to the operator: 'Each business has it's own cadence of doing these periodic stock taking.' DATING: the Freshdesk KB (support.urbanpiper.com) is retired and was read only through Wayback. The Prime inventory articles carry 'Modified on Fri, 17 Feb 2023' and were captured between 2023-03-27 and 2024-06-22. The current help.urbanpiper.com GitBook help centre has zero occurrences of recipe, raw material, intermediate, par level, wastage, purchase order or stock count; its Prime 'inventory' pages cover only marking menu items in or out of stock (86'ing). The only later first-party mentions are grade C www product-update posts. November 2023 adds delivery-date filters to Transfer Requests. January 2024 says 'Low Inventory Stock Alerts are part of Prime' (the Stock Automation Module, enabled on request to support). December 2024 announces batch and expiry tracking in 'Prime Inventory’s Batch Production module', then 'currently being piloted'. So the inventory module was still being marketed in December 2024, but the only documentation of this workflow is the 2023 archive, and current docs are silent. Not asserted current. https://web.archive.org/web/20230327234258/https://support.urbanpiper.com/support/solutions/articles/12000092188-stock-taking-guide · retrieved 2026-09-12

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: a mobile/tablet counting app with barcode or QR scanning that keeps accepting counts with no network and syncs on reconnect. VERDICT partial. EVIDENCE: the counting tool and the scanning half are shipped. Prime Web is a browser PWA ('No additional installation is needed -- it runs entirely in your browser', help.urbanpiper.com), it registers a Workbox service worker, and it has a full stock-count workflow ('Create Stock Count', 'Add items to stock count', 'Stock Count {{number}} created successfully!', 'Approve Stock Count', 'Stock count approved and changes made to inventory') with item identification by code -- 'Item barcode', 'Are barcodes unique?', 'Either SKU/Barcode depending on company settings', 'No modifier found for this barcode', 'Configure settings related to barcodes and identifiers associated with your items'. SHORTFALL: the app's offline capability is scoped to BILLING, not counting. What it pre-caches for offline use is exactly two lists -- `/api/v1/customers/offline-list` and `/api/v1/products/location/:id/offline-top-selling-list` -- and what it queues is bills (`billSyncRequests`, `BILL_STATUS_SYNCING`, 'Retry to Sync Bill', 'Sync All', 'Sync KOTs'). No raw-material or stock-count object is pre-cached and no count queue exists; the generic banner is 'You're offline. Check your internet connection.' Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: pre-built electronic vendor catalogue and order-transmission integrations with named broadline distributors (Sysco, US Foods, PFG) that send POs and receive invoices electronically rather than by emailed PDF. VERDICT no. EVIDENCE: Prime ships a COMPLETE purchasing module -- suppliers (`/api/v1/products/suppliers`, `/api/v1/products/suppliers/search`, `/inventory/suppliers`, `/inventory/details/suppliers/:id`), purchase orders (Create/Approve/Cancel PO, 'PO Sent for Approval', 'PO Force Expired', 'Define reorder stock level here', 'Define minimum order quantity level here', 'Define order multiple here'), purchase receives, contracts and supplier email ('Email Supplier'). Its transmission mechanism is stated in its own UI string: 'PO sent to supplier via email' and 'Purchase Orders will be created for these suppliers'. That is precisely the emailed route the claim excludes. BOUND/CONTROLS: denominator = the whole Prime app (110 KB English literals + 300 API paths, no lazy chunks) plus the 240 KB help llms-full corpus. Tokenised case-insensitive: `\bEDI\b` 0/0, `sysco` 0/0, `us ?foods` 0/0, `performance food` 0/0, `broadline` 0/0, `punchout` 0/0, `cXML` 0/0. No supplier catalogue import, no distributor connector, no electronic invoice receipt object exists anywhere. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: ingests supplier invoices from photo, PDF or email and extracts line-item detail into the inventory ledger without manual line entry. VERDICT no. EVIDENCE: Prime's invoice objects are all OUTBOUND sales documents or subscription billing -- 'Invoice ID: #{{invoiceId}}', 'Invoice Type', 'Standard Invoice Template', 'In-store Invoice', 'Online Invoice', 'Starting number for invoices generated from the register', `/api/v1/billing/invoices`, `/api/v1/number/used/invoice-number`. The inbound side is 'Purchase Receive', whose UI is line-by-line entry ('Edit Lines', 'Purchase Receive Settings', 'Stock Adjustment lines updated'). BOUND/CONTROLS over the same denominator: `\bOCR\b` 0, `invoice scan` 0, `extract` 0 in an invoice sense, and the only file ingestion in the app is the generic CSV/data importer (`/api/v1/data/import/`, `/data/new-import/:id`), which takes structured rows, not a photo or PDF. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 adversarially verified

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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. VERDICT no. EVIDENCE: Prime has the inputs (suppliers, POs, purchase receives, 'Standard Cost for 1 {{baseName}}', Contracts with `/api/v1/contracts/list/purchase...`, 'Stock Valuation') and it HAS an alerting idiom, but the only stock alert it ships is a quantity one: 'When stock levels drop below this quantity, you will see low stock alerts'. BOUND/CONTROLS: tokenised over the whole app, `price change` 0, `price alert` 0, `price variance` 0, `\banomal` 0; `threshold` 2 hits, both the KDS prep-time guard 'Prep time increment/decrement should be between {{minThreshold}} and {{maxThreshold}} minutes'. No purchase-price history view and no price-deviation alert exist. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · 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

Freshdesk KB 'Setting up stock par level', in the Prime > Raw materials folder; Wayback capture 2023-03-27, modified 17 Feb 2023. MET (par per item per location): par levels can be defined 'either at raw material level (both materials and intermediates) or at their location association level.' The article gives step-by-step setup for both levels. 'Tracking stock health' (12000092189, Prime > Inventory, capture 2024-04-15) uses par: 'Stock health can be tracked in Prime based on the' par levels. The states are Healthy, Low ('- Stock is greater than 0 but less than par level') and Critical, and the stock list can be filtered by health and exported to CSV. The January 2024 www product-update post (grade C) adds a per-ingredient 'Critical Stock Level' that raises a notification, as part of Prime's Stock Automation Module. SHORTFALL: nothing documents suggested purchase-order quantities generated from on-hand versus par. POs are built by adding products, quantities and unit prices by hand ('Raise a purchase orders', 12000092185). No forecast-driven ordering mode is documented; the par and alert features flag low stock but do not propose an order. DATING: the Freshdesk KB (support.urbanpiper.com) is retired and was read only through Wayback. The Prime inventory articles carry 'Modified on Fri, 17 Feb 2023' and were captured between 2023-03-27 and 2024-06-22. The current help.urbanpiper.com GitBook help centre has zero occurrences of recipe, raw material, intermediate, par level, wastage, purchase order or stock count; its Prime 'inventory' pages cover only marking menu items in or out of stock (86'ing). The only later first-party mentions are grade C www product-update posts. November 2023 adds delivery-date filters to Transfer Requests. January 2024 says 'Low Inventory Stock Alerts are part of Prime' (the Stock Automation Module, enabled on request to support). December 2024 announces batch and expiry tracking in 'Prime Inventory’s Batch Production module', then 'currently being piloted'. So the inventory module was still being marketed in December 2024, but the only documentation of this workflow is the 2023 archive, and current docs are silent. Not asserted current. https://web.archive.org/web/20230327235745/https://support.urbanpiper.com/support/solutions/articles/12000092221-setting-up-stock-par-level · retrieved 2026-09-12

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

inventory-waste-logging

Freshdesk KB 'Log material wastage', in the Prime > Inventory folder; Wayback capture 2023-03-27, modified 17 Feb 2023. MET (a structured workflow against stock): 'Wastage are common in restaurant operations. With Prime, you can log with using the' Adjust Stock function. From Inventory > stocks, the user picks a location, clicks Adjust stock on a product, and enters an Adjustment Type, Count and Notes 'in the popup view'. The article ends 'You have logged the wastage entry.' The entry is a stock adjustment on that product and location; the article does not separately state the resulting stock figure. SHORTFALL: the Adjustment Type values are not listed, so structured reason codes are only implied (a type selector plus free-text notes). No report of waste COST, separate from count variance, is documented. DATING: the Freshdesk KB (support.urbanpiper.com) is retired and was read only through Wayback. The Prime inventory articles carry 'Modified on Fri, 17 Feb 2023' and were captured between 2023-03-27 and 2024-06-22. The current help.urbanpiper.com GitBook help centre has zero occurrences of recipe, raw material, intermediate, par level, wastage, purchase order or stock count; its Prime 'inventory' pages cover only marking menu items in or out of stock (86'ing). The only later first-party mentions are grade C www product-update posts. November 2023 adds delivery-date filters to Transfer Requests. January 2024 says 'Low Inventory Stock Alerts are part of Prime' (the Stock Automation Module, enabled on request to support). December 2024 announces batch and expiry tracking in 'Prime Inventory’s Batch Production module', then 'currently being piloted'. So the inventory module was still being marketed in December 2024, but the only documentation of this workflow is the 2023 archive, and current docs are silent. Not asserted current. https://web.archive.org/web/20230327224437/https://support.urbanpiper.com/support/solutions/articles/12000092183-log-material-wastage · retrieved 2026-09-12

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

PARTIAL. Inter-location transfers exist as a named part of Prime's Inventory Module, but only a filter change is documented, not the accounting. The November 2023 product update says: 'Now you can filter your Transfer Requests by delivery date ranges on the Transfers list view page ... so you can easily prioritise and plan your preparations based on the nearest upcoming delivery dates', reached by 'go to the Inventory Module on Prime and select Transfers', with the delivery date shown in a 'Dates' column and the filtered set exportable. That a transfer is a REQUEST carrying a future delivery date implies a raise-then-fulfil lifecycle. SHORTFALLS: no source states the two-sided credit/debit this claim requires, none names an explicit in-transit or approval state, and none states that the two ends are different LOCATIONS rather than a central kitchen issuing to itself. The whole Inventory Module is absent from the 116-page help centre, and the post announces availability for India only. https://www.urbanpiper.com/blog/november-2023-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

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

Freshdesk KB 'Issue goods on a "transfer request"', in the Prime > Inventory folder; Wayback capture 2023-03-28, modified 17 Feb 2023. PARTLY MET (a producing location issuing to others): a location raises a transfer request, or indent, naming the from and to locations ('Raise a transfer request or intent', 12000092186). The issuing location enters quantities and issues all or part of them, producing a Transfer Issue PDF for the logistics team, and once everything is issued 'the transfer request will automatically be' closed. An issuer short of stock can convert the request into a PO (12000092178). Production is documented separately: a recipe can be prepared at any location, which adds its stock there and reduces its ingredients ('Preparing recipe at a location', 12000092223). 'Base kitchens' is a listed location type ('Location details', 12000092197). No article explicitly shows intermediates or prepared items moving on a transfer; the commissary flow is assembled from these separate articles. SHORTFALL: no transfer COST or inter-location SALE is documented. No article prices a transfer issue or derives one from recipe or weighted-average cost. The November 2023 www post (grade C) confirms Transfer Requests still existed then ('Manage your Transfer Requests More Efficiently with Delivery Date Filters'). DATING: the Freshdesk KB (support.urbanpiper.com) is retired and was read only through Wayback. The Prime inventory articles carry 'Modified on Fri, 17 Feb 2023' and were captured between 2023-03-27 and 2024-06-22. The current help.urbanpiper.com GitBook help centre has zero occurrences of recipe, raw material, intermediate, par level, wastage, purchase order or stock count; its Prime 'inventory' pages cover only marking menu items in or out of stock (86'ing). The only later first-party mentions are grade C www product-update posts. November 2023 adds delivery-date filters to Transfer Requests. January 2024 says 'Low Inventory Stock Alerts are part of Prime' (the Stock Automation Module, enabled on request to support). December 2024 announces batch and expiry tracking in 'Prime Inventory’s Batch Production module', then 'currently being piloted'. So the inventory module was still being marketed in December 2024, but the only documentation of this workflow is the 2023 archive, and current docs are silent. Not asserted current. https://web.archive.org/web/20230328001839/https://support.urbanpiper.com/support/solutions/articles/12000092182-issue-goods-on-a-transfer-request- · retrieved 2026-09-12

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

PARTIAL. Batch numbers and a traceability claim are documented, but not at the points this claim names. The December 2024 product update describes 'Batch Number & Expiry Tracking in Prime Inventory's Batch Production module': 'Effortless Batch Tracking: Automatic batch number assignment keeps your inventory organized and traceable, from raw materials to final products', with 'detailed reports with batch numbers and expiry data'. SHORTFALLS: (1) batch numbers are assigned automatically at PRODUCTION, and no source describes capturing a supplier lot at receiving -- no receiving surface is documented at all; (2) the traceability asserted runs raw material to finished product and stops there, with nothing linking a batch onward to a sale or a transfer, so neither a forward nor a backward recall trace is evidenced end to end; (3) the vendor states the feature 'is currently being piloted with select restaurant partners and will soon be available to all', announced for India only, and it appears nowhere in the 116-page help centre. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

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

PARTIAL. Expiry dating is documented for prepped items. December 2024: 'Stay on Top of Freshness: Set shelf-life limits for recipes with easy "Expires In (Days)" tracking to ensure every dish meets your quality standards', and 'Actionable Insights: Access detailed reports with batch numbers and expiry data to make informed stock decisions in real time', both in Prime Inventory's Batch Production module. SHORTFALLS: (1) the shelf life is set on the RECIPE, i.e. on prepped output -- no source describes capturing a use-by date on a RECEIVED item, and no receiving surface is documented anywhere; (2) what is offered is a report carrying expiry data, not the expiring-soon report or pre-spoilage alert this claim names -- the only threshold alert published in Prime Inventory is the January 2024 quantity-based Critical Stock Level; (3) the vendor states the feature 'is currently being piloted with select restaurant partners', announced for India only, and it is absent from the 116-page help centre. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-01

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

inventory-bar-partial-bottle

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting. VERDICT no. EVIDENCE: Prime's stock count is unit-quantity based -- 'Create Stock Count', 'Add items to stock count', 'Approve Stock Count', 'Stock Count Sent for Review', 'Old Count', 'Expected & variance values will now be shown after approval to ensure higher accuracy' -- and its units system is a conversion table on the item ('Base Unit is required', 'Eg- pcs, case, g, kg, ...', 'Unit Scale'), so a raw material CAN be held in grams or millilitres. That is generic UOM, not the claim. BOUND/CONTROLS: tokenised `bottle` 0, `pour` 0, `pour cost` 0, `\bkeg\b` 0, `liquor` 0, `\bbar\b` 0 as a venue; `scale` 26 hits, all the unit-conversion map `units:{default:'pcs',base:'pcs',scale:{pcs:1}}` or CSS `transform:scale(1.4)`; `weigh` 164 hits, all CSS `font-weight` plus `weight_text` / 'Item Weight: {{weightText}}', which is a free-text weight LABEL printed on a bill line from an aggregator payload, not a captured measurement. The device enumeration is printers and USB peripherals ('No USB devices found', 'No receipt printers configured yet', QZ Tray); no weighing scale or flow-meter device type exists. WEAKEST ROW OF THIS BATCH: the generic g/kg/ml unit support means an operator could count a part bottle by weight manually; what is absent is scale integration and any bottle-fraction object. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 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

CLAIM: period COGS and accounts-payable invoice detail exported in a named accounting system's import format with GL account mapping configurable per item category. VERDICT: partial. EVIDENCE: Prime ships two named accounting integrations with real, configurable account mapping. QuickBooks Online (/api/v1/integrations/accounting-qb-online/{authorize-url,link,config/,accounts/,payment-methods/,tax-rates/}, OAuth callback /callbacks/accounting-qb-online) presents a mapping table whose prose is "Map from Prime Payment Methods into QuickBooks Online Payment Methods. If an account is missing you can add it in QuickBooks and Refresh Payment Methods", with per-payment-method PaymentAccount/<key> and PaymentMethod/<key> selects drawn from the live QBO chart of accounts. Tally (/api/v1/integrations/accounting-tally/{enable,export-configuration,import-configuration,export-data,export-types-v2}) runs a setup wizard whose question list is complete in the bundle: ledger_location, ledger_location_type ("Do you maintain separate ledgers for Online and In-store ?"), ledger_brand, ledger_platform, ledger_floor, tally_prime_item_map ("Would you like to map your catalogue items on Prime to Tally as well ?"), export_modifiers, export_payments, export_transfer_receives. SHORTFALL: that enumerated export set is sales, payments and transfer receives -- no period COGS figure and no accounts-payable purchase-invoice detail is among the export types, and the ledger mapping axes are location / channel / brand / floor / payment method plus catalogue ITEM, not item CATEGORY. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · 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

PARTIAL. The inventory module is UrbanPiper's own, not a resold third party: the December 2024 update names 'Prime Inventory's Batch Production module', the January 2024 update names 'Prime's comprehensive Stock Automation Module', and the November 2023 update instructs 'go to the Inventory Module on Prime and select Transfers' -- Prime being UrbanPiper's own store-manager application. The help centre corroborates that inventory is a first-party responsibility: the Prime Manager role 'handle[s] inventory transactions' (business-manager/user-access/understanding-standard-roles-in-prime-and-atlas). SHORTFALLS: (1) it is not part of the standard product -- 'To enable this Module, reach out to us at support@urbanpiper.com' (January 2024) -- and Batch Production was 'currently being piloted with select restaurant partners'; (2) the announcements are India-only; (3) the claim's second half, recipe COSTING, is unevidenced entirely: no cost field, plate cost or margin appears in any published source (see inventory-recipe-bom-costing), so native delivery is established for inventory but not for costing. Differentiator weight bars a yes on grade-D blog evidence regardless. https://www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-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

NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: 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. VERDICT no. EVIDENCE: both halves exist separately and are never joined. Recipes are a first-class object (`/api/v1/products/recipes`, `/inventory/recipes/all|new|details/:id|update/:id`, 'Manage Ingredients of the recipe', 'Prepare Recipe', 'Reverse catalogue item's recipe on bill void / cancellations', 'Standard Cost for 1 {{baseName}}') and sales analytics exist ('Sales Analytics', 'Avg Order Value', `/analytics/sales`, `/analytics/inventory`). BOUND/CONTROLS: tokenised `margin` = 0 occurrences in the entire 110 KB English literal set and 0 in the 300 API paths (the only `margin` bytes in the bundle are the CSS property `margin:`); `contribution` 0, `menu engineering` 0, `food cost %` 0. No per-item contribution-margin report and no margin threshold flag. Retrieved 2026-09-18. https://prime.urbanpiper.com/ · retrieved 2026-09-18 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

Hub markets a centralised reporting dashboard with operational and sales data; refresh latency and off-premise mobile access are not specified. https://www.urbanpiper.com/hub · 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

A day-end workflow exists: Prime's design-upgrade post lists 'Business Day End' among the features reachable from the POS sliding panel ('access features such as Business Day End, Order Voiding, Notes Screen, etc. from a sliding panel'), and the user-access help article has Cashiers who 'manage operational shifts using registers, process bills, and complete settlements'. The shortfall: no published page describes what the Business Day End produces, so the claim's single-document reconciliation — gross and net sales, tax, tips, discounts, refunds, tender types and expected cash deposit — is unverified; the help centre's Data & Reports section contains only per-order transaction exports, none of them an EOD packet. https://www.urbanpiper.com/blog/prime-latest-design-upgrade-top-6-exciting-highlights · 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

Modifier-level sales data is published: the Option-wise Order Transactions Report gives 'a breakdown of every single customization, add-on/Variant, and option chosen for each item in an online order' with Option Title, Option Price, Option Quantity and Option Group ID per row alongside order channel, store and date-time, and item-level counterparts exist (Item-wise Order Transactions; Items Summary Across All Locations). The shortfalls: these are row-level transaction exports over online orders, not an aggregated product-mix view; no gross-versus-net sales fields are documented at option level; and no daypart or revenue-centre filtering is documented — slicing is by channel, store and date only. https://help.urbanpiper.com/data-and-reports/option-wise-order-transactions-report · 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

UrbanPiper's Prime POS web-app production bundle (read 2026-09-14) keeps a per-bill activity log. Each entry records the event, a description, a Unix timestamp and a user, for events including 'Line item voided', 'Void bill synced', 'Discount offered on bill' and FOC settlement ('bill-settled-foc'). The register session summary prints aggregate 'Void', 'Refunds Given' and 'Discounts' figures. No consolidated audit report of comps, voids and discounts was found. A void log entry records one user (the authorizer when a manager PIN is used), not the operator and approver separately, and later voids overwrite that entry. Voids take free-text remarks rather than reason codes, and price overrides are not shown. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

Freshdesk KB 'Understanding Registers and its Sessions', in the Prime > POS folder; Wayback capture 2024-05-20, modified 17 Feb 2023. MET per register (cash drawer) per shift: the cashier counts and enters Opening Cash at the start of the shift and Closing Cash at the end. Withdrawals (including ad-hoc payments) and deposits are logged with notes during the session ('Withdraw or deposit cash during a register session', 12000092216, which says unlogged cash movements break the balancing of expected versus realized cash). 'At the Register Session level, a report is generated' showing Received (closing minus opening 'balance of the Cash Drawer'), Expected ('- This is the total from the Bills that have been generated in the Register Session') and Difference ('This is variance b/w Received and Expected.'). SHORTFALLS: (1) no per-EMPLOYEE over/short is documented; the unit is the register session. (2) As defined, Expected is the total of all bills in the session, not cash tenders specifically, and the definitions do not show how logged withdrawals and deposits enter the calculation. (3) The May 2024 www product-update post (grade C) says merchants can enable or disable the register workflow on Prime POS. With it off, 'Registers open with zero balance and unsettled bills are forcefully settled in cash at the end of the business day', so this report exists only where the workflow is on. DATING: the Freshdesk KB is retired and was read through Wayback. The POS articles carry 'Modified on Fri, 17 Feb 2023'. The current GitBook help centre has zero hits for register session or closing cash. The May 2024 post is the latest first-party confirmation that Prime registers exist, and the session report itself is documented only in the 2023 archive. Not asserted current. https://web.archive.org/web/20240520115945/https://support.urbanpiper.com/support/solutions/articles/12000092214-understanding-registers-and-its-sessions · retrieved 2026-09-12

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

CLAIM: sales per labor hour and labor cost as a percentage of sales by hour, department and employee, using actual clocked hours from the POS time clock. VERDICT: no. EVIDENCE: the claim names its own input and that input does not exist -- Prime has no time clock and stores no clocked hour or wage, so no report built on the platform can satisfy it. This verdict does NOT depend on enumerating Prime's server-side report catalogue (/api/v1/reporting/, /reports/list, /reports/preview/:id/:reportId), which I could not read. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Per-server metrics have no published home. I read all seven Atlas report articles' field lists; none carries a server, waiter, employee or tip column, and the closest actor attribution anywhere is the Store Action Report's 'username' / 'user_first_last_name', which records who toggled a store, not who sold. Average check is published only as 'Avg. Order value' in Atlas Analytics (April 2024 product-update post) cut by location, platform and brand -- the three dimensions that post names -- never by employee. Prime does have a front-of-house Captain role that 'take[s] customer orders, especially for dine-in', so the underlying data could exist, but no source describes reporting on it, and 'attachment rate' and 'items per check' return zero hits in both corpora. Unresolved. 2026-09-12 (263rd sweep, new corpus): New corpus read 2026-09-12: the 141 Wayback-recovered support.urbanpiper.com Freshdesk articles (fd) and 239 www.urbanpiper.com sitemap pages incl. 21 monthly product-update posts (www) in .cache/q263-urbanpiper/corpus.txt, word-boundary regex, every hit read in context, with the www footer phrase "manage your restaurant online and offline" neutralised before counting. changelog.urbanpiper.com is robots-barred (User-agent: * / Disallow: /; listed in data/robots-bars.json), so nothing from it is cited or restated. Prime assigns a server or waiter to each table ('Open a table and manage orders', fd 12000092210, 2023-03-27) and has a Sales Commission module setting (12000092177), so per-server data plausibly exists. But no per-server report (average check, items per check, attachment rate, tip %) is documented in fd or www. In the 2021 Quint report catalogue (12000070770), the only operator column is the POS operator on the loyalty in-store purchase transactions report. Unresolved. || 325th: MERGE HOLD (proposed no/B, held unknown): Prime POS, the store-level product, is NOT bounded: the Atlas source-map set is a census of the back office only, and Prime is covered by 27 release-note posts, which are a floor. The same gap already falsified two 324th no verdicts on Prime Inventory. A no on a store-level feature needs a census of Prime itself. PROPOSAL AS WRITTEN: 325th, CELL MOVED unknown -> no/B. BOUND as on multi-location-central-labor-policy (complete Atlas app by asset-manifest + all 6 source maps, 1,585 first-party sources, nonsense-map control 404; 27 monthly product-update posts fetched entire, 230,818 chars; 116 help and 87 API pages on record). The app's analytics surface is enumerated in its own nav config (Home, Revenue, Orders, Operations, Catalogue, Customers, Compare) and in reducers (salesAnalytics, operations, topPerforming, anaSummary, compareAnalytics); there is no server, waiter, employee or tip dimension in any of them, and the only leaderboard shipped is Orderline's agentsLeaderboard over AI phone agents, with agentDetail, scriptAdherence and violations - bot conversation quality, not average check or tips as a percentage of sales. Tips in the product are guest presets (tippingConfig) and the aggregator Driver Tip; neither is attributable to a server. Retrieved 2026-09-17. || 326th: MERGE HOLD (proposed no/B, held unknown): the no rests on the tips conjunct alone; average check and items per check by employee could sit in Prime's server-side report catalogue (/reports/list), which was not readable, so a partial cannot be excluded. PROPOSAL AS WRITTEN: CLAIM: per-server metrics including average check, items per check, attachment rate for named categories, AND tips as a percentage of sales. VERDICT: no. EVIDENCE: the tips conjunct is unsatisfiable on this platform -- Prime captures no tip at all (0 word-boundary hits for tip/tips/gratuity/tipout across 21,343 literals; the only UrbanPiper tipping feature is on the Meraki consumer channel and carries no employee attribution). The nearest per-employee report Prime ships is the Sales Commission ledger (/api/v1/commissions/employee/{id}) whose complete column list is Date, Commission, Bill Number, Item, Quantity, Applicable, Commission -- commission currency, not check averages or attachment rates. WEAKNESS I WILL NAME: Prime's report catalogue is served from /api/v1/reporting/ and /reports/list and I could not enumerate it, so an average-check-by-server report could exist there; the verdict rests on the tips conjunct, which the app census does bound. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. Retrieved 2026-09-18. || 327th: NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. NEW, NARROWER BOUND (327th) for the 326th hold: the server-side report catalogue has now been LOCATED and is confirmed login-gated, so it cannot be opened without auth and no bypass was attempted. `/reports/list` is a CLIENT ROUTE, not an API; the catalogue behind it is `GET /api/v1/reporting/v2` (with `/api/v1/reporting/{group}/v2`, `POST /api/v1/reporting/{group}/export/{id}/v2`, `/api/v1/reporting/history`, `/api/v1/reporting/history/all`). Probed anonymously 2026-09-18: HTTP 400 {"errorCode":"BAD_REQUEST","message":"Access Token is required for this request"} -- a live gate, not a 404. The bundle embeds NO report names or ids: the only report literals in the whole 110 KB English set are the chrome ('All Reports', 'Report Name', 'Store Reports', 'No reports found', 'View all your reports here', 'Export Report', 'Report will be available shortly'), and the list component renders `l(ne.name)` from the server payload. So the per-server-metric conjuncts stay unreadable. What IS visible and adjacent, not equivalent: per-employee Sales Commission (`/company-admin/sales-commission/employee/:id`, 'View Sales Commission', `/api/v1/commissions/employee/`). Tokenised `average check` 0, `items per` 0, `attachment rate` 0, `scorecard` 0. The tips conjunct remains unsatisfiable (no tip capture). Retrieved 2026-09-18. || 331st: 331st NEW SURFACES, still unknown. (a) The Prime report catalogue's only public picture: changelog post 296721's image (cloud.headwayapp.co/changelogs_images/images/big/000/130/598-...png, read as an image; 'original' size 403s) shows Prime > Reports > Sales > Day Summary Reports (Summary, Summary Detailed, Bills, Register Session Payment Summaries, Payments, Products), then Product Sales Report and Period Sales Reports -- a cropped view of ONE category, not a census, and no employee/server report is in frame. changelog.urbanpiper.com is a Headway CNAME (account x9bqE7) and still lists the same 29 posts as the 326th. (b) 331st NEW SURFACE: the Prime ANDROID app unpacked (com.urbanpiper.satellite_prime v69.0.0, versionCode 457, XAPK 43,935,331 B fetched anonymously via d.apkpure.com; base APK + config splits; never executed). It is React Native with a Hermes bytecode bundle (assets/index.android.bundle, 8,696,000 B, magic c61fbc03, version.txt 1.10.0_ed1d888b); its i18n table holds 863 [[key]] entries and 40 /api paths, a strict SUBSET of the web app (order tracker, KOTs, bills, register sessions, external-payment devices incl. /pinelabs/devices). Its keys add 'Select Server', 'Add Server', 'Server: {{server}}', 'Cashier: {{cashier}}' (bill attribution again) and `average` 0 / `report` 0 as i18n keys: the mobile app has no reports module. The gated /api/v1/reporting/v2 catalogue remains the blocker. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. report.svc.urbanpiper.com/openapi.json (20,642 B, 14 operations) is the report service behind Prime/Atlas 'All Reports': GET /v1/reports returns ReportListViewResponseModel = [Group{group, reports:[ReportType{id, name, description, filters, supported_formats, preview_available}]}], and every /v1/reports* operation carries security HTTPBearer. So the catalogue is DATA returned per tenant, not part of the contract: the spec names no report, and the catalogue stays unread (no call was made). ON THIS CELL: this confirms the 327th finding from the server side - the per-server metrics question sits entirely in the tenant's report catalogue, which the contract does not enumerate and which answers only to a bearer token. No report-list surface is public anywhere else either: the Webflow site search on www.urbanpiper.com/search swept for report, reports, staff, employee and waiter returned only pages already in the 239-URL sitemap. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: over all 15 contracts employee 0, staff 0, cashier 0, waiter 0, gratuity 0, tips 0; tip 2, both in order-line (Orderline, the AI phone-ordering agent: 'Tipping Amount ... Absolute tip amount', a guest tip on a phone order, not a per-server tip-%). No scorecard surface exists in any contract; the catalogue remains the bearer-gated report.svc GET /v1/reports. Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: 'What are the reports that are available? Prime has extensive reports in the following categories: Sales, Online Ordering, Employee Reports, Restaurant Operations, Payments, Taxes and Fees, Inventory, and Transfers and Purchasing.' ON THIS CELL: an 'Employee Reports' category exists in the unread server-side catalogue, which confirms the 326th hold's reasoning (average check / items per check by employee could sit there); the tips-as-%-of-sales conjunct is still unsupported (Prime captures no tip). No contents named, so no partial. Unknown. Retrieved 2026-09-18. adversarially verified

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

The channel dimension and the revenue side are both present at transaction grain, and the cost side is explicitly absent. Every row of the Order Transactions Report carries "Channel: The specific online platform where the order was placed (e.g., 'zomato', 'swiggy')", "Fulfillment mode... (e.g., 'delivery', 'pickup', 'dine-in')" and "Delivery Type... (e.g., 'Partner' for the aggregator's delivery fleet, 'Self' for your own delivery staff)", so revenue separates by marketplace and by fulfilment path, and the promotional cost is split by who funded it -- "Aggregator Discount: The part of the discount that was funded by the online platform" against "Merchant Discount... funded by your restaurant." SHORTFALL is the claim's own qualifier, net of marketplace commission, and the report defines itself out of it: Merchant Total is "the amount your restaurant is expected to receive from the order, after aggregator discounts but BEFORE aggregator commissions." No commission figure appears in any documented report field, so margin by channel cannot be computed from these reports alone. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/order-transactions-report · retrieved 2026-08-31

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

Consolidated across-location reporting is a documented, named product surface: two reports exist specifically for it -- "Items Summary Across All Locations Report... consolidating all the data from every location into one simple view", carrying Total Quantity, Total Amount, Total Taxes and Total Charges per item, and "Menu Snapshot Across All Locations Report... showing their pricing, availability, and categorization across every one of your restaurant locations". Drill-down to the individual transaction is available in the sense that the Order Transactions Report is one row per order with Store Name, Store ID and Store ref ID on it. SHORTFALL: the claim asks for a consolidated report with SIDE-BY-SIDE location comparison and navigational drill-down from group total to location to transaction, and what is documented is a set of separate exports at different grains. No article shows locations compared against each other in one view, and there is no documented path from a group figure to the rows behind it -- the operator re-runs a different report with a location filter. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-08-31

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

PARTIAL. What is documented is a fixed catalogue with a rich filter and scheduling surface, not a report builder. The reports landing page walks the entire configurable path: 'Navigate to the All Apps section and select Central Report ... You will see a list of all available reports'; then per report, 'Choose a pre-defined time range (daily, yesterday's, this week's, monthly) or select a custom date', 'Apply filters to sort by brand, location, or aggregator', 'Customize your report by selecting which order statuses you want to display', then preview, download as CSV or XLSX, email, or 'set up a recurring schedule', which persists the chosen report plus 'a date range and applying filters for brands, locations, platforms, or Meraki channels'. Atlas Analytics adds in-dashboard configuration -- 'advanced filtering and sorting directly within the dashboards' (April 2024 post), a Compare tab taking up to four location groups (December 2024 post), and a 'Customizable Location Performance Table' where you 'add columns for taxes, charges, discounts, and other revenue components' (February 2025 post). SHORTFALL: every one of those is a filter, a column toggle or a schedule over a PRE-BUILT report or dashboard. No source describes choosing dimensions and measures freely, and the only thing that can be saved is a delivery schedule of a named canned report -- not a user-defined report object. A named limit on the schedule too: 'the default schedule is set to deliver reports at 8 a.m. for the previous day. At this time, custom delivery times are not available.' https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

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

Recurring automatic delivery exists and its cadence is fixed. Any report in Central Report can be scheduled -- "Click on the Schedule button and choose the report you want to schedule", then "Customize the data by selecting a date range and applying filters for brands, locations, platforms, or Meraki channels", then "Confirm and Schedule" and "Choose your desired format to finalize the schedule" -- and delivery is by email: "You will now receive your scheduled order transaction report in your email every day at 8 a.m." A one-off email route exists alongside it, where "A secure link to download the generated report will be sent to your inbox." SHORTFALL, and the article states it against the vendor's interest: the cadence is not operator-defined. "Note that the default schedule is set to deliver reports at 8 a.m. for the previous day. At this time, custom delivery times are not available." No recipient LIST is documented either -- the one-off route takes a single address -- and there is no shared destination (SFTP, bucket, drive) as an alternative to email. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

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

THE CELL THE 179th DEFERRED PENDING THIS READ, now settled. Recurring automated export of transaction-level data does exist -- the sibling extensibility-bi-data-warehouse cell records the Central Report scheduler delivering a daily order-transaction report at one-row-per-order grain -- so the claim's 'not just manual CSV download' half is satisfied. SHORTFALL is the customer-controlled destination, and the API read is what closes it rather than leaving it open: across the entire public API reference (llms-full.txt, 778,699 bytes, manifest-verified complete at 86 entries and 0 unmatched) the strings export, S3, SFTP, Snowflake and BigQuery occur ZERO times, and the 86 documented endpoints cover stores, menu, availability, order relay and rider status with no reporting, analytics or bulk-extract endpoint among them. So the recurring pipe terminates in email and no programmatic route to a customer-controlled destination is documented on either surface. https://api-docs.urbanpiper.com/downstream/llms-full.txt · retrieved 2026-08-31

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

The documentation half is fully satisfied and the credentials half is not. A public REST reference covers orders (Order Relay, Order Status Update, Rider Status Update), menu (Add/Update Menu, Menu Toggle, Category Timing Groups) and stores (Add/Update Stores, Store Toggle), readable without any agreement. PARTIAL on three counts, the first being the claim's own operative condition -- self-service credentials. This page states the gate: "We have two environments - the **Staging** environment (also referred to as the **pos-int** environment) and the **Production** environment. The access to the staging environment is provided after the partnership agreement is in place", and "Production environment base URL will be provided in the integration certification email by us." Second, there is no labor data in the API at all. Third, payments are present only as fields inside an order payload, never as a resource with its own endpoints. https://api-docs.urbanpiper.com/downstream/getting-started/environments.md · retrieved 2026-08-31

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

Outbound webhooks to a customer-supplied endpoint exist and retry behaviour is documented in unusual detail: "we have a retry logic (3 attempts) in place for dealing with request failures (Read timeout/ *Bad Request/ Connection time-out)* while making the webhook callback to 3rd party URLs", against a published "**Connection timeout of 3 seconds** and **Read timeout of 5 seconds**". PARTIAL on the signature limb, which the vendor forecloses rather than omits. The companion callbacks page (getting-started/webhooks-callbacks.md) states that a static token-based authorization is the only mode available for these endpoints and that no other mode of authorization is supported on the vendor side, and the strings HMAC, signature and X-Signature occur zero times in the entire 778,699-byte reference. There is no payload signature to verify. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker.md · retrieved 2026-08-31

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

PARTIAL. Raw data is included; a programmatic API for the merchant is not. Included side: any Atlas user with the Sales Analytics role can export order-, item- and option-level transaction data as CSV or XLSX, receive it by email, or schedule it, with no fee named anywhere (data-and-reports/getting-started). SHORTFALL, and it is the substance of the claim: UrbanPiper's public API is a POS-PARTNER programme, not a merchant entitlement. The onboarding page opens 'Once you have completed the signup formalities for the integration programme you will receive the credentials for Gamma', requires progress tracking through a partner dashboard, and gates production on certification -- 'We shall validate all the APIs marked as "To-be-verified" during the testing session ... Partner will be marked as "Active" post that' -- after which 'POS partnership team converts "Backlog" to "Merchant"'. Every one of the 87 documented endpoints is stores, menu, availability, orders or webhooks; there is no reporting or data-export endpoint at all. Whether money changes hands is undetermined: www.urbanpiper.com publishes no pricing page in its 239-URL sitemap, and the one pricing signal found is the December 2024 launch of Scheduled Reports as a 'Limited Time Free Trial', which implies scheduling is chargeable. https://api-docs.urbanpiper.com/downstream/getting-started/onboarding-process · retrieved 2026-09-01

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

325th, CELL MOVED unknown -> partial/B. The prior note said there is no published plan structure to test the claim against; the Atlas app publishes one in its own code. EVIDENCE: the 'All Apps' catalogue is built in two titled tiers - 'Essentials' = Customers, Orders, Catalogue, Menu, Schedules, Kitchen Display (KDS), Rider Display (RDS), Analytics, Central Reports, Marketing, Reconciliation, Platform Apps; 'UrbanPiper Boosters' = Periscope, Disputes, Orderline, OrderDesk, Reviews, Meraki. Each entry carries render and isLocked predicates, and they differ in kind: Analytics renders on (access.isSalesAnalysis || access.isOperationsAnalysis || access.isMarketing) and Central Reports on (access.isSalesAnalysis || access.isOperationsAnalysis) - USER-ROLE gates with no isLocked - while the paid layers carry explicit commercial gates (isLocked:!biz.modulesEnabled.includes('Meraki') on Meraki and on Meraki Coupons/Referrals with merakiWebSubscription.subscription.status in [null,'cancelled','not-subscribed']; isLocked:!biz.isOrderlineEnabled; isLocked:!isOrderdeskEnabled; Reconciliation renders on biz.isReconEnabled). So multi-location comparison (/analytics/compare, render:true) and PMIX-equivalent catalogue analytics sit in the unpaid-for tier, not behind an analytics SKU. SHORTFALL (why partial): two conjuncts cannot be met - labor-vs-sales does not exist at all (no labour data anywhere in the product) and no comps/voids audit report is published - and one feature IS commercially gated: UrbanPiper launched Scheduled Reports as 'Schedule Your Reports on Atlas - Limited Time Free Trial!' with 'Start your free trial by navigating to Scheduled Reports in the Reports section of Atlas' (www.urbanpiper.com/blog/december-2024-product-updates-whats-new-in-our-restaurant-tech-platform, 2024-12-17), and the entry price itself is quote-based. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 adversarially verified

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

324th, CELL MOVED unknown -> no/B on a REBUILT legal corpus the old record predates. CLAIM: documents >=24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. VERDICT: no -- UrbanPiper publishes the opposite on both conjuncts. EVIDENCE: Merchant Agreement clause 10, 'Data Access, Reports and Sources', 10.2: 'We will try to provide access to all historical data through the dashboard of the Services. You acknowledge and agree that data preceding more than one (1) year may not be available for some data sets. You may request Us for such data and We shall at Our sole discretion provide some or all of the data requested subject to a reasonable fee as determined by Us.' 10.1 adds 'You are advised to take regular data backups to ensure all historical data is available with them at all times.' The published window is therefore best-efforts, one year for some data sets, and retrieval beyond it is discretionary and chargeable -- the archive retrieval fee the claim rules out. Corroborated by the Privacy Policy retention schedule: 'Order and integration data routed through Hub: retained only transiently for the purpose of delivering the integration and, where logs are kept, for up to 90 days, unless the Merchant's instructions require otherwise', against 'Account and User data (Atlas): for the duration of the Merchant's relationship with Us and for up to 24 months thereafter'. The help centre's cancellation page says the same thing operationally: 'Download any reports or data you need from UrbanPiper before your subscription ends, as your data will be permanently removed after cancellation.' CONTROLS: '24 months' = 0/1 (the Atlas account-data clause, not transaction detail), '12 months' = 0/1 (recruitment data), 'months of data' = 0/0, 'data retention' = 0/3. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-17 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

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Every alert documented is event-driven, not metric-threshold-driven. Prime Web's notification settings offer 'New orders, Customer complaints, Cancelled orders, Stock toggles (availability changes), And other important updates' with a chosen sound (store-manager/prime-web/customise-notification-settings), and store-manager/prime-app/managing-notifications is the same shape; the April 2025 payment-reminder alerts concern the merchant's own overdue UrbanPiper invoice. The one threshold alert in the product is inventory, not reporting: crossing an ingredient's Critical Stock Level fires a notification (January 2024 post). Nothing lets an operator set a threshold on a sales, void or discount metric, and 'anomaly', 'deviation' and 'below forecast' return ZERO hits in both corpora. NOT scored no because that settings list ends 'And other important updates', so it does not enumerate its own surface, and Atlas Analytics has no help-centre documentation at all to test. Unresolved. 2026-09-12 (263rd sweep, new corpus): New corpus read 2026-09-12: the 141 Wayback-recovered support.urbanpiper.com Freshdesk articles (fd) and 239 www.urbanpiper.com sitemap pages incl. 21 monthly product-update posts (www) in .cache/q263-urbanpiper/corpus.txt, word-boundary regex, every hit read in context, with the www footer phrase "manage your restaurant online and offline" neutralised before counting. changelog.urbanpiper.com is robots-barred (User-agent: * / Disallow: /; listed in data/robots-bars.json), so nothing from it is cited or restated. Every www alert/anomaly/threshold hit is an event or inventory alert: January 2024 low-stock alerts (Stock Automation Module); May 2024 'Bolt', which monitors store and item AVAILABILITY with 'real-time alerts on multiple platforms like WhatsApp, Telegram, Email, and Slack'; February 2024 order-push-failure notifications; June/July 2024 aggregator complaint alerts; August 2023 advance-order notifications. The single fd hit is not a metric alert. None lets an operator set a threshold on a sales, void or discount metric, or detects deviation from historical patterns. Bolt comes closest, but it monitors operational availability, which is not what the claim describes. Unresolved. || 325th: MERGE HOLD (proposed partial/B, held unknown): the alerts builder is event-based, not a metric threshold or deviation, and its event enum is server-side and unread. The agent flagged it as its weakest row. PROPOSAL AS WRITTEN: 325th, CELL MOVED unknown -> partial/B. NEW SURFACE: Atlas ships an operator-facing Alerts builder that the doc corpora never mention. EVIDENCE (Atlas source maps): components/Alerts/AlertHeader.js renders 'Alerts / View and configure all your alerts here' with a 'Create an Alert' button, an Active/Archived filter and brand+location filters; containers/Alerts.js (49 KB of source) builds the form from backend metadata - EVENT_TYPES from alertMetadata.event_types (fallback [{label:'Store Closure by User', value:'store_closure'}]), ALERT_MEDIUMS from alertMetadata.mediums filtered to is_implemented (fallback [{label:'By Email', value:'email'}]), AGGREGATION_LEVELS = [{label:'Location', value:'location_id'}] with Brand and Global commented out, plus a reopen reminder ('send a follow-up alert if the store is still down') mapping to AlertConfig.reopen_reminder.after_hours, presets 6/12/24/48 h, product-capped 2-48 h. services/alertConfigService.js posts to ${PERISCOPE_BASE_URL}/api/v1/alert-configs/create and lists by brand_id / location_id / event. SHORTFALL (why partial): every documented trigger is an operational EVENT from Periscope's availability monitoring (store closure, item downtime), not a metric threshold or a deviation from a historical pattern - tokenised case-insensitive controls over all 1,585 first-party sources return 'anomaly' 0, 'deviat' 0, 'forecast' 0, and the 44 'threshold' hits are all unrelated (IntersectionObserver visibility thresholds, a Fuse.js fuzzy-match threshold, Meraki's minimumWalletCreditThreshold / pointUseThreshold, an Orderline low-score drilldown threshold=50, an idealTextColor contrast threshold of 105). No void-spike, discount-rate or sales-below-forecast alert exists. BOUND CAVEAT: the event_types enumeration is served by the Periscope API at runtime and cannot be listed anonymously, so the absence of a metric-threshold event type is bounded by the client's form code and its fallback, not by the server's full enum. Retrieved 2026-09-17. || 326th: NEW SURFACE, still unknown; the 325th partial was held and the Prime census does not rescue it. Prime's own notification surface is /api/v1/notifications/ and /api/v1/notifications/events, and like the Atlas alerts builder its event vocabulary is returned by the server, so it is still unread. What the complete Prime bundle DOES enumerate is threshold-style alerting on stock only -- "Critical Stock Level", "Low inventory", and the stock automations at /automation/stocks and /api/v1/automations/stocks/ with an Availability Changes / Recommendation History tab -- i.e. a fixed low-stock threshold, not a configurable metric deviation on sales, voids, discounts or labour. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. || 331st: 331st NEW SURFACE: the Prime ANDROID app unpacked (com.urbanpiper.satellite_prime v69.0.0, versionCode 457, XAPK 43,935,331 B fetched anonymously via d.apkpure.com; base APK + config splits; never executed). It is React Native with a Hermes bytecode bundle (assets/index.android.bundle, 8,696,000 B, magic c61fbc03, version.txt 1.10.0_ed1d888b); its i18n table holds 863 [[key]] entries and 40 /api paths, a strict SUBSET of the web app (order tracker, KOTs, bills, register sessions, external-payment devices incl. /pinelabs/devices). Its 863 i18n keys hold no alert/threshold/anomaly key (`alert` 0, `anomaly` 0; the raw `threshold` 48 / `deviat` 4 string hits are regex and library identifiers, e.g. relativeTimeThreshold, recoveryThreshold). The Headway changelog images for the 7 analytics/report posts were read: none shows an alert configuration. Unresolved. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. report.svc.urbanpiper.com/openapi.json (20,642 B, 14 operations) is the report service behind Prime/Atlas 'All Reports': GET /v1/reports returns ReportListViewResponseModel = [Group{group, reports:[ReportType{id, name, description, filters, supported_formats, preview_available}]}], and every /v1/reports* operation carries security HTTPBearer. So the catalogue is DATA returned per tenant, not part of the contract: the spec names no report, and the catalogue stays unread (no call was made). ON THIS CELL: the report service's only proactive delivery is SCHEDULED, not conditional - POST /v1/reports/schedule with ScheduleData = {report, report_filters, schedule_for, show_data_for, status, emails, export_format, dispatch_times}, ScheduleFor = Every Day | Every Week | Every Month | Every Quarter | Intraday, ShowDataFor = Previous Day | Previous Week | Previous Month | Previous Quarter | Since Last Slot | No Date Range. There is no threshold, condition, comparison or baseline field in the schedule contract, so this is timed report e-mail, not a metric alert (adjacent, not a partial). notification.svc.urbanpiper.com/openapi.json ('UrbanPiper Notification Service - Activity & notification read API for Atlas', 7 operations: /activities, progress, details, /ws/auth, /realtime/auth) is a read/transport API with no rule configuration. The alert-rule service the 325th located in the Atlas source (Periscope, /api/v1/alert-configs) answers 401 on its staging host and exposes no spec, so its event enum is still unread. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: alert 0, alerts 0, anomaly 0, deviation 0 across all 15 contracts; threshold 18, all POISON: automations (13) is an internal on-call/Slack 'piperbot' RAG tool whose threshold is a 'Similarity threshold' for issue search, and order-line (5) is the Orderline call dashboard's fixed 'abandoned threshold (20s)' drill-down, not an operator-configured metric alert. activity-history.svc (LIVE in production, 'Read-only API serving merchant activity history from ClickHouse') and notification are job-progress feeds (ActivityResponse: title, status, total/completed/failed_count, notification_type) with no rule, condition or baseline field. No alert-rule contract exists among the published services. Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: (no alert or threshold language in the FAQ: threshold 0, notification 0, alerts 0 across the four captures; alert 1 is POISON, the form script's JS alert(e) call). ALSO NEW: the vendor YouTube channel censused with yt-dlp for the first time (UCoeKYcu9uuK_-g4zptkBDrg: 51 videos, 20 shorts, 0 streams; titles in .cache/q334/urbanpiper/a/yt_list.txt) - customer stories, founder interviews and marketing; the only title naming Prime is 'Captain App For Restaurants ... Prime POS' (RYWzF70fJ_I, 79 s) and the only analytics title is the Atlas dashboard launch (s3iRA09Psuk, 111 s); no alerts tutorial exists. Unknown. Retrieved 2026-09-18. 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

325th, CELL MOVED unknown -> no/B. The record now holds the whole Atlas back-office app (census on menu-pricing-upsell-prompts) and both AI surfaces in it fall short of the claim. (1) components/ExplainWithAI/ExplainWithAI.js is shipped: it POSTs {payload} to ${REACT_APP_NEW_BASE_API_URL}${REACT_APP_API_EXPLAIN_JSON}, streams the reply token-by-token under the heading 'Explanation by PIP' with the footer 'AI-generated content may contain errors', and auto-fires on mount whenever a payload is present. It EXPLAINS an analytics payload the page already fetched; there is no question input, and it returns prose, never a figure or chart. (2) containers/PipSearch.js is a Cmd-K command palette over the app's own nav/create/help items using Fuse.js (threshold 0.4) with typed placeholders like 'Try "Orders" or "Items"'; its item types are Go To / Analytics / Create / Help. It declares MODES={SEARCH,CHAT}, but the CHAT branch calls fetch('http://localhost:8000/chat') and, when that fails, returns canned strings ('I can't analyze data right now as I'm unable to connect to the analysis server'), optionally reformatted through generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash - a developer's local backend, i.e. not shipped to tenants. BOUND: all 6 files in /asset-manifest.json with their source maps, 1,585 first-party sources, 11.8 MB of sourcesContent, nonsense-map control 404; plus the 116-page help centre and 87-page API reference already on record and 27 monthly product-update posts on www.urbanpiper.com (230,818 chars of stripped text) where 'natural language' returns 0. CONTROL POISON found and discarded: 'llm' matches 595 times only as a substring (allMenus etc.); 'ML ' matches 'HTML '. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 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

UrbanPiper's Atlas console (the merchant dashboard that also hosts Meraki) ships a 'Customer Analytics' page (src/containers/Analytics/Customers.js, from the public source map of main.550329ed.js; the same strings are in the 2026-07-30 Wayback capture of main.11fd3553.js). It has tabs 'Active Customers', 'New vs. Repeat Customers' and 'New Customers Breakdown' ('Breakdown of first-time customers by the platform or brand they used.'), plus metric cards 'Repeat Customers' ('Customers who placed multiple orders during the selected time range.') and 'Lapsed Customers' ('Customers who haven't placed an order in the selected time range, even though they ordered before.'). New-versus-returning counts are met. Visit frequency is short: 'repeat' means only more than one order in the range. Lifetime-spend cohorts are absent. The page shows aggregate counts filtered by platform and brand with no link to identifiable guest records, and it states 'Customer Analytics isn’t available for selected platforms & dates before Jan 1st, 2025.' https://web.archive.org/web/20260730213022/https://atlas.urbanpiper.com/static/js/main.11fd3553.js · retrieved 2026-09-14 adversarially verified

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

325th, CELL MOVED unknown -> no/B. BOUND: the complete Atlas back-office app (asset-manifest census, 1,585 first-party sources, 11.8 MB sourcesContent, nonsense-map control 404) plus 27 monthly product-update blog posts (230,818 chars) that the record did not hold. Tokenised case-insensitive 'forecast', 'predicted', 'projection' and 'demand planning' return ZERO hits across all 1,585 sources; 'predict' returns 2, both in unrelated comments. The app enumerates its own analytics surface and it is entirely retrospective: the Analytics nav children are Home, Revenue, Orders, Operations, Catalogue, Customers and Compare, and Central Reports is a downloader. The only 4 'forecast' occurrences anywhere in the marketing corpus are in a generic advice article ('Mistake 2: Failing to Forecast Demand Accurately'), whose own remedy is to read UrbanPiper's existing item-level analytics and order-volume heatmap - i.e. the vendor tells operators to forecast by eye from historical reports. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 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

REPLACES the prior rationale. Re-examined 2026-09-02 by direct grep of the two on-disk first-party corpora (.cache/urbanpiper/help-corpus.txt, 479,604 chars, all 116 pages of help.urbanpiper.com; .cache/urbanpiper/apidocs-corpus.txt, 924,046 chars, all 87 pages of api-docs.urbanpiper.com -- each host's llms.txt manifest fetched entire and every listed page live), plus a by-hand read of www.urbanpiper.com/sitemap.xml and of the March 2025, February 2025 and November 2024 product-update blog posts. I do not restate a sitemap URL count: two reads of the same file through my fetch tool returned different totals, so that denominator is not one I measured. Tips DO exist in the data model and they are couriers', not servers': the partner API's order payload types a charge 'title' with expected values 'Restaurant Packaging Charge', 'Packaging Charge', 'Delivery Charge', 'Service Charge', 'Driver Tip', 'Surcharge', 'Other Charges', and the per-aggregator support matrix lists 'Driver Tip' for Zomato, Swiggy, Talabat, Careem, Deliveroo, Uber Eats and Justeat. That is an aggregator-passed courier tip on an order with no employee attached; 'gratuity', 'tip pool' and 'declared tips' return ZERO hits in both corpora, no Atlas report carries a tip column, and no employee or timecard object exists anywhere (see reporting-labor-productivity). The tax half exists only as raw columns -- 'Merchant Taxes' ('Taxes that your restaurant is responsible for collecting and remitting'), 'Total Taxes', and a per-charge 'liability_on' attribute in the order payload -- never as a jurisdiction-level liability summary, and no payroll export of any kind is documented. Unresolved: the employee tip reporting this claim is about has no published source in either direction. 2026-09-12 (263rd sweep, new corpus): New corpus read 2026-09-12: the 141 Wayback-recovered support.urbanpiper.com Freshdesk articles (fd) and 239 www.urbanpiper.com sitemap pages incl. 21 monthly product-update posts (www) in .cache/q263-urbanpiper/corpus.txt, word-boundary regex, every hit read in context, with the www footer phrase "manage your restaurant online and offline" neutralised before counting. changelog.urbanpiper.com is robots-barred (User-agent: * / Disallow: /; listed in data/robots-bars.json), so nothing from it is cited or restated. tip/gratuity/tip pool: no fd product hit; the www 'tips' hits are blog advice ('marketing tips'). Nothing documents declared versus charged tips per employee, tip pool distribution, or a tax liability summary by jurisdiction. The 2023 fd 'Taxes' article (12000092174) warns that UrbanPiper does not file sales tax and that its reports only help the merchant do so. Unresolved. || 326th: MERGE HOLD (proposed no/B, held unknown): the tip conjuncts are unsatisfiable (Prime captures no tip) but the claim's tax-liability-summary-by-jurisdiction conjunct lives in the unread server-side report catalogue, so a partial cannot be excluded. PROPOSAL AS WRITTEN: CLAIM: declared versus charged tips per employee, tip pool distribution detail and a tax liability summary by jurisdiction. VERDICT: no. EVIDENCE: Prime captures no tip at all -- `tip`, `tips`, `tip pool`, `tipout`, `tip share`, `gratuity` are 0 as word-boundary tokens across the complete 4,860,546 B app bundle and its 21,343 literals, and there is no declared-tip field on a bill, a payment or a register session. The bill's only add-on money is the generic Charges entity (/api/v1/sales/fees, Charge Type, Charges on Bill), a merchant charge with no employee attribution. UrbanPiper's one tipping feature is on Meraki, its consumer ordering channel (changelog: "Turn appreciation into tips on Meraki", configured in Atlas under Meraki > Settings > Apps, three preferred tip values plus custom), and the post states "Tips do not attract taxes or charges" -- no employee, no pool, no jurisdiction. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. Retrieved 2026-09-18. || 327th: NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. NEW, NARROWER BOUND (327th) for the 326th hold: the unread server-side report catalogue is now located and confirmed auth-gated -- `GET /api/v1/reporting/v2` answers HTTP 400 'Access Token is required for this request' anonymously (probed 2026-09-18); no login was attempted. The bundle embeds no report names or ids, so the tax-liability-summary-by-jurisdiction conjunct cannot be settled from the client. Confirmed on the tips side: tokenised `\btip\b` in the Prime app returns 7 substring hits and every one is poison -- `multiple`, `Multilingual`, `Municipal`, `encodePosMultipleVoidLine` -- so Prime captures no tip, declared or charged, and that conjunct is unsatisfiable. Retrieved 2026-09-18. || 331st: 331st NEW SURFACE: the Prime ANDROID app unpacked (com.urbanpiper.satellite_prime v69.0.0, versionCode 457, XAPK 43,935,331 B fetched anonymously via d.apkpure.com; base APK + config splits; never executed). It is React Native with a Hermes bytecode bundle (assets/index.android.bundle, 8,696,000 B, magic c61fbc03, version.txt 1.10.0_ed1d888b); its i18n table holds 863 [[key]] entries and 40 /api paths, a strict SUBSET of the web app (order tracker, KOTs, bills, register sessions, external-payment devices incl. /pinelabs/devices). `tip`/`gratuity` 0 as i18n keys (the single raw `tips` hit is React's 'for tips about how to debug'); `jurisdiction` 0. The one Prime report-list image (changelog 296721) shows only the Sales > Day Summary group, no tax report in frame. Unresolved. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. report.svc.urbanpiper.com/openapi.json (20,642 B, 14 operations) is the report service behind Prime/Atlas 'All Reports': GET /v1/reports returns ReportListViewResponseModel = [Group{group, reports:[ReportType{id, name, description, filters, supported_formats, preview_available}]}], and every /v1/reports* operation carries security HTTPBearer. So the catalogue is DATA returned per tenant, not part of the contract: the spec names no report, and the catalogue stays unread (no call was made). ON THIS CELL: the tax-by-jurisdiction conjunct the 326th hold turned on lives in that unread per-tenant catalogue; the contract names no report and no tax grouping. The production payments contract (payments.svc) and order contract (order-edge.svc) carry tax only as order/item-level lines (Tax, TaxLiabilityType = merchant | platform), and `tip` scores 0 in both specs, consistent with Prime capturing no tip. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: jurisdiction 0, gratuity 0, tips 0 across all 15 contracts; tip 2 = Orderline phone-order guest tip (order-line 'tipping_amount'/'tipping_percentage'), not Prime and not a per-employee declared-vs-charged tip. The tax-by-jurisdiction conjunct still lives only in the bearer-gated report.svc catalogue. Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: 'Prime has extensive reports in the following categories: Sales, Online Ordering, Employee Reports, Restaurant Operations, Payments, Taxes and Fees, Inventory, and Transfers and Purchasing.' ON THIS CELL: a 'Taxes and Fees' report category exists in the unread catalogue, which is exactly the 326th hold's point (the tax-liability-by-jurisdiction conjunct cannot be excluded); its contents are not named, and the tip conjuncts remain unsupported. Unknown. Retrieved 2026-09-18. adversarially verified

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 levels exist as first-class objects: a business identified by its Biz ID, brands beneath it ("Multi-Brand Support: Allows restaurants to manage each brand independently, making it ideal for groups with diverse brand offerings"), and locations, with Location Groups as a further grouping object used to scope taxes, charges and schedules. Reporting scopes to them -- the Business Manager "empowers you to oversee all orders processed across various locations and platforms". SHORTFALL is the permissions half, and the documentation states it against the vendor's interest: "The location-level access is not available in Atlas." Above-store permissions are therefore not location-scopable except through two purpose-built roles (Non-HQ Analytics and Non-HQ Report) that restrict downloads to designated locations; genuine per-location role assignment exists only in Prime, the store-level product. There is also no region or area tier as a named object -- location groups are an association device rather than a level of a hierarchy. https://help.urbanpiper.com/business-manager/introduction · retrieved 2026-08-31

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

One-click menu updates propagate across all channels and outlets; a publish/version history showing what, when and by whom is not documented. https://www.urbanpiper.com/hub · retrieved 2026-08-01

Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator

multi-location-local-override-policy

REPLACES a seeded placeholder rationale that recorded no work, not absence. The partner API reference documents the override surface field by field. 'In our system, the menu is handled in a federated structure. For each of the menu entities, a master record is maintained and then for each store, references are set to the master menu entities.' Then the per-field rule, quoted in full: 'NOTE: At present, categories and option groups are maintained only at the master level, since there aren't many scenarios where the metadata for these entities would vary between stores. For an item, the metadata that varies between stores are: price, current_stock, sort_order, recommended and availability. And for an item option, this can be price and availability.' That is a closed list of store-varying fields (price and availability among them, as the claim instances) against a master record that holds every other attribute -- name, description, images, tags, category and option-group structure -- so a store cannot diverge on them. The architecture page states the same rule from the other side: 'The same item can have different prices and other possible store-wise varying attributes for different stores. However, the item ID should remain the same.' HONEST LIMIT: this is the data model as the POS-facing API exposes it, and the mechanism is structural (master-only fields have no per-store representation) rather than a per-user editing permission in Atlas; no Atlas article describes a store-level menu editor at all, and the roles article says 'The location-level access is not available in Atlas' outside the two Non-HQ reporting roles. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu · retrieved 2026-09-01

Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.

multi-location-price-zones

The location axis is met without duplicating the item record: Zomato, Swiggy and Keeta all carry "Location-Based Pricing -- Apply different prices for different locations", and Location Groups exist as a reusable object that taxes, charges and schedules are associated to. SHORTFALL on the claim's other two axes. Per-CHANNEL pricing is documented only in the connected POS (Foodics Price Tags, "different prices for the same product based on the delivery channel") or as fulfilment-mode pricing whose "support... varies by DSP", not as an Atlas price book. Per-DAYPART pricing does not exist at all: schedules govern whether a category is AVAILABLE at a time, never what it costs, and no article prices an item differently by time of day. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

Future-dated activation across a chosen set of locations is documented end to end: "Click on the Scheduled Publish button. Select locations and platforms in a similar way to a regular publish. Our internal validation checks for errors and warnings on the menu. Select the date and time. Clicking on Submit confirms the schedule for a later point of time", and a pending schedule can be withdrawn with Cancel Scheduled Publish. SHORTFALL on both of the claim's qualifiers. Timezone is never stated -- the operator picks one date and time for a publish that may span locations in different countries, and no article says whose clock it is read against. And there is no rollback after activation: the documented reverse action only exists while the publish is still pending. https://help.urbanpiper.com/business-manager/publishing-your-menu · retrieved 2026-08-31

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. Cloning exists and is a first-class step of the provisioning wizard: the ten-step 'How to Add a New Location' flow reads '4. Select Number of Locations: Choose the number of locations you want to create' and '8. Catalog Options: Choose to either copy the catalog from existing locations or skip to add it later', followed by brand association and DSP selection. Operating hours are then attached by associating an existing reusable Schedule rather than re-entering times (business-manager/setting-up-schedules-for-locations: 'Click on Associate Your First Location... Select the list of locations you want to associate with the schedule'). NAMED SHORTFALL, two limbs. (a) The cloned unit is the CATALOG only. The article names no copying of user roles, printer assignments or tenders; printers are bound per device in the Prime Web articles (connecting-a-printer, assigning-a-printer-for-kot-invoice) with no template, and Atlas roles are assigned by per-user email invitation (business-manager/user-access). (b) NO EXPECTED TIME-TO-OPEN IS PUBLISHED. Neither the 116-page help centre nor the 87-page API reference states a provisioning or go-live duration; the partner onboarding page instead routes go-live through a manual gate -- 'Data pushed will be verified by the Onboarding Manager post which outlet will be sent for mapping to the aggregator.' https://help.urbanpiper.com/business-manager/creating-a-new-location · retrieved 2026-09-01

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. An above-store/in-store split is documented and enumerated. Atlas ships ten named roles, two of which exist specifically to fence a location operator out of brand-wide data: 'Non-HQ Analytics: Provides access to analytics data, but strictly limited to specific locations. Users cannot download full business data or reports without a location filter, ensuring localized data security' and 'Non-HQ Report: Similar to Non-HQ Analytics, this role limits report access to designated locations only.' Prime ships six standard roles plus custom roles and 'You can also assign roles with limited access based on specific locations', while Admin has 'complete control over the platform, managing user accounts, system configurations, and all operational settings' -- so corporate can see every location's sales and hold the configuration while a location user sees only its own. NAMED SHORTFALL: this is a role filter within a SINGLE tenant, not the two-tenant model the claim asks for. The same article states 'The location-level access is not available in Atlas' outside those two reporting roles, so a franchisee cannot own its own catalogue or user administration; nothing documents separate franchisor and franchisee accounts, cross-tenant visibility, or franchisee-owned banking. Employees, banking and labor data are not objects in this product at all -- the 116-page help centre has no time clock, payroll or scheduling article -- so the 'franchisee owns its own employees, banking and labor data' limb cannot be satisfied here in any form. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-09-01

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

325th, CELL MOVED unknown -> no/B. BOUND: the complete Atlas back-office app (asset-manifest census of all 6 files, 1,585 first-party sources, 11.8 MB sourcesContent, nonsense-map control 404) plus 27 monthly product-update posts fetched entire (230,818 chars), on top of the 116 help pages and 87 API pages already on record. Tokenised case-insensitive 'royalt' returns ZERO hits in the app and ZERO in the blog corpus. CONTROL POISON, and it matters here: 'franchis' returns 14 hits in the app and every one is the field franchisee on UrbanPiper's OWN invoice to its customer (graphql invoice query franchisee{id gstin name addressLine1 ... postalCode}, rendered under 'Invoice To' in InvoiceDetail) - UrbanPiper billing a franchisee for its own subscription, not computing a franchisor's royalty. The app's Billing/Invoices module is the vendor's receivable, and the money-movement modules that do exist are Reconciliation (aggregator payout matching) and the Meraki prepaid wallet; neither carries a percentage-of-sales or fixed-fee accrual by location. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 adversarially verified

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

325th, CELL MOVED unknown -> no/B, same bound and the same poison as multi-location-royalty-calculation ('royalt' zero across the complete Atlas app and 27 product-update posts; all 14 'franchis' hits are the franchisee field on UrbanPiper's own outbound invoice). Positively, the only debit/credit machinery in the product runs the wrong way and to the wrong party: Invoices/BillingPortal/BillingRecovery/CreditSettings collect UrbanPiper's own subscription fees (paymentLink, paymentTransactions, dueDate, status, and a Zenskar/Zoho billing source), and Reconciliation matches aggregator payout sheets against orders. There is no franchisee ACH/debit mandate, no statement run and no arrears tracking against a store. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 adversarially verified

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

STRENGTHENED WITHIN THIS SESSION with the Data & Reports articles from page 1 of a paginated llms-full.txt, which replace a marketing-page inference with named reports. Above-store aggregation ships as purpose-built reports: "Items Summary Across All Locations Report... consolidating all the data from every location into one simple view" (Total Quantity, Total Amount, Total Taxes, Total Charges per item) and "Menu Snapshot Across All Locations Report... showing their pricing, availability, and categorization across every one of your restaurant locations", alongside an order-grain report filterable "by brand, location, or aggregator. You can also choose to select all locations." The role model corroborates the surface, with dedicated Sales Analytics and Operation Analytics roles and Non-HQ variants that exist to restrict the all-locations view. SHORTFALL: the claim's comparison features are still undocumented -- no store-versus-store ranking and no variance flagging appears in any report description -- and two of its named measures cannot exist here, since UrbanPiper has no labour module and no drawer, so labour and voids are not reportable at all. https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-08-31

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. The report exists and is named for exactly this: 'Unlike detailed transaction reports, this report gives you a high-level overview of your product performance, consolidating all the data from every location into one simple view.' Its key is the corporate item identifier -- 'Item ID: The unique code for this specific menu item within your system... This is your primary key for tracking the performance of each product' -- and the aggregated measures are 'Total Quantity: The total number of units of this item sold across all orders and all locations during the report period' plus Total Amount, Total Taxes and Total Charges, each described as 'aggregated from all your locations'. The aggregator's own per-platform code is carried alongside as a separate field ('Item ref ID: The unique code for the item as it exists on the online platform (like Swiggy or Zomato)'), so channel-side renaming does not fragment the rollup. The data model guarantees the shared key even where stores price differently: the API menu architecture states 'this item should be created at the master level in the POS system and must carry the same menu ID across all the stores... The same item can have different prices and other possible store-wise varying attributes for different stores. However, the item ID should remain the same', and gives brand-level reporting as the reason -- 'For a brand, it would be very easy to analyse the sales of the Margherita Pizza item since it is one item tagged to multiple stores.' https://help.urbanpiper.com/data-and-reports/items-summary-across-all-locations-report · retrieved 2026-09-01

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

CLAIM: gift cards issued at one location redeemable at any other location in the brand, WITH a reported outstanding-liability balance AND inter-store settlement/redemption reconciliation between owners. VERDICT: partial. EVIDENCE: the Gift Card entity is completely enumerated by the create form, the edit form and the list screen and it is COMPANY-scoped with no location field at all -- create/edit fields are Number, Amount, Expiry Date ("Leave empty if gift card does not expire") and Remarks; list columns are Number, Amount, Redeemed (links to the redeeming bill: bill_number + "Redeemed {amount}") or "Not Redeemed", Expiry, Created, Action; endpoints are GET/POST /api/v1/sales/gift-cards, /api/v1/sales/gift-cards/for-redemption, with a Bulk Import at /data/new-import/gift-card-import and permission p/c-gift-cards. Because nothing on the card or in the redemption lookup scopes it to a location, a card is redeemable at any location of the company -- the first conjunct. SHORTFALL: the card is single-redemption (redeemed_bill is one bill; once set the row is no longer editable), there is no outstanding-liability balance report anywhere in the 1,854-module app (`outstanding balance`, `liability` as a money concept, `cross-location` = 0), and there is no inter-store settlement or reconciliation between owners. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

REPLACES a seeded placeholder rationale that recorded no work, not absence. A per-customer loyalty balance exists and is held at brand level, not per location. The Meraki campaign placeholder table defines '{{user_points}}: Shows the customer's current loyalty points balance' and '{{user_wallet_balance}}: Displays the customer's current wallet balance', alongside {{user_name}}, {{user_phone}} and {{user_email}} -- one customer record with one balance, addressable from the brand-wide campaign tool. The Meraki storefront it belongs to is a single branded site and app for the business ('build and launch your own website and mobile app... under your own identity'), and the corresponding balances are offered as a checkout tender: 'Wallets or Loyalty Points (if configured)'. Order history is likewise consolidated rather than per-store: the Order Transactions Report carries Customer Name and Customer ID as fields on a report explicitly filterable across 'all locations'. NAMED SHORTFALL: no page states that a balance earned at one location is redeemable at another -- cross-location redemption is inferred from a single brand-level ledger, never asserted -- and the 116-page help centre contains NO loyalty-program configuration article at all, so accrual rules, tiers, expiry and the redemption mechanism are undocumented. The documented scope is the Meraki direct channel; nothing describes points accruing on aggregator (Zomato, Swiggy, Uber Eats) or in-store Prime orders, and the Partner with Us page files loyalty under third-party partners ('Marketing & Loyalty: Gupshup, and more'). https://help.urbanpiper.com/direct-ordering/manage-campaigns · retrieved 2026-09-01

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

Brands are first-class and separately managed: "Multi-Brand Support: Allows restaurants to manage each brand independently, making it ideal for groups with diverse brand offerings", supported by a "Consistency and Customization" statement about maintaining "a unified brand identity across platforms while enabling each brand to tailor operations", and a dedicated Creating a Brand article. Each brand carries its own menus, and orders are viewable across brands and platforms. SHORTFALL, and it is precisely what this claim asks beyond brand management: nothing documents TWO brands running on ONE location or one terminal. No article describes brand selection at the terminal, per-brand receipt branding, or a shared drawer with separately reportable per-brand revenue, and the virtual-brand case that makes this claim matter for a delivery aggregator is never addressed in the help centre. https://help.urbanpiper.com/business-manager/introduction · retrieved 2026-08-31

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

Per-location tax configuration with simultaneous rates and item-class rules is documented concretely. Rates are defined in Catalog > Taxes and scoped by association: "By default, all items and location groups are automatically associated with the taxes you create. If you need to limit taxes to specific items or locations", the operator builds an item group and a location group and links the pair to the rate, which is per-location tax and per-location exemption in one mechanism. Multiple simultaneous rates are native -- "For GST rates like 5%, 9%, 12%, or 18%, the platform will automatically divide the rate equally into SGST and CGST (e.g., 5% GST will become 2.5% SGST and 2.5% CGST)" -- and jurisdiction-specific product rules are handled by a tag: an item taxed above 5% "must be accompanied by a packaged goods tag", and the same tag flips a 5% rate from the aggregator's liability to the merchant's. SHORTFALL: every documented rule is India/GST-specific, no other jurisdiction is worked anywhere in the help centre, and the inclusive-versus-exclusive tax setting this claim names is never mentioned. https://help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-taxes · retrieved 2026-08-31

Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.

multi-location-multi-currency-locale

REPLACES a seeded placeholder rationale that recorded no work, not absence. THE LANGUAGE LIMB IS DOCUMENTED. The API reference publishes a supported-language list -- 'The list of supported language codes for certain entity fields: hi for Hindi, ar for Arabic, ja for Japanese, pt for Portuguese, fr for French, es for Spanish' -- and the entity schemas carry it: the Add/Update Stores payload includes a per-store 'translations' array of {language, name} objects, as do menu entities. The platform is operated across regions in one account model (the Meraki payment-gateway article maps gateways across India, MENA, KSA, UK, LATAM and USCAN columns, and gateways 'can be configured globally for all outlets, or per outlet if needed'). NAMED SHORTFALL, and it is the whole currency limb: the string 'currenc' appears NOWHERE in either complete corpus -- not in the store schema, not in the menu or item schema, not in the order payload, and not in any of the seven report articles. Prices are bare floats with no currency field, and no page describes a reporting currency, an FX rate, or consolidation of differently-denominated locations into one figure. So differing languages across locations are supported and differing currencies are simply not addressed by the published data model. https://api-docs.urbanpiper.com/downstream/api/references/supported-languages · retrieved 2026-09-01

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

A real audit log exists, is described as one, and names its fields: the Store Action Report is "your detailed report for every operational change made to your stores. Think of it as a security log that helps you audit actions", recording action_time ("the most critical field for auditing. It creates a historical timeline of all changes"), action_performed ("e.g., 'publish,' 'enable,' 'disable'"), platform, status ("e.g., ack_success"), the store and brand identifiers, and both application_src ("an API call, a user in the UI, or an internal system") and username plus user_first_last_name -- so who, what, when, where, how it was initiated, and whether it succeeded. It is exportable, since it is one of the Central Report exports. SHORTFALL is scope, and it is a large one against this claim: the objects covered are STORE STATUS and PUBLISH actions. Nothing documents an audit entry for a price change, a tax change, a permission change or a discount change, and no immutability property is stated anywhere. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/store-action-report · retrieved 2026-08-31

Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator

multi-location-enterprise-sso

324th, CELL MOVED unknown -> no/B. CLAIM: SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. VERDICT: no. EVIDENCE: the Atlas User Access help page is a complete account-lifecycle enumeration and it is username/password only -- invite by email address, 'An email invite will be sent to the employee's email address', then the invitee must 'Complete their profile', 'Validate their phone number with a one-time password', 'Pick a unique username and set a password', after which 'the employee can log in to Atlas using their new username and password'. The Roles tab is documented as two standard roles, 'Admin: Provides unfettered access across the entire Atlas portal' and 'Default: The role with the least access, allowing users to view catalogs and locations only' (custom roles exist but are 'exclusive to Prime'). Deprovisioning has its own page -- 'How to archive, delete or restore Atlas or Prime user' -- and is a manual admin action, with sibling pages for password reset and store-operations PIN reset. CONTROLS: SSO = 0/0, 'single sign-on' = 0/0, SAML = 0/0, OIDC = 0/0, OAuth = 0/0, LDAP = 0/0, SCIM = 0/0, 'identity provider' = 0/0, provisioning = 0/0, deprovision = 0/0. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. https://help.urbanpiper.com/business-manager/user-access · retrieved 2026-09-17 adversarially verified

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. Scored on the claim's second limb (data warehouse/BI export), which is met. From the Data & Reports getting-started article: reports live in one place -- 'Navigate to the All Apps section and select Central Report. You will see a list of all available reports, including order transactions, item-wise transactions, item summaries' -- and the scope is explicitly cross-location and cross-brand: 'Apply filters to sort by brand, location, or aggregator. You can also choose to select all locations.' The grain is transaction level: the Order Transactions Report article states 'Each row in this report represents a single order' and documents its fields, including Order ref ID, Channel, Created At, Order State, Payment Mode, Payment Transaction ID, gross and net amounts, taxes, charges, Customer ID, Store ID and Store ref ID. Delivery is machine-readable and unattended -- 'You can download the report in either CSV or XLSX formats', a mailed 'secure link to download the generated report', and 'a recurring schedule to automatically receive your most important reports' defaulting to 8 a.m. for the previous day. All of it is reached with the single Atlas account the operator already holds; nothing in the flow asks for per-location credentials. HONEST LIMIT ON THE OTHER LIMB: the claim's API alternative is NOT satisfied -- the 87-page partner API reference (api-docs.urbanpiper.com, manifest-complete) publishes no reporting, export or bulk-extract endpoint, and scheduling is fixed at 8 a.m. ('At this time, custom delivery times are not available'). https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

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

CLAIM: labor rules (overtime, break enforcement, predictive-scheduling compliance) configurable per location or location group and enforced at the terminal. VERDICT: no. EVIDENCE: Prime does have real per-location and location-group configuration -- location overrides, /api/v1/locations/floors, per-location catalogue, per-location price and availability overrides, per-location permission scoping -- so the absence is specifically of labour policy, not of the multi-location machinery. There is no overtime, break or scheduling rule anywhere to scope. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 adversarially verified

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

extensibility-public-api-docs

WAS `unknown` at grade F, on the rationale that 'no publicly readable API reference was reachable without a partner flow'. That is falsified by a host THIS RECORD ALREADY CITES AT GRADE A. api-docs.urbanpiper.com serves a complete GitBook API reference to an anonymous client: its robots.txt (served from /downstream/robots.txt) is 211 bytes reading allow: / with three GitBook asset allows and no disallow at all, and the whole reference is retrievable in one request as llms-full.txt at 778,699 bytes. No login, agreement or sales contact intervenes. The landing page states the scope plainly: "The UrbanPiper API is organized around REST", followed by a table of contents covering Overview, Getting Started, Authentication, Manage Stores, Managing Menu, Receive/Manage Orders, Availability, Testing and Validation, Certification and Resources. COMPLETENESS WAS MEASURED, NOT ASSUMED, using the 179th's falsifier: the llms.txt manifest lists 86 entries and 0 are unmatched against the dump's 229 headings, and the dump carries no Next Page marker. The same instrument reproduces the 179th's help-centre result (115 entries, 14 unmatched against page 0, 0 against both pages), so the zero is from an instrument shown to produce a non-zero. https://api-docs.urbanpiper.com/downstream/readme.md · retrieved 2026-08-31

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

extensibility-api-access-cost

325th, CELL MOVED unknown -> partial/B, on the Atlas app's own module-gating table (census on menu-pricing-upsell-prompts). EVIDENCE: 'API Access' is a top-level Atlas nav item (path /api-access, containers/APIAccounts.js, APIAccountCreate, APITypeSelectorDrawer, plus Webhooks and Developer Tools) and its render predicate is access?.isAdmin alone - no isLocked, no biz.modulesEnabled check, no subscription-status check. In the same config the vendor's paid layers are all gated explicitly (isLocked:!biz.modulesEnabled.includes('Meraki'); isLocked:!biz.isOrderlineEnabled; isLocked:!isOrderdeskEnabled; merakiWebSubscription.subscription.status in [null,'cancelled','not-subscribed']). Archiving an API access is warned as 'Archiving API access can disrupt integrations', i.e. it is a self-service credential, not a provisioned SKU. SHORTFALL (why partial, not yes): this is the vendor's UI, not its price list - no published document states that API access carries no fee. The nearest published statement remains www.urbanpiper.com/uk/free-trial ('Plans from GBP 79', 'No one-time set-up fee', 'Unlimited orders; No per order charges', 'No additional costs') which never names API access, and Hub pricing is explicitly quoted per location and per brand. Retrieved 2026-09-17. https://atlas.urbanpiper.com/static/js/main.2199edb3.js.map · retrieved 2026-09-17 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

The vendor does publish the STRUCTURE of its partner commercial terms, on its partner landing page rather than in its documentation: 'Flat fee. No nasty surprises. No hidden charges. No percentage cut from your client's orders. No bill that unexpectedly escalates as they grow. One clear fee, what you see is what you pay.' The same page describes the commercial track as 'referral / reseller programs, and strategic partnerships along with co-marketing' and lists what a live partner receives ('A listing on the UrbanPiper integrations hub, a named partner manager, joint announcement support, access to co-marketing assets, and warm intros into the restaurant brands where your product is the best fit'). SHORTFALL: no figure of any kind is published -- no referral fee amount, no revenue share percentage and no per-location partner fee. The page states only that the fee is flat and is not a cut of order value, and routes the rest to a sales conversation ('Drop us a note at partnerships@urbanpiper.com or fill the form on this page'). The documentation hosts carry none of it: across help.urbanpiper.com (116 pages) and api-docs.urbanpiper.com (87 pages), both verified complete against their llms.txt manifests by link-crawling the retrieved page bodies on 2026-09-01, 'revenue share', 'referral' and 'rev share' return zero hits, and the POS-partner track (onboarding-process, testing-and-validation, certification) states engineering obligations and a certification gate with no commercial figure. developers.urbanpiper.com is Clerk-gated and was not read. https://www.urbanpiper.com/partner-with-us · retrieved 2026-09-01

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

extensibility-free-sandbox

A real test environment exists with seeded data and tooling: "The Sandbox is a package that would consist of everything you would need to start the integration, build it, test it and complete the same", comprising "the credentials to access Atlas, the auth details (more on this later) and the sample postman collection", against a published staging host and Atlas portal, and Atlas itself lets the integrator "mock the test orders with the populated menu". A companion Developer Tools feature simulates orders across ten named aggregators in four regions. SHORTFALL is the claim's operative word, self-serve availability: the sandbox is provisioned by hand -- "You would be receiving the details related to sandbox over an email" -- and the companion environments page (getting-started/environments.md) gates access to the staging environment on the partnership agreement being in place. No developer can obtain it without contacting the vendor. https://api-docs.urbanpiper.com/downstream/getting-started/environments/sandbox.md · retrieved 2026-08-31

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

The partner API reference states the mechanism outright: 'We use a static token-based authentication for all the requests made to our system via API calls.' One token per business entity, constant over time; rotation is manual — a suspected compromise means emailing pos.support@urbanpiper.com for a new token. This is exactly the shared static credential model the claim excludes: no OAuth 2.0, no scopes, no operator-granted consent, no self-serve revocation. The downstream POS-partner API is the only published third-party integration surface. https://api-docs.urbanpiper.com/downstream/authentication/authentication.md · retrieved 2026-08-04

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

extensibility-webhooks-push

WAS `unknown` at grade F ('UrbanPiper publishes no webhook documentation'). It publishes a great deal. The callbacks page states the model -- "Our platform relies on a system of webhooks" to "Notify an external system when a particular *event* occurs", and "The webhooks get triggered as soon as the event happens" -- and then enumerates ten named endpoints the integrator supplies, including "**Order Relay** - triggered as soon as an order is placed on our system", "**Order Status Update** - triggered as soon as the status of an order changes on our system" and "**Rider Status Update** - triggered as soon as the status of rider for an order changes on our system", alongside processing callbacks for store, menu, category-timing, item and option actions. Push, not polling, is unambiguous. PARTIAL against this claim's own enumeration: order creation and every status transition (including cancellation) are covered, but there is no payment, void or refund event -- money movement happens on the aggregator, and no webhook in the list corresponds to it. https://api-docs.urbanpiper.com/downstream/getting-started/webhooks-callbacks.md · retrieved 2026-08-31

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

This claim is an AND of signing and retry, and the two halves land on opposite sides. Retry and replay are documented thoroughly: "we have a retry logic (3 attempts) in place"; a Webhook Circuit Breaker trips when "a 3rd party system URL throws more than 15 request failures within a minute for particular biz", with a cool-off scaled to recent history -- "If there have been >= 5 incidents in the past week, all webhooks will be disabled for 3 mins. If the number of incidents is less than 5, then the webhooks will be disabled for 1 min" -- and missed deliveries are replayed: "For the orders which were not relayed in the timeframe of webhook deactivation, our system tries to push them at once when the webhooks are re-enabled." A separate Webhook Order Retry API lets the POS partner re-request an Order Relay. SHORTFALL is the signing limb, and it is a positive exclusion rather than silence: the companion callbacks page (getting-started/webhooks-callbacks.md) states that beyond a static token no other mode of authorization is supported for configuration on the vendor side, and HMAC and signature occur zero times across the whole reference. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker.md · retrieved 2026-08-31

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. WHAT IS SATISFIED: orders originating outside the operator's own system are handled as first-class tickets. The integration overview describes the whole product this way -- aggregators are 'upstream', the POS is 'downstream', and Order Relay means 'Receive orders from aggregators directly to the POS through the webhook endpoint configured in UrbanPiper', with order-status and rider-status updates flowing back. Those orders print: Prime's auto-print settings fire the bill and the KOT by order status, kitchen-station KOT routing exists (store-manager/prime-web/print-kot-for-kitchen-stations), and they land in reporting as rows of the Order Transactions Report with Channel and Order ref ID fields. NAMED SHORTFALL: the direction is outbound, not inbound. The API reference is the POS-partner surface -- 'This document lists the API endpoints that can be consumed by a merchant's backend system like a PoS or ERP system' -- and its complete endpoint set (add/update stores, store toggle, add/update menu, menu toggle, category timing groups, order STATUS update, rider status update, webhook order retry, self-delivery rider management, aggregator feature actions, mark order item stock out, customer complaints) contains NO create-order call. The documented scope is stated as closed on that page -- 'order relay and status update, menu management, item and store availability control mark the scope of the integration' -- so a third-party ordering front end cannot inject a ticket except by becoming one of UrbanPiper's integrated channels. Not scored `no` because the same reference disclaims its own completeness: 'We try our best to keep this doc in sync with our development pace, but at times a gap creeps in.' https://api-docs.urbanpiper.com/downstream/getting-started/overview · retrieved 2026-09-01

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

extensibility-menu-write-api

The Add/Update Menu endpoint writes the whole catalogue, not a subset, and the same endpoint serves both operations: "Since the same endpoint can be used for both adding and updating menu objects, the required set of attributes differ based on the context of the request. For *create* events, along with the required set of parameters, you have to send all the relevant parameters in the request payload. For *update* events, along with the required set of parameters, you can pass only the updated information-carrying parameters in the request payload." The documented object set is Categories, Items, Option Groups, Options, Taxes and Charges, written at master level or per location, with prices carried on items and options and destructive resets available through documented flush and clear flags. Items, modifiers and prices are all writable, which is the whole of this claim. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-31

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. Read against the complete 87-page reference (manifest-verified 87/87 on 2026-09-01). Symmetry holds for exactly one object and fails for the rest. ORDERS: readable, as a webhook delivery, and partially writable -- order-status-update and rider-status-update exist, and webhook-order-retry-api re-delivers a missed order -- but there is no create-order endpoint, so the read is richer than the write. MENU AND STORES: writable only. add-update-menu and add-update-stores push the full payload, menu-toggle and store-toggle flip availability, and category-timing-groups sets schedules -- but no GET returns a menu, an item, a store or a timing group. The onboarding page confirms the round trip is a UI one rather than an API one: 'Push the Stores, add the platform details for each store and Menu data using the API or configure the same through Atlas manually. Verify the data using the callbacks or through Atlas.' CUSTOMERS, EMPLOYEES AND INVENTORY: not objects in this API in either direction -- the only customer-shaped endpoint is customer-complaints, item stock is a per-item toggle (mark-order-item-stock-out, availability/item-option) rather than an inventory resource, and there is no employee entity. NAMED SHORTFALL: the claim's universal fails because the API is a one-way push surface for configuration and a one-way receive surface for orders, with the reconciliation read left to the Atlas UI and the Central Report exports. Held at partial rather than `no` because api/readme disclaims completeness -- 'We try our best to keep this doc in sync with our development pace, but at times a gap creeps in' -- so its endpoint list is not a closed enumeration. https://api-docs.urbanpiper.com/downstream/api/readme · retrieved 2026-09-01

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

extensibility-published-rate-limits

Numeric quotas are published per endpoint, under a "**Constraints & Expectations**" heading on each. This one reads "A *throttle limit* is applicable on this endpoint limiting the maximum of **1 request&#x20;*****per*****&#x20;5 secs**. If you breach this threshold, the platform will respond with a `429` error response code and you will not be able to make new requests for a duration of **5 seconds**." The pattern repeats across the reference with per-endpoint figures ranging from 2 requests/hour to 150 requests/min, one of them split by time of day, each naming its own 429 and its own cool-off window. PARTIAL on the claim's last word: no rate-limit response headers are documented anywhere -- Retry-After, X-RateLimit and RateLimit-Remaining occur zero times in the 778,699-byte reference -- so a client must hard-code the quota rather than read its remaining budget from a response. https://api-docs.urbanpiper.com/downstream/api/endpoints/menu/add-update-menu.md · retrieved 2026-08-31

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 count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means 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 `urbanpiper_production`, rendered 'UrbanPiper', with qualityStatus PREFERRED and 8 of the 8 high-quality features built. 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

UrbanPiper operates its own marketplace integrations rather than reselling someone else's -- each has a per-platform authorisation flow, a feature matrix and a stated 48-hour activation timeline -- and it is itself the aggregation layer this claim contrasts against, so the no-paid-middleware condition is met in the only way it can be for this record. SHORTFALL is the claim's named list: Uber Eats is fully documented (getting started, menu update and publish, menu timings, prep time), but of the other two, DoorDash and Grubhub appear exactly once between them, in a single line of Business Manager prose -- "organize menus across various online food delivery platforms such as DoorDash, Grubhub, and Uber Eats" -- with no integration article, no supported-feature table and no authorisation flow. The documented depth sits instead on Zomato, Swiggy and Keeta, which the claim does not name. Not `no`: a named US marketplace with no help-centre article is an undocumented integration, not an absent one. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

extensibility-middleware-compatibility

328th: THE 327th NOTE SAID THIS CELL 'turns on whether THIRD PARTIES list Prime as a supported POS, which their own directories would have to establish; the vendor's own corpus cannot bound that'. Those directories were fetched today and none of them lists UrbanPiper. (1) DELIVERECT, bounded by the publisher's own sitemap: www.deliverect.com/sitemap.xml (130,134 bytes) enumerates 617 distinct https://www.deliverect.com/en/integrations/<partner> pages - Deliverect's complete integration directory, not a filtered view. Tokenised case-insensitive over the whole sitemap: 'urbanpiper' 0 and 'urban-piper' 0, with no integrations slug matching /piper|prime/. POSITIVE CONTROLS PASS, and one of them is decisive against a geography excuse: toast 27, lightspeed 46, square 23, clover 12, revel 7 and POSIST 4 - posist is an Indian POS in UrbanPiper's home market, so Deliverect does carry this region and simply does not carry Prime. (2) ITSACHECKMATE: www.itsacheckmate.com/integrations (34,406 bytes, HTTP 200) scores urbanpiper 0 against positive controls toast 4, square 8, clover 4, revel 4. (3) OTTER: www.tryotter.com/integrations (540,809 bytes, HTTP 200) scores urbanpiper 0 against positive controls toast, square, clover, revel and lightspeed all present. (4) CHOWLY cannot be measured and is not counted either way: the company rebuilt onto chowly.com (chowlyinc.com 301s to it) and its sitemap.xml publishes no POS integration directory at all - the whole site is /solutions/, /agents/ and /resources/blogs/. So of the five platforms this claim names, three publish directories and zero of the three list UrbanPiper Prime, one publishes no directory, and a fourth (Checkmate/ItsaCheckmate) is the same company. The claim requires at least TWO supporting platforms; the count is zero. This is consistent with the vendor-side measurement already recorded - deliverect 0, chowly 0, otter 0, checkmate 0, itsacheckmate 0 across the complete store-level Prime app (main.js 4,860,546 B + vendors.js 12,194,965 B, no lazy-chunk loader) and the 240 KB help.urbanpiper.com llms-full corpus - and with the structural reason: UrbanPiper IS the aggregation middleware layer (its own Hub relays Zomato, Swiggy, Talabat, Careem, Uber Eats, DoorDash, Deliveroo), so competing middleware has no commercial reason to certify it. GRADE D and stated honestly: the evidence is three third parties' own marketing directories, which is the correct source type for a claim about what third parties support, but it is not vendor documentation; a private/unlisted certification would not appear. Retrieved 2026-09-18. https://www.deliverect.com/sitemap.xml · retrieved 2026-09-18 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

The September 2023 product-update post (vendor blog, grade C) documents a Tally accounting feature on UrbanPiper's own Prime dashboard, not a third-party connector: 'We’ve introduced two new exciting updates to help speed up your accounting activities using the Tally feature, available on your Prime dashboard!'; under the bolded heading Group Data Within a Transaction, 'With this new feature, you can easily combine many bills into one voucher for any time period you want.'; 'To use this feature, just go to Tally Integrations on Prime, choose ‘Export Data tab’ and turn on ‘Data Aggregation’.'; and 'Now you can export comprehensive ‘Receipts Data’ along with ‘Sales Data’ on Prime'. So one non-QuickBooks accounting system (Tally) has a first-party Prime feature that aggregates bills into Tally vouchers. SHORTFALLS: (1) no QuickBooks Online connector is evidenced -- QuickBooks, Xero and Zoho Books are 0 across the 141 retired-KB and 239 www docs and across help.urbanpiper.com and api-docs.urbanpiper.com; Tally itself is 0 in the retired KB, help centre and API reference, and this post is its only accounting mention on www (every other www 'Tally' hit is the tally.so form-embed script in the page template, a homonym); (2) the feature is driven from an Export Data tab, so whether it posts to Tally directly or produces an import file is not established -- the claim's mapped-entries-not-CSV-only condition is only partly met; (3) Prime POS only (India-market product), not Hub/Atlas; (4) evidence is a grade-C blog post dated 2023-09-07, not a help article. Quotes checked as exact substrings of the raw HTML (comments stripped). changelog.urbanpiper.com is robots-barred and was not read. https://www.urbanpiper.com/blog/september-2023-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-12

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

extensibility-payroll-export

CLAIM: labor hours export natively to at least two named payroll providers. VERDICT: no. EVIDENCE: the complete integration set in Prime main.js is QuickBooks Online, Tally, external payment terminals (incl. Pine Labs) and the UrbanPiper catalogue-publish channel; there is no payroll destination and no labour hour to send. The QuickBooks Online config screen's mapping tables are Payment Method -> QBOnline Payment Account and Payment Method -> QBOnline Payment Method, i.e. sales settlement, not payroll. `Gusto`, `ADP`, `Paychex`, `Paylocity` = 0 across every corpus. BOUND: Prime has NO labour module of any kind. Its 300-endpoint API enumeration contains no time, attendance, shift, schedule, break or payroll endpoint; the only employee endpoints are /api/v1/employees, /api/v1/employees/location/ and /api/v1/commissions/employee/. The Employee record's field list is complete in the detail screen and is Name, Created, Updated and an enabled-locations toggle -- nothing else. The app's own route table (/company-admin/employees, /company-admin/sales-commission, /company-admin/permission-levels, /company-admin/users, /company-admin/roles) has no labour route. Employees exist in Prime only as (a) a sales-commission payee and (b) a name printed on a receipt ("Cashier:", "Server: {{server}}"). This is a full POS that ships the module not at all, which the merge policy scores `no` once the product's own app is censused -- and it is, above. PRIME CENSUS (new surface, 326th). prime.urbanpiper.com IS the store-level UrbanPiper Prime POS web app: <title>Prime</title>, /manifest.json short_name "Prime", webpack runtime global self.webpackChunkprime_web. It ships exactly TWO scripts -- /vendors.a82de318208444ce3a4e.js (12,194,965 B) and /main.877fb1f9292d7b25014a.js (4,860,546 B). The runtime defines r.e=function(){return Promise.resolve()} and contains NO r.u, no chunkFilename and no chunk-hash table, so there are no lazy chunks: those two files ARE the whole app (1,854 app modules in main, 2,930 vendor modules). Source maps are not published -- main.877fb1f9292d7b25014a.js.map returns 404/548 B byte-identical to the nonsense control main.877fb1f9292d7b25014a.js.NONSENSE.map, so the 404 is real and not a soft-200 shell. From main.js I extracted 21,343 string literals and 569 app paths, of which 300 are /api/v1../v3 endpoints -- a complete client-side enumeration of Prime's own REST surface, which the Android build (com.urbanpiper.satellite_prime, Play listing title "Prime - by UrbanPiper", description "Prime is an online-first POS...") and satellite terminals share (/auth/satellite-login, /api/v1/users/satellite/login). This is the census the 325th holds asked for: it bounds the STORE-LEVEL product, not the Atlas back office. Grade B (production JS, not published documentation). CORPORA (all re-derived 2026-09-18): Prime main.js 4,860,546 B + Prime vendors.js 12,194,965 B (complete app, above); the q325 Atlas source-map corpus 11,389,794 B over 5,354 sources (back office AND the campaign/marketing module -- CreateCampaign, CampaignList, TemplateEditor, graphql/segments); help.urbanpiper.com llms-full.txt 237,767 B / 425 headings; changelog.urbanpiper.com paginated to exhaustion through its ?after= cursors (3 pages, 29 posts, 46,017 B) -- its robots.txt bars a generic User-agent: * and does NOT name ClaudeBot, so it was read like a browser under the standing order. urbanpiper.helpjuice.com IS DEAD: every one of the 210 URLs in its still-served sitemap.xml returns the Helpjuice "Account Canceled" shell (~2.5 KB, identical bytes for all 210), so the old KB is not a corpus at all and the current KB is help.urbanpiper.com. POISON FOUND AND TOKENISED AWAY: in Prime main.js `W-4` scores 402 and `W-2` 17 -- every one is the Tailwind width class w-4 / w-2; `shift` 18 is the keyboard "Shift" in the shortcut table plus Array.prototype.shift; `break` 132 is the JS break statement and Tailwind break-words; `punch` is UrbanPiper's Indian-POS sense of keying a bill ("Punch a bill", "order punching", "punch in-store orders"), never a time punch; `unsubscribe` 16 is pub/sub teardown. In the Atlas corpus `DND` is 6/6 react-dnd drag-and-drop, `opt-in`/`opt out` are source-code comments about feature flags, `churn` 81 is UrbanPiper's OWN subscription churn (BIZ_CHURN_CANCEL_SUBSCRIPTION_USER_EMAILS), and `scorecard` 33 is the AI call-insights "judge" kind ("Weighted quality evaluation with scored steps"), not a server scorecard. ZERO, tokenised / word-boundary / case-insensitive, across ALL of the corpora above: clock in, clock-in, clockin, clock out, time clock, timeclock, timesheet, timecard, attendance, roster, overtime, geofence, geo-fence, labor, payroll, wage, Gusto, ADP, Paychex, Paylocity, workweek, predictive scheduling, predictability pay, I-9, W-4 (after de-poisoning), E-Verify, open shift, tip pool, tip-out, tipout, tip share, gratuity, hours worked, staffing, forecast, sales per labor hour, SPLH, rest break, meal break, minor (app code). Denominator for the Prime leg: 4,860,546 B / 1,854 modules / 21,343 literals / 300 API endpoints. Retrieved 2026-09-18. https://prime.urbanpiper.com/main.877fb1f9292d7b25014a.js · retrieved 2026-09-18 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

Scheduled, recurring, transaction-level export exists and its destination is an inbox. The operator schedules any Central Report, filters it "for brands, locations, platforms, or Meraki channels", picks a format, and thereafter "receive[s] your scheduled order transaction report in your email every day at 8 a.m."; a one-off route emails "a secure link to download the generated report", and manual export is CSV or XLSX. The grain is genuinely raw -- one row per order with identifiers, financial breakdown, payment mode and transaction ID, and companion reports at item and option grain. SHORTFALL is the claim's operative requirement, a CUSTOMER-CONTROLLED destination: no S3, SFTP, bucket, warehouse or Snowflake share is documented anywhere, and the recurring pipe terminates in email. NOT scored `no`: this article documents the Central Report UI and not the vendor's API surface, so it cannot establish that no programmatic route exists -- api-docs.urbanpiper.com was not re-read in this pass and reporting-raw-warehouse-export is deliberately left unresolved for that reason. Found on PAGE 1 of a PAGINATED llms-full.txt: the 231,780-byte page every prior pass read ends with a Next Page link to /llms-full.txt/1, which carries a further 50,864 bytes -- the seven Data & Reports articles and the eight Meraki direct-ordering articles. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

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

extensibility-app-marketplace

A public, categorised list of named integration partners is published in the help centre -- Online Aggregators ("Zomato, Swiggy, Uber Eats, and more"), POS Systems ("Foodics, oodo, Ginesys, RanceLab, and more"), Logistics Partners ("Dunzo, Shadowfax, and others"), Payment Gateways ("Razorpay, PayU, and others") and Marketing & Loyalty ("Gupshup, and more") -- so the browsable-listing half of the claim is met, and the help centre carries full integration guides for four of the named marketplaces plus Foodics, Lightspeed K-Series and TouchBistro. SHORTFALL, and the documentation is unambiguous about it: nothing is self-install. Turning on a marketplace requires a Go-Live Request through Platform Settings with vendor verification and an activation window ("typically takes up to 48 hours to go live", weekdays only), and enabling the Scan and Pack module needs a support ticket -- "Scan and Pack needs to be activated by the UrbanPiper team before it's available in your account." The list is also a partner page written to sell, closing with Book a demo, rather than a catalogue with per-app detail pages. https://help.urbanpiper.com/basics/partner-with-us · retrieved 2026-08-31

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

extensibility-custom-fields-scripting

UrbanPiper's Atlas console gives users with the Catalogue Management role a 'Custom Fields' tab on items and modifiers. There they can 'Add Field Group', set a 'Group Title', and add free Name/Value pairs ('Add another field'), saved through updateItemCustomFields / updateModifierCustomFields (keyValuesToInsert/Edit/Delete). Bulk Operations also offers 'Item Custom Fields' and 'Modifiers Custom Fields' CSV tabs, described as 'A reference ID for the custom field. This can be an identifier for the item in your ERP/PoS system'. Shortfalls: custom fields exist only on catalogue items and modifiers, with none found for orders, customers, employees or locations. No scripting, rule engine or custom-logic surface was found; outbound webhooks only deliver events. Source: UrbanPiper's Atlas merchant console production bundle (public source map), read 2026-09-14. https://web.archive.org/web/20260730213022/https://atlas.urbanpiper.com/static/js/main.11fd3553.js · retrieved 2026-09-14 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

CLAIM: a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API. VERDICT: partial. NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. THIS ANSWERS THE 330th HOLD, which said inbound channel integrations 'reach UrbanPiper through an ordering-channel API that this portal does not document'. That API is now located and its contract is public: order-edge.svc.urbanpiper.com, PRODUCTION, 13 operations, including 'POST /order/v1/generic/{platform} | Place Order' (description: 'This endpoint is used by generic platforms to place orders.') and 'POST /order/status/v1/generic/{platform} | Update Order Status', both HTTPBearer, beside platform-specific place-order routes (doordash incl. /adjustment 'Place Modified Order', chefz, grubhub, keeta). Its staging twin (order-edge.staging.svc-hz.urbanpiper.com/openapi.json, 30,924 B, 27 operations) carries the full order model the production copy strips, incl. a 'Documentation' route /doc/payloads/core-order/ ('Endpoint to document core order payload'): Order = {meta, payment, customer, items, discounts, platform_attributes, order_processors}; Meta.status enum OrderStatus = placed | modified; FulfillmentMode = partner_delivery | merchant_delivery | pickup | dinein; PaymentMode = cash | prepaid | payment_gateway | paytm | aggregator | simpl | paypal | card_on_delivery; and OrderProcessorType = FLATTEN_OPTIONS, ADD_MIN_ORDER_DELIVERY_TIME, ADD_ITEM_WEIGHT, LINK_OPTION_TO_OPTION_GROUP, BACKCOMPUTE_TAXES, REPLACE_WITH_MENU_PRICES - i.e. the platform can re-price an injected order from its own menu and back-compute tax. So a third-party ordering front end (any 'generic platform', dine-in included) can create and modify orders in UrbanPiper's stack through a bearer-authenticated API, and those orders are relayed downstream like any aggregator order. WHY PARTIAL, NOT YES: it is ORDER INJECTION (place / modify / status), not a transaction engine a guest UI drives step by step - there is no open-check, add-line, apply-discount or tender operation, and the caller supplies totals and taxes; access is a selective partnership per the developer hub ('These integration APIs are not open-access'); and it is a single unlinked service spec (production contract read, grade B, no call made). The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). Retrieved 2026-09-18. https://order-edge.svc.urbanpiper.com/openapi.json · retrieved 2026-09-18 adversarially verified

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

extensibility-api-versioning-deprecation

An absence measured against a documentation set proven complete, which is what licenses a `no` on a claim about what a vendor PUBLISHES. The public API reference is retrievable whole as llms-full.txt (778,699 bytes), and its completeness was verified rather than assumed: the llms.txt manifest lists 86 entries, 0 of them unmatched against the dump's 229 headings, and the dump carries no pagination marker -- the instrument reproducing the 179th's known-positive case (14 unmatched on page 0 of the help centre) on the same run. Across that whole reference the strings changelog, deprecat and versioning occur ZERO times, and no endpoint carries a version-negotiation header or a sunset policy. SCOPE OF THE FINDING, stated because it bounds it: this is the POS-partner programme's documentation, the only API documentation UrbanPiper publishes; a changelog held privately for certified partners would not appear here and is not excluded by this evidence. https://api-docs.urbanpiper.com/downstream/llms-full.txt · retrieved 2026-08-31

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

REPLACES a seeded placeholder rationale that recorded no work, not absence. WHAT EXISTS: a documented, machine-readable, operator-driven export. Central Report offers order transactions, item-wise transactions, item summaries, option-wise transactions, menu snapshot across all locations and store actions; 'You can download the report in either CSV or XLSX formats', with an emailed secure link and a daily schedule as alternatives, filterable across all brands and locations (data-and-reports/getting-started). The coverage is broad: the Order Transactions Report's documented fields include Customer Name and Customer ID, Payment Mode and Payment Transaction ID, order state, timing, amounts, taxes and charges, and the Menu Snapshot Across All Locations report covers the catalogue -- so orders, customers, menu and payments metadata are all reachable. NAMED SHORTFALL, and it is the 'at contract end' limb, refuted in the vendor's own words: the cancellation article's Before-you-begin warning reads 'Download any reports or data you need from UrbanPiper before your subscription ends, as your data will be permanently removed after cancellation', and the aftermath section states 'A week after the cancellation date, you won't be able to access your portal any longer.' There is therefore no on-demand export AT or AFTER contract end -- the operator must self-serve in advance, inside the retention window, and no bulk archive, escrow or extract-on-request process is offered. The API route is closed too: the 87-page partner reference publishes no export or bulk-extract endpoint. https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-09-01

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

reliability-offline-order-entry

UrbanPiper's Prime POS web-app production bundle (main.5e41e891716be92f2e7b.js, read 2026-09-14) states 'We store register and bills locally on your browser to support offline mode.', and its offline screen reads 'It appears you are offline.' ... 'You can still use the register <name> to sell.' with an 'Open POS' link. Bills made offline queue for sync ('The bill will automatically sync once you have active internet connection', 'Retry to Sync Bill'), and KOTs are created locally with a pending sync status. Order entry offline is met. Printing goes through a local 'Qz-Tray' printer plugin, but nothing states that check printing works offline. Kitchen ticket routing is not shown to work offline: KDS reads KOTs from server endpoints. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

reliability-offline-card-auth

UrbanPiper never holds card data, so there is nothing to store and forward. The privacy policy (last updated 11 Aug 2026) states the position affirmatively: 'Where payments are processed in connection with the Services, card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki.' The customer terms say the same from the other side -- 'We do not store, retain or process Your credit card or other payment information' (cl. 1.1, www.urbanpiper.com/legal/customer-terms-and-conditions). The only documented card path is an online gateway the operator brings themselves (Atlas > Meraki > Payments > Add Gateway, twelve gateways across six regions), which authorises against that gateway in real time; there is no card-present entry surface, no terminal-side vault and no offline authorisation mode anywhere in the 116-page help centre or the 87-page POS-partner API reference. Store-and-forward requires the vendor to retain a card credential it says it does not retain. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

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

Both limbs fail on a fully read document set. There is no store-and-forward capability to allocate loss for (see reliability-offline-card-auth: the privacy policy states UrbanPiper stores no card numbers and no payment identifiers), and the published Merchant Agreement -- which cl. 16.9 declares 'the entire agreement' together with the Order Form -- contains no offline transaction cap, no per-transaction or cumulative offline limit, and no allocation of chargeback or decline loss. Its Charges and Payment clause 7 covers fees, late-payment interest at 1.5% per month, reactivation fees and non-refundability, and its Limitation of Liability clause 14.1 caps all liability at 'ONE (1) MONTH OF THE FEES PAID BY YOU' without mentioning transaction risk at all. Clause 2.4 pushes payment-dispute risk to the merchant in general terms: 'You are solely responsible for resolving disputes or grievances by the Customer and We shall have no liability or obligation for any claim arising from such payment records.' Nothing on either documentation host addresses offline declines. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

Prime POS registers share bills only through UrbanPiper's cloud services. They load and push bills through /api/v1/dr3/bills, transfer them with a cloud call (`/api/v1/dr3/bills/<id>/owner`, logged as 'Remote bill claimed'), and get live commands over a hosted websocket (centrifugo.svc.urbanpiper.com). When offline, each register keeps its own copy: 'We store register and bills locally on your browser to support offline mode.' The full production client has no local-network, peer-to-peer or local-server transport. The only localhost connection goes to the QZ Tray print helper. With the internet down, each terminal is an island rather than part of a shared LAN. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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 vendor documents the opposite architecture in two places. The DPA's Schedule B (Technical and Organisational Measures, the SCC annex whose explanatory note requires measures to be described 'in specific (and not generic) terms') opens 'UrbanPiper's production environment is hosted on Amazon Web Services' and describes only cloud infrastructure -- multiple fault-independent availability zones, orchestration tooling that can 'regenerate hosts, building them from the latest backup'. On the merchant side the help centre states there is nothing to install: 'Prime Web is accessible directly through the Atlas management console... No additional installation is needed -- it runs entirely in your browser' (help.urbanpiper.com/store-manager/prime-web). Across 116 help pages and 87 API-reference pages there is no on-premise connector, edge server, local database or installable service; the only local software documented is QZ Tray, a browser print bridge, and the only local device that holds a queue is an Epson printer that polls UrbanPiper's cloud. POS integration is cloud-to-cloud HTTP -- webhooks plus REST endpoints -- which is precisely the request/response path the claim excludes. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-01

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

reliability-offline-kds-printing

Prime POS numbers and prints kitchen tickets (KOTs) on the register before it syncs the bill, and a failed sync is caught and logged: `try{yield o(U.default.syncRequest,s)}catch(e){console.error(e)}`. KOT numbers come from a counter the register keeps locally, and the server is told the number without waiting for a reply. Printing goes to QZ Tray over `host:["localhost"]`. If QZ Tray is unreachable the POS shows 'Make sure Qz-Tray is running, and the printer is connected.' and offers 'Browser Print'. The POS route is marked `offline:!0`, and settings state 'We store register and bills locally on your browser to support offline mode.' The shortfall: offline kitchen printing is inferred from the code rather than stated by the vendor, and the kitchen display reads and updates tickets only through cloud endpoints (/api/v1/kds/kots), so the KDS side is not shown to work offline. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 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

The alerting half is documented and the failover half is manual. Alerting: when a cloud printer is added on Prime Web the operator supplies 'Notification emails -- email addresses to notify if a print job on this printer fails', and there is a failure log -- 'you can check if any print jobs failed, for example if a printer was offline or unreachable when a Bill/KOT was due to print... This opens a drawer listing all failed and expired print jobs, along with the order, printer, print type (Bill/KOT), and the reason each one failed.' A second path is deliberately kept armed: 'Qz-Tray setup is completed, and this same printer is also added under Receipt Printers on Prime Web. This acts as a fallback, if cloud printing fails for any reason (network issue, printer offline, etc.), you will still be able to print the same Bill/KOT the regular way from Prime Web.' SHORTFALL, and it is why this is not a yes: that fallback is an operator re-print from the browser, not automatic re-routing -- 'you will still be able to print', not 'the job is re-sent'. No backup-printer assignment, no failover order between kitchen stations and no KDS fallback target appears in assigning-a-printer-for-kot-invoice, print-automations or print-kot-for-kitchen-stations, and the alert is an email plus a drawer rather than an on-screen prompt to staff at the terminal. https://help.urbanpiper.com/store-manager/prime-web/cloud-printing-setup-guide · retrieved 2026-09-01

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

Two published rules, both in the POS-partner API reference. (1) Partition recovery, resources/webhook-circuit-breaker: when a partner's webhook endpoint fails more than 15 times in a minute the platform trips a circuit breaker and disables that host's webhooks for 1-3 minutes, then 'our system tries to push them at once when the webhooks are re-enabled', and the reconciliation rule is stated explicitly -- 'whatever the state of the order present in the Urbanpiper system, the same will be present in the Order Relay payload under the state/order_state attribute... if the state of the order is Acknowledged in our system due to status change happening from aggregator, then in the order relay payload, the state/order_state attribute will have the Acknowledged status instead of Placed. Please make sure that you do not expect only a Placed state value to be passed in that attribute.' That is current-state-wins on replay, documented as such. (2) Two-surface edit precedence, api/endpoints/menu/add-update-menu: 'platform_pricing only ever sets or updates the price for the platforms explicitly listed in it. It never resets a platform price you don't mention, and the base price never overwrites a platform price that already exists', with the pitfall spelled out -- 'if a platform price was set earlier (for example, through Atlas), sending only the base price will not update that platform -- the existing platform price takes precedence.' That is an explicit merge rule, deliberately not last-write-wins, between an edit made in the Atlas UI and one pushed by the POS. SHORTFALL, three parts. First, both rules govern the UrbanPiper-cloud-to-partner channel, not two operator devices: the claim's scenario cannot arise in Prime, which has no documented offline mode (Prime Web needs 'No additional installation... it runs entirely in your browser' against Atlas). Second, there is no general concurrency machinery -- no version, revision, ETag or updated-at conflict field anywhere in the menu, store or order schemas; the only other collision handling is a menu-push error string ('An item and a modifier have the same name, causing conflict') and the advisory 'Menu push is queued up due to multiple pushes or server lag at Swiggy. Wait for up to 4 hours before publishing the menu again.' Third, no operator prompt on conflict is documented anywhere. Checked against all 116 help.urbanpiper.com pages and all 87 api-docs.urbanpiper.com pages retrieved 2026-09-01. https://api-docs.urbanpiper.com/downstream/resources/webhook-circuit-breaker · retrieved 2026-09-02

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

This is a publication claim and the publication surface is fully enumerated. Both documentation hosts are GitBook with permissive robots and machine-readable manifests -- help.urbanpiper.com/llms.txt lists 116 pages and api-docs.urbanpiper.com/downstream/llms.txt lists 87; all 203 were retrieved on 2026-09-01 and all 203 are live. Across that entire corpus the word 'offline' appears eleven times and not one is a feature-availability statement: marketing boilerplate ('online and offline operations'), deactivating a location ('takes it offline'), aggregator mapping ('carried out offline, with assistance from the Zomato team'), a cloud printer being 'offline or unreachable', and three aggregator rejection strings ('Your outlet is currently offline due to high number of rejections'). There is no offline-mode article, no supported/unsupported table, no degraded-operation page and no per-feature availability matrix; the four legal pages at www.urbanpiper.com/legal/ contain none either. The vendor publishes no such list. https://help.urbanpiper.com/llms.txt · retrieved 2026-09-01

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

reliability-public-status-page

Both limbs verified, and the page itself was fetched rather than taken on the documentation's word. status.urbanpiper.com returns 200 with no login and renders per-component state: Atlas Portal, "Online Delivery Service Providers (DSP) 5 components", "Store operations 4 components", "Direct Ordering Channel (Meraki) 4 components" and "Integrations 4 components", each with a 90-day uptime figure over a "Jun 2026 - Aug 2026" window and a per-day incident calendar, above a "We are fully operational" banner. History is therefore present as well as current state. The help centre documents the same surface and what it is for: it shows "Integrations (e.g., with POS and delivery platforms) / Dashboard performance / API availability / Scheduled maintenance / Known incidents or outages", and "You can subscribe to receive status alerts via email or SMS directly from the status page." https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

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 standard agreement is published in full and warrants the opposite. Clause 13.2: 'YOU ACKNOWLEDGE AND AGREE THAT URBANPIPER DOES NOT WARRANT THAT THE ACCESS TO THE SERVICES WILL BE UNINTERRUPTED, TIMELY, SECURE, ERROR-FREE OR FREE FROM VIRUSES... URBANPIPER DOES NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED AS THE SERVICES ARE PROVIDED OVER THE INTERNET'; cl. 13.1 puts the Services on an 'AS IS' and 'AS AVAILABLE' basis. No uptime percentage appears anywhere in the agreement, and the only remedy structure is a liability cap -- cl. 14.1 limits aggregate liability to 'ONE (1) MONTH OF THE FEES PAID BY YOU' -- with no service-credit mechanism of any kind; cl. 16.10 further excuses unavailability caused by matters beyond UrbanPiper's control. Clause 16.9 makes this text prevail over an Order Form except where the Order Form expressly amends it. CAVEAT recorded rather than hidden: cl. 3.2 says 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form', and Order Forms are per-merchant and unpublished, so a negotiated support commitment may exist. What the claim asks is whether an uptime percentage plus a credit remedy is published or sits in the standard agreement, and it is not: the standard agreement disclaims uptime instead. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

reliability-incident-postmortems

The vendor documents that it publishes root-cause summaries: during "any system degradation or outage" the status page carries "Issue identification and investigation / Ongoing resolution progress / Final incident resolution and root cause (post-mortem)." SHORTFALL, and it is why this is not a `yes`: the status page was fetched on 2026-08-31 and every component reads 100% uptime across its whole Jun-Aug 2026 window, so there is no incident on it and therefore NO PUBLISHED POST-MORTEM TO INSPECT. What is established is the vendor's stated practice, not an artefact; a written post-incident report has not been seen. That distinction is the difference between documenting a policy and evidencing its output, and it is recorded here so a later pass with an incident in the window can settle the cell either way. https://help.urbanpiper.com/basics/urbanpiper-status · retrieved 2026-08-31

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

Live human support is included with no premium tier documented, but neither the phone limb nor the 24/7/365 limb is met. The vendor's whole published support-channel statement is the Contact Us article: 'If you couldn't find what you were looking for in our Help Center, our Support Team is ready to assist you. Click the chat icon at the top right corner of your Manager Portal to connect with one of our support agents... Our agents can use screen sharing or call you, if needed, to help resolve your issue quickly. Prefer email? You can also reach us at support@urbanpiper.com.' In-portal chat with a human agent is available to any account, and no paid support tier, ticket allowance or premium plan appears anywhere in the help centre or the Merchant Agreement. SHORTFALL: no support telephone number is published at all -- a call is an agent-initiated callback 'if needed' -- and no coverage window is stated anywhere, let alone 24/7/365; the Merchant Agreement instead defers the commitment to a private document, cl. 3.2, 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form.' A separate pos.support@urbanpiper.com queue exists for POS partners, also with no hours. https://help.urbanpiper.com/basics/contact-us · retrieved 2026-09-01

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

2026-09-02: re-grepped all 116 help.urbanpiper.com pages on word boundaries for 'onsite', 'on-site', 'site visit', 'field engineer', 'installation', 'installer', 'technician', 'dealer' and 'reseller'. There is exactly ONE hit in the entire help centre and it points the other way -- 'No additional installation is needed -- it runs entirely in your browser' (store-manager/prime-web). The most complete onboarding document, pos-integrations/foodics/integrate-your-foodics-account-with-urbanpiper, 'outlines the onboarding steps, timelines, and key operational guidelines' in three phases (Authorization, Menu Setup, Menu Pull and Aggregator Mapping) and assigns a named human -- 'An UrbanPiper Onboarding Manager will be assigned to work alongside the Foodics team and support you throughout the entire integration process' -- with published go-live timelines (Deliveroo 24-48 hours; Talabat requests Sunday/Tuesday, go-live Wednesday/Thursday), but every documented step is performed in a console or by email. The Merchant Agreement, re-read 2026-09-02, describes a 'DIY approach' with remote assistance (cl. 2.8), puts training in Value Added Services -- 'We may provide training to You and Your Users as a part of the Value Added Services' (cl. 6) -- and defers 'support and resolution timelines' to the Order Form (cl. 3.2). help.urbanpiper.com/basics/partner-with-us and www.urbanpiper.com/integrations enumerate partners only as POS, delivery, fulfilment, online-ordering, payment and marketing categories, with no implementation-partner or certified-dealer category. UNRESOLVED because the Order Form catalogue that would price an on-site option is private, so an on-site programme cannot be excluded. 2026-09-12 (263rd sweep, new corpus): New corpus read 2026-09-12: the 141 Wayback-recovered support.urbanpiper.com Freshdesk articles (fd) and 239 www.urbanpiper.com sitemap pages incl. 21 monthly product-update posts (www) in .cache/q263-urbanpiper/corpus.txt, word-boundary regex, every hit read in context, with the www footer phrase "manage your restaurant online and offline" neutralised before counting. changelog.urbanpiper.com is robots-barred (User-agent: * / Disallow: /; listed in data/robots-bars.json), so nothing from it is cited or restated. install/on-site/technician/dealer: 1 fd hit (installing the Qz-Tray utility for seamless printing); the www hits are Odoo 'Onsite installations' (an Odoo hosting edition) and generic prose. The fd support-process articles (e.g. Prime Login issue, 2023-01-27) escalate through a ticket and a Google Meet with the merchant, i.e. remotely. No on-site installation or certified dealer programme is documented. Unresolved. || 324th: 324th, NEW SURFACE, CELL NOT MOVED. Merchant Agreement clause 2.8 states UrbanPiper's service model in its own words: 'You understand that as a part of daily operations, there would be a need to make changes in the configuration of the Your Account from time to time. While all Our Services are built keeping a Do-It-Yourself (DIY) approach in mind, You may still feel it necessary to seek Our assistance to perform configuration changes/actions. You hereby provide Your consent to Our representative to make configuration changes on Our behalf on a case-to-case basis.' That is remote, DIY-first configuration assistance. CONTROLS over both corpora: 'on-site' = 0/0, onsite = 0/0, dealer = 0/0, 'field technician' = 0/0; 'installation' = 1/0 (a printer driver install), 'reseller' = 0/2 and both are the partner-programme page's referral/reseller model, which is a channel-sales arrangement and says nothing about who physically installs. Not yet a no: clause 3.2 defers support scope to the unpublished Order Form, and UrbanPiper does ship physical hardware (printer, tablet, cellular modem) whose delivery and setup arrangements are nowhere described. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. || 327th: MERGE HOLD (proposed no/B, held unknown): On-site installation is a SERVICE, not an app feature: a store-level bundle cannot bound it, and a documented remote ticket workflow does not exclude dealer/on-site installs sold alongside it. No explicit 'remote only' statement was quoted. PROPOSAL AS WRITTEN: NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. CLAIM: the vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. VERDICT no. EVIDENCE: UrbanPiper's own documented go-live is a REMOTE ticket workflow, described end to end in the help corpus: 'Create a Go-Live Request', 'Select the platform you want to go live on', 'the system will automatically: Verify your menu / Raise a go-live request with the internal team', a tracker showing 'Menu verification timestamp / Date the go-live request was submitted / Current mapping status', 'Going live typically takes 2-3 business days', and per-aggregator cycles ('Talabat runs two mapping cycles per week'; 'Requests raised every Sunday/Tuesday; go-live on Wednesday/Thursday'). The product itself needs no installer: 'No additional installation is needed -- it runs entirely in your browser' (Prime Web; printing via QZ Tray). BOUND/CONTROLS over the 240 KB llms-full manifest corpus + 65 KB helpjuice sitemap corpus: `on-site` 0, `onsite` 0, `field technician` 0, `dealer` 0, `installer` 0, `cutover` 0; the 39 `installation`/`go-live` hits are the ones quoted above. Retrieved 2026-09-18. || 331st: 331st: no new surface bears on this SERVICE claim. The Prime Android app (com.urbanpiper.satellite_prime 69.0.0, unpacked) is self-installed from Google Play and its i18n keys hold one 'Install' (an app-update prompt); `on-site`/`onsite` 0, `technician` 0. A bundle cannot bound a service, per the 327th hold. Retrieved 2026-09-18. || 332nd: 332nd: two new public surfaces checked, neither bears on this SERVICE claim. (a) www.urbanpiper.com's own Webflow site search (/search?query=), swept with 27 vocabulary queries (installation, install, on-site, onsite, technician, hardware, warranty, replacement, onboarding, training, prime, ...): 91 distinct result pages, EVERY ONE already inside the 239-URL sitemap, so the site carries no unlinked service or legal page; the only hits for the claim's words are the Odoo blog's 'Onsite installations' (an Odoo hosting edition), the printer-setup blog's QZ Tray install, and the Merchant Agreement / DPA text already on record. /prime 301s to /prime-pos, which 404s like the nonsense control (39,423 B). (b) NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). None of the *.svc service contracts (report, payments, notification, order-edge) has a field-service, installation, warranty or RMA operation. Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: install 0, installation 0, hardware 0, warranty 0, replacement 0 across all 15 contracts; no field-service or onboarding-visit operation exists in any published service (onboarding.staging.svc-hz serves no spec). A service claim; this bounds nothing. Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: 'How do I sign up for Prime? ... One of our product experts will reach out to you to schedule a custom demo for your business shortly. How long does it take to set up Prime? Usually, it takes us 7 days to get Prime working on your system. However, our team is currently working on reducing this time. So, you can expect a turnaround time of less than 7 days.' and 'Prime does not require any additional hardware. It can work on any mobile or desktop device.' ON THIS CELL: the vendor performs the setup ('it takes us 7 days') but never says where - no on-site, visit, installer, technician or dealer word appears in any of the four captures (tokenised: onsite 0, on-site 0, install 0, installation 0, technician 0; visit 1 is POISON, a customer testimonial 'we didn't even visit the kitchens'). A vendor-run setup of unstated modality is neither in-person installation nor an explicit remote-only statement. Unknown. Retrieved 2026-09-18. adversarially verified

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 vendor does put its own people on the initial build, but not on the menu itself. Documented as a staffed process: 'An UrbanPiper Onboarding Manager will be assigned to work alongside the Foodics team and support you throughout the entire integration process', the onboarding runs in three phases ending in 'Menu Pull and Aggregator Mapping', and 'After the menu pull, the UrbanPiper Onboarding Manager will coordinate with the various aggregators to map the brand's locations. This is a manual process, and timelines differ by aggregator' -- with a published timeline table. Account creation is also done for the operator: 'Once you decide to signup with UrbanPiper, the onboarding team will take care of setting up your account and share with you an administrator access' (basics/editor). The aggregator-side menu mapping is likewise vendor-assisted: 'This mapping is carried out offline, with assistance from the Zomato team.' SHORTFALL: the initial menu is not built by UrbanPiper, it is imported from the operator's existing POS -- 'Choose Import Menu from the dropdown... It usually takes 2 to 5 minutes for the menu to be updated. Once the menu is pulled from the POS, you can make the necessary changes and publish the menu on the DSPs' -- and every catalogue task after that (items, modifier groups, charges, taxes, publishing) is documented as the operator's own work in Atlas, in a product the Merchant Agreement describes as built 'keeping a Do-It-Yourself (DIY) approach in mind' (cl. 2.8). For a merchant with no POS menu to pull, no vendor menu-build service is documented at all. https://help.urbanpiper.com/pos-integrations/foodics/integrate-your-foodics-account-with-urbanpiper · retrieved 2026-09-01

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

reliability-hardware-replacement-sla

2026-09-02: re-read the Merchant Agreement at www.urbanpiper.com/legal/merchant-agreement and re-grepped all 116 help.urbanpiper.com pages on word boundaries for 'warranty', 'warranties', 'replacement', 'repair', 'RMA' and 'technician' -- ZERO hits in the help centre for every one of them. UrbanPiper does issue hardware to some merchants: the agreement defines 'Hardware' as 'the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper', it 'shall remain the exclusive property of UrbanPiper', and cl. 8.7 prices it on exit at '$350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem', refunded if returned in good operating condition within five business days. NEW this pass, and the clause the 2026-09-01 rationale missed: cl. 2.7 supplies it with no warranty at all -- 'Hardware is provided to You Merchant AS IS' -- and its only repair term runs toward the merchant: 'If damages to the Hardware are caused by the Merchant's misuse, the Merchant agrees to reimburse UrbanPiper for the full cost of repairing or replacing the damaged Hardware plus shipping costs.' No advance exchange, no loaner, no turnaround time and no hardware SLA appears anywhere in the agreement, and help.urbanpiper.com/basics/compatible-hardware is a buy-your-own minimum-specification page ('minimum specification requirements for buying hardware to use UrbanPiper products', with a device-certification path taking '20-25 working days') rather than a replacement programme. UNRESOLVED rather than no because the claim admits a PURCHASABLE programme and cl. 3.2 places 'support and resolution timelines' in the per-merchant Order Form, which is not published. 2026-09-12 (263rd sweep, new corpus): New corpus read 2026-09-12: the 141 Wayback-recovered support.urbanpiper.com Freshdesk articles (fd) and 239 www.urbanpiper.com sitemap pages incl. 21 monthly product-update posts (www) in .cache/q263-urbanpiper/corpus.txt, word-boundary regex, every hit read in context, with the www footer phrase "manage your restaurant online and offline" neutralised before counting. changelog.urbanpiper.com is robots-barred (User-agent: * / Disallow: /; listed in data/robots-bars.json), so nothing from it is cited or restated. replacement/warranty/RMA/advance exchange: 0 product hits in fd. The www hits are the Merchant Agreement (already on record: hardware is supplied AS IS) and blog text. No replacement programme or turnaround time is documented. Unresolved. || 324th: 324th, NEW SURFACE, CELL NOT MOVED, but the record now holds UrbanPiper's published hardware terms for the first time. The Merchant Agreement defines the kit -- 'Hardware: means the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper under this Agreement' -- and clause 2.7 governs it: 'During the Term of this Agreement, UrbanPiper provides to the Merchant the Hardware... The Hardware shall remain the exclusive property of UrbanPiper. The Hardware is provided to You Merchant "AS IS". The Merchant shall use and maintain the Hardware in a good condition and shall take care of the same with reasonable care. If damages to the Hardware are caused by the Merchant's misuse, the Merchant agrees to reimburse UrbanPiper for the full cost of repairing or replacing the damaged Hardware plus shipping costs.' Clause 8.7 prices it on exit: 'UrbanPiper shall charge a Hardware Fee of $350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem', refundable if the kit is returned in good operating condition within five business days. So replacement COST is published and replacement TURNAROUND is not, anywhere -- and clause 3.2 puts the timings in a document we cannot read: 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form.' An unpublished Order Form is a refusal, not an absence, so this stays unknown rather than becoming a no. BOUND (the same three censuses for every row, all retrieved 2026-09-17): (a) help.urbanpiper.com -- llms.txt lists 115 .md pages and sitemap-pages.xml lists the same 115 URLs plus the site root (set difference = the root alone); all 115 fetched as .md. (b) api-docs.urbanpiper.com/downstream -- llms.txt lists 86 .md pages and the two sitemap-pages.xml files list 86 URLs, the only differences being the two section roots against their readme aliases; all 86 fetched. (c) www.urbanpiper.com -- sitemap.xml holds 213 URLs and all 73 non-blog, non-author, non-case-study pages were fetched, including /legal/merchant-agreement, /legal/customer-terms-and-conditions, /legal/data-processing-agreement and /legal/privacy-policy. Denominator: 1,394,977 chars of documentation + 888,305 chars of site text. Every control is tokenised, word-boundary, case-insensitive over BOTH corpora, counted docs/site. POISON MEASURED HERE: 'punch' = 2/22 and every site hit is 'we used to manually punch orders into the POS' (order keying, not a time clock); 'apple' = 2/0, the App Store link for Prime and the macOS Apple menu (untokenised it also hits 'pineapple' in the cake-flavour tags); 'birthday' = 2/1, the menu tag birthday-cake; 'tiered' = 1/0, the menu tag tiered-cake; 'gold' = 1/0, a cake tag; 'lapsed' = 1/0, a lapsed GST registration; 'fallback' = 1/0, a backup printer path; 'exclusive' = 3/14, all tax-exclusive pricing, a Prime-exclusive feature or the licence grant; 'precedence' = 2/1, category_id precedence in the menu payload; 'automation' = 11/43, Prime's PRINT automations; 'wallet' = a stored-value balance; 'pour' = French on /fr; 'till' = the preposition; 'float' = a JSON type; 'membership' = 1 site hit, trade-union membership in the privacy policy's special-category definition. Retrieved 2026-09-17. || 327th: NEW SURFACE (327th): the 326th's Prime census re-grepped PER CELL (this cell had never been checked against it). prime.urbanpiper.com is UrbanPiper's STORE-LEVEL POS and its bundle carries no lazy-chunk loader, so main.877fb1f9292d7b25014a.js (4.86 MB) + vendors.a82de318208444ce3a4e.js (12.6 MB) ARE the whole app: 110 KB of extracted English UI literals, 300 distinct API paths and ~540 client routes. Grade B (vendor's own shipped production code, not published documentation). The doc corpus alongside it is help.urbanpiper.com fetched from the publisher's own llms.txt manifest (llms-full.txt, 240 KB) plus the urbanpiper.helpjuice.com sitemap (65 KB). changelog.urbanpiper.com is robots-barred for the cited paths and was NOT read. CONTROL POISON measured in this bundle and named here so it is not re-run naively: a substring `EDI` scores 1,047 hits, every one inside `credit`, `credit_limit`, `Credit Sales` or `qr_redirects_to` -- tokenised `\bEDI\b` is 0; `scale` is the per-item unit-conversion map (`units:{default:'pcs',base:'pcs',scale:{pcs:1}}`) and CSS `transform:scale()`, never a weighing device; `tip` matches `multiple`, `Multilingual`, `Municipal` and `encodePosMultipleVoidLine`; and `offline` is a HOMONYM -- `payment_mode:'offline'` in Prime means a payment NOT taken through an online gateway (cash/counter card), not a network outage. NEW BOUND (327th), still unknown: the claim may not apply. With the store-level POS censused it is established that UrbanPiper ships NO hardware: Prime Web 'runs entirely in your browser' with no installation, printing goes through QZ Tray to the operator's own printers ('No USB devices found', 'No receipt printers configured yet'), and the device enumeration in the whole app is printers plus generic tablet/mobile preview modes. Tokenised over the whole Prime app and the 240 KB help llms-full corpus: `RMA` 0, `advance exchange` 0, `replacement` 1 hit (prep 'turnarounds'), `depot` 0, `warranty` 0. Per merge policy a product that lacks the category entirely is held unknown rather than scored no. Retrieved 2026-09-18. || 330th: 330th: CORRECTION TO THE 327th NOTE, PLUS A NEW SURFACE. The 327th wrote 'it is established that UrbanPiper ships NO hardware' and proposed holding the cell as not-applicable on that basis. That premise is FALSE and contradicts this record's own 324th entry: the Merchant Agreement (re-read 2026-09-18, 55,736 chars) defines 'Hardware: means the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper under this Agreement', clause 2.7 supplies it ('The Hardware shall remain the exclusive property of UrbanPiper... provided to You Merchant "AS IS"'), and clause 8.7 prices it on exit at $350.00 per printer, $150.00 per tablet, $250.00 per cellular modem. UrbanPiper DOES ship hardware; the fact that Prime Web needs no installer is about software. Do not re-score this cell as not-applicable. The 327th's Prime-bundle controls (`RMA` 0, `warranty` 0, `depot` 0) are therefore measuring the wrong corpus: a replacement programme would live in the contract, not the browser app. NEW SURFACE CHECKED THIS PASS: developers.urbanpiper.com, a fully public 30-file Vite SPA (1,346,248 B, fixpoint census, nonsense control passes) that is UrbanPiper's POS integration certification portal -- it carries no hardware, warranty, RMA or support-turnaround terms at all (`warranty` 0, `\bRMA\b` 0, `replacement` 0), so it does not settle this cell either. WHAT STILL BLOCKS A `no`: the contract's own clause list ('Your Rights, Your Responsibilities, Services and Support, ... Value added Services, Charges and Payment, ...') shows the two places a purchasable replacement programme could live -- clause 3.2 'We shall take responsibility for certain aspects of the Services including support and resolution timelines as set forth in the Order Form' and clause 6 'You may avail certain value added services from Us as mentioned in the Order Form ... The charges for Value added Services shall be as set forth in the Order Form' -- and the Order Form is per-merchant and unpublished. An unpublished contract annexe is a refusal, not an absence. Retrieved 2026-09-18. || 331st: 331st: nothing new. The unpacked Prime Android app carries no warranty/RMA/replacement text (`warrant` 0, `RMA` 0; `replace` 11 raw hits are JS replace()/replaceReducer). The Order Form remains the unread document. Retrieved 2026-09-18. || 332nd: 332nd: two new public surfaces checked, neither bears on this SERVICE claim. (a) www.urbanpiper.com's own Webflow site search (/search?query=), swept with 27 vocabulary queries (installation, install, on-site, onsite, technician, hardware, warranty, replacement, onboarding, training, prime, ...): 91 distinct result pages, EVERY ONE already inside the 239-URL sitemap, so the site carries no unlinked service or legal page; the only hits for the claim's words are the Odoo blog's 'Onsite installations' (an Odoo hosting edition), the printer-setup blog's QZ Tray install, and the Merchant Agreement / DPA text already on record. /prime 301s to /prime-pos, which 404s like the nonsense control (39,423 B). (b) NEW SURFACE (332nd): certspotter run to exhaustion on urbanpiper.com for the first time (297 issuances, 201 names, 192 of them absent from the 325th's crt.sh list). It exposes a production service mesh at *.svc.urbanpiper.com whose FastAPI services publish their OpenAPI contract ANONYMOUSLY at /openapi.json (report.svc, payments.svc, notification.svc, order-edge.svc: HTTP 200, JSON; controls: a nonsense subdomain zzznopeqq.svc.urbanpiper.com/openapi.json 404s and a nonsense path on order-edge.svc 404s with a 22-byte body, so these are real specs, not a catch-all), plus staging twins at *.staging.svc-hz.urbanpiper.com (report.staging's spec is byte-identical to production's). Only the /openapi.json documents were read; no API operation was called. The other new production hosts are gated or empty and were not entered: features.urbanpiper.com (Nolt board, sign-in wall), piper-academy / main.piper-academy / csteam.piper-academy (TalentLMS logins), test-docs.urbanpiper.com (307 to app.gitbook.com, a private GitBook site), forums.urbanpiper.com (302 to Google OAuth), ask.urbanpiper.com (login), apidocs.urbanpiper.com (307 to the api-docs host already censused). None of the *.svc service contracts (report, payments, notification, order-edge) has a field-service, installation, warranty or RMA operation. Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. The 332nd's certspotter host list was taken to 100% of its *.svc names for the first time: all 56 staging hosts (*.staging.svc-hz.urbanpiper.com plus order-line-chat.staging.svc) probed with curl at /openapi.json, /docs, /api/openapi.json and /v1/openapi.json (224 probes; the 332nd had probed 9). 15 hosts serve a real JSON OpenAPI 3.1 contract anonymously (the rest are SPA shells returning one fixed body for every path, gRPC, 404 or dead): activity-history, atlas-chat, automations, checkout-service, indexing, iris, menu-publish, menu-service, notification, order-edge, order-line (155,609 B), order-line-chat, payments, pg-service (byte-identical to payments), report. Production twins probed at <name>.svc.urbanpiper.com/openapi.json: activity-history.svc and indexing.svc are LIVE (200, identical to staging); atlas-chat, checkout-service, menu-publish, menu-service, order-line, pg-service and iris 404 in production. Only the /openapi.json documents were read; no operation was called. ALSO NEW: stl-prime.staging.svc-hz.urbanpiper.com is a STAGING copy of the Prime web app (<title>Prime</title>, main.587ce9c98e8e9cc18bd8.js, 4,861,826 B, same vendors.a82de318208444ce3a4e.js); a string-literal diff against production main.877fb1f9292d7b25014a.js (19,631 vs 19,639 literals) differs ONLY in environment config (hosts, SDK keys, version 1.102.66 vs 1.102.67), so it ships no pre-release feature; its .js.map 404s byte-identically (548 B) to the nonsense sibling, so no source map there either. ON THIS CELL: hardware 0, warranty 0, replacement 0, RMA 0 across all 15 contracts. The Merchant Agreement's Order Form remains the unread document. Retrieved 2026-09-18. || 334th: 334th NEW SURFACE: the RETIRED Prime POS product page and its FAQ, which no prior pass read (the 332nd recorded only that /prime 301s to /prime-pos, which now 404s like the nonsense control at 39,423 B; /au/prime-pos and /in/prime-pos 404 the same way today). Wayback CDX for urbanpiper.com/prime* and a domain-wide CDX filter found four captures, read with id_ URLs: www.urbanpiper.com/prime-pos 2022-06-30 and 2024-10-13, /us/prime-pos 2023-05-16, and /au/prime-pos 2025-06-21 (https://web.archive.org/web/20250621181044/https://www.urbanpiper.com/au/prime-pos); the 2022, 2024 and June-2025 captures carry an identical Prime FAQ (marketing page, grade C; retired, so it may carry positives at most and no `no`). Verbatim: 'Does Prime require any hardware? No. Prime does not require any additional hardware. It can work on any mobile or desktop device.' and 'Do you also provide hardware for your software? We currently do not provide any hardware but would be happy to guide you with the hardware required to run our POS system.' ON THIS CELL: for the store-level POS the vendor states it supplies NO hardware (through June 2025), which sits beside the US Merchant Agreement's 'Hardware ... provided to You Merchant AS IS' (printer/tablet/modem for Hub merchants, cl. 2.7). Neither document offers a replacement or advance-exchange programme with a turnaround; the Merchant Agreement's Order Form remains unread, and a retired FAQ may not carry a no. Unknown. Retrieved 2026-09-18. adversarially verified

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

reliability-backup-restore

Half of the claim's first limb is met and the rest is not. Retrieval is genuinely self-serve: Merchant Agreement cl. 10.1 states 'You will have access to the dashboards of the Services and all the Customer Data or order-related data which can be downloaded from the Services. In the event You require such data in a format which is not available, a request can be made to Us', and the Central Report UI exports to 'CSV or XLSX formats' on demand or on a daily schedule. The same clause makes self-backup the merchant's own job in as many words: 'You are advised to take regular data backups to ensure all historical data is available with them at all times.' SHORTFALL on everything else. There is no restore path at all -- nothing in the help centre or the API reference lets an operator upload a backup or roll an account back -- no account-level backup artifact exists (only per-report downloads), and no RPO or RTO figure is published anywhere. The DPA's Schedule B describes the vendor-side capability without numbers: infrastructure 'spans multiple fault-independent availability zones', with orchestration tooling 'that has the ability to regenerate hosts, building them from the latest backup', and no objective attached. Reach is capped too: cl. 10.2 warns 'data preceding more than one (1) year may not be available for some data sets', releasable at UrbanPiper's discretion 'subject to a reasonable fee as determined by Us'. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

No PCI attestation is published, and the vendor's own certification sentence limits how any such report is released. Privacy policy s.9 (last updated 11 Aug 2026, re-read 2 Sep 2026): 'We maintain an information security programme aligned to recognised standards and hold ISO/IEC 27001 certification and a SOC 2 attestation... The scope and currency of Our certifications, and copies of relevant reports, are available to Merchants on request... subject to appropriate confidentiality undertakings.' That is a stated limitation on publication -- reports go to merchants under confidentiality, not to the public -- and this claim asks whether a current v4.0/4.0.1 AoC or validated P2PE listing is PUBLISHED. NOT RELIED ON: that the same sentence exhaustively lists every attestation the vendor holds. It does not, and an audit on 2 Sep 2026 refuted that reading; the cell no longer rests on it. What carries it instead is measured absence of any publication surface plus a positive allocation of PCI to others: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki.' www.urbanpiper.com/sitemap.xml enumerates exactly four legal pages and no security, trust, compliance or pricing page; /security, /trust and /pricing all return a genuine HTTP 404 (identical 39,423-byte 404 body, re-probed 2 Sep 2026) and trust.urbanpiper.com and security.urbanpiper.com do not resolve. The string PCI does not occur once in the 285,626 bytes of the help centre's two-page llms-full dump (re-fetched 2 Sep 2026), nor in the API reference, the Merchant Agreement or the DPA Schedule B measures. A third-party press release for the Payarc integration says only 'Built-in security with PCI-compliant processing', which is Payarc's compliance and not a published UrbanPiper attestation. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-02

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

reliability-mfa-role-based-access

Role-based permissions are documented in more depth than most records in this corpus can show, and MFA is not documented at all. Prime ships six standard roles -- Captain, Online Order Processor, Online Order Supervisor, Cashier, Manager, Administrator -- with duties separated at a useful granularity (Captains "cannot settle bills; that's handled by Cashiers"), location-scoped assignment, and custom roles: "Prime gives you the flexibility to create custom roles tailored to your specific needs... assign very specific permissions." Atlas ships ten, including data-scoped variants -- "Non-HQ Analytics: Provides access to analytics data, but strictly limited to specific locations. Users cannot download full business data or reports without a location filter." SHORTFALL: no multi-factor authentication appears anywhere in the help centre for either back-office or store login. The only one-time code documented is a password-RESET PIN sent to a registered email, and the store-operations PIN is a shared-device unlock, not a second factor. https://help.urbanpiper.com/business-manager/user-access/understanding-standard-roles-in-prime-and-atlas · retrieved 2026-08-31

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

reliability-self-serve-training

The public free-training half is met generously. help.urbanpiper.com is open to an ordinary user agent, publishes its whole corpus as a single 231,780-byte llms-full.txt, and the operator-facing articles are built around embedded video walkthroughs -- roughly forty trainn.co tutorial embeds across menu building, publishing, 86ing, store status, printer setup, user access and order management, several with an Arabic-language version linked beside the English one. SHORTFALL: the claim's second limb is a practice or training MODE on the terminal, and nothing of the sort is documented. Prime has no sandbox, demo or training-mode article; the closest the documentation comes is telling an operator to acknowledge a real incoming order to test the Scan and Pack flow, which is live production. https://help.urbanpiper.com/llms-full.txt · retrieved 2026-08-31

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

reliability-failover-terminal-role

Prime POS has no designated primary terminal or local server that another terminal could replace. Each browser register connects to UrbanPiper's cloud (/api/v1/dr3/devices), and bills are transferred between registers through cloud calls. The word 'master' appears only as 'Master KOT', a consolidated kitchen ticket. The 'captain' is a waiter app whose actions are routed to a register. A register stays tied to the device that opened it. Recovering it elsewhere means a manual force close, which warns 'This can result in issues with Invoice numbering.' and 'Please close the register on the system it was opened on.' No terminal takes over another's role automatically. https://prime.urbanpiper.com/main.5e41e891716be92f2e7b.js · retrieved 2026-09-14 adversarially verified

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

reliability-cellular-backup

First-party cellular hardware is documented; automatic failover is not. The Merchant Agreement defines Hardware as 'the thermal printer and other items including but not limited to a tablet, stand, modem and computer cables provided to Merchant by UrbanPiper' and prices a cellular modem explicitly on exit: 'UrbanPiper shall charge a Hardware Fee of $350.00 per printer, $150.00 per tablet, and $250.00 per cellular modem' (cl. 8.7). So UrbanPiper does issue a cellular modem to merchants under contract, which is the first-party half of the claim. SHORTFALL: nothing states what it is for. No page in the 116-page help centre mentions cellular, LTE, 4G or a data SIM -- the connectivity article is prime-app/connecting-your-tablet-to-wifi, and the cloud-printing prerequisites assume 'a Wi-Fi router using a LAN cable' -- so the modem is documented only as a billable asset, with no configuration article, no automatic switchover behaviour, and no statement that it is a backup path rather than a store's primary connection. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

The cancellation article establishes monthly billing and self-serve exit without a sales call: an operator raises the request from Atlas Settings > Profile > Cancel Subscription, and "You can cancel from the current billing month or a future one. The full month in which the cancellation takes effect will be charged." No minimum term, notice period, early-termination charge or remaining-term liability appears anywhere in the article, and the only stated cost of leaving is the current month. SHORTFALL: the claim asks for a PUBLICLY OFFERED month-to-month subscription for the core tier, and that is an inference here rather than a statement. UrbanPiper publishes no pricing page and no terms of service in this help centre, no article states the contract length, and the exit is not fully self-serve either -- "After you submit the form, a member of our team will get in touch with you to complete the process." https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-08-31

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

The exit terms are published and carry no termination charge, but they do not state the claim's proposition and one clause cuts against it. In favour: termination for convenience is bilateral and cheap -- 'Either Party may terminate this Agreement at any time and without cause, by giving not less than one (1) month's prior written notice' (cl. 8.2) -- and cl. 7.9 spells out the exit cost as the notice period only: 'Merchants can cancel their subscription (applicable for the whole Account or to a specific outlet) at any time by providing UrbanPiper a 30 days prior notice... Merchant's cancellation will take effect at the end of the notice period of 30 days and the Merchant shall be billed accordingly for the notice period term.' No early-termination fee, no liquidated damages clause and no acceleration of remaining-term fees appears anywhere in the agreement; the help centre says the same operationally ('The full month in which the cancellation takes effect will be charged'). SHORTFALL: the agreement never states that there is no ETF, and cll. 7.3 and 7.9 impose the economic equivalent on a prepaid term -- 'all Fees are non-refundable. No refunds shall be issued for partial use or non-use of the Services', while 'All subscriptions (monthly, quarterly and yearly) renew automatically' -- so a merchant on the marketed annual plan forfeits the unused balance. Two further exit charges exist: a Hardware Fee of $350 per printer, $150 per tablet and $250 per cellular modem collected at cancellation (refundable on return within five business days, cl. 8.7) and a reactivation fee after suspension (cl. 7.5). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

No publicly accessible contract terms, auto-renewal term, or cancellation notice window; the pricing URL itself returns 404. https://www.urbanpiper.com/ · retrieved 2026-08-01

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

This is the strongest form of the claim: UrbanPiper takes no processing position at all, so there is nothing to lock. The operator brings their own gateway account -- 'You can configure payment gateways on Meraki to enable online payments for your customers'; configuration is Atlas > Meraki > Payments > Add Gateway, where 'Each gateway requires specific credentials (e.g., API Key, Secret Key, Merchant ID). You can obtain these from your payment gateway provider's dashboard.' Twelve gateways are published as a region matrix across India, MENA, KSA, UK, LATAM and USCAN: RAZORPAY, PAYMENTOS, PHONEPE, INSTAMOJO, PAYSTACK, PAYTABS, STRIPE, PAYTMBLINK, PAYTABS_V2, PAYULATINAMERICA, MERCADOPAGO and FREEDOMPAY, configurable 'globally for all outlets, or per outlet if needed'. The legal documents corroborate that no in-house processing exists: 'We do not store, retain or process Your credit card or other payment information' (customer terms cl. 1.1) and 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS)' (privacy policy s.9). On marketplace orders the aggregator collects. No UrbanPiper merchant-acquiring product appears anywhere in 203 pages of documentation or in the Merchant Agreement's Charges and Payment clause, which prices subscription fees only. https://help.urbanpiper.com/direct-ordering/configuring-payment-gateway · retrieved 2026-09-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

The vendor sells no card processing, so it publishes no processing rate of any structure -- interchange-plus or blended. Affirmatively stated: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki' (privacy policy s.9, updated 11 Aug 2026), and 'We do not store, retain or process Your credit card or other payment information' (customer terms cl. 1.1). The operator supplies their own gateway credentials in Atlas and contracts the rate with that gateway directly (help.urbanpiper.com/direct-ordering/configuring-payment-gateway). Consistent with that, no basis-point figure, per-transaction figure or discount rate appears anywhere in the 116-page help centre, the 87-page API reference or the four legal pages; the Merchant Agreement's Charges and Payment clause 7 locates every fee in a private Order Form and describes subscription fees only, the sole percentage in the document being late-payment interest at 1.5% per month. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-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

Scored against the nearest thing this vendor has: there is no processing agreement at all, since merchants bring their own gateway and UrbanPiper states it does not process card payments, so the subject is the software subscription. The agreement does constrain price changes, in one region block: 'We may on a mutually agreed basis change prices at any time' (cl. 7.10, headed 'Applicable for the Merchants in USA, LATAM and other applicable regions'), which is a mutual-consent formulation rather than a unilateral right; and exit is always available without cause on one month's notice (cl. 8.2), which is the escape route the claim's second limb contemplates. SHORTFALL on every other element: no cap, index or percentage limit is stated; that mutual-agreement sentence is expressly scoped to one set of regions and no equivalent appears for India, MENA or the UK; nothing addresses pass-through interchange or network fees, because the vendor has no processing position to pass them through; cl. 16.2 lets UrbanPiper amend the agreement itself unilaterally on ten days' notice with continued use deemed acceptance; and the exit is not penalty-free in substance, since cl. 7.3 makes all fees non-refundable 'for partial use or non-use of the Services' and annual subscriptions auto-renew (cl. 7.9). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

The published /pricing page returns HTTP 404 and no dollar figures appear anywhere on the site; quote-only. https://www.urbanpiper.com/ · retrieved 2026-08-01

Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator

commercial-module-unbundling

www.urbanpiper.com March 2024 product-update post (grade C, vendor blog), read 2026-09-12. MET in part (modules sold on top of a base plan): QR Code Ordering is described as 'This is an add-on feature for your existing plan', with pricing and activation through the team ('To learn more about pricing and how you can activate'). The same post says 'Our Loyalty Module is a powerful add-on for Prime POS'. The January 2024 post (grade C) says Prime's Stock Automation Module is enabled on request to support. SHORTFALL: nothing says a module can be CANCELLED independently, or that adding or removing one leaves the base subscription price unchanged. No module price is published. The Merchant Agreement (already on record) scopes cancellation to the whole Account or a specific outlet, prices by live brand location, and defers all charges to a private Order Form. The UK free-trial pricing page lists plan units (integration type, locations, brands) and no module menu. Grade C only, so this is not a yes. changelog.urbanpiper.com is robots-barred and was not read. https://www.urbanpiper.com/blog/march-2024-product-updates-whats-new-in-our-restaurant-tech-platform · retrieved 2026-09-12

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

UrbanPiper sells no hardware, so no lease or rental is possible: the Compatible Hardware page publishes 'the minimum specification requirements for buying hardware to use UrbanPiper products' — commodity Android and iOS devices, receipt printers and laptops the operator sources independently. The shortfall against the claim's letter: there is no vendor-published price list and no first-party purchase channel, and no KDS hardware is specified at all. https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-08-04

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

The vendor publishes minimum specifications rather than a device list, which is the strongest form of this claim. "Please find below the minimum specification requirements for buying hardware to use UrbanPiper products", followed by RAM/storage/CPU/screen/OS tables for generic Android handhelds, phones, tablets and terminals (Android 9+) and for iOS phones and tablets, a laptop row reading "Google Chrome / latest / 13 inch or above", and a printer matrix listing the ESC/POS, STAR LINE and STAR GRAPHIC command modes over USB, Bluetooth, Ethernet, parallel and serial, in 58 mm, 80 mm and custom widths. The governing sentence is explicit that nothing is vendor-locked: "Any device that adheres to the Minimum Specification Requirements (MSR) will work fine with our products." The vendor even documents a certification path for a device it has not tested, needing "20-25 working days to complete the testing and provide certification." https://help.urbanpiper.com/basics/compatible-hardware · retrieved 2026-08-31

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

commercial-implementation-fee-published

Nothing is published, and the agreement says where the numbers live instead. 'All charges associated with Your Account and use of our services (Fees) and any other details about such Fees including payment specifics shall be mentioned in an Order Form' (cl. 7.1), and onboarding-adjacent services are routed the same way: 'At Your option, We may provide training to You and Your Users as a part of the Value Added Services. The charges for Value added Services shall be as set forth in the Order Form' (cl. 6). Order Forms are per-merchant and unpublished. On the public side there is no pricing page at all -- www.urbanpiper.com/pricing returns HTTP 404 and the site's own sitemap.xml lists no pricing, implementation or onboarding-fee page -- and no currency figure of any kind appears in the 116-page help centre. The only amounts UrbanPiper publishes anywhere are the returnable hardware deposits in cl. 8.7 ($350 printer, $150 tablet, $250 cellular modem), which are not implementation fees. No implementation, menu-build, onboarding or training fee is stated as an amount, and none is stated as $0. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-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

STRENGTHENED WITHIN THIS SESSION from a role-model inference to the article that documents the export itself, found on page 1 of a paginated llms-full.txt. Export is self-serve, unticketed and free so far as anything published says: "Navigate to the All Apps section and select Central Report", pick a report, "Choose a pre-defined time range (daily, yesterday's, this week's, monthly) or select a custom date", "Apply filters to sort by brand, location, or aggregator", then "click the download button to export it directly. You can download the report in either CSV or XLSX formats." Depth is real: orders at one row per order with payment mode and payment transaction ID, line items in the Item-wise report, modifiers in the Option-wise report, and a daily scheduled email. The role model corroborates that this is governed rather than absent -- "Non-HQ Report... Users cannot download reports that cover the entire business." SHORTFALL, and it is why this is not a `yes`: the claim asks for FULL transactional history including labour, and no labour data exists in this product at all -- there is no time clock, no hours and no payroll object anywhere in the help centre. No retention window is published either, so how much history a download can reach is undocumented. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-08-31

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

Guest identity is exportable as a by-product of order data; loyalty and gift-card balances are not exportable at all. What works: Central Report exports are self-serve and machine-readable -- pick a report, 'Choose a pre-defined time range... or select a custom date', 'click the download button to export it directly. You can download the report in either CSV or XLSX formats' -- and the Order Transactions Report carries Customer Name and Customer ID columns per order. The contract backs the general right: 'You will have access to the dashboards of the Services and all the Customer Data or order-related data which can be downloaded from the Services. In the event You require such data in a format which is not available, a request can be made to Us' (Merchant Agreement cl. 10.1). SHORTFALL, and it is threefold. The published report catalogue is eight reports -- order transactions, order status transitions, item-wise, items summary across locations, option-wise, menu snapshot across locations and store action -- and not one is a customer list, so there is no guest-record export as such, only orders that happen to carry two customer columns. No loyalty point ledger or balance export exists anywhere: the only loyalty balance in the documentation is a campaign merge field, '{{user_points}} -- Shows the customer's current loyalty points balance', with no report behind it. And gift cards do not exist in this product at all -- the string occurs zero times in 116 help pages and 87 API pages -- so no gift-card liability balance can be exported. Reach is capped as well: cl. 10.2 warns 'data preceding more than one (1) year may not be available for some data sets', released at the vendor's discretion 'subject to a reasonable fee'. https://help.urbanpiper.com/data-and-reports/getting-started · retrieved 2026-09-01

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

A defined window is documented, and the same article contradicts it, so the cell records both. Portal access outlives the cancellation date by a stated period: "A week after the cancellation date, you won't be able to access your portal any longer", and the request itself is reversible up to that point -- "you can always Withdraw your request by going to same place you went to cancel your subscription." That is a defined number of days rather than an immediate cutoff, which is what the claim asks. SHORTFALL: the warning at the top of the same article says the opposite about the DATA -- "Download any reports or data you need from UrbanPiper before your subscription ends, as your data will be permanently removed after cancellation" -- so the operator is told both that access persists for a week and that the data is already gone. No retention period, export format, bulk export mechanism or API is named, and the documented exit path for the data is manual report downloads before the end date. https://help.urbanpiper.com/business-manager/cancel-your-subscription · retrieved 2026-08-31

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

Both limbs are stated expressly in the published Merchant Agreement. Ownership, cl. 4.2: 'You own the rights to the Customer Data that You provide to Us. We do not claim ownership over such Customer Data. You hereby grant Us a royalty-free licence and right to use Customer Data solely to provide, support, maintain and improve the Services.' Customer Data is defined broadly enough to cover the claim's subject matter -- 'all electronic data, text, messages, personal data or other materials, including without limitation Personal Data of Users and Customers, submitted to the Services'. The constraint on vendor use is the word 'solely' in that licence, reinforced by cl. 9.4 ('We shall Process Customer Data only to provide, maintain and improve the Services, or prevent or address any technical problems, or at Your request in connection with support requests') and by the controller/processor allocation in cl. 9.6 ('We shall Process any Personal Data only on Your behalf and as Your data processor and that You are deemed to be the data controller'). The carve-out is exactly the one the claim permits and it is fenced: aggregated data 'which does not identify Your Users, Customers or any other identifiable individual' may be used for any lawful purpose (cl. 9.10), and cl. 4.5(a) adds 'UrbanPiper will only disclose aggregate/anonymous Data externally in a de-identified (anonymous) form that does not identify Merchant or its customers, and that is stripped of all persistent identifiers.' The privacy policy adds 'We do not sell Your Personal Data for money.' The two extractions outside guest data are disclosed rather than hidden: feedback assignment (cl. 4.3) and a logo and case-study publicity licence (cl. 16.7). https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-01

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

The licence is the opposite of source-available and self-hosting is excluded by the grant itself. The merchant receives only 'the limited, non-exclusive, non transferable, revocable right to access and use the Services for Your internal business purposes' during the subscription term (cl. 1.1), and cl. 2.2(a)-(b) forbids exactly what a source-available licence permits: the merchant may not 'license, sublicense, sell, resell, rent, lease, transfer, assign, distribute, timeshare disassemble, reverse engineer, decompile or make the Services available to any third party', nor 'modify, adapt, or hack the Services'. Clause 4.1 reserves everything: 'all rights, title and interest in and to all intellectual property... including patents, inventions, copyrights, trademarks, domain names, trade secrets, know-how Code, visual interface, graphic designs, user interface, user experience, associated with the Service shall belong to and remain exclusively with Us', and cl. 4.4 adds 'All rights not expressly provided to You herein are reserved by Us.' The deployment is vendor-hosted SaaS: 'UrbanPiper's production environment is hosted on Amazon Web Services' (DPA Schedule B), and Prime Web 'runs entirely in your browser' with 'no additional installation'. No repository, licence file, self-hosting guide or distributable component appears in the 116-page help centre or the 87-page API reference. https://www.urbanpiper.com/legal/merchant-agreement · retrieved 2026-09-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

There is no card-entry surface to encrypt and no SAQ is named anywhere. The vendor states it handles no card data: 'card and payment details are handled only by payment processors that are certified as compliant with the Payment Card Industry Data Security Standard (PCI-DSS). We do not store full payment card numbers, and We do not store any card or payment identifiers collected through Meraki' (privacy policy s.9, updated 11 Aug 2026), and the customer terms put it flatly -- 'We do not store, retain or process Your credit card or other payment information' (cl. 1.1). Payments on the vendor's own channel are online gateway transactions against credentials the operator supplies (Atlas > Meraki > Payments), and marketplace orders are collected by the aggregator; basics/compatible-hardware specifies only Android and iOS devices, receipt printers and a Chrome laptop, with no PIN pad, card reader or encrypting terminal in the matrix. Consequently no validated P2PE solution or listing, no hardware-encrypted entry path, no tokenization service and no SAQ type -- A, A-EP or P2PE-HW -- appears in the 116-page help centre, the 87-page API reference, the Merchant Agreement, the DPA (including its Schedule B technical measures) or the privacy policy. The string PCI occurs once on any first-party surface, in the sentence quoted above, and it assigns the obligation to someone else. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

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

Neither limb is documented, and the vendor's own security enumerations are where they would be. The DPA's Schedule B is the SCC annex whose explanatory note requires measures to be described 'in specific (and not generic) terms'; it details encryption ('AES-256, applied at the storage layer across databases, object storage and backups, with encryption keys managed through AWS Key Management Service', 'TLS v1.2 or higher'), availability zones, VAPT audits and centralised log retention -- and mentions no multi-factor authentication at all, for a cardholder data environment or otherwise. The privacy policy's security section lists 'encryption of Personal Data in transit and at rest, role-based access controls, network and infrastructure protection, regular security testing, and confidentiality obligations on Our personnel', again without MFA, and names ISO/IEC 27001 and SOC 2 as the programme's frames rather than PCI DSS. Nothing anywhere addresses payment-page script integrity, Requirement 6.4.3 or 11.6.1, or tamper detection for the hosted Meraki checkout. The string PCI appears exactly once across all first-party surfaces, assigning compliance to third-party processors, and the vendor states it holds no card data around which to define a CDE. No PCI DSS version, requirement number or future-dated control is documented in 203 documentation pages or four legal pages. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-01

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

Stated verbatim, including the on-request-under-confidentiality mechanism the claim asks for. Privacy policy section 9 (Effective 14 Mar 2023, last updated 11 Aug 2026): 'We maintain an information security programme aligned to recognised standards and hold ISO/IEC 27001 certification and a SOC 2 attestation, and We operate a data protection programme designed to meet the requirements of the EU and UK General Data Protection Regulation (GDPR). The scope and currency of Our certifications, and copies of relevant reports, are available to Merchants on request through (by contacting Us at the details in the Contact section) subject to appropriate confidentiality undertakings.' That is a present-tense assertion of a current ISO/IEC 27001 certification -- which satisfies the claim's disjunction on its own -- plus a SOC 2 attestation, and an undertaking to hand over the reports under confidentiality. Corroborating detail rather than marketing: the DPA grants audit rights over 'the TOMs (including data Processing systems, policies, procedures and records)' and its Schedule B names specific controls (AES-256 at rest with AWS KMS, TLS v1.2+, multi-AZ infrastructure, VAPT). Recorded limits: the SOC 2 is not stated to be Type II rather than Type I, no report date, auditor or scope boundary is published, and there is no trust portal to self-serve them -- www.urbanpiper.com/security, /trust and /compliance all return HTTP 404 and trust.urbanpiper.com does not resolve. https://www.urbanpiper.com/legal/privacy-policy · retrieved 2026-09-01

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

The paper half is fully met and the product half is absent. A DPA is published and executable rather than available on request -- www.urbanpiper.com/legal/data-processing-agreement, incorporated by Merchant Agreement cl. 9.5, carrying the EU SCCs (Modules 2 and 3), the UK Addendum, Swiss variations, a sub-processor change process with fifteen days' notice and an objection right, a 48-hour breach-notification commitment and audit rights. Data-subject requests are addressed contractually: 'In case the Merchant receives any request or communication from Data Subjects which relate to the Processing of Personal Data (Request), UrbanPiper shall reasonably provide the Merchant with full cooperation, information and assistance in relation to any Request', with identification within a stated number of business days; the privacy policy commits to access, correction, deletion and erasure, objection, restriction and portability rights exercisable at infosec@urbanpiper.com and names CCPA/CPRA plus the Virginia, Colorado, Connecticut, Utah and Texas regimes. SHORTFALL: none of that is in-app tooling. Across the 116-page help centre there is no guest-lookup, guest-export or guest-delete function -- no article documents locating an individual customer's records, exporting them or deleting them, and the eight published reports are order-level with no per-guest erasure action; the Atlas surfaces documented for customer data are campaign segments and order reports. The mechanism is an email to the vendor, and the DPA makes it chargeable: UrbanPiper may levy 'reasonable charges for providing the assistance... to the extent that such assistance cannot be reasonably accommodated within the normal provision of the Services'. https://www.urbanpiper.com/legal/data-processing-agreement · retrieved 2026-09-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

No accessibility conformance report exists on any first-party surface, and there is no kiosk product for the claim's second limb. Checked, all on 2026-09-01: www.urbanpiper.com/sitemap.xml, which lists the marketing, blog, product and legal trees and enumerates exactly four legal pages (privacy-policy, customer-terms-and-conditions, data-processing-agreement, merchant-agreement) with no accessibility statement among them; www.urbanpiper.com/accessibility and /legal/accessibility, both HTTP 404 on a host whose 404s are genuine; the 116-page help centre and 87-page POS-partner API reference, in which WCAG, VPAT, ACR, 'accessibility conformance' and 'screen reader' occur zero times ('accessible' appears twice, once about a GitBook docs site and once about Prime Web being reachable from Atlas); and all four legal pages, which contain no accessibility clause. The kiosk limb has no subject at all: 'kiosk' occurs zero times across both corpora, and the vendor's published product set is Hub, Meraki and Orderline AI -- middleware, a self-branded consumer ordering site and app, and a voice agent -- with no self-order kiosk and therefore no tactile or audio non-visual access mode to document. https://www.urbanpiper.com/sitemap.xml · retrieved 2026-09-01

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

The charge configuration screen is the entire configurable surface for adding money to an order, and it has no payment-method dimension. Creating a charge in Atlas (Catalog > Charges > Add Charge) offers exactly three applicable modes, enumerated in the article: 'Item Quantity: Based on the quantity of items ordered by the customer. Order Subtotal: Based on the order-level packaging charges. Item Price: Option to include a percentage-based packaging charge for the items', after which the operator sets an amount and scopes it to item groups and location groups. There is no condition on tender type, card brand, debit versus credit, or prepaid status, and no automatic exclusion mechanism could be built from those three modes. The payment side is equally flat: Atlas > Meraki > Payments lets the operator 'Enable/disable the methods you want to accept' (online payments, COD, wallets or loyalty points) with no per-method pricing. The word surcharge appears once in the corpus, as a pass-through charge item to be created in a POS back office for aggregator-originated charges (Lightspeed K-Series guide), and 'Cash Discount' appears only as a Meraki coupon type -- 'Applies a fixed amount discount on the order subtotal', targeted by customer group and explicitly 'not item-specific' -- which is a promotional discount, not a tender-based dual price. No receipt or menu-board fee-disclosure feature is documented anywhere. https://help.urbanpiper.com/business-manager/creating-a-menu/create-and-manage-charges · retrieved 2026-09-01