Flipdish

order-capture-floor-plan-editor

Two passes on the permitted host. Pass 1 read the 99-page v3.0 developer dump (.cache/flipdish/developers.txt, pulled via https://developers.flipdish.com/llms.txt): the hierarchy is org -> brand -> property -> sales channel and the only table concept is dineIn.tableId, a free-text string on a sale. Pass 2 on 2026-08-09 read the much larger v1.0 reference (1,064 pages, .cache/flipdish/developers-v1.txt, pulled via https://developers.flipdish.com/v1.0/llms.txt). v1.0 does model in-venue seating, but as a flat list: an order carries DropOffLocationId and DropOffLocation ('Represents table service drop off location') plus an OrderDropOffLocation object of exactly {OrderId, LocationId, LocationAreaId}, with PickupLocationType TakeOut|TableService|DineIn and a closed TableServiceCatagory enum Generic|Villa|House|Room|Area|Table|ParkingBay|Gate|DriveThrough|Team (/v1.0/reference/getorderbyid). Nothing carries a shape, capacity, coordinate, layout version or server assignment - the only spatial data anywhere in 27.6MB is DeliveryZone.WellKnownText, a delivery polygon. Grep for floor, section, seatmap and layout across both corpora returns nothing. That is evidence about the API surface only: a graphical editor with saved layouts and server sections lives in the merchant portal, documented on help.flipdish.com, which is excluded from this sweep by policy (its robots.txt carries User-agent: ClaudeBot / Disallow: / and Content-Signal: ai-train=no). Unresolved.

order-capture-seat-level

Checked both API versions on developers.flipdish.com on 2026-08-09. In v3.0 (/docs/sales-management-api) the dineIn object is exactly tableId (free text) and guests (integer), and items[] is menuItemId, quantity, unitPrice, notes and modifierItems. Pass 2 read the 1,064-page v1.0 reference (.cache/flipdish/developers-v1.txt): the OrderItem schema is enumerated as OrderItemOptions[], Metadata, MenuItemPublicId, MenuSectionName, MenuSectionDisplayOrder, Name, Description and Price, with no seat, cover, guest-position or per-line owner attribute, and the only seating field on the order (DropOffLocationId / OrderDropOffLocation {OrderId, LocationId, LocationAreaId}) is per order, not per line (/v1.0/reference/getorderbyid). Grep for 'seat' across all 27.6MB of v1.0 plus the 4.6MB v3.0 dump returns zero hits. So no seat number can round-trip through either public API. That constrains integrators only; tagging a line to a seat at entry and splitting by seat afterward are POS UI operations documented in help.flipdish.com, which is excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-coursing-hold-fire

Checked both API versions on developers.flipdish.com on 2026-08-09. v3.0 publishes eight whole-sale statuses (SALE_CREATED, SALE_ACCEPTED, SALE_PREPARED_BY_KITCHEN, SALE_DISPATCHED, SALE_ON_THE_WAY, SALE_DELIVERED, SALE_REJECTED, SALE_CANCELLED) with no per-line state. Pass 2 found that the older v1.0 surface goes further and exposes a configurable order state machine at /api/v1.0/{appId}/fulfillment/configuration/states, where each FulfillmentStatusItem carries StatusId, Name, IsEnabled, IsInternalState, IsCustom, a list of statuses it can move to ('can be back or forth'), a default next status, ChangeType Manual|Automated|Integrated, and OrderTypes drawn from All|Delivery|Collection|DineIn (/v1.0/reference/getfulfillmentstatesconfigurationtemplate). Every state in that machine is order-level; there is no course, seat, hold or per-line state anywhere, and grep for 'course' across the 27.6MB v1.0 corpus returns zero hits. Assigning items to courses and firing a course from a handheld is a till-and-KDS workflow documented in help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-split-merge

Checked both API versions on developers.flipdish.com on 2026-08-09. In v3.0 the sale surface is create, cancel and query only, cancellation is documented as final, and discounts are explicitly sale-level ('there is no per-line discount'). Pass 2 read the 1,064-page v1.0 reference: its order operations are GET /api/v1.0/orders, GET /api/v1.0/orders/{id}, accept, reject, dispatch and refund, with no split, merge, transfer or re-open verb, and grep for 'split' and 'merge' across 27.6MB returns zero hits. The nearest construct, /api/v1.0/stores/{storeId}/order-batching-configuration, groups whole orders together for dispatch rather than dividing one. Neither version has an open-check, tab or ticket entity that could be split by item, seat, N-way or amount, or merged after partial payment. Splitting and merging checks are POS UI operations documented in help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-bar-tab-preauth differentiator

Checked both API versions on developers.flipdish.com on 2026-08-09. In v3.0 a payments[] line is type, paymentMethod (Cash|Credit|Online|PhonePayment|ExternalPayment), amount, paidAt and two description fields. Pass 2 read the 1,064-page v1.0 reference and found the payment surface there is a closed PaymentAccountType enum - Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken - plus Stripe-backed card-present plumbing (/api/v1.0/{appId}/stripeterminal/connectiontoken, /api/v1.0/{appId}/payments/terminals/stripe/register, /api/v1.0/payment_intents/{paymentIntentId}). Stripe itself supports incremental authorisation, but no Flipdish endpoint in either version exposes an authorisation/capture split, a pre-auth amount, an incremental re-auth call, an open-tab entity or an end-of-day stale-tab close, and grep for 'preauth' and 'pre-auth' across 27.6MB returns zero hits. Bar-tab pre-auth is a till workflow documented in help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-transfer-audit

Re-read the whole audit-log surface across both API versions on developers.flipdish.com on 2026-08-09. v3.0 offers only POST /auditlogs/orgs/{orgId}, 'Publish an audit log entry'. Pass 2 found v1.0 carries two more, both also write-only: POST /api/v1.0/auditlogs/orders/{orderId} (AddOrderAuditLog) and POST /api/v1.0/auditlogs/stores/{storeId} (AddStoreAuditLogEvent). Their payload is an ExternalStoreAuditLog - described as 'External event' - with ExternalCreateTime, StoreId, Description, Source ('Identifies the source of the log'), Version, DescriptionFormat/Fields/Id, Ref through Ref4, OrderId, Tags and FieldChanges[] of {Path, Name, Key, OldValue, NewValue}. That is an ingest channel for an integrating partner to push its own entries; across all 1,064 v1.0 pages there is no read endpoint for audit entries and no enumerated set of Flipdish's own audit event types, so the corpus cannot be used to show what Flipdish records. Separately, no transfer verb exists on an order in either version (accept, reject, dispatch, refund in v1.0; create, cancel, query in v3.0), and the v3 event catalogue - self-described as 'a catalog of every Flipdish Webhooks (v3) event type' - lists 13 menu, snooze and sale-lifecycle events with no server-to-server or table-to-table handover. The employee-facing transfer log would be in help.flipdish.com, excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-native-handheld

Verified verbatim: 'All-in-one device for taking orders and payments' with 'built-in payment terminal and printer', 'bring the ordering and payment experience directly to the customer', and a 'Tipping Prompt'. hardware-handheld-lte likewise verified: 'built-in SIM connectivity means it keeps working wherever you need it.' Confirmed no battery life, no drop/IP rating, no price and — notably — no offline capability claim, so the offline unknowns are correctly left open. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01 adversarially verified

order-capture-offline-order-entry

Positive absence, from the vendor's own FAQ as already recorded in this dossier: 'The Flipdish POS does not support an offline mode', with the only documented mitigation being 'setting up a backup hotspot network'. With no offline mode there is no offline order entry, no offline modifier application, no offline send-to-kitchen and no offline cash tender; and no offline feature matrix is published, since the vendor's answer is that the mode does not exist. Corroborating: the whole v3.0 API is cloud-only (all paths under api.flipdish.co, OAuth2 bearer, no local or sync endpoint) and www.flipdish.com/pos-system/order-management markets the POS as a cloud platform where orders 'appear instantly' in the KDS.

order-capture-qr-same-check differentiator

Checked both API versions on developers.flipdish.com on 2026-08-09. New in pass 2: the v1.0 Payout Report 3 detail schema breaks a store's revenue into named channel pairs - WebAndAppCash/WebAndAppCard, KioskCash/KioskCard, QropCash/QropCard, PosCard and PosCardOnFlipdishOrders (/v1.0/reference/getpayoutreport3details) - so QR order-and-pay ('Qrop') is a distinct revenue channel Flipdish accounts for separately, alongside www.flipdish.com/contactless-ordering-with-flipdish-qr-code-stickers and several blog posts on order-and-pay at table. What neither version provides is an open-check entity a QR order could join: v1.0 orders are created complete and then accepted, rejected, dispatched or refunded, and v3.0 sales are created complete with sale.updated.v1 (Beta) merely reporting material changes. The v3.0 sales-channel type enum is closed at eight values (POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo) with no QR channel. Whether QR items land on a server-opened check or as a separate ticket is exactly the in-product behaviour the product manual would state, and help.flipdish.com is excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-kiosk-first-party differentiator

First-party kiosks run the same online-ordering menu as Flipdish websites; accessibility is an aspiration (WCAG 2.1 AA / EAA) with no ACR and admitted gaps. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

order-capture-drive-thru

The v1.0 Order schema assigns a pickup point to each order: DropOffLocationId and DropOffLocation ('Represents table service drop off location'), an OrderDropOffLocation object of {OrderId, LocationId, LocationAreaId}, PickupLocationType TakeOut|TableService|DineIn, and a closed TableServiceCatagory enum of Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team. The receipt payload echoes it as TableServiceCategory plus PickupLocationOptionValue (/v1.0/reference/getreceipt). So a drive-through window or a numbered parking bay can be assigned to an order and printed - the pull-forward/parking-spot leg of the claim. Named shortfall: that is the whole of it. DeliveryType is a two-value enum (Delivery|Pickup), so there is no order-point / pay-window / pickup-window separation; nothing in the 1,064-page v1.0 reference or the 99-page v3.0 reference models a lane, a tandem-lane assignment or an order sequence, and no pull-forward action exists as an operation. Flipdish's own hardware page (www.flipdish.com/pos-system/hardware) lists no drive-thru peripheral. Scored on the API surface; the merchant manual (help.flipdish.com) is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getorderbyid · retrieved 2026-08-09

order-capture-drive-thru-timers

Checked both API versions on developers.flipdish.com on 2026-08-09. v3.0 publishes only whole-sale lifecycle timestamps (createdAt, dispatchTime, requestedFulfillmentTime, saleStatusUpdatedTime). Pass 2 read the 1,064-page v1.0 reference: an order carries PlacedTime, RequestedForTime and AcceptedFor ('Time store has accepted the order for'), and fulfillment states change through a configurable machine, but there is no order-point, window or per-segment timer, and TableServiceCatagory 'DriveThrough' is a location label with no clock attached (/v1.0/reference/getorderbyid). The only aggregation endpoints are /api/v1.0/{appId}/apm/statistics/orders/{aggregateDataBy} and /apm/statistics/calendar, which count orders by period rather than timing service segments. www.flipdish.com/pos-system/reporting-and-analytics is marketing copy and names no drive-thru report. A speed-of-service report catalogue would live in the merchant portal, documented on help.flipdish.com, which is excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-voice-ai differentiator

Upheld on far better evidence than the researcher used. Citing https://www.flipdish.com/phone-agent-draft — a '-draft' slug — was a real sourcing failure. But the product is corroborated by a company newsroom release (GlobeNewswire, 19 Nov 2025, launched at Dished Live '25): 'available now for restaurant and takeaway operators in the UK, Ireland, and select international markets', answers calls, confirms modifiers and delivery details, upsells, 'takes secure payment during the call', integrates with Flipdish POS, kitchen printers and loyalty. Two caveats the dossier omits: it is geographically https://www.globenewswire.com/news-release/2025/11/19/3190837/0/en/flipdish-launches-ai-phone-agent-to-ensure-every-call-becomes-an-order.html · retrieved 2026-08-01 adversarially verified

order-capture-throttling differentiator

Partial: the documented load-management mechanism is snooze, not throttling. Flipdish exposes it in both directions - inbound events menu.item.snoozed.v1 / unsnoozed.v1 and sales_channel.snoozed.v1 / unsnoozed.v1 'with optional expiry', and outbound Operations Updates endpoints POST .../item-snooze-status and POST .../store-snooze-status whose only payload field is requestedStatus, 'Snooze or UnSnooze'. www.flipdish.com/pos-system/order-management markets the same thing: 'pause sales channels directly from the POS when things start heating up'. Named shortfalls: snooze is binary on/off per item or per sales channel, so there is no per-channel capacity limit, no per-time-slot order quota, and no automatic quote-time extension when kitchen load crosses a threshold - the corpus contains no capacity, throttle, quote-time or prep-time field anywhere, and requestedFulfillmentTime plus desiredAsap is the only fulfilment-timing input. Note the Operations Updates endpoints and v3 webhooks are in closed beta ('Email integrations@flipdish.com to request access'). https://developers.flipdish.com/docs/build-a-marketplace-integration.md · retrieved 2026-08-09

order-capture-scheduled-orders

Help Centre: scheduled/pre-orders sit in a Pending state and, with 'Automatically print KOT when an order becomes active' enabled, the Kitchen Order Ticket 'prints only when the order becomes Active' — the doc's own example is a 4:00 PM order for 6:00 PM delivery printing 'closer to the scheduled preparation time'. Pre-ordering is configured per channel with wholly independent collection and delivery settings — lead time, order interval, capacity limits, days-in-advance (e.g. 2 or 30) and an order cutoff time ('Configure Pre-Ordering', help article 9585385) — and POS lead times support per-dispatch-type, per-day/time overrides (article 9585541). Caveat: fire-at-time KOT printing is a setting, not the default; without it the KOT may print on receipt. https://help.flipdish.com/en/articles/13941944-automatically-print-kot-when-an-order-becomes-active-in-pos · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

order-capture-catering

Checked both API versions on developers.flipdish.com on 2026-08-09. Grep across the 99-page v3.0 dump and the 1,064-page v1.0 reference (27.6MB) returns zero hits for catering, quote and balance-due. The only 'deposit' in v1.0 is DepositReturnFee, defined on menu items and option-set items as 'An optional fee that can be added to the price of the item' - a container deposit-return-scheme charge, not an event deposit - and it has a matching DepositReturnFeesSummary on the receipt. The /api/v1.0/{appId}/invoices family (getinvoices, ListInvoices, ListSubscriptionInvoices, InvoicePdf) is Flipdish's own subscription billing to the merchant, not customer invoicing. Scheduling is limited to RequestedForTime plus an IsPreOrder flag and per-store lead times; there is no separate event schedule or catering queue. A distinct catering flow with quotes, deposits and balance tracking would be a merchant-portal feature documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

order-capture-order-ready-signal differentiator

The marketplace integration guide documents the exact signal: a marketplace subscribes to sales.pos.status.updated.v1, described as 'Kitchen / POS state changed (e.g. SALE_PREPARED_BY_KITCHEN)', and the worked payload carries orgId, propertyId, salesChannelId, saleId, the marketplace's own externalId and "status": "SALE_PREPARED_BY_KITCHEN". The testing section ties it explicitly to in-store state rather than a tablet tap: 'push a real sale ... and confirm you receive sales.created.v1 followed by sales.pos.status.updated.v1 as the merchant's POS / kitchen progresses'. The successor event sale.status.updated.v1 unifies POS and delivery status and carries the same SALE_PREPARED_BY_KITCHEN value for sales on any channel (/docs/sale-events). Caveats: DoorDash specifically is not a Flipdish marketplace channel - the sales-channel type enum names UberEats, JustEats and Deliveroo - and the newer sale.* family is in closed beta, while the sales.* family that carries this event is generally available but marked 'Deprecating soon'. https://developers.flipdish.com/docs/build-a-marketplace-integration.md · retrieved 2026-08-09

order-capture-void-comp-controls

Permissions gate who can 'give freebies or discounts'; reason codes and an exception report are not documented. https://www.flipdish.com/pos-system · retrieved 2026-08-01

menu-pricing-nested-modifiers

The published menu schema makes modifier nesting recursive and unbounded, with independent selection counts at each level. ModifierResponseSchema carries min ('The minimum number of items that can be selected'), max, canSameItemBeSelectedMultipleTimes and hiddenInOrderFlow; it extends ContainerResponseSchema whose items[] are CategoryItemResponseSchema, and those items themselves carry modifierMembers[], each with its own nullable min and max plus parentModifierId - so an item inside a modifier group can reference further modifier groups without limit. The docs say so outright: modifierItems allow 'any depth of nesting (e.g. a pizza item -> size modifier -> topping modifier -> extra-cheese modifier)' and 'Nested modifiers (recursive - same structure at any depth)', restated in prose in the Sales Management API guide as 'Items nest recursively ... so any depth of modifier ... is expressed as nested items'. Forced selection is expressed as min >= 1 rather than a separate boolean flag; this record's existing modifier evidence independently describes portal-side nesting ('nesting a new modifier inside a size option (Level 2)') and min/max controls. Note all Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

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

Positive absence: the AI Menu Editor modifier guide gives each modifier option a single price plus tax, and the pricing guide (article 14484417) varies prices only by dispatch type and price band — never by parent item or selected size. Reusing a modifier links it to another item with identical option prices, and the documented mechanisms for per-parent variation are 'Deep copy / Deep paste' of the whole modifier group or nesting a new modifier inside a size option (Level 2) — exactly the duplication the claim excludes. The enumerated 'Additional settings' (multiple selection, hide group in order flow, conditional modifiers) contain no price matrix. https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

menu-pricing-fractional-placement differentiator

Positive absence in the vendor's own menu model. The Menu Management schema gives a modifier member parentModifierId, caption, min, max, enabled and canSameItemBeSelectedMultipleTimes, and gives a modifier item pricingProfiles keyed by priceBandId with four dispatch-type prices - there is no placement, position, section, portion, half, quarter or fraction attribute anywhere, and the same is true of the sale line schema (menuItemId, quantity, unitPrice, notes, modifierItems), which the docs describe as the one PublicSale object used for creation, retrieval and webhooks. Flipdish's own canonical pizza example in the same docs is flat - 'a pizza item -> size modifier -> topping modifier -> extra-cheese modifier' - with no notion of which side a topping lands on, so a half-topping has nowhere to travel except the free-text notes field. This record independently carries menu-pricing-half-and-half-rule as a grade-B no from the vendor's modifier documentation ('No half-and-half pricing rules (charge higher, average, per-section) documented anywhere'). The only available construction is duplicated per-section modifier groups, which is the workaround this claim excludes. Hedge: Menu Management endpoints carry a Beta Notice, and the merchant-facing manual is excluded from this sweep by policy. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

menu-pricing-half-and-half-rule differentiator

Positive absence: Flipdish modifier system allows single price per option, per-dispatch-type variants only. No half-and-half pricing rules (charge higher, average, per-section) documented anywhere. https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

menu-pricing-topping-quantity-tiers

Positive absence: the modifier guide's enumerated settings offer only 'Enable multiple selection — allows customers to select the same option more than once', which is precisely the add-the-modifier-twice model this claim distinguishes from tiering. No light/regular/extra/double tiers and no per-tier price multiplier appear anywhere in the AI Menu Editor documentation; option pricing is a flat per-option price with per-dispatch-type variants only (article 14484417). https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

menu-pricing-size-style-matrix differentiator

Positive absence. In the published menu model an item's entire pricing surface is pricingProfiles[], and each profile is keyed by exactly one priceBandId and carries exactly four base prices - collectionPrice, deliveryPrice, dineInPrice, takeawayPrice - each with its own taxable/tax and upselling-points fields. The axes are therefore price band and dispatch type; there is no variant, option-set, matrix or grid construct, and no per-cell price override on a base item. Size and style are modelled as ordinary modifier groups whose options each carry their own flat price, so a Large-Thin cell cannot be priced independently of a Large-DeepPan cell except by building a second modifier group nested inside each size option - duplication, not a grid. This record independently carries menu-pricing-modifier-price-by-parent-size as a grade-B no from the vendor's own modifier and pricing guides, which 'var[y] prices only by dispatch type and price band - never by parent item or selected size' and whose enumerated additional settings 'contain no price matrix'. Hedge: Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

menu-pricing-included-allowance differentiator

Positive absence: the modifier guide's only quantity controls are minimum/maximum selection counts ('Minimum = least number of options a customer must pick'), and option pricing is a flat per-option price. No included-modifier allowance, first-N-free overage-only charging, or substitution credit/forbid configuration appears in the enumerated modifier settings (min/max, multiple selection, hide group, conditional modifiers) or in the pricing surface (base price, price by dispatch type, price bands — article 14484417). https://help.flipdish.com/en/articles/14484250-how-to-create-and-manage-modifiers-in-ai-menu-editor · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

menu-pricing-combos

The v1.0 Menu API builds meals out of option sets. A MenuItemOptionSet carries MinSelectCount ('Minimum items must be selected'), MaxSelectCount, DisplayOrder, and IsMasterOptionSet - documented verbatim as 'Usually it is true if the option could be considered a standalone item as opposed to an addition ("with ketchup") or modifier ("large")'. Each MenuItemOptionSetItem carries its own Price, its own TaxRateId/TaxValue, IsAvailable, and NextMenuItemOptionSetId ('if null, next option set is next. if -1, this is the final option set'), so an operator can compose a meal from standalone components and swap each one at its own price delta, in a defined sequence. Named shortfall: the second half of the claim has no representation at all. Neither the 1,064-page v1.0 reference nor the 99-page v3.0 Menu Management schema defines a combo, meal, bundle or set entity (a v3.0 menu is exactly categories[], modifiers[] and categoryGroups[], the latter documented as cosmetic UI grouping), and nothing expresses a cart rule. The v1.0 VoucherType enum is closed at PercentageDiscount, LumpDiscount, AddItem, CreditNote and FreeDelivery, and the v3.0 sale discount type enum at Voucher|Loyalty|Spot|Other applied sale-level only - so automatic detection of eligible a-la-carte items in the cart and conversion to a combo price is not a documented behaviour in either version. Scored on the API surface; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getmenuitemoptionsetbyid · retrieved 2026-08-09

menu-pricing-upsell-prompts differentiator

'Menu upsells automatically show your customers other popular items' on kiosk and online; no per-channel rule config or attach-rate reporting documented. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

menu-pricing-86-propagation

Menu Management API v3.0 (beta): POST /menuManagement/orgs/{orgId}/menus/{menuId}/snoozes snoozes an item or option with snoozeStart, snoozeEnd ('Time period of the snooze in seconds') and an optional propertyIds array - 'If omitted, the snooze applies to all properties using the menu'. The snooze is held on the menu, and a sales channel carries a required menuId, so one 86 reaches every channel bound to that menu; menu.item.snoozed.v1 and sales_channel.snoozed_menu_items.updated.v1 broadcast it to subscribers. No propagation latency is published anywhere in the v3.0 corpus, nothing states that KDS receives it, and the endpoint carries the standing 'Beta Notice: this endpoint is currently in beta and may change or be deprecated at any time without notice'. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_snoozes_12 · retrieved 2026-08-09 adversarially verified

menu-pricing-countdown-auto-86 differentiator

Vendor's own FAQ states the limitation: 'At this time, no, there is no notification when an item is almost out of stock. It is the responsibility of the admin to manage the inventory through the Flipdish Portal and send order requests to their suppliers as necessary.' 86ing is the manual Menu Snooze flow — snooze an item 'for a preset amount of time or leave it in Manual to snooze it indefinitely' (article 9585219). A timed un-snooze exists, but no per-item countdown/par count that decrements on sale and auto-86s at zero is documented anywhere in the menu or inventory docs. https://help.flipdish.com/en/articles/9585304-are-staff-notified-when-an-item-is-out-of-stock-or-almost-out-of-stock-when-using-the-flipdish-point-of-sale · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

menu-pricing-dayparting

Availability scheduling is real and precisely specified; price scheduling is not. Both CategoryItemResponseSchema and CategoryResponseSchema carry availabilityOverrides[], each override having name, enabled, mondayEnabled through sundayEnabled, fromTime and toTime (example '10:00'), plus optional scoping by dispatchTypes (DineIn|TakeAway|Collection|Delivery), propertyIds and venueCodes (Property|MobileApp|WebApp|Deliveroo|UberEats|JustEats|ExternalApp|Flipdish); the marketplace integration guide maps availabilityOverrides[] to 'Day-and-time availability rules'. Whole menus are scheduled a level up through opening-hours endpoints per property and per sales channel, and a property record carries an IANA timeZone (example 'Europe/Dublin'). Named shortfalls: (1) no price can be scheduled - an item's pricingProfiles are keyed by priceBandId with four fixed dispatch-type prices and carry no day, time or date dimension at all, so a timed price change means republishing the menu or reassigning the channel's price band; (2) the schema does not state which timezone fromTime/toTime are evaluated in, so the claim's 'in the location's own timezone' is documented for the property record but not for override evaluation. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

menu-pricing-channel-price-books

Menu Structure v3.0: 'Each item (CategoryItem or ModifierItem) can have multiple PricingProfiles, one per price band. Each profile defines separate prices for four dispatch types: Collection, Delivery, DineIn, and TakeAway.' Binding is per channel: the SalesChannel schema (GET /orgManagement/.../salesChannels/{id}) lists priceBandId and menuId as REQUIRED fields, and the channel type enum is POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - so each marketplace listing can be priced off its own band. Shortfall: prices are entered per item per band (the PriceBand object is only id/name/code/notes); no percentage-markup or derived-price rule appears anywhere in the v3.0 or v1.0 corpora, and the endpoints are beta. https://developers.flipdish.com/docs/menu-structure-v3 · retrieved 2026-08-09 adversarially verified

menu-pricing-dual-pricing differentiator

The documented pricing surface enumerates its dimensions and payment method is not among them: item prices vary by dispatch type and price band only (articles 14484417, 9585264), per-channel pricing is done by assigning separate menus per storefront (9585270), and the only documented order-fee mechanism is a per-sales-channel percentage service charge — 'Set a custom percentage, such as 5% or 12%', mandatory or optional (9585753). No cash/card price differential, cash-discount or surcharge configuration exists anywhere in the Help Centre, and the payment-types article lists methods with no price effect. https://help.flipdish.com/en/articles/9585753-configure-service-charges-in-the-flipdish-portal · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

menu-pricing-versioning-effective-dates differentiator

Menu Management API v3.0 (beta). Menus carry a revisionId 'incremented on each save'; GET /menus/{menuId}/revisions lists them and GET /revisions/{revisionId} returns any one, so a prior version can be inspected before use. Rollback after publish is supported by republishing an earlier revision: POST /menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to'. Shortfall: publishCheck ('Check if menu can be published') is a validation gate, not a rendered preview, and there is no effective-dating - grep of the entire v3.0 corpus returns no scheduled-publish, effective-date or go-live field on any menu endpoint. All Menu Management endpoints carry the beta notice. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_revisions__revisionid_publish_18 · retrieved 2026-08-09 adversarially verified

menu-pricing-franchise-hierarchy differentiator

Org Management API v3.0 (beta) models org -> brand -> property -> sales channel, and a menu is owned by the org and published downward: POST /menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to', and GET /menus/{menuId}/references returns 'all properties and sales channels referring to a menu'. Central-to-local propagation is expressed by SalesChannelHierarchy, type Primary|Linked, 'Indicates if the sales channel is dependent on another or if updates to this channel will impact other linked channels', with linkedSalesChannelIds / primarySalesChannelId. Shortfall: governance is all-or-nothing at the channel level. There is no field-level override policy - a location cannot be granted, say, price-only override rights; the only local variation documented is AvailabilityOverrides scoped by property, and those are authored inside the central menu, not by the location. https://developers.flipdish.com/reference/getsaleschannelbyid · retrieved 2026-08-09 adversarially verified

menu-pricing-allergen-nutrition

Allergen flags are a first-class per-item field; nutrition is entirely absent. BaseItemSchema - described in the spec as 'Base schema for an item, including visuals, allergens and availability' - carries allergens[] as a closed enum of 19 values: Alcohol, Mild Spice, Medium Spice, Hot Spice, Celery, Crustaceans, Egg, Fish, Gluten, Lupin, Milk, Molluscs, Mustard, Nuts, Peanuts, Sesame, Soybeans, Sulphur Dioxide, Wheat, plus a separate required boolean 'alcohol'. Because these ride on the menu object that menu.published.v1 delivers and that marketplaces are instructed to map onto their own listings, they do publish to online ordering and to third-party menus. Named shortfalls: (1) there is no nutrition field of any kind - no calories, energy, macronutrients or serving size anywhere in the item, modifier or menu schema, and the 99-page corpus has zero occurrences of 'nutrition'; (2) there is consequently no recipe-component linkage and no derived nutrition, because the menu model has no recipe or ingredient entity at all; (3) the allergen list is a fixed enum with no free-text or custom allergen, and three of its 19 values are spice-heat levels rather than allergens. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

menu-pricing-recipe-linkage differentiator

POS feature list includes 'Recipe builder', 'Inventory management' and 'Food sales and costs calculations'; depletion-on-sale and item-level theoretical cost are not explicitly documented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

menu-pricing-3p-menu-push

Menu synchronisation to Just Eat, Uber Eats and Deliveroo is claimed; API exposes menu publish-status updates and a menu.validation.failed webhook, but per-item marketplace rejection surfacing is not documented. https://www.flipdish.com/pos-system/order-management · retrieved 2026-08-01

menu-pricing-dynamic-pricing

Only the channel limb of this claim is met, and only statically. A SalesChannel record carries priceBandId as a required field (/reference/getsaleschannelsbyorgidandpropertyid), and every item pricingProfile is keyed by priceBandId, so the same item can carry a different price on the POS, kiosk, web app, mobile app and each marketplace; Flipdish exposes a GET price bands endpoint for an org, and the marketplace guide maps pricingProfiles[] to per-dispatch-type pricing. Named shortfalls: (1) a price band is a static price list, not a rule - there is no condition, trigger, schedule, date, day or time field on a pricing profile or a price band anywhere in the schema; (2) there is no demand, load, inventory or occupancy input to pricing anywhere in the corpus; (3) there are no floor or ceiling guardrail fields, so nothing bounds an automated change; (4) demand- and event-based pricing appears on the Flipdish Labs page only as an innovation the company is 'excited about', which is not evidence that it ships. Menu Management endpoints carry a Beta Notice. https://developers.flipdish.com/reference/get__menumanagement_orgs__orgid_menus_published_2 · retrieved 2026-08-09

payments-processor-choice differentiator

Positive absence. The vendor's own hardware FAQ answers the question directly: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The same page's neighbouring answers show the hardware flexibility on offer is about registers, printers and drawers ('Can I mix and match different hardware brands? Yes'), not about the acquirer. No list of supported processors or gateways is published anywhere on either permitted host: www.flipdish.com/integrations categorises partners as Point of Sale, Last mile delivery + Driver Management, and Other Integrations, with no payments category at all; the 99-page developer corpus names no gateway or processor (zero occurrences of Adyen, Worldpay, Stripe, Checkout.com, Braintree, Elavon or Global Payments) and the sale paymentMethod enum is a closed list of tender categories - Cash, Credit, Online, PhonePayment, ExternalPayment - naming no processor; and www.flipdish.com/pos-system/payments markets Flipdish Pay as 'one solution for online and in-store payments ... All under one roof. One brand. One support team.' The T&Cs reinforce it at clause 1.3, re-verified verbatim on 2026-08-09: 'You agree that we will be your exclusive provider of technological solutions similar or equivalent to any of the Services that you use.' The one qualification, from the same clause, is that a merchant is 'not restricted from using similar third-party offerings for components of the Services that you don't currently use' - so a stand-beside terminal from another acquirer is contractually permissible, but that is not integrated processor choice within the POS, which is what this claim asks about. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

payments-published-rates differentiator

Flipdish repeatedly asserts 'transparent transaction fees' / 'no hidden fees' but publishes no rate figure on any pricing page. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

payments-dual-pricing differentiator

Two exhaustive schemas settle this. (1) Price storage: in v1.0 a MenuItemOptionSetItem and a menu item each carry exactly one Price (plus an optional DepositReturnFee), and in v3.0 an item's whole price surface is pricingProfiles keyed by priceBandId with four dispatch-type prices. Price bands vary price by sales channel and dispatch type, never by tender; there is no cash price, card price or tender dimension in 27.6MB of v1.0 reference or the 99-page v3.0 dump. (2) Receipt: GetReceiptByOrderIdQueryResponse is enumerated as LogoUrl, Address, VatNumber, PaymentMethodDescription, TsOrderPlacedLocal, TsRequestedForLocal, DepositReturnFeesSummary and a PreviousOrder block of DeliveryType, PaymentAccountType, OrderId, LocalOrderId, CustomerName, Currency, ProcessingFee, ServiceChargePercentage, ServiceChargeAmount, TipAmount, DeliveryAmount, DepositReturnFeeAmount, TotalTax, TotalAmount, Items[] and TaxRates[] - one TotalAmount and one payment method, with no cash-total/card-total pair to print. What Flipdish does have is a tender-differentiated fee, not a second price: ProcessingFeeConfig sets PercentFee and FixedFee 'to customer' per store per PaymentAccountType (/v1.0/reference/getprocessingfeeconfigsbystoreidandpaymentaccounttype). Consistent with this record's earlier help-centre reading (2026-08-03, before the policy exclusion), which found payment types documented as cash, card and combinations only and price bands as per-sales-channel lists. Flipdish's core IE/UK/EU markets also restrict consumer-card surcharging. Scope caveat: the receipt schema above is the order receipt Flipdish itself renders; a POS printer template is not published. https://developers.flipdish.com/v1.0/reference/getreceipt · retrieved 2026-08-09

payments-surcharge-guardrails differentiator

The v1.0 API publishes a per-location, per-tender consumer fee. ProcessingFeeConfig is documented as {StoreId, PaymentAccountType, PercentFee 'Percent fee to customer, including VAT', FixedFee 'Fixed fee to customer, including VAT'}, readable at /api/v1.0/stores/{storeId}/processingfeeconfigs and /api/v1.0/stores/{storeId}/processingfeeconfigs/{paymentAccountType}. The order schema corroborates that the fee lands on the guest: ProcessingFee is 'the online ordering processing fee. For card payments this is charged directly to the customer and for cash orders it is paid by the customer to the store.' So a card fee exists, is charged to the cardholder, and is configured per location and per tender - the per-location enable/disable leg of the claim. Named shortfall: the guardrails are absent. PaymentAccountType is a closed ten-value enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) that treats every card as one type, so debit and prepaid cannot be distinguished, let alone excluded; grep across the 1,064-page v1.0 reference and the 99-page v3.0 dump returns zero BIN, card-product-code, debit or prepaid attribute; and there is no percentage-cap or network-limit field anywhere - nothing enforces a scheme cap. In v3.0 a surcharge could only be recorded as an untyped 'Other' charge (charges[] is Delivery|Service|Tip|Other). This record's earlier census of all 13 help-centre collections (2026-08-03, before the policy exclusion) found no surcharging article; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getprocessingfeeconfigsbystoreidandpaymentaccounttype · retrieved 2026-08-09

payments-emv-nfc

Kiosk card readers 'support a variety of payment cards and NFC-enabled device payments'; POS 'Accept contactless'. Apple Pay and Google Pay are not named, and no EMV/PTS device model is published. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

payments-softpos-tap-to-pay differentiator

Positive absence, from the vendor's own hardware FAQ: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The page enumerates the device catalogue - POS register with optional 10.1-inch customer-facing display, cash drawer, kitchen printer, wifi-connected card reader and card-reader mount, RFID card reader for staff login, and the K2, K2 Mini and D2S kiosks (each with its own built-in card reader) - and it contains no phone-based acceptance, no Tap to Pay on iPhone and no Android tap-to-pay. The handheld is sold as a device with a built-in payment terminal, i.e. dedicated acceptance hardware rather than software-only acceptance on a commodity phone, and /pos-system/payments markets contactless acceptance and custom-branded card readers in the same terms. Nothing in the 99-page developer corpus references a software point-of-sale, NFC acceptance or a mobile acceptance SDK. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

payments-pay-at-table

Handheld setup guide lists an 'NFC reader', 'Magnetic card reader' and built-in 80mm printer on the device, has the operator pair a 'Stripe Reader' credit-card terminal, and instructs 'Choose Card as the payment method. The card option should display a contactless icon.' Tipping is a documented POS prompt ('automatically prompt customers with a tipping option when they go to complete a transaction in store'). The dine-in tabs guide covers printing the bill at the table and 'Splitting the Bill (if necessary): If customers want to split the bill by items, click on the items in the payment summary.' https://help.flipdish.com/en/articles/11508326-getting-started-with-flipdish-handheld-pos · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-qr-guest-pay differentiator

Checked both API versions on developers.flipdish.com on 2026-08-09. New in pass 2: the v1.0 Payout Report 3 detail schema splits store revenue into WebAndAppCash/Card, KioskCash/Card, QropCash/QropCard and PosCard (/v1.0/reference/getpayoutreport3details), so QR order-and-pay is a channel Flipdish accounts for separately in cash and card - but those fields carry no descriptions in the OpenAPI definition and the abbreviation is not expanded anywhere in the 1,064-page corpus, so it cannot by itself establish the mechanism. What is absent in both versions is the object the claim needs: an unpaid open check that a guest payment could close. v1.0 orders are created complete and moved through accept/reject/dispatch/refund, with payment state exposed only as PaymentStatus and /api/v1.0/payments/payment/{orderId}/refundable; v3.0 sales are created with payments[] supplied, and an empty payments[] is documented simply as 'the sale is unpaid' with no settle endpoint. No pay-by-link, payment-request or scan-to-settle construct appears in either. On www.flipdish.com the QR material is white-paper and blog content, not product documentation. Scan-a-printed-check-and-settle is in-product behaviour documented on help.flipdish.com, excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

payments-tip-adjust

Shortfall: on-device prompt only, no tip adjustment after authorization. The POS tips article documents configuring the reader so staff 'automatically prompt customers with a tipping option when they go to complete a transaction in store', with fixed or percentage defaults, a 'Cut-off Bill Amount for Percentage', and a customer custom-amount option; it requires 'the Flipdish card payment reader'. No pre-auth-then-tip-adjust flow, no stated batch/adjust window, and no unadjusted-tip manager screen appears in the help centre - the only post-hoc tip surface documented is a read-only Tips Report. https://help.flipdish.com/en/articles/9704177-enable-and-configure-tips-on-your-flipdish-pos · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-tip-pooling differentiator

Positive absence, already established in this record at grade B: the Tips Report enumerates Flipdish's entire tip-reporting surface - total tips, delivery versus pick-up tips, refunded tips, tips per store, tips per week - all at store or channel level, with nothing per employee or per shift; the per-staff payroll breakdown enumerates gross/net wage, NI, HMRC contribution and PAYE with no tips line; and no tip-pooling, contribution or distribution feature appears anywhere in the censused help-centre title list or the 47-report catalogue. With no per-employee tip allocation there is nothing to export to payroll, and no distribution rule by hours worked, sales, role percentage or points is configurable. Independently checked on 2026-08-09: in the API a tip is only a charge of type 'Tip' on a sale, carrying amount and an optional itemId and no employee attribution field at all, so the platform's canonical sale object cannot carry a per-employee allocation either.

payments-offline-store-and-forward differentiator

Vendor FAQ: 'The Flipdish POS does not support an offline mode'. Store-and-forward requires offline capability which Flipdish lacks. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

payments-offline-decline-liability differentiator

Vendor FAQ states verbatim: 'The Flipdish POS does not support an offline mode', recommending 'setting up a backup hotspot network' for persistent connectivity issues. There is no store-and-forward payment capability at all, so no stored offline transactions exist to decline on reconnect, no liability allocation is published, and no post-reconnect failed-offline-payment report exists. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

payments-gift-cards

Checked both API versions on developers.flipdish.com on 2026-08-09. Grep for 'gift' across the 99-page v3.0 dump returns zero hits; across the 1,064-page v1.0 reference (27.6MB) it returns exactly sixteen, and every one is the same thing - 'GiftCard' as a member of the Flipdish App Store integration Categories enum (PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other). That is Flipdish classifying gift cards as a partner integration category, not shipping a first-party programme. Alongside it, both tender enums are closed and contain no stored-value type (v1.0 PaymentAccountType: Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken; v3.0 paymentMethod: Cash, Credit, Online, PhonePayment, ExternalPayment), and the v1.0 VoucherType enum is closed at PercentageDiscount, LumpDiscount, AddItem, CreditNote and FreeDelivery with no balance, expiry or remaining-value field. No issuance, redemption or balance ledger endpoint exists in 1,064 pages. This is short of positive absence for one specific reason: a merchant could sell a gift card as an ordinary menu item and redeem it as a 'CreditNote' voucher or an 'ExternalPayment', which would produce exactly this schema while a real programme ran in the portal. The 1,719-URL www sitemap has no gift-card product page (only a blog post) and /pos-system/payments does not mention them. help.flipdish.com is excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

payments-house-accounts

Checked both API versions on developers.flipdish.com on 2026-08-09. In v3.0 the sale customer object is documented exhaustively as id, externalId, name, contactPhoneNumber, contactMaskingCode and emailAddress - identity only. Pass 2 read the 1,064-page v1.0 reference: grep returns zero hits for credit limit and for statement; the CustomerSummary on an order is likewise identity-only; the PaymentAccountType enum is closed at ten payment instruments with no on-account or invoice tender; and the only invoicing endpoints, /api/v1.0/{appId}/invoices, /invoices/ListInvoices, /invoices/ListSubscriptionInvoices and /invoices/InvoicePdf, are Flipdish's own subscription billing to the merchant rather than merchant-to-guest statements. No accounts-receivable, running-balance or credit-limit entity appears anywhere. This falls short of positive absence because an on-account settlement could be recorded through v3.0's 'ExternalPayment' or 'PhonePayment' tender or simply left as an unpaid sale, so a portal-side house-account ledger would be invisible to both APIs. www.flipdish.com/pos-system/payments and /pos-system/reporting-and-analytics do not mention house accounts, and help.flipdish.com is excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

payments-split-tender

Multi-tender is representable, but only on an access-gated surface. The v3.0 PublicSale object -- which the docs state is the one schema used for the create request, every org-wide GET and the sale.* webhooks -- carries payments[] as an array in which each line has type (Sale|Refund), paymentMethod (Cash|Credit|Online|PhonePayment|ExternalPayment), amount, paidAt and two free-text description fields, with no documented maximum number of lines, so settling one sale with several tenders of arbitrary amounts is representable and there is no cap below eight ways. Availability: Sales Management carries the 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice', and the marketplace guide puts the Sales API in closed beta -- 'Email integrations@flipdish.com to request access and credentials' -- so this is a gated surface, not a shipped one. On the generally-available v1.0 API there is no payments array at all: an Order carries a single PaymentAccountType (e.g. Card) plus PaymentAccountDescription, so multi-tender is not expressible there. Named shortfalls: (1) split by seat cannot be expressed -- the dineIn object is documented exhaustively as tableId and guests, sale lines carry no seat attribute, and 'seat' appears zero times in the 27.6MB v1.0 corpus; (2) split by item cannot be expressed -- a payment line has no itemId and cannot be attributed to specific lines, and the docs state 'Discounts always apply at the sale level - there is no per-line discount'; (3) there is no even-N-way split construct, only free amounts; (4) this is a sale-recording schema, so it evidences that the platform stores multi-tender settlements, not that the till UI offers the four split modes the claim lists, and the till manual on help.flipdish.com is excluded by policy. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09 adversarially verified

payments-refund-void-controls

Flipdish's product feature list states 'Manager Approvals - Specify when your staff would need manager approval for actions like applying discounts or refunds' and 'Roles and Permissions - Assign custom roles to store staff ensuring they have the correct permissions'. That is a first-party feature page, not documentation: it names the approval gate but not what is recorded. The v3.0 API offers no support - /auditLogs/orgs/{orgId} is POST-only ('Publish an audit log entry to the Org audit trail'), a beta endpoint for an integrator to file its own {status,name,message,data} events, with no query endpoint and no approver identity field; v1.0 exposes /orders/{id}/refund with no documented role gate. Approver attribution on a void or refund, and immutability of the log, remain undocumented on any permitted host - the merchant manual is on help.flipdish.com, which robots.txt closes to us. https://www.flipdish.com/products-overview · retrieved 2026-08-09 adversarially verified

payments-chargeback-tooling differentiator

Shortfall: no in-product dispute dashboard or evidence-submission workflow. Flipdish's 'Manage Chargebacks' article documents that a chargeback deducts 'The order amount, and A chargeback fee (usually around $15/EUR15/GBP15)', that 'Once a chargeback is registered, Flipdish automatically blocks the customer from making future card payments on the platform', and that the merchant should 'Contact the customer directly' and 'Submit evidence... (e.g. order confirmation, delivery records, customer communication)' - but names no Portal screen for listing open disputes or uploading that evidence, and states 'the final decision is made by the issuing bank'. The marketing page's 'Dispute tools - Manage and resolve chargebacks quickly' is unsupported by any documentation. https://help.flipdish.com/en/articles/9585375-manage-chargebacks · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-card-on-file differentiator

Shortfall: online/app channels only - no phone-order or in-store reuse. Tokenization is explicit: 'Neither Flipdish nor the store you have ordered from have access to your debit/credit card details. These are stored securely by a third-party payment provider, Stripe, who then sends Flipdish a unique token which we use to charge the card.' Reuse spans the platform - 'if you consent to have your card details retained, they will be available when you place a digital order from a different store if it is also on the Flipdish Platform' - but only for digital orders. Phone orders are handled by a texted or emailed payment link the customer completes themselves ('Direct the customer to check their text message or email inbox'), not by charging a card on file, and no in-store POS card-on-file flow is documented. https://www.flipdish.com/consumer-information/card-details · retrieved 2026-08-08

payments-payout-timing differentiator

Schedule is published: 'Weekly payouts: Issued every Monday, or on Tuesday if Monday falls on a holiday. Covering sales from Monday through Sunday of the previous week' and 'Daily payouts: Issued each business day. Please note: This may incur an additional monthly charge.' Funds timing is stated too - 'Funds usually arrive in your bank account on the same day the payout is processed', with Ireland/UK bank processing given as 1-3 business days. The accelerated option is chargeable but offered. https://help.flipdish.com/en/articles/9585397-how-and-when-are-flipdish-payouts-issued · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

payments-multi-entity-routing differentiator

Three v1.0 endpoint families establish this. (1) Separate merchant accounts per location: GET /api/v1.0/{appId}/customconnect/{storeId} returns StripeCustomConnectedAccount, documented as 'Flipdish Stripe Custom Connected Account associated to the Store', carrying StoreId ('Physical Restaurant Id'), StripeId ('Stripe's own connected account identifier'), CardPaymentsStatus, TransfersStatus and AccountStatus - i.e. each store can hold its own acquiring account, with its own business type (/customconnect/bank-account/{bankAccountId}/businesstype), its own verification status and its own payout schedule (/customconnect/update-payout-schedule/{stripeConnectedAccountId}/{interval}). (2) Separate settlement destinations per location or legal entity: a BankAccountDetail carries AccountName, Iban, Swift, NationalClearingCode, BankCountryCode, AccountHolderAddress, AccountHolderCountryCode, VatNumber, CurrencyCode and a StoreIds[] array, and POST /api/v1.0/{appId}/bankaccounts/{bankAccountId}/store/{storeId} is literally 'AttachBankAccountToStore'. Distinct VAT numbers and account holders per bank account is exactly the separate-legal-entity case. (3) Unified reporting: GET /api/v1.0/{appId}/payouts queries payouts across the whole app with a payoutRequestIds.bankAccountIds filter ('List of bank account ids to search for'), GET /{appId}/payouts/summaries rolls them up, and Payout Report 3 gives per-payout overview, details and exports of orders, POS sales, chargebacks, refunded orders and ledger entries. One caveat recorded for the reader: this is the v1.0 surface, the older of Flipdish's two published API versions, and the v3.0 root index does not list bank-account or payout endpoints at all. https://developers.flipdish.com/v1.0/reference/getcustomconnect · retrieved 2026-08-09

payments-p2pe-pci4

Checked both permitted hosts on 2026-08-09, twice. www.flipdish.com/legal presents itself as the page that 'provides access to our terms, policies and regulatory compliance information' and links exactly five documents (Terms & Conditions, Privacy Policy, Cookie Policy, EU Digital Services Act, EU Accessibility Act); there is no attestation, P2PE listing, security or trust-centre page anywhere in the 1,719-URL sitemap, and the T&Cs (/docs-inner/tac-2) contain zero occurrences of PCI, P2PE or encryption. Grep for PCI and P2PE across the 99-page v3.0 dump and the 1,064-page v1.0 reference (27.6MB) returns zero hits in both. What pass 2 did establish is the architecture: card-present acceptance runs on Stripe Terminal - /api/v1.0/{appId}/stripeterminal/connectiontoken, /stripeterminal/location, POST /api/v1.0/{appId}/payments/terminals/stripe/register - with a closed reader DeviceType enum of CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3 and WISEPOS_E, all Stripe-supplied encrypted readers. That is a strong hint about where card data is protected but it is not an attestation and Flipdish makes no P2PE claim of its own. None of this settles the claim either way: a PCI DSS 4.x AoC is customarily furnished to merchants under NDA rather than published, a P2PE validation would appear on the PCI SSC listings registry (not checked in this sweep) rather than on the vendor's site, and the merchant-facing manual is help.flipdish.com, excluded by policy. Unresolved.

kitchen-station-routing

Verified verbatim, though weaker than the dossier's phrasing suggests: 'Prepare orders faster by sending them to different stations – if that's how you prefer to work.' The dossier also quotes 'Organise tickets by station and dispatch types', which I did not find on this page. One hedged marketing sentence supports the capability existing; no routing-rule configuration is documented. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01 adversarially verified

kitchen-expo-consolidation

KDS station profiles include 'Cook, Drinks, Fry, and Packing stations. The packing station is designated as the final step in the process, where orders are packed up for collection or delivery' (9585121); items bump per item from prep stations to the pack station or to dispatch (9585308), and KDS/station tags route items and modifier options to stations (15656778). Shortfall: no documentation states the order is only marked complete when every contributing station has bumped its items — the all-stations completion-gating half of the claim is undocumented. https://help.flipdish.com/en/articles/9585121-edit-kds-station-settings · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

kitchen-course-firing differentiator

Course assignment IS documented, refuting the earlier 'no course management' claim: KDS Course Tags are created in Portal > Sales Channels > Settings > Tags with 'a tag code which can be... starter, main course, drinks or dessert' and 'a number to highlight in which sequence the courses should appear', applied per item under Kitchen Operations, with a 'Display course name' toggle on the KDS and 'Ticket-specific printing... ensuring that items like appetizers, main courses, or desserts are printed on separate tickets'. Shortfall: the hold-and-fire half of the claim is absent — no hold or fire-on-demand action from a server terminal, handheld or expo screen appears anywhere (Help Centre searches for 'fire', 'hold' and 'coursing' on 2026-08-05 return only course-tag grouping/sequencing articles). Course grouping and sequencing without on-demand firing is partial, not no. https://help.flipdish.com/en/articles/9619311-apply-kds-course-tags-to-menu-items · retrieved 2026-08-05 · not refetchable · site policy · graded B when read adversarially verified

kitchen-prep-time-pacing differentiator

Checked both API versions on developers.flipdish.com on 2026-08-09. Pass 1 found no cook-time or prep-duration field in the v3.0 Menu Management or Sales Management schemas. Pass 2 read the 1,064-page v1.0 reference and found the only prep-duration construct in Flipdish's whole published surface is store-level, not item-level: GET/POST /api/v1.0/stores/{storeId}/leadTimes returns OrderLeadTimes, 'a mapping from the type of order to the default lead time that will be applied to those orders. The lead time is an integer number of minutes.' A menu item, an option set and an option-set item carry Price, tax, availability, display order and nutrition fields but no cook time, and no endpoint or event expresses a staggered item start. On www.flipdish.com the KDS page (/pos-system/kitchen-display-system) offers manual sequencing only ('Drag and drop tickets on the KDS to change their priority') plus a configurable 'order due time' in the ticket layout, which is a display setting. Per-item cook times and a finish-together algorithm would be KDS configuration documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-order-throttling differentiator

The v1.0 API publishes an order-capacity limiter per store. POST /api/v1.0/{appId}/storeordercapacity/{storeId} takes a StoreOrderCapacityConfigEditModel of OrderCapacityPeriods[], each a StoreOrderCapacityPeriod of {MaxOrderNumberPerStoreInterval, DayOfTheWeek, PeriodStartHour, PeriodStartMinutes, PeriodEndHour, PeriodEndMinutes}, and the schema explains it verbatim: 'The maximum number of orders per each store order interval in this order capacity period. E.g. for a period from 9:00 till 11:00, if the store's interval is 10 minutes, and MaxOrderNumberPerStoreInterval is set to 5, it means that within each 10-minute interval between 9:00 and 11:00 (i.e. 9:00-9:10, 9:10-9:20, .., 10:50-11:00) it will be possible to request at most 5 orders.' It is set separately per delivery type (Delivery|Pickup) and read back at GET /storeordercapacity/{storeId}/{deliveryType}. That is a configurable order-volume threshold that paces incoming digital orders per location. Named shortfall: it is a static weekly schedule, not a load-responsive rule. Nothing measures current kitchen load or ticket time and feeds it back - the trigger is the clock and a fixed count, never a ticket-time threshold - and crossing the cap blocks further slots rather than delaying release or extending the quoted prep time (lead times are a separate, fixed per-store default at /stores/{storeId}/leadTimes). Grep for throttle, pacing and capacity-by-load across both API versions returns nothing else; the only other load-shedding primitive is manual snoozing of an item or a channel. Scored on the API surface; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/updatestoreordercapacityconfig · retrieved 2026-08-09

kitchen-channel-pause-propagation differentiator

v3.0 marketplace guide, 'Item and store availability': 'When a merchant marks an item or sales channel as unavailable on the Flipdish portal' Flipdish fires menu.item.snoozed.v1 / menu.item.unsnoozed.v1 and sales_channel.snoozed.v1 / sales_channel.unsnoozed.v1, and the instruction to the integrator is 'Mirror these onto your marketplace listing'. Shortfall, twofold: the propagation step is delegated to the marketplace's own webhook consumer rather than performed by Flipdish, and the enumerated sales-channel types are POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - DoorDash and Grubhub appear nowhere in either corpus and would arrive only as a generic ExternalApp channel. Nothing documents a KDS-originated pause. Sales API, Operations Updates and v3 webhooks are all in closed beta ('Email integrations@flipdish.com to request access'). https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

kitchen-order-ready-callback differentiator

Correction to the earlier note, which claimed no page documents Flipdish propagating readiness back to a marketplace: the marketplace integration guide does exactly that. Its end-to-end diagram runs 'Flipdish --sales.created.v1 / sales.pos.status.updated.v1 / sales.delivery.status.updated.v1 / sales.cancelled.v1--> your platform' then 'Update marketplace order, dispatch driver', and it publishes the payload verbatim with '"eventType": "sales.pos.status.updated.v1"' and '"status": "SALE_PREPARED_BY_KITCHEN"'. Readiness is a modelled state: the sale lifecycle table lists SALE_PREPARED_BY_KITCHEN 'Kitchen has finished preparing the sale' between SALE_ACCEPTED and SALE_DISPATCHED. Named shortfalls, all about availability rather than modelling. (1) Neither carrier is on a shipped tier: sales.pos.status.updated.v1 is marked 'Deprecating soon' ('Do not build new integrations against sales.*'), and its replacement sale.status.updated.v1 is Beta and, per llms.txt, 'in closed beta -- request access by emailing integrations@flipdish.com'. (2) The callback goes to a subscriber endpoint the marketplace builds; no native Uber Eats / Deliveroo / Just Eat / DoorDash ready-callback connector is documented on either developer host. (3) On the generally-available v1.0 API the OrderState enum is exhaustive and contains no kitchen-prepared state at all -- Created, PlacedCanBeCancelled, ReadyToProcess, AcceptedByRestaurant, Dispatched, Delivered, Cancelled, ManualReview, RejectedByStore, RejectedByFlipdish, RejectedAutomatically, RejectedAfterBeingAccepted, AcceptedAndRefunded -- so readiness cannot be emitted from the shipped surface. (4) Whether the KDS bump is what sets the status is a portal-manual question and help.flipdish.com is excluded by policy. Also withdrawn: the earlier note leaned on the events (v3) catalogue as an exhaustive list; it is not, since sale.accepted.v1 is documented in the Sale webhook events guide and is absent from that catalogue. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

kitchen-bump-bar-hardware

Checked both permitted hosts on 2026-08-09. www.flipdish.com/pos-system/hardware names 15 model-specific devices - 15.6" TS2 POS register, 10.1" customer-facing display, 21.5" kitchen display screen, Sunmi 80mm kitchen cloud printer, Epson TM-20III (012A0) receipt printer, Brother QL-800 label printer, Sunmi barcode scanner, Artech caller ID, cash drawer, WisePOS E card reader and mount, RFID reader, K2 / K2 Mini / D2S kiosks - with no bump bar or programmable keypad among them, but it explicitly does not claim to be the complete supported list ('Complete your hardware setup with compatible devices'), so it cannot carry a no. Pass 2 checked whether the 1,064-page v1.0 reference supplies a device catalogue that would meet the enumeration bar: it does not. The only closed device-model enum in the whole corpus is the card-reader DeviceType - CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3, WISEPOS_E - which is Stripe Terminal's reader list, not a KDS peripheral list; the /devices, /kioskiot and /terminaliot families manage kiosk and terminal provisioning and connectivity (HydraDeviceStatus Online|PossiblyOffline|...), and carry no bump bar, keypad or input-peripheral type. www.flipdish.com/pos-system/kitchen-display-system describes interaction only as touch. A supported-peripherals article would sit in help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-all-day-counts

Checked both API versions and www on 2026-08-09. The v3.0 dump is order-level throughout. Pass 2 read the 1,064-page v1.0 reference: its aggregation endpoints are /api/v1.0/{appId}/apm/statistics, /apm/statistics/calendar and /apm/statistics/orders/{aggregateDataBy}, which roll orders up by time period, and nothing anywhere queries outstanding quantities per item or per modifier across open tickets on a station - there is no station entity in either version at all. That is expected of an ingest and notification API and says nothing about the KDS UI. www.flipdish.com/pos-system/kitchen-display-system enumerates six KDS capabilities (prep stations, colour-coded modifiers, drag-and-drop prioritisation, item label printing, customisable ticket layout, driver assignment from the ticket) and an all-day roll-up is not among them, but that page is marketing and does not claim to list every KDS view. The KDS manual is in help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-sla-alerts

'Customise your ticket layout, order due time, notifications and more'; no configurable per-station target time or colour-escalation detail published. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

kitchen-printer-fallback differentiator

The vendor's documented response to a failed receipt or KOT printer is a manual in-store troubleshooting guide — reboot, reseat cables, reselect the printer in POS settings, re-run the Configuration Wizard, update the printer IP in the Portal, then 'contact our support team and include your AnyDesk address' (9585705). The printer configuration surface (printers assigned per KDS station in 9585121; Portal > Devices > Receipt Printers) has no backup-printer or failover option, and the POS has no offline mode (9585187). No automatic failover, staff alert on printer loss, or ticket-preservation mechanism appears anywhere in the printer or KDS documentation. https://help.flipdish.com/en/articles/9585705-troubleshoot-pos-receipt-printer-and-kot · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

kitchen-offline-operation differentiator

KDS is cloud-based component. Vendor FAQ confirms no offline mode: 'The Flipdish POS does not support an offline mode.' KDS requires internet. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

kitchen-item-build-screens differentiator

'Items and ingredients that need to be added or removed are colour-coded and clearly visible' — full modifier breakout, but no recipe-step or portioning build screen. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

kitchen-pizza-fractional-display differentiator

Checked both API versions on developers.flipdish.com on 2026-08-09. v3.0 models modifiers purely as recursion ('a modifierItems[] entry has the exact same shape as its parent item, so any depth of modifier (e.g. pizza -> size -> topping -> extra-cheese) is expressed as nested items') with only menuItemId, quantity, unitPrice and free-text notes. Pass 2 read the v1.0 menu model in full: a MenuItemOptionSet is {MenuItemOptionSetId, PublicId, Name, IsMasterOptionSet, MinSelectCount, MaxSelectCount, DisplayOrder, CellLayoutType, ImageName/Url, CatalogItemId, MenuItemOptionSetItems[]} and an item within it is {Name, Price, DepositReturnFee, IsAvailable, DisplayOrder, CellLayoutType, TaxRate*, Metadata[], NextMenuItemOptionSetId, PublicId, ImageUrl} - no fraction, portion, placement, half, quarter or section attribute, and grep for those terms across 27.6MB returns nothing. So a topping cannot be tagged to a half over either public API and nothing sectioned could be transmitted to an integrated KDS or POS. That is evidence about the API surface only; whether Flipdish's own menu editor and KDS render sections internally would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). www.flipdish.com/pos-system/kitchen-display-system mentions only colour-coded added and removed ingredients. Unresolved.

kitchen-recall-refire

Checked both API versions and www on 2026-08-09. v3.0 publishes the sale lifecycle as a one-way flow (SALE_CREATED through SALE_DELIVERED, plus REJECTED and CANCELLED) with no reverse transition. Pass 2 found v1.0 is not one-way: /api/v1.0/{appId}/fulfillment/configuration/states defines a configurable state machine in which each status carries 'list of statuses that this status can move to (can be back or forth)', a ChangeType of Manual|Automated|Integrated, an IsInternalState flag and per-order-type applicability, with the current state readable and writable at GET/POST /api/v1.0/orders/{orderId}/fulfillment/state and an actions view at /fulfillment/state/details. So an order's state can be moved backwards by design. Two reasons that does not settle the claim: nothing in the corpus identifies that state machine with the KDS bump action, and there is no item-level operation of any kind - no refire, reprint or per-line status exists in either version, and the KDS marketing page (www.flipdish.com/pos-system/kitchen-display-system) lists drag-and-drop reprioritisation and per-item label printing but no recall or refire. Recall/unbump behaviour would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-order-modification-alerts differentiator

Checked both API versions and www on 2026-08-09. v3.0's events catalogue lists sale.updated.v1, firing when 'a sale ingested by Flipdish is materially updated (items, charges, or discounts changed)', but it is marked Beta and carries the whole sale payload rather than a diff. Pass 2 found v1.0 carries a genuine field-level change structure - AuditLogFieldChangeInformation of {Path (hierarchy), Name, Key, OldValue, NewValue} inside the ExternalStoreAuditLog posted to /api/v1.0/auditlogs/orders/{orderId} - so a diff shape exists in the platform. But that endpoint is write-only and is for a partner to push its own entries, and neither construct is a KDS behaviour: both are subscriber-facing. www.flipdish.com/pos-system/kitchen-display-system says items and ingredients 'that need to be added or removed are colour-coded and clearly visible', which describes modifier rendering on the original ticket, not a change highlight on a ticket already on screen. Whether the KDS flags a live edit is a product-manual question and help.flipdish.com is excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-guest-ready-notification differentiator

Digital signage for order collection is a listed POS feature and SMS/email receipts exist; an explicit bump-triggered guest notification is not documented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

kitchen-waste-logging

Checked both permitted hosts on 2026-08-09. www.flipdish.com/pos-system/reporting-and-analytics puts wastage in the COST MANAGEMENT block ('COGs, inventory, wastage, discrepancies, and profitability') and /docs/pos-features lists 'Inventory management' and 'Recipe builder', so a wastage figure clearly exists downstream - but neither page says where the entry is made, whether reason codes exist, or whether it depletes stock. Pass 2 grepped the 1,064-page v1.0 reference (27.6MB) for waste, spoilage, remake and shrink: zero hits, and the v1.0 resource list (bankaccounts, channels, stores, storegroups, orders, menus, vouchers, campaigns, teammates, webhooks, kiosk/terminal IoT, appstore, reporting/payouts and so on) contains no inventory, stock or recipe family at all - consistent with v3.0, whose scope is orgs, brands, properties, sales channels, menus, sales and webhooks. So neither published API surfaces inventory, and the capture screen and its reason codes would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-speed-of-service-reporting

Checked both API versions and www on 2026-08-09. The raw material exists over the API - v3.0's sale.status.updated.v1 carries saleStatusUpdatedTime for acceptance, kitchen preparation, dispatch and delivery, and v1.0 orders carry PlacedTime, RequestedForTime and AcceptedFor plus a configurable fulfillment state machine whose states can be flagged IncludeInReports - so a partner could derive stage times, but that is a build-it-yourself path rather than a report. Pass 2 checked v1.0's actual reporting family: /api/v1.0/{appId}/apm/statistics, /apm/statistics/calendar and /apm/statistics/orders/{aggregateDataBy} aggregate order counts by period, /reporting/reports/payouts3/... exports orders, POS sales, chargebacks, ledger entries and refunded orders per payout, and a /looker family exists - none of them expose a ticket-time, prep-time, station or percentile dimension, and there is no station entity in either version. www.flipdish.com/pos-system/reporting-and-analytics names only custom, real-time, multi-location, POS, sales and cost-management reports sliced by 'sales by channel, dispatch types, payment methods, sales by store'. A speed-of-service report could exist in the portal without appearing on either surface; help.flipdish.com is excluded by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

kitchen-prep-forecasting

Checked both permitted hosts on 2026-08-09. www.flipdish.com/docs/pos-features lists 'Smart sales forecasts' alongside 'Inventory management' and 'Recipe builder', and /pos-system/reporting-and-analytics covers COGs and inventory, but nothing on www turns a forecast into a predicted prep quantity or a daily prep task list for kitchen staff, and the KDS page lists no prep-list view. Pass 2 grepped the 1,064-page v1.0 reference (27.6MB) for forecast, prep list and predicted: zero hits, and v1.0 has no inventory, recipe or forecasting endpoint family - its aggregation surface is /apm/statistics/orders, which counts past orders. v3.0 likewise has none. Note that predictive prep appears on www.flipdish.com/us/labs as unshipped R&D ('Inventory automation: predictive ordering and waste management'), a roadmap page and not evidence of a shipped feature. The prep-list workflow, if it exists, would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

delivery-driver-roster

Drivers are first-class in the shipped v1.0 API, so the roster half is better attested than the marketing page allowed, but the surface is bounded and it is not a roster module. The app permission enumeration carries exactly five driver verbs - InviteDriverToApp, GetDriverForApp, RemoveDriverFromApp, AssignDriverToOrder, UnassignDriverFromOrder - plus UpdateOrdersDeliveryTrackingStatus, and the fields that travel with a driver anywhere in 27.6MB are DriverId, DriverName and DriverImage only. Assignment state is modelled per order as DeliveryTrackingStatus [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver] (/v1.0/reference/getorderbyid). Named shortfall: no clock-in/out (zero hits for ClockIn, shift or roster across the v1.0 dump), no driver shift or run-history entity, and no per-driver report - the index of 1,064 v1.0 pages contains no driver-scoped reporting endpoint at all. The previous note's marketing quotes are withdrawn as the basis; www.flipdish.com/pos-system/delivery-driver-tracking is a grade-C feature page and was cited at grade B. https://developers.flipdish.com/v1.0/reference/setappconfig · retrieved 2026-08-09 adversarially verified

delivery-dispatch-board

Assignment is documented in the shipped v1.0 API rather than only on a marketing page: an order carries DriverId ('Assigned driver identifier') and DeliveryTrackingStatus [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver], and AssignDriverToOrder / UnassignDriverFromOrder / UpdateOrdersDeliveryTrackingStatus are named permissions. The KDS feature page adds 'Assign orders to your delivery drivers at the touch of a button, right from your tickets' and 'Orders are grouped and auto-assigned to maximise efficiency'. Named shortfall: there is no dispatch or expo resource in the API - no queue of undispatched orders, no driver-availability collection, no elapsed-time field, and no run or batch object that groups two or more orders under one driver; the 1,064-page v1.0 index has no dispatch endpoint. Whether the merchant portal renders such a screen is documented on help.flipdish.com, which is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). https://developers.flipdish.com/v1.0/reference/getorderbyid · retrieved 2026-08-09 adversarially verified

delivery-route-map differentiator

Geocoded stop data and live courier position are real, but only on the third-party courier leg and with no sequencing. The v1.0 Stuart job resource (/api/v1.0/stuart/jobs/{jobId}) returns a JobDriver with Latitude and Longitude, a JobDeliveryDetail for both Pickup and Dropoff each carrying Latitude/Longitude and an address, a JobEta with Pickup and Dropoff times, and job-level Distance and Duration - that is a live, mappable position plus geocoded stops. Named shortfalls: (1) it is Stuart's courier job, not an in-house driver - the native customer-tracking payload (CustomerDeliveryTrackingOrder) carries the CUSTOMER's Latitude/Longitude with DriverId, DriverName and DriverImage but NO driver coordinates; (2) there is no route object and no sequencing anywhere - 'route' and 'optimi' are zero-hit across the whole 27.6MB v1.0 dump, and no waypoint or stop-order construct exists in either version; (3) whether the portal renders a map view at all is help.flipdish.com territory, excluded by policy. Marketing's 'monitor your riders' locations in real-time' (www.flipdish.com/pos-system/delivery-driver-tracking, grade C) is a claim about the integrated stack. https://developers.flipdish.com/v1.0/reference/stuart_getjob · retrieved 2026-08-09 adversarially verified

delivery-driver-tracking differentiator

Position tracking exists but is the courier partner's, not a Flipdish driver app. Positive evidence from the shipped v1.0 reference: the native customer delivery-tracking payload (CustomerDeliveryTrackingOrder) enumerates its fields as OrderId, Address, DeliveryNotes, StorePhoneNumber, AppIconUrl, OrderTrackingCode, payment fields, order lines, TotalAmount, Currency, Latitude and Longitude described as 'Customer Location Latitude/Longitude', Placed, RequestedFor, DriverId, DriverName, DriverImage and EstimatedMinutesForDelivery - the driver appears as an identity and a picture with NO coordinates. What Flipdish does hold natively is the assignment plus the eight-state DeliveryTrackingStatus lifecycle [Unassigned, Unaccepted, Accepted, Carrying, OnTheWay, ArrivedAtLocation, Delivered, CannotDeliver] (/v1.0/reference/getorderbyid). Driver GPS enters only through a courier partner: /api/v1.0/stuart/jobs/{jobId} returns a JobDriver with Latitude and Longitude, DisplayName, Phone, PictureUrl and TransportType, and Stuart is configured per store at /api/v1.0/stuart/settings/{storeId}. Named shortfall: no Flipdish-operated driver app position feed. The previous note's help.flipdish.com citation is withdrawn - that host disallows ClaudeBot by name and may not be used as evidence here. https://developers.flipdish.com/v1.0/reference/stuart_getjob · retrieved 2026-08-09 adversarially verified

delivery-zones-polygon differentiator

The shipped v1.0 API defines a delivery zone as arbitrary spatial geometry. GET/POST /api/v1.0/stores/{storeId}/deliveryzones returns a DeliveryZone whose WellKnownText property is described as 'Spatial data in Well Known Text format. We also support CIRCLE((0 0, 200)) - (centerLong centerLat, radius in m)', and the worked example is 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))' - an arbitrary five-vertex polygon, with the radius form offered as an additional option rather than the only one. Zones are full CRUD (AddDeliveryZone, UpdateDeliveryZone, RemoveDeliveryZone) and emit store.delivery_zone.created/updated/deleted webhooks. Drive-time isochrones are not supported ('isochrone' is zero-hit in both corpora), but the claim is satisfied by the polygon limb: areas are not restricted to a radius or a postcode list. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 adversarially verified

delivery-zone-pricing

Two of the three legs are documented at grade A and the third is positively absent. The DeliveryZone object (GET /api/v1.0/stores/{storeId}/deliveryzones) has exactly six properties - Id, FeeChargedToStore, DeliveryFee ('Delivery fee (will not be set below 0)'), MinimumDeliveryOrderAmount ('Minimum delivery order amount (will not be set below 0)'), WellKnownText and IsEnabled - so per-zone fee and per-zone order minimum are independently configurable, and a separate per-zone fee override exists at /api/v1.0/stores/{storeId}/feeConfig/deliveryZones (StoreDeliveryZoneFeeConfig = DeliveryZoneId + Fee). The order carries DeliveryFeeAreaId ('Delivery area identifier'), which is how the matched zone is applied. Named shortfall: there is no per-zone promise or prep time. The zone schema is closed and contains no time field; the only delivery time estimates in v1.0 are store- or integration-level (EstimatedMinutesForDelivery / EstimatedMinutesForCollection), never zone-level. Marketing's 'Set minimum order amounts and delivery charges for multiple areas' is consistent with this and says nothing about time. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 adversarially verified

delivery-address-validation

Spatial zone matching is documented at grade A, address validation as such is not. Delivery zones are stored as Well Known Text geometry (DeliveryZone.WellKnownText, 'POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))', with CIRCLE also supported) and the resulting zone is carried onto the order as DeliveryFeeAreaId ('Delivery area identifier'), so a checkout address must be resolved to a point and tested for containment for the right fee and minimum to apply. Named shortfalls: no mapping or geocoding provider is named anywhere and 'geocod' is zero-hit across both the 27.6MB v1.0 dump and the 99-page v3.0 dump, as are 'autocomplete' and any address-validation operation - there is no CanDeliver, IsDeliverable or ValidateAddress endpoint in the 1,064-page v1.0 index. Nothing states what happens to an address outside every zone. The API's address surface is formatting only: 'Get address templates' (POST /orgManagement/orgs/{orgId}/addresses/templates/query) returns per-country field layouts and is explicitly marked 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice', while the v3 sale's delivery.location carries 'Optional geographic coordinates for the drop-off point'. Consumer checkout behaviour is documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/getdeliveryzones · retrieved 2026-08-09 adversarially verified

delivery-driver-comp differentiator

Checked both API versions and www on 2026-08-09. Pass 2 established that drivers are real first-class entities in v1.0, but only as assignable people: the permission set is InviteDriverToApp, GetDriverForApp, RemoveDriverFromApp, AssignDriverToOrder and UnassignDriverFromOrder, and the fields that travel with them are DriverId, DriverName and DriverImage. Grep across the whole 27.6MB v1.0 reference returns zero hits for mileage, distance-per-run, reimbursement and driver pay, and no payroll, wage or labour-cost endpoint exists in either version; tips appear only as an order-level TipAmount and a v3.0 sale charge of type 'Tip', never attributed to a driver. Third-party courier work is handed to Stuart (/api/v1.0/stuart/settings/{storeId}, /stuart/jobs/{jobId}), where the courier is paid by the network rather than by the merchant's payroll. On www, /pos-system/payroll-management and /docs/pos-features ('Staff rotas and payroll', 'Delivery driver management') establish that both modules exist but no page ties them together, and /pos-system/delivery-driver-tracking describes assignment, notifications and viewing 'order details, including payment status' only. Driver pay configuration would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

delivery-cash-reconcile

Checked both API versions and www on 2026-08-09. Pass 2 found v1.0 tracks cash in detail, but always at store and payout level: the Payout Report 3 schema carries RevenueOfWhichCash, WebAndAppCash and WebAndAppCashRevenueIncludingTips, KioskCash and KioskCashRevenue, QropCash, CashCustomerFees with bracket amounts, RefundsOnCashOrders, opening and closing balances and BalanceRepaid (/v1.0/reference/getpayoutreport3details). None of it is attributed to a driver: the driver surface is assignment only (AssignDriverToOrder / UnassignDriverFromOrder, DriverId/DriverName/DriverImage), and grep across 27.6MB returns no float, cash-bank, settle-up, over/short or shift-reconciliation construct, nor any cash-drawer endpoint. v3.0 likewise records payments at sale level with no driver attribution. On www, /pos-system/delivery-driver-tracking says riders 'easily view order details, including payment status', which tells a driver which orders are cash but is not a cash bank, and /pos-system/reporting-and-analytics names no driver cash report. An end-of-shift settle-up procedure would be documented on help.flipdish.com, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

delivery-daas-dispatch

Native, documented, and in the shipped v1.0 API rather than only on a price list. Flipdish exposes a first-party courier surface at /api/v1.0/stuart/settings/{storeId} (GET and POST) whose StuartSettings object is configured per store - ClientId, ClientSecret, Enabled, WebhookUrlBasicAuthentication, OverrideWebhookUrl, MinutesToPickupBeforeThanDeliveryTime, PackageType [Xsmall..Xlarge], TransportType [Bike, Cargobike, Cargobikexl, Motorbike, Motorbikexl, Car, Van], CancelOrderIfStuartCancelDelivery and a TransportPrices map ('If the order exceeds are certain amount this configuration will determine a new vehicle type'). The courier job comes back into the order record: GET /api/v1.0/stuart/jobs/{jobId} returns Status, PickupAt, DropoffAt, Distance, Duration, a JobPricing block (Currency, PriceTaxIncluded, PriceTaxExcluded, TaxAmount, InvoiceUrl - the quote), per-delivery Status, PickedAt, DeliveredAt, TrackingUrl, Eta and Proof, and a JobDriver with Latitude/Longitude; the job can be cancelled from Flipdish (Stuart_CancelJob), and CancelOrderIfStuartCancelDelivery ties courier cancellation back to the Flipdish order. The order itself carries DeliveryTrackingStatus and a tracking URL. DoorDash Drive Order Fulfillment is a separately monitored production component on status.flipdish.com (operational, created 2022-12-07, last updated 2026-06-16), and www.flipdish.com/integrations lists Okestro, Ondway, Nash, Stuart and VROMO under last-mile delivery. Commercially, Uber Direct is sold as a separate add-on on the pricing page - a packaging point, not a capability limit. https://developers.flipdish.com/v1.0/reference/stuart_getstuartsettings · retrieved 2026-08-09 adversarially verified

delivery-daas-fallback differentiator

Both halves of a hybrid model are documented and the automatic switch between them is not. In-house: drivers are first-class in v1.0 (InviteDriverToApp, AssignDriverToOrder, DeliveryTrackingStatus). Third-party: a per-store Stuart courier configuration at /api/v1.0/stuart/settings/{storeId} plus Okestro, Ondway, Nash, Stuart and VROMO on www.flipdish.com/integrations, with v3 modelling the distinction as delivery.deliveredBy ['Client' - the restaurant fulfils the delivery itself; 'External' - a marketplace or third-party courier delivers]. Named shortfall: the StuartSettings object is closed and its only automatic rules are TransportPrices ('If the order exceeds are certain amount this configuration will determine a new vehicle type' - order value to vehicle class, not in-house to courier) and CancelOrderIfStuartCancelDelivery (courier cancellation to order cancellation). There is no no-driver-available trigger, no out-of-zone trigger and no wait-time threshold anywhere in the 27.6MB v1.0 reference or the v3.0 reference, and deliveredBy is set on the sale at ingest rather than re-evaluated. Any portal-side dispatch rule would be documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/stuart_getstuartsettings · retrieved 2026-08-09 adversarially verified

delivery-3p-direct-integration differentiator

One of the three named marketplaces is a first-party channel; two are not. The sales-channel schema enumerates type as a closed list - POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats, Deliveroo - with no DoorDash and no Grubhub, and 'grubhub' is a zero-hit across all four Flipdish corpora (v1.0 reference, v3.0 reference, the ten off-index guides, and www). Correction to the earlier note, which said DoorDash 'is not named': Flipdish's status page publishes a live production component 'DoorDash Drive Order Fulfillment' (operational, created 2022-12-07, last updated 2026-06-16) and the v3 audit-log schema uses 'doordash.job_updated' as its worked example event name. That is DoorDash DRIVE - white-label courier fulfilment - not the DoorDash marketplace, so it does not satisfy this claim, but the blanket absence statement was wrong and is withdrawn. The GA v1.0 surface cannot enumerate marketplaces at all: its Channel object is {ChannelId, TranslationKey, Source Internal|External, LogoUri, Available, MaintainedExternally} behind /api/v1.0/{appId}/channels/available-channels, a data-driven list with no vendor names. Middleware paths remain on offer alongside the direct ones - Deliverect, ItsaCheckmate and UrbanPiper are all named on www.flipdish.com/integrations. The v3 sales-channel endpoints carry the beta notice. https://developers.flipdish.com/reference/getsaleschannelsbyorgidandpropertyid · retrieved 2026-08-09 adversarially verified

delivery-3p-injection

Re-grounded on the GA v1.0 API; the previous grade-B citation was a marketing feature page. An order arriving from an external channel is an ordinary Flipdish Order object, not a separate marketplace ticket type: the Order schema carries Channel (a $ref to the Channel object), 'ChannelOrderId' described as 'ChannelOrderId from external channel' and 'ChannelOrderDisplayId' likewise, alongside exactly the same DeliveryType, OrderItems, FulfillmentStatus state machine and OrderDropOffLocation as a first-party order, so nothing has to be re-keyed. Manual accept is optional rather than mandatory: the store payload carries 'AutomaticallyAcceptOrders' - 'True if the stores orders are automatically accepted in Flipdish' - and the permission set includes UpdateOrdersAccept / UpdateOrdersDispatch for the manual path. Printers are modelled as store-assigned devices (PrinterAssignedToStoreEvent, PrinterUnassignedFromStoreEvent, PrinterTurnedOnEvent/OffEvent, PrinterHub), and flipdish's status page runs 'Third Party Delivery Integrations' and 'SIM Printers' as live production components. Marketing corroborates in plain words - 'Flipdish automatically syncs orders from all your marketplace platforms straight into your POS and kitchen' - and no injection-latency figure or failure-mode documentation is published in either API version. https://developers.flipdish.com/v1.0/reference/getorderbyid · retrieved 2026-08-09 adversarially verified

delivery-menu-push

Correction: the earlier shortfall - 'channel-specific markups are not documented (price bands exist as a separate object)' - is withdrawn, because the sales channel is what a price band binds to. The sales-channel schema carries both 'menuId' and 'priceBandId', and the v3 menu structure gives every CategoryItem and ModifierItem a pricingProfiles[] array with 'one per price band', each profile defining 'separate prices for four dispatch types: Collection, Delivery, DineIn and TakeAway'. Channel-specific pricing is therefore exactly what the model is for. Menu, modifiers and photos all travel: menu.published.v1 fires 'when a menu is (re)published to a sales channel that belongs to your marketplace' and 'the payload includes the full published snapshot so you usually don't need a follow-up GET' - categories, items, modifiers, pricingProfiles, charges - with imageUrl on category, item and modifier group; Menu Management also exposes /menuManagement/orgs/{orgId}/menus/headers, /menus/{menuId}/current and /revisions/{revisionId}. The real shortfall is that Flipdish does not write to the marketplace. The guide's own sequence is 'Flipdish - menu.published.v1 webhook - your platform / Your platform GETs the menu revision from Menu Management API', after which the partner POSTs .../salesChannels/{salesChannelId}/menu-publish-status 'so the merchant sees the publish status in the portal'. A listing is only in sync if the partner implements the mirror, and the whole v3 surface carries the beta notice. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

delivery-86-sync

Bidirectional and documented, but partner-mediated. Outbound: menu.item.snoozed.v1 / unsnoozed.v1 carry menuId, menuRevisionId, menuItemId and an expiry ('Null if the snooze is indefinite'), and the guide tells the marketplace to 'Mirror these onto your marketplace listing'. Inbound: 'If a snooze on your marketplace originates from your side (e.g. driver reports an item out), report it via the Operations Updates API' - POST /operations-updates/orgs/{orgId}/properties/{propertyId}/salesChannels/{salesChannelId}/item-snooze-status with requestedStatus Snooze|UnSnooze. Item and item-option are both covered (the menu snooze itemType enum is menu.item|menu.option). The GA v1.0 surface has no snooze vocabulary at all ('snooze' is a zero-hit across its 1,064 pages); its nearest equivalent is the permission UpdateMenuItemsHideTemporarily, so the two-way contract above is v3-only and carries the beta notice. Shortfall: no near-real-time figure or SLA is published, and Flipdish emits the event but does not itself write to the marketplace. Correction to the earlier note, which said DoorDash is absent 'from the whole corpus': DoorDash is absent from the sales-channel type enum (UberEats, JustEats, Deliveroo), which is the sense that matters here, but it is not absent from Flipdish's material - the status page carries a live 'DoorDash Drive Order Fulfillment' component and the v3 audit-log schema uses 'doordash.job_updated' as its example event name. Both are courier fulfilment, not a snoozeable marketplace listing. https://developers.flipdish.com/docs/build-a-marketplace-integration · retrieved 2026-08-09 adversarially verified

delivery-store-pause

A whole sales channel can be snoozed from Flipdish, and the snooze is timed: the sales_channel_snoozed_v1 payload requires 'expiry' - 'The expiry datetime of the snooze in ISO-8601 UTC format. Null if the snooze is indefinite' - so auto-reactivation at a set time is documented, contrary to an earlier reading. The channel is identified by salesChannelType from the enum UberEats, JustEats, Deliveroo, ExternalApp, POS, KIOSK, MobileApp, WebApp, Flipdish*. Shortfall: Flipdish publishes the event and the marketplace integrator is instructed to mirror it onto its listing, so Flipdish does not itself pause the third-party storefront; the reverse-direction endpoint POST .../store-snooze-status takes only requestedStatus and success, with no expiry; and DoorDash and Grubhub are not enumerated channel types. All beta. https://developers.flipdish.com/reference/post_sales-channel-snoozed-v1 · retrieved 2026-08-09 adversarially verified

delivery-3p-reconciliation differentiator

Checked both API versions and www on 2026-08-09. Pass 2 found the reconciliation machinery pass 1 could not see, but it is aimed at the wrong deposit. Payout Report 3 (/api/v1.0/{appId}/reporting/reports/payouts3/{bankAccountId}/{payoutId}/overview and /details) itemises GrossSales, SalesTax, DeliveryCharges, OtherCharges, Tips, FlipdishFees, Adjustments, RefundsOnCard/CashOrders, Chargebacks, RefundedFeesOnChargebacks, TotalChargebackCost, opening/closing balance and PreviousPayoutId/NextPayoutId, with per-payout exports of orders, POS sales, chargebacks, ledger entries and refunded orders. That reconciles the Flipdish payout into the merchant's bank account. Marketplace deposits from Uber Eats, Just Eat and Deliveroo are paid by those platforms directly and are not the subject of this report: the only third-party lines in it are the aggregates ThirdPartyIntegrationFeesAndTips, OtherIntegrationFees and OtherIntegrationTips, with no per-marketplace commission or marketing-fee breakdown, and nothing anywhere flags a missing or unpaid marketplace order. Orders do carry Channel, ChannelOrderId and ChannelOrderDisplayId, so the join key exists, but no endpoint performs the match. On www, /pos-system/order-management markets fee visibility ('See which marketplaces are driving profit and where you're paying too much in fees') without describing deposit matching. Whether the portal publishes a marketplace reconciliation report is a help.flipdish.com question, excluded from this sweep by policy (robots.txt names ClaudeBot with Disallow: /). Unresolved.

delivery-injection-error-visibility differentiator

Re-grounded on the shipped surface. v1.0 publishes a per-delivery webhook log at GET /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions/{webhookSubscriptionId}/logs whose WebhookLog schema carries WebhookEventName, WebhookSubscriptionCallbackUrl, HttpResponseStatusCode, HttpResponseStatus, RequestHeaders, RequestBody, ResponseHeaders, ResponseBody, Duration and RetryCount, alongside a test-fire endpoint at .../events/{eventName}/test; both are unmarked in a corpus that marks its exceptions (8 of 1,064 v1.0 pages carry a marker, all ALPHA). On v3.0, menu.validation.failed.v1 is 'Generally available' and fires when 'a menu fails validation after a publish attempt', which is the documented way to detect a failed publish rather than inferring it from silence. Named shortfalls. (1) The injection-error half is weaker than previously recorded: the menu-publish-status callback an integration reports failures through belongs to Operations Updates, which the marketplace guide places in closed beta behind integrations@flipdish.com, and sales.pos.status.updated.v1 -- cited in the earlier note -- is marked 'Deprecating soon'. (2) Everything above is programmatic and integrator-facing: no operator-facing channel-health dashboard, connection-status view or failure alerting is documented on either developer host, and the portal manual (help.flipdish.com) is excluded by policy, so the operator-visibility half of the claim is unevidenced rather than refuted. https://developers.flipdish.com/v1.0/reference/getwebhooklogs · retrieved 2026-08-09 adversarially verified

delivery-tracking-page

Guest-facing and explicitly documented, but on Flipdish's domain rather than the restaurant's - which is the half of the claim that fails. GET /api/v1.0/orders/{orderId}/deliveryinfo is described as 'Returns an orders delivery information. This would be used to display the latest known delivery information on a screen' and returns OrderDeliveryInformation {OrderId, ExternalReferenceId, TrackUrl, Status, DeliveryStatusNotes, ErrorMessage, IntegrationCode, IntegrationName}; the page's own worked response is TrackUrl 'https://deliverytracking.flipdish.com/713144192', Status 'Accepted', DeliveryStatusNotes 'Driver: Ryan (+353 20 913 2725)', IntegrationName 'Flipdish Delivery'. The state driving it is real driver state, not order state alone: Status is the enum None|Unassigned|Unaccepted|Accepted|Carrying|OnTheWay|ArrivedAtLocation|Delivered|CannotDeliver, mirrored on the order itself as DeliveryTrackingStatus alongside DriverId and a 6-character OrderTrackingCode, and there is a dedicated customer-side event, OrderCustomerTrackingCreatedEvent, whose payload CustomerDeliveryTrackingOrder is documented as 'the order data required for customer driver tracking' (order lines, prettified address, delivery notes, store phone number, AppIconUrl, OrderTrackingCode, payment method, last four digits). Shortfalls: the tracking host is deliverytracking.flipdish.com, a Flipdish domain, and the only branding field in the customer payload is AppIconUrl, so this is not the restaurant's own domain; no SMS-link surface is documented in either API version (Twilio SMS and Vonage SMS appear only as status-page components); and live driver coordinates exist but on the operator side - the Stuart courier job exposes JobDriver {DisplayName, Phone, PictureUrl, TransportType, Latitude, Longitude} and a JobEta {Pickup, Dropoff} through /api/v1.0/stuart/jobs/{jobId}, with nothing documenting that a map is rendered to the guest. https://developers.flipdish.com/v1.0/reference/getdeliveryinformation · retrieved 2026-08-09 adversarially verified

delivery-promise-time differentiator

The v1.0 API defines the quote as a constant. GET/POST /api/v1.0/stores/{storeId}/leadTimes returns OrderLeadTimes, documented verbatim as 'When orders are accepted, and no lead time is specified by the operator, this is the lead time that will be applied to the order', with LeadTimeMinutes as 'Mapping from the type of order to the default lead time that will be applied to those orders. The lead time is an integer number of minutes', and a LeadTime object requiring DispatchType ('There are two valid values for this field - collection and delivery') and LeadTimeMinutes. So the promise is a fixed per-store, per-dispatch-type number, with the only variation being a manual operator override at acceptance (the order's AcceptedFor field, 'Time store has accepted the order for'). None of the three inputs the claim requires feeds that number. Zone drive time: the DeliveryZone schema is fully enumerated as {Id, FeeChargedToStore, DeliveryFee, MinimumDeliveryOrderAmount, WellKnownText spatial polygon, IsEnabled} with no drive-time, ETA or travel-duration field. Kitchen load: the one load-aware control, StoreOrderCapacityConfig, caps how many orders may be requested per interval rather than lengthening the quote when load rises, and over-capacity is handled by rejection (the order RejectionReason enum includes 'TooBusy'). Driver availability: correcting an earlier statement that the driver surface is 'invite/assign/unassign only' - it is not. Flipdish's Stuart courier surface (/api/v1.0/stuart/jobs/{jobId}) returns JobEta {Pickup, Dropoff}, a JobDriver with Latitude and Longitude, a job Duration and a per-delivery TrackingUrl, and the order-ingest/submit endpoint accepts an inbound EstimatedDeliveryTime from an external channel. But all of that is post-dispatch courier telemetry or a third party's own figure arriving with the order; nothing feeds either back into leadTimes, and the quote the guest sees at order time remains the stored constant. Flipdish also makes no dynamic-ETA claim on www: /pos-system/delivery-driver-tracking mentions 'tracking rider availability and optimising order preparation' but never says the guest-facing quote moves, and /delivery is silent on ETAs. Scope note: this scores the documented quoting mechanism across Flipdish's own v1.0 and v3.0 APIs; help.flipdish.com is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/setstoreleadtimes · retrieved 2026-08-09 adversarially verified

delivery-offline-behavior

Checked both API versions and www on 2026-08-09. Grep for offline, outage, degraded and connectivity across the 99-page v3.0 dump returns nothing, and the Error Handling guide covers HTTP status codes, idempotency and retries for callers rather than merchant-side outage behaviour. Pass 2 found the only 'offline' in the 1,064-page v1.0 reference is device monitoring: HydraDeviceStatus is an enum of Online, PossiblyOffline and related states, surfaced through a HydraConnectionStatusChangedEvent webhook and the /api/v1.0/{appId}/emvterminals, /kioskiot, /terminaliot and /heartbeat families. So Flipdish detects that a terminal has dropped, and says nothing whatever about what a store can still do while it is dropped - no statement about cash delivery orders, driver assignment or driver settlement continuing. On www, /pos-system, /docs/pos-features and /pos-system/delivery-driver-tracking make no offline claim in either direction, and /pos-system says the POS is 'Cloud-based'. Because the claim asks whether the vendor documents the behaviour, and the vendor's operational documentation is help.flipdish.com - excluded from this sweep by policy (robots.txt carries User-agent: ClaudeBot / Disallow: / and Content-Signal: ai-train=no) - this cannot be settled from the permitted hosts. Unresolved.

digital-first-party-web

Branded ordering website sold on a flat per-site subscription (from EUR49 / USD119 per month) with no per-order marketplace commission; explicitly positioned as a Just Eat / Seamless alternative. https://www.flipdish.com/online-ordering · retrieved 2026-08-01

digital-menu-single-source

One menu record feeds every channel. The SalesChannel schema makes menuId a required property of each channel, and the type enum spans POS, FlipdishKIOSK, FlipdishMobileApp, FlipdishWebApp, FlipdishPhoneAgent, UberEats, JustEats and Deliveroo - so the till, the website, the app and the kiosk can all reference the same menuId. POST /orgManagement/.../salesChannels/{id}/menu/publish publishes a menu to a channel, POST /menuManagement/orgs/{orgId}/menus/{menuId}/revisions/{revisionId}/publish takes an 'Optional list of Sales Channel IDs to publish to', and GET /menuManagement/orgs/{orgId}/menus/{menuId}/references returns 'all properties and sales channels referring to a menu'. No separate digital menu build is documented anywhere. Caveats: the schema notes a channel 'can have a different menu associated with it', so single-source is a configuration rather than an enforced invariant, and these endpoints are in beta. https://developers.flipdish.com/reference/publishmenutosaleschannel · retrieved 2026-08-09 adversarially verified

digital-native-app differentiator

Branded mobile apps are a distinct product and price tier (Website & Mobile App from EUR79 / USD199 per month). https://www.flipdish.com/online-ordering/mobile-apps · retrieved 2026-08-01

digital-account-saved-payment

Consumer profile carries saved card and saved address across every Flipdish-powered site: 'if you consent to have your card details retained, they will be available when you place a digital order from a different store if it is also on the Flipdish Platform', and 'your details, such as name and delivery address, will appear when you are logged in to any Flipdish-powered app or website'. Cards are tokenized by Stripe, not stored by Flipdish or the store. Repeat ordering is attested only on the vendor's mobile-app marketing page (grade C): 'Flipdish saves your customer's last order so they can quickly go through the ordering flow' and 'From automatically populating addresses to remembering their last order'. https://www.flipdish.com/consumer-information/card-details · retrieved 2026-08-08

digital-upsell-engine differentiator

Rules-light 'menu upsells' surface popular items at checkout/kiosk; no attach-rate reporting documented. https://www.flipdish.com/online-ordering · retrieved 2026-08-01

digital-scheduled-pacing

Upgraded on evidence the first pass missed by searching only the 99-page v3.0 corpus: the throttling half is documented on the generally-available v1.0 API. GET /api/v1.0/{appId}/storeordercapacity/{storeId}/{deliveryType} and POST /api/v1.0/{appId}/storeordercapacity/{storeId} read and write a StoreOrderCapacityConfig of OrderCapacityPeriods, each a StoreOrderCapacityPeriod with DayOfTheWeek, PeriodStartHour/PeriodStartMinutes, PeriodEndHour/PeriodEndMinutes and MaxOrderNumberPerStoreInterval, documented verbatim: 'The maximum number of orders per each store order interval in this order capacity period. E.g. for a period from 9:00 till 11:00, if the store's interval is 10 minutes, and MaxOrderNumberPerStoreInterval is set to 5, it means that within each 10-minute interval between 9:00 and 11:00 (i.e. 9:00-9:10, 9:10-9:20, .. , 10:50-11:00) it will be possible to request at most 5 orders.' It is set per deliveryType (Delivery|Pickup), there is a matching portal permission EditStoreOrderCapacity and a store.order_capacity.updated event, so slots are capped per daypart and stop taking orders once the cap is reached. The slot grid itself comes from PreOrderConfig at /api/v1.0/stores/{storeId}/preorderconfig/{deliveryType} (LeadTimeMinutes, IntervalMinutes, MaxOrderAheadDays, CutOffTimeCurrentDayBasic, CutOffTimePreviousDayBasic, IncludeAsap, RequireExplicitSelectAlways) with a /preview endpoint. Scheduled orders themselves stay documented on v3.0: a sale carries requestedFulfilmentTime plus isAsap, and 'if requestedFulfilmentTime is more than ~1 hour away the requested time is honoured and the sale is treated as scheduled'. Maturity: every v1.0 page cited here is unmarked in a corpus that marks its exceptions (only 8 of 1,064 v1.0 pages carry a marker, all ALPHA, none of them these). Residual gap: the cap counts orders, not items, per slot. https://developers.flipdish.com/v1.0/reference/getstoreordercapacity · retrieved 2026-08-09 adversarially verified

digital-fulfillment-modes

The generally-available v1.0 Order schema enumerates the fulfilment surface: DeliveryType [Delivery, Pickup]; PickupLocationType [TakeOut, TableService, DineIn]; and TableServiceCatagory [Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team] -- so a parking-bay (curbside) and a drive-through collection point are modelled, which the earlier note missed. Store settings carry per-mode switches: TakeOutEnabled, TableServiceEnabled, DineInEnabled, PickupEnabled, DeliveryEnabled, PreOrderEnabled and AllowPreOrdersAndTableService. Mode-specific fees and prep timing are documented too: menu pricingProfiles carry collectionPrice / deliveryPrice / dineInPrice / takeawayPrice, charges[] has a Delivery type, and PreOrderConfig (lead time, interval, cut-off) is configured per deliveryType. v3.0 adds dispatchType [DineIn, TakeAway, Collection, Delivery] on the sale object. Named shortfalls. (1) Arrival check-in is not documented anywhere on either developer host: the only arrival concept in the 1,064-page v1.0 corpus is the courier-side DeliveryTrackingStatus value ArrivedAtLocation, and there is no guest 'I am here' signal, so curbside is a location type rather than a check-in flow. (2) The string 'QR' appears zero times in both developer corpora (99-page v3.0 and 1,064-page v1.0), so the earlier note's 'QR table ordering exists' is not supported by the developer documentation -- table service is modelled, but the QR mechanism is a portal/marketing claim and help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/getorders · retrieved 2026-08-09 adversarially verified

digital-qr-table

Shortfall: the QR order does not attach to a POS check, and there is no tab or bill split. Guest-facing scan-to-order works and table-specific codes pre-fill the table number at checkout, but Flipdish's Table Ordering FAQ states 'Can I get the orders assigned to the tables I have set up on our POS? Not at the moment, the table numbers are going to your POS as a note. They will be printed on your receipts', and 'Can my customers open a tab and pay at the end of their meal? No, customers must pay in advance for their order unless they choose to pay cash'. Tipping is available on the online checkout via Portal tip configuration; splitting the QR bill is not documented anywhere. https://help.flipdish.com/en/articles/9585439-table-ordering-and-qr-code-faq · retrieved 2026-08-08 · not refetchable · site policy · graded B when read

digital-kiosk differentiator

K2 (24" floor/wall), K2 Mini (15" tabletop) and D2S countertop kiosks with integrated card readers, running the same online-ordering menu; loyalty and tipping supported. Accessibility is aspirational rather than certified. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

digital-group-ordering

Second pass, 2026-08-09, against the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09) (pass 1 had only the 99-page v3.0 root index). The v1.0 Order schema (/v1.0/reference/getorderevents) is single-owner throughout: one Customer block (CustomerSummary - Id, Name, EmailAddress, PhoneNumber), exactly one Voucher (a single OrderVoucherSummary object, not an array), one PaymentAccountType drawn from a closed enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken), and a Cart of LineItems with a CartAmount and a Tip. The strings 'split', 'participant' and 'contributor' occur zero times in the 27.6MB dump and there is no per-person cap field anywhere. That settles that group ordering cannot be expressed over either published API version, which is evidence about the API surface only. A shareable multi-participant cart is a consumer web/app feature that need never surface in an integration API, www.flipdish.com/online-ordering and /online-ordering/websites are marketing roundups that do not enumerate order modes, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

digital-catering-portal differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The word 'catering' occurs zero times in the 27.6MB dump. Two of the claim's six elements have near-neighbours: PreOrderConfig (/v1.0/reference/getstoreevents) exposes LeadTimeMinutes, IntervalMinutes, MaxOrderAheadDays, IncludeAsap and RequireExplicitSelectAlways per store and delivery type, and StoreSummary carries MinimumPickupOrderAmount - but both sit on the ordinary consumer checkout, not on a separate catering menu. The App resource enum at /v1.0/reference/getapp-1 shows a back-office accounting module exists (EditAccountsCreditAccounts, ViewAccountsCreditBooks, EditAccountsBills, ViewInvoices), which is house-account shaped, yet no endpoint in the 1,064 pages reads or writes any of it, so I cannot tell whether credit accounts can be used as guest payment terms. No quote, proposal or deposit construct exists in either API version. Because the distinct catering flow that heads the claim is entirely unevidenced rather than shown-and-limited, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

digital-voice-ai-phone differentiator

Same as order-capture-voice-ai: upheld, but re-source off the '-draft' page onto the launch release. Note it is a priced add-on, not included in the EUR99 bundle, and restricted to UK/IE plus unnamed 'select international markets'. https://www.globenewswire.com/news-release/2025/11/19/3190837/0/en/flipdish-launches-ai-phone-agent-to-ensure-every-call-becomes-an-order.html · retrieved 2026-08-01 adversarially verified

digital-drivethru-ai

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). Flipdish does model drive-thru, but as a collection point: the PickupLocationType enum (/v1.0/reference/getorderevents) is Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team - a place the guest is met, attached to an order that was already placed on web, app or kiosk. There is no lane, intercom, speech, transcript, ASR or voice-session object anywhere in the 27.6MB dump, and the sales-channel enum used for voucher restrictions is closed at Ios, Android, Web, Kiosk, Pos, Google. That is consistent with the 2021 marketing post at www.flipdish.com/resources/blog/drive-thru-system-flipdish framing drive-thru as pre-ordering with a chosen collection time, and with www.flipdish.com/ai scoping the AI Phone Agent to inbound telephony while /us/labs lists 'voice-enabled ordering' as unshipped R&D. An integration API is not where a lane speech product would necessarily appear, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

digital-sms-ordering

The text-a-link branch of the claim is documented as a product feature: 'Automatically send an SMS to your phone customers to prompt them to order online, freeing up staff and increasing revenues' -- an automated outbound SMS that diverts a caller into Flipdish's own ordering flow, whose orders land in the Flipdish POS and KDS ('All your delivery orders flow straight into your Flipdish POS system, where they get categorised, colour-coded, and displayed on your Flipdish Kitchen Display System', /delivery). Named shortfalls: it is a one-way prompt, not an ordering channel -- the guest completes the order on the web, not over SMS; no conversational SMS or chat ordering, reordering-by-text or two-way message parsing is documented on www or in the 99-page developers.flipdish.com corpus, whose only conversational product is the inbound AI Phone Agent (voice). Elsewhere on www SMS appears purely as a marketing channel (/marketing) and as a receipt/notification channel. Grade C: this is a vendor feature page, not documentation. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/online-ordering · retrieved 2026-08-09

digital-google-order differentiator

Flipdish's own product-update post documents the integration: 'It pulls the menu from your Flipdish website into Google Search and Google Maps, so people can order, without leaving Google.' Named shortfalls: (1) this is a grade-D vendor announcement -- the claim carries differentiator weight, which needs grade A or B for a yes, and the configuration documentation sits in help.flipdish.com, excluded from this sweep by policy; (2) the post states the feature 'will be rolling out to stores across the UK' over the following weeks and no permitted page states current availability outside the UK; (3) neither 'Google Business Profile' nor 'Preferred by Business' appears -- nothing on a permitted host says the direct ordering link is provisioned as the preferred ordering action ahead of marketplace links, which is the part of the claim that distinguishes real placement from mere presence. www.flipdish.com/integrations does not list Google in any category. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/us/resources/blog/the-dish-september-23 · retrieved 2026-08-09

digital-apple-business-connect

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The contrast is sharper than pass 1 could see: Order with Google is plumbed into the platform as a channel - the voucher ChannelRestrictions enum is closed at Ios, Android, Web, Kiosk, Pos, Google (/v1.0/reference/updatevoucher) and StoreFeeConfig carries dedicated PercentFeeOrderWithGoogle and FixedFeeOrderWithGoogle lines (/v1.0/reference/getstorefeeconfig) - while every one of the 70 occurrences of 'Apple' in the 27.6MB dump is either Apple App Store distribution of the branded iOS app or the payment description 'Visa ****2371 or Apple Pay'. There is no listings, place, map or business-profile resource of any kind. But Apple Business Connect placement is a listings-management action performed in Apple's own console, and a merchant could point a Maps 'Order Food' action at a Flipdish ordering URL without any Flipdish API object existing, so the enums are not an enumeration of supported placements. www.flipdish.com/integrations lists no Apple entry and disclaims completeness ('And more!'). help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

digital-loyalty-attach

Marketing-page only, and thin. The single accrual description is 'Reward customers who order regularly. Flipdish will even let them know how close they are to their next discount!' The kiosk page adds 'redeem vouchers and collect loyalty'. There is no documentation of enrolment, identity resolution across channels, ledger, or redemption at POS — and no customer or loyalty object exists in the public API to corroborate any of it. https://www.flipdish.com/marketing · retrieved 2026-08-01 adversarially verified

digital-subscriptions

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'Subscription' appears 756 times and every occurrence I sampled is merchant-side billing: CreateAppStoreSubscription / UpdateAppStoreSubscription / DeleteAppStoreSubscription and ViewSubscriptions / ViewInvoices in the App resource enum (/v1.0/reference/getapp-1), and the App Store app model's IsPaid flag. The guest object is thin and carries no membership: Customer is CustomerId, RegistrationDate, PhoneNumber, CashOrdersEnabled, CardOrdersEnabled, MarketingEnabled (/v1.0/reference/getcustomerbyid) - no plan, tier, entitlement or renewal field. The two loyalty constructs (LoyaltyCampaign, RetentionCampaign) are threshold-triggered voucher issuers with no recurring charge, and the closed PaymentAccountType enum has no recurring or mandate tender. So no guest subscription can be expressed over either API version - evidence about the API surface only. A paid membership sold inside the consumer app need not surface there, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

digital-promo-parity

Vouchers, discounts and loyalty are defined centrally and run across Flipdish channels; per-channel eligibility controls are not documented. https://www.flipdish.com/marketing · retrieved 2026-08-01

digital-guest-data-ownership differentiator

T&Cs: 'You retain ownership of all content and data provided by you', and marketing positions Flipdish as building the operator's own customer database. But the privacy policy states Flipdish acts as controller for consumer ordering data and processes it 'for its own independent purposes, such as platform security, analytics, and service improvement', and no fee-free self-serve bulk export is documented. https://www.flipdish.com/privacy-policy · retrieved 2026-08-01

digital-checkout-pci-sca

Flipdish operates the checkout itself rather than handing card fields to the restaurant's own page -- ordering runs on Flipdish-built websites, apps and kiosks with 'Integrated payments' (/docs/pos-features) and Flipdish 'Securely accept credit and debit cards with leading payment processors around the world' -- and it asserts 'Built-in PCI compliance to prevent security breaches and card data theft'. Named shortfalls, each a specific element of the claim left unpublished on the permitted hosts: (1) no PCI DSS version is stated anywhere on www, so the 4.0 requirement is unevidenced -- the only versioned mention is a competitor-fee explainer defining 'PCI DSS Monthly Fees' generically (/us/resources/blog/payment-processing-fees); (2) no client-side script-integrity or payment-page-script-inventory claim (the 6.4.3 / 11.6.1 requirements effective March 2025) appears at all; (3) no Attestation of Compliance, Level, or trust/security page exists -- www.flipdish.com/legal links only T&Cs, privacy, cookies, the EU DSA statement and the EU Accessibility Act statement; (4) 3DS/SCA is documented by Flipdish only in help.flipdish.com, which is excluded from this sweep by policy, so it cannot be cited here. /pos-system/payments itself says only 'Fraud detection that works' and 'Advanced tools spot risks early'. [Retrieved via: direct fetch of www.flipdish.com (permitted host; no ClaudeBot directive in robots.txt).] https://www.flipdish.com/products-overview · retrieved 2026-08-09

digital-surcharge-transparency differentiator

Partial. Present: fee configuration is channel-aware and does pass to the guest. StoreFeeConfig (/v1.0/reference/getstorefeeconfig) is a per-store matrix of percent and fixed fees split by tender and channel - PercentFeeCardOrders / PercentFeeCashOrders, ...Web, ...Kiosk, ...LocationService, PercentFeeCardPosTransaction, PercentFeeDelivery, PercentFeeTips / TipsCollection / TipsDelivery, PercentFeeOrderWithGoogle - and each digital channel has an explicit guest pass-through pair, e.g. PercentFeeCardOrdersChargedToCustomerIncludingVat and FixedFeeCardOrdersKioskChargedToCustomerIncludingVat, alongside a TaxRatePercent. ProcessingFeeConfig (/v1.0/reference/getprocessingfeeconfigsbystoreid) states the intent in words: per store and per PaymentAccountType (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken), a PercentFee and FixedFee described as 'Percent fee to customer, including VAT'. A separate store-level ServiceCharge object (/v1.0/reference/configurestoreservicecharge) carries PercentageValue ('The Default Service Charge Value'), Enabled, IsOptional ('Sets the service charge to be optional'), DisplayWithProcessingFee ('Display service charge together with processing fee') and IncludesVouchers, and is set on the store rather than per channel, so it applies uniformly. Named shortfalls: (1) surcharging is dimensioned by payment ACCOUNT TYPE, not by card brand - there is no Visa/Mastercard/Amex attribute and nothing that could suppress a surcharge for a prohibited brand; (2) there is no jurisdiction, state or country attribute on any fee object, so no prohibited-jurisdiction handling is expressible; (3) there is no dual-price pair on a menu item and no cash-discount construct anywhere in the 27.6MB v1.0 dump or the 99-page v3.0 dump; (4) the only guest-facing disclosure control is the DisplayWithProcessingFee boolean - there is no disclosure-text field; (5) parity with the POS is not actually symmetric: the POS lines PercentFeeCardPosTransaction and FixedFeeCardPosTransaction have no ...ChargedToCustomer counterpart, so guest pass-through is configured for web, kiosk and location service but not, in this schema, for the POS card transaction. StoreFeeConfig's own field descriptions are empty strings; the reading rests on the field names plus ProcessingFeeConfig's explicit wording. help.flipdish.com is excluded by policy, so the merchant-facing fee screens were not read. https://developers.flipdish.com/v1.0/reference/getstorefeeconfig · retrieved 2026-08-09

guest-loyalty-unified-profile

A marketing CRM aggregates customer value and order frequency across Flipdish channels; documented dedup/merge behaviour between POS, web and kiosk identities is absent. https://www.flipdish.com/marketing · retrieved 2026-08-01

guest-loyalty-thirdparty-identity-attach differentiator

The sale 'customer' object carries id (Flipdish customer UUID), externalId, name, contactPhoneNumber and emailAddress, and the guide publishes explicit availability tables for what marketplaces actually deliver. Present: 'Marketplace order with international-format phone - UberEats, Deliveroo, JustEat, etc. forward a phone already in international format'. Absent: 'Most major marketplaces (UberEats, Deliveroo, JustEat) do not share customer email addresses for privacy/contractual reasons - emailAddress will be absent for these orders', and where a platform masks the number 'The relay is not the customer's real number, so contactPhoneNumber is absent' (only contactMaskingCode is set). Shortfall: marketplace orders are therefore not anonymous tickets - a name and usually a phone attach - but email is documented absent for the three major marketplaces, Deliveroo arrives masked, and nothing in the 99-page developer documentation says a marketplace order creates or links to a native Flipdish customer profile (customer.id: 'If provided, must reference an existing customer - omit or leave empty if unknown'). Whether the Portal attaches these to a guest profile is a product-manual question and help.flipdish.com is excluded by policy. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09

guest-loyalty-accrual-models

Loyalty rewards recurring customers with visible progress toward a discount; only one accrual model is described publicly. https://www.flipdish.com/marketing · retrieved 2026-08-01

guest-loyalty-tiers differentiator

Positive absence, from the complete schema of the loyalty program itself. The v1.0 API defines loyalty as one object, LoyaltyCampaign, created and updated through /api/v1.0/{appId}/campaigns/loyalty, and its full property list is CampaignId, PublicId, AppId, Stores / StoreIds, Statistics, IsEnabled, OrdersBeforeReceivingVoucher ('Number of orders customer needs to make, before receiving voucher'), PercentDiscountAmount (1-100), MaxDiscount, RoundingStrategy, ShouldIncludeOrdersWithLoyaltyVoucher, VoucherValidPeriodDays (1-300), IncludeDeliveryFee, AutoApplyResultingVouchers, IncludeExistingOrders and ForceDiscount. That is a single-threshold stamp card: count orders, issue one percentage voucher. There is no tier, level, status, rank, points-balance, rolling-window, promotion or demotion field; the campaign has no spend dimension at all, only an order count. Corroborating in the same corpus: the closed voucher sub-type enum is None, SignUp, Loyalty, Loyalty25, Retention, SecondaryRetention, Custom (/v1.0/reference/updatevoucher), which is the platform's complete set of automatically issued lifecycle vouchers and contains no tier; the Customer object is CustomerId, RegistrationDate, PhoneNumber, CashOrdersEnabled, CardOrdersEnabled, MarketingEnabled with no status field (/v1.0/reference/getcustomerbyid); the App permission enum's loyalty entries are View/Create/Update/DeleteCampaignsConfigurations plus StampLoyaltyCardAgainstCampaignsConfigurations (/v1.0/reference/getapp-1) - the vendor's own word for the mechanic is a stamp card; and the strings 'tier' and 'Tier' occur zero times in the 27.6MB v1.0 dump and zero times in the 4.6MB v3.0 dump. www.flipdish.com/marketing describes the same single threshold in prose: 'Reward customers who order regularly. Flipdish will even let them know how close they are to their next discount.' Scope of the finding: loyalty is fully modelled in the published API rather than being Portal-only, so this is an enumeration of the loyalty program, not merely of an integration surface; help.flipdish.com was not read. https://developers.flipdish.com/v1.0/reference/createloyaltycampaign · retrieved 2026-08-09

guest-loyalty-offline-behavior differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'offline' occurs ten times in the 27.6MB dump and every occurrence is hardware telemetry - the kiosk and terminal device Status field, 'Device status online or offline', and the card-reader enum Not_Connected, Connecting, Connected, Online, Offline (/v1.0/reference/cardreaders_getreader and /v1.0/reference/getbluetoothterminalstatus). Nothing in it describes queueing, caching, deferred write or reconciliation of anything, let alone of loyalty; both API versions are cloud-only against api.flipdish.co with OAuth2 and no local or sync endpoint. Loyalty itself is fully online: LoyaltyCampaign issues vouchers server-side and a voucher carries a Code plus a server-held Status enum (Valid, NotYetValid, Expired, Used, Disabled) with per-customer and global use counters (/v1.0/reference/updatevoucher). No statement of what lookup, accrual or redemption do during an outage exists on either permitted host - www.flipdish.com/pos-system and /handheld-pos make no offline claim at all. This record already carries the vendor's own 'The Flipdish POS does not support an offline mode' at order-capture-offline-order-entry, but that FAQ is on help.flipdish.com and cannot be re-read or newly cited here, and it does not itself say what loyalty does. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

guest-loyalty-offer-stacking-rules differentiator

Partial. Present: the v1.0 voucher object exposes precedence and exclusion as real configuration. Each voucher carries TakesPriority ('Takes priority'), ForceDiscount ('Force the discount to be applied which bypasses some menu restrictions'), IsAutomaticallyApplied, ValidOnOrdersOver ('Valid on orders on or above'), IsValidOncePerCustomer, IsValidOnlyOnce, IsValidForFirstOrderOnly, MaxRedemptions, ValidityPeriods (day-of-week windows) and ChannelRestrictions (Ios, Android, Web, Kiosk, Pos, Google); LoyaltyCampaign and RetentionCampaign each carry their own ForceDiscount, 'Controls whether the voucher generated from this campaign will override discount exclusions'. The exclusion side is set on the menu: the v3.0 menu item schema has disableVouchers ('Whether vouchers are disabled for this item') and excludeFromVoucherDiscounting. Named shortfalls: an order carries exactly ONE voucher - the v1.0 Order schema's Voucher property is a single OrderVoucherSummary object, not an array (/v1.0/reference/getorderevents) - and the v3.0 sale schema states 'Discounts always apply at the sale level - there is no per-line discount'. So there is no combinable-versus-exclusive setting because combining is not expressible, no ordered application sequence and no priority ranking beyond the single TakesPriority boolean, and no rule that says which of two priority vouchers wins. The Portal offer builder is documented on help.flipdish.com, which is excluded by policy, so the merchant-facing wording of these switches was not read. https://developers.flipdish.com/v1.0/reference/updatevoucher · retrieved 2026-08-09

guest-loyalty-targeted-offers differentiator

Automated discounts can be sent to target customer segments built from customer value and order frequency; the rule surface is not documented. https://www.flipdish.com/marketing · retrieved 2026-08-01

guest-loyalty-rfm-segmentation differentiator

Partial. Present: the platform computes lifecycle state itself. RetentionCampaign (/api/v1.0/{appId}/campaigns/retention) is defined by NotifyCustomerAfterMinutes - 'Time in minutes, after which customer will receive retention voucher if he/she does not order', minimum 1440 - so recency is evaluated per customer by Flipdish and a voucher is issued automatically; LoyaltyCampaign does the same on frequency via OrdersBeforeReceivingVoucher; and the closed voucher sub-type enum None, SignUp, Loyalty, Loyalty25, Retention, SecondaryRetention, Custom (/v1.0/reference/updatevoucher) names the resulting states - newly signed up, regularly ordering, lapsed, and a second lapse stage. The operator sets a threshold, not a query. Named shortfalls: there is no monetary dimension anywhere - no lifetime-value, average-spend or VIP construct on the Customer object, which is only CustomerId, RegistrationDate, PhoneNumber and three consent booleans (/v1.0/reference/getcustomerbyid); there is no segment, audience or cohort resource in any of the 1,064 v1.0 pages or the 99 v3.0 pages, and 'segment' occurs zero times in either dump, so a segment cannot be named, listed, counted or exported as an object; and the lifecycle states are not surfaced as labels on the guest, only as triggers that mint a voucher. What the Portal's customer screens show is documented on help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/createretentioncampaign · retrieved 2026-08-09

guest-loyalty-lifecycle-automation

Retention campaigns automatically target inactive customers and acquisition campaigns target first orders; birthday and first-visit automations are not documented. https://www.flipdish.com/marketing · retrieved 2026-08-01

guest-loyalty-native-email-sms differentiator

Partial is correct but the note misstates it. SMS is NOT a self-serve native campaign tool — on /marketing it sits under the 'MANAGED MARKETING' heading as a done-for-you paid service ('our team will send SMS campaigns'), and Managed Marketing is listed as a separately-sold add-on on the pricing page. Email campaigns are confirmed absent from the page. So the partial rests on push notifications plus a paid managed service, not on native SMS. https://www.flipdish.com/marketing · retrieved 2026-08-01 adversarially verified

guest-loyalty-consent-management

Shortfall: consent is a single global 'Receive promotions' boolean, not per-channel, and no timestamp or source-of-consent record is documented. What IS documented: customers default to opted-OUT with a GDPR-designed affirmative opt-in at signup (article 9585259); per-customer opt-in status is visible in the Portal; and revocation is honoured by several means — the profile toggle on web/app, an opt-out link in every marketing SMS (article 9585359), and staff-initiated opt-out from the Portal, which staff cannot reverse (only the customer can re-opt-in). POS-side opt-in for phone orders is a verbal confirmation logged against Caller ID (article 9585218) with no consent-source logging documented. https://help.flipdish.com/en/articles/9619309-customer-opt-in-out-for-marketing · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

guest-loyalty-10dlc-registration

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). SMS configuration is now visible and it is bring-your-own-provider: /api/v1.0/sms-providers/orgs/{orgId}/brands/{brandId}/provider-credentials returns SmsProviderCredential, whose complete property list is OrgId, BrandId, SmsServiceType (enum Nexmo, Twilio, Default, MessageBird), SenderId, Username and AuthToken. There is no brand-registration id, campaign id, use-case, vetting-status or approval-state field, and no registration or compliance endpoint anywhere in the 1,064 pages; '10DLC' and 'A2P' occur zero times in the 27.6MB v1.0 dump and zero times in the 4.6MB v3.0 dump. The natural reading is that A2P registration is done in the operator's own Twilio/Vonage/MessageBird account, or by Flipdish out of band on the 'Default' provider - but that is an inference, and the claim is satisfied either by handling registration OR by explicitly documenting it, and the documentation that would carry the second half is the SMS-campaign setup article on help.flipdish.com, excluded by policy. www.flipdish.com/marketing and /products-overview sell SMS campaigns (including as a managed service, 'Our team will send SMS campaigns that target your customers') and a United States locale is published, but neither page mentions registration, carrier fees or lead times. Unresolved.

guest-loyalty-campaign-attribution differentiator

'Campaign performance' is named as one of the Report Types: 'View reports on Costs, Sales, Sales Channels, Customers, Campaign performance, Payments, Staff Upsells, Menu Items Ordered, Mileage, Inventory, Payroll, Hourly Turnover and more.' www.flipdish.com/pos-system/reporting-and-analytics gives the matching use case - 'Easily highlight opportunities for growth such as continuing a marketing promotion that boosted sales'. Shortfall: this is a marketing feature list (grade D), which the differentiator grade floor bars from carrying a yes, and nothing on either permitted host states that redeemed offers are tied to actual check totals or that incremental (lift) sales are computed rather than gross sales inside a campaign window. The report's contents are documented only on help.flipdish.com, which is excluded from this sweep by policy. https://www.flipdish.com/products-overview · retrieved 2026-08-09

guest-loyalty-data-export-portability differentiator

The org-scoped read API documents 'List sales - paginated complete sale objects for sync or export', cursor-paginated with after/before filters on createdAt, returning the full PublicSale payload including the nested customer object (id, externalId, name, contactPhoneNumber, emailAddress). Credentials are self-provisioned: create a free account at portal.flipdish.com/signup, then Developer tools > OAuth apps > Add New, and use client_credentials (Getting Started). Shortfall: this is transaction history from which a guest list must be derived, not a guest list - the 90-page API reference exposes no customer, guest or loyalty-balance resource - the endpoint carries 'Beta Notice: this endpoint is currently in beta and may change without notice', the Sales Management API states 'Contact integrations@flipdish.com to request access', which is exactly the support ticket the claim excludes, and emailAddress is documented as absent for most major marketplace orders. Whether the Portal offers a self-serve CSV guest export is a product-manual question and help.flipdish.com is excluded by policy. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-09

guest-loyalty-cdp-event-api differentiator

Guest data is queryable but not subscribable. The v3.0 catalogue -- 'This page lists every event type available through Flipdish Webhooks (v3)' -- enumerates thirteen types across Menu Publishing, Menu Validation, Snoozes and Sales, and there is no customer, guest, loyalty or marketing-consent event among them; the sale.* family carries a customer object inline but fires on the sale, not on the guest. Correcting the previous note: guest resources DO exist on the v1.0 surface -- GET/POST /api/v1.0/{appId}/customers, GET /api/v1.0/{appId}/campaigns/loyalty, and two event logs, GET /api/v1.0/{appId}/events/customer/{customerId} and GET /api/v1.0/{appId}/events/order, both filterable by eventType, date range and storeIdList. The shortfall is the delivery model, not the data: both event logs make customerId a REQUIRED path or query parameter, so they are per-guest lookups for a customer you already know, not a feed a CDP can sweep or subscribe to. Ignore the boilerplate in the createWebhookSubscription blurb that names 'customer.created' as an example -- no such type appears in the catalogue. https://developers.flipdish.com/docs/flipdish-events-v3-overview · retrieved 2026-08-09 adversarially verified

guest-loyalty-review-capture-routing differentiator

A 'Customer Feedback App' is sold as a priced add-on; score-based routing to private recovery vs public review sites is not documented. https://www.flipdish.com/pricing · retrieved 2026-08-01

guest-loyalty-referral-program

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'Referral' occurs twice in the 27.6MB dump, both in the same account sign-up model: Rid ('Referral ID', int32, nullable) alongside Cid ('Campaign ID') and RecaptchaToken on the /api/v1.0/accounts create path - web acquisition attribution parameters on a merchant account, not a guest referral code. There is no referral resource, no per-guest code or link generator, no referred-order attribution field on Order (whose only campaign link is CreatedCampaignVoucherId, 'The id of the campaign voucher that was created from this order'), and the closed voucher sub-type enum None, SignUp, Loyalty, Loyalty25, Retention, SecondaryRetention, Custom has no referral member - though a two-sided reward could in principle be issued as two ordinary vouchers, so that enum is not decisive. www.flipdish.com/referral, read in full on 2026-08-09, is Flipdish's own B2B scheme ('Share Flipdish. Get EUR 350', UK and Ireland only, paid when the referred customer goes live). help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

guest-loyalty-wallet-pass differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'Wallet' occurs 34 times in the 27.6MB dump and every occurrence is GoogleWalletToken, a member of the closed PaymentAccountType enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) - a payment credential, not a loyalty pass. 'PassKit' and 'pkpass' occur zero times, there is no pass, barcode or push-update resource, and the mobile-apps API (/api/v1.0/mobileapps/{appId}/submission/...) covers only iOS and Android store submission status. Loyalty rewards are delivered as vouchers with a Code, and the guest surfaces Flipdish markets are the branded website and app (www.flipdish.com/marketing). An Apple or Google Wallet pass is a consumer-app artefact that need not appear in an integration API, so this is evidence about the API surface only, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

guest-loyalty-privacy-rights-tooling

A self-service deletion path is documented, with its propagation stated: on web and iOS 'you can select "Delete Account" under the "About my Data" section', and 'an account deletion is irreversible and affects your account across all Flipdish-powered restaurants - this includes any progress toward loyalty campaigns, and your order histories etc.' Shortfall: the tooling is guest-facing, not operator-facing. Kiosk and Android users must email Flipdish Support with the registering phone number plus an order ID or the last 4 digits of the payment card; access rights are handled by Flipdish ('Any requests to exercise any Data Subject Right will be dealt with in accordance with Data Protection Laws') and the privacy policy routes them to a data-protection address. No admin screen for fulfilling guest access or deletion requests is described on either permitted host, and the Portal manual on help.flipdish.com is excluded from this sweep by policy. https://www.flipdish.com/consumer-information/data-protection · retrieved 2026-08-09

guest-loyalty-redemption-fraud-controls

Shortfall: the only documented integrity control is manual — 'Customers can be blocked from placing further orders if necessary to maintain the integrity of the loyalty campaign.' No redemption velocity limits, no manager approval on adjustments (progress is order-count based; there is no adjustable points ledger at all), no employee self-redemption flagging and no loyalty-specific audit log appear anywhere in the loyalty docs (9585533, 9585702). Loyalty vouchers auto-apply; POS discount permissions exist per staff role but are not tied to loyalty redemption. https://help.flipdish.com/en/articles/9585533-create-and-manage-loyalty-campaigns · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

guest-loyalty-ai-offer-recommendation differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). No AI, ML, recommendation, prediction, propensity or send-time-optimisation resource exists in the 1,064 v1.0 pages or the 99 v3.0 pages; the campaign objects the API does publish are threshold-driven and deterministic (LoyaltyCampaign's OrdersBeforeReceivingVoucher, RetentionCampaign's NotifyCustomerAfterMinutes), and their CampaignStatistics block is explicitly dead - VouchersIssued, VouchersRedeemed, Conversion, SalesGenerated and ReturnOfInvestment are each marked 'Deprecated ... This field is always zero' - so even campaign measurement is not live in the API, let alone recommendation. On www, the churn-likelihood and 'end user profiling' items sit under 'Some restaurant innovations we are excited about' at www.flipdish.com/labs, i.e. roadmap, exactly what the claim warns against; the shipped AI product on www.flipdish.com/ai is the AI Phone Agent for order taking and in-call upsell. Because the claim asks what the vendor DOCUMENTS, and the documentation is help.flipdish.com which is excluded by policy, this is unresolved rather than absent.

guest-loyalty-stored-value-gift

Partial. Present: a native decrementing balance exists. The v1.0 voucher type enum is PercentageDiscount, LumpDiscount, AddItem, CreditNote, FreeDelivery, and the CreditNote variant carries CreditNoteDetails with a RemainingCredit field ('Remaining credit', double) - a balance that persists between orders rather than a one-shot discount. The same voucher object carries CustomerId ('Customer UserID', nullable), which ties an instrument to one guest profile, and Stores / StoreNames ('Stores that this voucher applies to'), which lets it be honoured across the brand's locations, plus MaxRedemptions and ExpiryDate. Named shortfalls: it is a credit note, not a gift card - there is no purchase, activation, load or reload operation anywhere in the 1,064-page v1.0 reference, so nothing lets a guest BUY value; the balance lives on a voucher rather than on the guest, and the Customer object (CustomerId, RegistrationDate, PhoneNumber, CashOrdersEnabled, CardOrdersEnabled, MarketingEnabled) has no balance field, so a guest cannot hold one wallet across instruments; there is no stored-value tender in the closed PaymentAccountType enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) nor in the v3.0 sale paymentMethod enum (Cash, Credit, Online, PhonePayment, ExternalPayment), so a redemption is recorded as a discount rather than as a gift tender; and the word 'gift' appears in the 27.6MB v1.0 dump only inside the App Store category name GiftCard - Flipdish's own App Store category enum lists GiftCard as a partner-integration category alongside PointOfSale, CRM, Accounting and LoyaltyAndMarketing (/v1.0/reference/getappstoreapp), which is where a gift-card product appears to come from. www.flipdish.com/products-overview's phrase 'view their purchase history, loyalty and account balances' is consistent with the CreditNote balance but names no gift card. help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/updatevoucher · retrieved 2026-08-09

labor-clock-in-at-pos

Attendance is tracked against rotas with 'live updates' from the POS ('keep an eye on who's working'); a PIN/badge punch mechanism is not explicitly documented. https://www.flipdish.com/pos-system/payroll-management · retrieved 2026-08-01

labor-photo-punch-verification differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The staff identification methods the platform exposes are account credentials: /api/v1.0/accounts/login/pin, /api/v1.0/accounts/pin, /api/v1.0/accounts/password/pin and /api/v1.0/accounts/login/sso, alongside the RFID card login named on www.flipdish.com/products-overview. The App resource enum at /v1.0/reference/getapp-1 is the platform's complete permission surface and contains no photo, camera, image-capture or biometric resource among its 204 members; 'facial' and 'biometric' occur zero times in the 27.6MB dump, and the only occurrences of 'photo' anywhere in it are the sales-channel name Photon and brand cover-image URLs. But there is no employee, timecard, punch or attendance resource anywhere in either API version - the only staff entity is Teammate, a Portal user account (TeammateId, Name, Email, LastActivity, InvitationStatus, AppAccessLevel, StoreIds) - so the API cannot see how a punch is captured, and its silence is not evidence. The labour module's manual is on help.flipdish.com, excluded by policy. Unresolved.

labor-geofenced-mobile-punch

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The only geographic constructs in the 1,064-page v1.0 reference are delivery zones and store location (/api/v1.0/stores/{storeId}/deliveryzones, Coordinates, MapCenter, MapNorthEast) and store location-areas - all about where a customer is, never where an employee is. 'clockIn', 'timecard' and 'punch' return zero hits across the 27.6MB v1.0 dump and the 4.6MB v3.0 dump, and the payroll module surfaces only as permissions in the App resource enum (ViewPayrollReports, Edit/ViewPayrollHoliday, Edit/ViewPayrollRota, Edit/ViewPayrollStaff) with no endpoint behind them, so the rota and attendance data is Portal-only and cannot be inspected here. www.flipdish.com/products-overview describes login as RFID at the terminal and the Manager Mobile App as a sales-monitoring tool, not a punch clock. An API that models no timecard cannot show whether a mobile punch is geofenced; help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-offline-time-punch differentiator

Flipdish POS does not support offline mode. Time punching requires cloud connectivity. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

labor-granular-rbac

'Set permissions per module' and 'Easily control who can get access to what, give freebies or discounts'; per-discrete-action and per-location granularity is not documented. https://www.flipdish.com/pos-system · retrieved 2026-08-01

labor-manager-override-audit

Partial. Present: attribution and queryability are both documented. The v1.0 API exposes a read API over the platform's event log - GET /api/v1.0/{appId}/events/user/{userId}, /events/order/{orderId}, /events/store/{storeId}, /events/customer/... and /events/{eventId} - each taking limit, page, start and end date-time parameters, so the trail can be queried after the fact by actor, by order or by window. The events that correspond to manager overrides carry the actor: OrderRefundedEvent and OrderRejectedEvent each embed User (UserEventInfo - UserId, UserName, UserPhoneNumber, UserEmail) together with IpAddress, CreateTime and, for the rejection, Reason; configuration changes do the same and add a diff, e.g. StoreFeeConfigUpdatedEvent carries User, IpAddress and Changes ('Diff between before and after'), and StoreServiceChargeUpdatedEvent carries User and the resulting ServiceCharge. www.flipdish.com/products-overview confirms the gate these events sit behind: 'Manager Approvals - Specify when your staff would need manager approval for actions like applying discounts or refunds', with Roles and Permissions and RFID Login identifying the individual. The Portal exposes the same trail through about twenty distinct view permissions in the App resource enum (ViewOrdersAuditLogs, ViewUserEventsAuditLogs, ViewVouchersAuditLogs, ViewTeammatesAuditLogs, ViewCampaignsAuditLogs, ViewStoreAuditLogs and more, /v1.0/reference/getapp-1). Named shortfalls: (1) immutability is asserted nowhere on either permitted host - no retention period, no tamper-evidence, no write-once statement; (2) the coverage is uneven at exactly the point the claim cares about - VoucherAppliedEvent carries VoucherId, OrderId, CreateTime, AppId and IpAddress but NO User block, so a discount applied at the till is not attributed to an individual in the published event schema, while a refund is; (3) the only audit endpoints in the newer v3.0 surface are write-only and beta (POST /auditLogs/orgs/{orgId}, 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice'), so the queryable trail is the older v1.0 surface. help.flipdish.com is excluded by policy. https://developers.flipdish.com/v1.0/reference/getuserevents · retrieved 2026-08-09

labor-native-scheduling differentiator

Native, first-party, and documented step-by-step in the Flipdish Help Centre (article dated 2026-06-30). Portal > Add-ons > Payroll > Rota; load a date range, then 'Click a day of the week you wish to add working hours to for a particular staff member', set start/end via 'from' and 'to' dropdowns, Save. Shifts can be replicated with Copy/Paste across days, and the rota is committed with 'Click Publish at the top of the page once you have completed the rota'; 'This rota will then show in the Rota section of your Point of Sale.' Pending holiday requests render in-grid as blue boxes against hours worked in black boxes, and Add-ons > Payroll > Holiday Planner approves via an 'Approve Booking Request' dropdown with an 'Is Holiday Paid' flag. Requires store-manager-level access. No partner scheduling vendor is involved. Not documented: forecast-driven or demand-based scheduling, labour-cost-target enforcement at build time, shift swaps, or predictive-scheduling compliance. https://help.flipdish.com/en/articles/9585183-manage-staff-rotas · retrieved 2026-08-02 · not refetchable · site policy · graded B when read adversarially verified

labor-demand-labor-forecast differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The App resource enum (/v1.0/reference/getapp-1) is the platform's complete permission surface, and its entire labour section is ViewPayrollReports, EditPayrollHoliday, ViewPayrollHoliday, EditPayrollRota, ViewPayrollRota, EditPayrollStaff, ViewPayrollStaff - no forecast, recommendation, demand or scheduling-suggestion resource, and nothing labour-shaped among the statistics permissions either (ViewSalesStatistics, ViewOrderStatistics, ViewLiveStatistics, ViewCampaignsStatistics, ViewCustomerStatistics). No endpoint in the 1,064 pages reads or writes a rota, shift or labour hour. That constrains the module's shape but cannot show whether the rota screen proposes hours: a permission enum gates access, it does not enumerate features. On www, /products-overview names 'Sales Forecast - Use the projected sales tool to plan for inventory costs as well as staff scheduling' and /pos-system/reporting-and-analytics frames staffing as a manager decision read off live data; www.flipdish.com/labs still lists staff scheduling among 'innovations we are excited about'. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-realtime-labor-percent differentiator

Live wage-cost monitoring alongside real-time sales; labour as a percentage of sales on a manager view is not explicitly stated. https://www.flipdish.com/pos-system/payroll-management · retrieved 2026-08-01

labor-overtime-prevention differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'Overtime' occurs zero times in the 27.6MB v1.0 dump and zero times in the 4.6MB v3.0 dump, and there is no timecard, shift, punch or hours resource whose schema could carry a threshold - the labour module appears only as four permission pairs in the App resource enum (Payroll Reports, Holiday, Rota, Staff, /v1.0/reference/getapp-1) with no endpoints behind them, so the whole rota and attendance surface is Portal-only. www.flipdish.com/pos-system/payroll-management remains the dedicated labour page and covers rota creation, real-time attendance visibility, wage-cost tracking and holiday approve/reject, with no shift cap, threshold or warning; /products-overview adds only the 'payroll calculator'. A warning at clock-in is an in-product behaviour that an integration API would not necessarily expose, so this is undocumented on the hosts I may read rather than shown absent. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-break-compliance-by-state differentiator

The staff-management collection documents the complete timekeeping surface and it contains no break handling: clock-in/out is PIN or RFID with role selection and an automatic forced clock-out after a configured timeout (9585332); the rota is a manual from/to dropdown grid with copy/paste and Publish (9585183); the rota/clock-in report offers only print/export of hours worked and holiday requests (9585292); and the payroll calculator's per-staff outputs are gross/net wage, NI, HMRC and PAYE with no premium-pay concept (9585185). No jurisdiction-configurable break rules, break attestation prompts or missed-break premium flags exist anywhere in the documented labor surface. https://help.flipdish.com/en/articles/9585332-how-to-use-the-clock-in-and-clock-out-feature-on-flipdish-pos · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

labor-fair-workweek-support

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). No predictive-scheduling vocabulary appears anywhere - 'predictability', 'advance notice', 'good faith estimate' and 'schedule change premium' return zero hits across both dumps - and there is no scheduling, shift or published-schedule resource whose schema could carry a deadline or a premium calculation; the rota lives entirely behind the four Payroll permissions in the App resource enum (/v1.0/reference/getapp-1). The platform is not US-blind: the App Store country enum includes US, CA and MX (/v1.0/reference/getappstoreapp), the currency enum includes USD, and www.flipdish.com publishes a United States locale with US customer stories - so the claim is in scope, merely unevidenced. Flipdish's labour vocabulary on www is UK/Irish throughout ('rota', 'holiday requests', www.flipdish.com/pos-system/payroll-management). help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-minor-labor-rules

Scheduling is documented as an unconstrained manual grid — click a day, 'Select the start time and end time using the from and to dropdowns', copy/paste hours across days, Publish (9585183) — with no rule engine of any kind, and clock-in enforces only PIN/RFID identity plus a forced clock-out timeout (9585332). No age, minor, school-day or prohibited-time-window concept appears anywhere in the staff-management collection, so there is no enforcement point at either scheduling or clock-in. https://help.flipdish.com/en/articles/9585183-manage-staff-rotas · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

labor-tip-pooling-rules

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). Tips are now fully visible on the capture side and absent on the distribution side. TipConfiguration (/api/v1.0/stores/{storeId}/tipconfig, 'Describes the configuration of tipping') is a per-store guest prompt: IsEnabled, AllowCustomTips, AllowRoundUp, AllowEmojis, Percentages ('Ordered list of tip breakpoints') and DefaultPercentage. The money lands as a single Order.TipAmount with no employee, role, shift or share field (/v1.0/reference/getorderevents), and the only other tip fields are Flipdish's own commission lines in StoreFeeConfig (PercentFeeTips, PercentFeeTipsCollection, PercentFeeTipsDelivery). There is no tip-pool, tip-out, distribution, share or points resource in any of the 1,064 v1.0 pages, and in v3.0 a tip is a sale-level charges[] line of type 'Tip'. But tip distribution is a back-office calculation that would run in the Portal's payroll module - which exists (ViewPayrollReports, Edit/ViewPayrollStaff in the App resource enum) but has no endpoints - so an API absence cannot settle it. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-tip-distribution-audit-trail

Positive absence: the Tips Report doc enumerates every metric in Flipdish's tip reporting — total tips, delivery vs pick-up tips, refunded tips, tips per store, tips per week — all at store/channel level, none per employee or per shift. The per-staff payroll breakdown enumerates gross/net wage, NI, HMRC contribution and PAYE only, with no tips line (payroll calculator, article 9585185), and no tip-pooling, contribution or distribution feature appears anywhere in the Help Centre title census. A per-shift, per-employee record of pool contributions and distributions cannot be produced from the documented surface. https://help.flipdish.com/en/articles/9585606-tips-report · retrieved 2026-08-03 · not refetchable · site policy · graded B when read

labor-qualified-tips-w2-reporting differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). A tip exists in exactly two shapes and neither can support the claim: Order.TipAmount, a single number on the order with no employee attribution and no cash/charged split (the order's separate PaymentAccountType describes how the ORDER was paid, not the tip), and Flipdish's own commission fields PercentFeeTips / PercentFeeTipsCollection / PercentFeeTipsDelivery in StoreFeeConfig. There is no occupation code, no W-2, Box 12, Box 14 or Treasury field, and 'W-2' and 'occupation' return zero hits across the 27.6MB v1.0 dump and the 4.6MB v3.0 dump; the payroll module has no endpoints at all, only the four permission pairs in the App resource enum (/v1.0/reference/getapp-1), so no payroll export format can be inspected. Flipdish does sell into the United States (US in the App Store country enum, USD in the currency enum, a US locale and US customer stories on www), so the claim is in scope. www.flipdish.com/pos-system/payroll-management and /products-overview describe a rota tool and a wage-cost 'payroll calculator' in UK/Irish terms and name no filing capability. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-native-payroll differentiator

Positive absence. The App object's AppResourceSet ('Constitutes a list of available resources') is the closed enum of every permissioned resource on the platform - 204 members covering apps, teammates, orders, stores, menus, vouchers, campaigns, bank accounts, payouts, kiosks, catalogs, the App Store, and the back-office suite (Accounts bills/categories/credit accounts/credit books/expenses/transaction accounts, Inventory purchase orders/stock items/suppliers/tracking profiles, Document Explorer). Its entire payroll section is seven members: ViewPayrollReports, EditPayrollHoliday, ViewPayrollHoliday, EditPayrollRota, ViewPayrollRota, EditPayrollStaff, ViewPayrollStaff. There is no payroll-run, pay-period, payslip, tax-filing, statutory-return or employee-payment resource, and no such endpoint exists in the 1,064-page v1.0 reference or the 99-page v3.0 reference; the only money-out objects in the platform are BankAccount and its payouts, chargebacks and refunds, all of which pay the MERCHANT (/api/v1.0/{appId}/bankaccounts/{bankAccountId}/payouts/{payoutId}). 'Payroll' occurs zero times in the v3.0 corpus and only inside those seven permission strings in v1.0. Both first-party product descriptions match: www.flipdish.com/pos-system/payroll-management offers 'easy rota creation, real-time tracking, and efficient payroll oversight ... Keep an eye on wage costs with up-to-date tracking. Plus, handle holiday requests easily', and www.flipdish.com/products-overview says 'Payroll - Use the payroll calculator to work out the wages that have been paid previously and also the upcoming payroll so you know how much to budget for staff wages for the next period.' Neither mentions tax filing, direct deposit, payslips or an employer-of-record arrangement. Scope of the finding: this asserts Flipdish does not itself process payroll as a first-party product, not that the rota and wage-cost module lacks other features; help.flipdish.com is excluded by policy and was not read. https://developers.flipdish.com/v1.0/reference/getapp-1 · retrieved 2026-08-09

labor-payroll-export-formats

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). Two new artefacts, neither decisive. The App Store app model's Categories enum is closed at PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other (/v1.0/reference/getappstoreapp) - no payroll or HR category - but a Gusto or ADP connector would sit under Accounting or Other, so this cannot carry an absence finding. And there is no timecard, wage, hours or tip-export endpoint anywhere in the 1,064 pages; exports that do exist are financial (payout, chargeback, refund and order CSV exports under /api/v1.0/{appId}/bankaccounts/{bankAccountId}/payouts/{payoutId}/...) and a DownloadCustomerCsvExport permission. The payroll module has no endpoints at all, only the four permission pairs in the App resource enum, so its export formats are invisible here. www.flipdish.com/integrations, read in full on 2026-08-09, lists POS, last-mile and 'other' partners (Deliverect, ItsaCheckmate, UrbanPiper, Zapier) with no payroll provider, but each group closes with 'And more! Can't find what you're looking for? Just get in touch' - a self-declared incomplete directory. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-shift-swap-workflow differentiator

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). The rota exists as a permissioned Portal module and nothing more that I can see: EditPayrollRota / ViewPayrollRota and EditPayrollHoliday / ViewPayrollHoliday in the App resource enum (/v1.0/reference/getapp-1), with no endpoint in the 1,064-page v1.0 reference or the 99-page v3.0 reference that reads or writes a shift, a schedule, a swap or a shift-claim, and no request or approval object of any kind for staff. 'Shift' and 'swap' return zero hits in both dumps. Note the enum does distinguish an employee-initiated approval loop elsewhere - holiday has its own permission pair, matching www.flipdish.com/pos-system/payroll-management's 'handle holiday requests easily - approve or reject them with just a click' - while no equivalent shift-request permission exists; that is suggestive but a permission enum gates access rather than enumerating workflows. help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-digital-onboarding-i9

Second pass, 2026-08-09, over the 1,064-page v1.0 API reference at developers.flipdish.com (local dump .cache/flipdish/developers-v1.txt, pulled from /v1.0/llms.txt on 2026-08-09). 'Onboarding' occurs 234 times in the 27.6MB dump and every occurrence is merchant onboarding - /api/v1.0/clients/{appId}/onboarding/config, the ViewOnboarding / UpdateOnboarding permissions, the CreateTeammateOnboarding role and the account sign-up step endpoints (/api/v1.0/accounts/signupstep/{signupStepAction}/answer and /skip) - i.e. getting a restaurant live on Flipdish, not hiring a member of staff. On the employee side the platform exposes only EditPayrollStaff / ViewPayrollStaff and EditDocumentExplorer / ViewDocumentExplorer in the App resource enum (/v1.0/reference/getapp-1), matching www.flipdish.com/products-overview's 'Document Management - Store and manage all your documents in one central location', with no endpoints behind either. W-4, I-9, E-Verify, e-signature and tax-form vocabulary return zero hits across both dumps. Neither permitted host describes a new-hire flow, and help.flipdish.com, where the product manual lives, is excluded by policy (its robots.txt names ClaudeBot with Disallow: /). Unresolved.

labor-server-performance-metrics differentiator

Per-staff reporting is claimed twice on this page: 'Customisable Reports - Build your own reports and quickly drill into your data to see how your store, your products and your staff are performing', and 'Staff Upsells' is one of the named Report Types ('View reports on Costs, Sales, Sales Channels, Customers, Campaign performance, Payments, Staff Upsells, Menu Items Ordered, Mileage, Inventory, Payroll, Hourly Turnover and more'). Shortfall: 'Staff Upsells' - an attachment-rate metric - is the only per-employee measure named anywhere on the two permitted hosts; average check per server, void rate and comp rate by employee are named on neither this page nor www.flipdish.com/pos-system/reporting-and-analytics, whose sales-report examples are by channel, dispatch type, payment method and store. The evidence is a vendor marketing feature list (grade D), which the differentiator grade floor bars from carrying a yes, and the report catalogue itself is documented on help.flipdish.com, excluded from this sweep by policy. https://www.flipdish.com/products-overview · retrieved 2026-08-09

inventory-recipe-bom-costing

'Recipe builder' and inventory cost insight 'even on the level of single-ingredient items'; multi-level sub-recipes and automatic plate-cost recalculation are not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

inventory-unit-conversion-yields

Stock items store a Measurement Type/Unit plus named stock units each with an explicit conversion factor — 'Enter the conversion factor (This is how you will typically break down the unit, for example, an onion, which would be within a bag of onions which would be the unit in this case)' — separate operational units per stock-item operation type, and recipe profiles with a base quantity and base-quantity unit (9585131). Shortfall: no yield or waste percentage applied to raw-to-usable conversion is documented anywhere — wastage exists only as an 'Is Wastage Tracked' flag feeding a POS Wastages Report, not as a conversion-time yield factor. https://help.flipdish.com/en/articles/9585131-add-and-edit-stock-items · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

inventory-theoretical-vs-actual differentiator

Cost reporting covers 'COGs, inventory, wastage, discrepancies, and profitability' — 'discrepancies' implies variance, but no theoretical-vs-actual methodology is documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

inventory-realtime-depletion differentiator

Re-checked on 2026-08-09 against the second, larger corpus on the same permitted host: the 1,064-page v1.0 API reference (.cache/flipdish/developers-v1.txt, pulled from developers.flipdish.com/v1.0/llms.txt). It adds one real fact the v3.0 corpus did not have: the App schema at /v1.0/reference/getapp-1 (/api/v1.0/apps/{appId}) publishes an AppResourceSet enum described as 'Constitutes a list of available resources', and that ~200-entry permission catalogue names EditInventoryStockItems, ViewInventoryStockItems, EditInventoryTrackingProfiles, ViewInventoryTrackingProfiles, EditInventorySupplier, EditInventoryPurchaseOrders and ViewInventoryReports. So Flipdish ships an inventory module with stock items and 'tracking profiles'. What neither corpus contains is any inventory ENDPOINT, schema or event: across 1,064 v1.0 pages and 99 v3.0 pages there is no stock, ingredient, recipe or depletion resource, and the order/sale schemas carry no stock movement. Depletion timing (near-real-time vs batch) and modifier-driven depletion are in-product behaviour documented only in help.flipdish.com, which is excluded from this sweep by policy (its robots.txt names ClaudeBot with Disallow: / and Content-Signal: ai-train=no). www.flipdish.com/pos-system/reporting-and-analytics asserts 'real-time cost reporting at the ingredient level' but is grade C marketing and cannot carry a differentiator yes.

inventory-86-auto-sync differentiator

Re-checked 2026-08-09 in the 1,064-page v1.0 API reference as well as the 99-page v3.0 dump. v1.0 adds a second, older availability mechanism to the v3.0 snooze endpoints: 'Bulk show/hide menu items or option set items' and 'Get bulk show/hide menu items and option set items' operations, plus an UpdateMenuItemsHideTemporarily entry in the App permission catalogue (/v1.0/reference/getapp-1). Like snooze, every one of these is an explicit operator or integrator action on an item. Neither corpus contains an ingredient, on-hand quantity, threshold or reorder-point field anywhere, so no automatic component-driven 86 trigger is expressed in either API version - even though the same permission catalogue shows an inventory module with stock items exists. Whether the merchant portal's inventory module fires a hide/snooze on its own, and whether it propagates to third-party delivery menus, is product-manual behaviour and help.flipdish.com is excluded by policy; www.flipdish.com/pos-system only says operators can 'easily snooze items when you run out'.

inventory-count-modes

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference (developers.flipdish.com/v1.0/llms.txt) in addition to the v3.0 dump and www. The v1.0 App permission catalogue (/v1.0/reference/getapp-1) establishes that stock items, suppliers, purchase orders, tracking profiles and inventory reports are real product surfaces, but there is no counting vocabulary anywhere in either corpus: no count sheet, spot count, cycle count, variance, on-hand or adjustment object, and no inventory endpoint of any kind among the 1,064 v1.0 operations. On www.flipdish.com the only inventory material remains feature-page copy (/pos-system, /pos-system/reporting-and-analytics), which names no count workflow and is not an enumeration of the module's screens. The counting workflow, if it exists, is documented in help.flipdish.com, which this sweep may not read (robots.txt names ClaudeBot with Disallow: /).

inventory-mobile-count-offline

A mobile counting app exists, refuting the earlier 'no': the Flipdish RMS app (Google Play / Apple App Store) includes 'Stock Taking - where you can take stock of items bi-weekly, daily, monthly or weekly', plus wastage logging and purchase orders, with per-item tracking profiles assigned from the Portal surfacing in the app (9585124). Shortfalls: tablet-only ('not compatible with phone or laptop'), gated behind a Food safety / Inventory Management subscription and activation by the Flipdish team; barcode scanning is documented only as a USB scanner on the POS front-of-house device (9585145), not in the RMS counting flow; and offline count capture with sync-on-reconnect is documented nowhere — the POS offline FAQ (9585187) covers the POS, not this app, so the claim's offline half is unverified rather than supported. https://help.flipdish.com/en/articles/9585175-flipdish-rms-restaurant-management-system-app-overview · retrieved 2026-08-05 · not refetchable · site policy · graded B when read adversarially verified

inventory-vendor-catalogs-edi differentiator

Re-checked 2026-08-09 including the 1,064-page v1.0 API reference. That corpus firms up the near half of the question - the App permission catalogue at /v1.0/reference/getapp-1 lists EditInventorySupplier / ViewInventorySupplier and EditInventoryPurchaseOrders / ViewInventoryPurchaseOrders, so supplier records and purchase orders are shipped product objects, matching www.flipdish.com/pos-system/health-food-safety-management ('manage your suppliers and purchase orders from one central place'). It settles nothing about electronic transmission: neither API version defines a supplier, catalogue, purchase-order or invoice endpoint, and the words EDI, punchout, broadline, Sysco, US Foods and Performance Food Group appear nowhere in 27.6MB of v1.0 reference plus 4.6MB of v3.0 docs. www.flipdish.com/integrations lists POS, last-mile and 'other' partners with no food distributor, but ends 'Can't find what you're looking for? Just get in touch', so it is an incomplete directory. The purchasing manual is on the excluded help centre.

inventory-invoice-ocr differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. New context, not a resolution: the App permission catalogue (/v1.0/reference/getapp-1) enumerates an accounting surface - EditAccountsBills/ViewAccountsBills, EditAccountsExpenses, EditAccountsCategories, EditAccountsCreditAccounts, EditAccountsCreditBooks, EditAccountsTransactionAccounts - and EditDocumentExplorer/ViewDocumentExplorer, i.e. a document store, plus the inventory purchase-order permissions. That makes supplier-invoice handling a real part of the product, but nothing published on either permitted host says how a bill gets in. There is no invoice-ingest, OCR, scan or document-parse endpoint among the 1,064 v1.0 operations (the only /invoices endpoints, /api/v1.0/{appId}/invoices and ListSubscriptionInvoices, are Flipdish's own subscription billing to the merchant), and no www page describes capture. Only help.flipdish.com could settle it and it is excluded by policy.

inventory-price-change-alerts differentiator

Re-checked 2026-08-09 including the 1,064-page v1.0 API reference. The v1.0 App permission catalogue (/v1.0/reference/getapp-1) names ViewCostReports and ViewInventoryReports as distinct report families and Edit/ViewInventoryPurchaseOrders, so received-cost data plausibly exists in the product; www.flipdish.com/pos-system/reporting-and-analytics claims real-time COGs reporting. But neither API version exposes a purchasing, receiving or supplier-price resource, there is no price-history, contracted-price or variance-threshold field in 27.6MB of v1.0 schemas, and the only alerting anywhere on the permitted hosts remains the food-safety email/SMS alerts on /pos-system/health-food-safety-management. Whether the inventory module alerts on a received price above a threshold is portal behaviour documented in help.flipdish.com, which is excluded by policy.

inventory-par-auto-suggest differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. The nearest new artefact is the pair EditInventoryTrackingProfiles / ViewInventoryTrackingProfiles in the App permission catalogue at /v1.0/reference/getapp-1 - a named inventory feature whose semantics are documented nowhere on the permitted hosts, and which may or may not be par management. No par level, reorder point, suggested order or forecast field appears anywhere in the 1,064 v1.0 pages or the 99 v3.0 pages, and there is no inventory endpoint to carry one. On www, /labs still frames 'full end to end inventory tracking based on predictions from ordering historicals' and 'automated inventory ordering' as work the Labs team is doing, not shipped behaviour, and /pos-system says nothing about pars. The shipped module is documented only in the excluded help centre.

inventory-waste-logging

Wastage is a named line in cost reporting; a structured reason-coded logging workflow is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

inventory-transfers

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. v1.0 is far richer than v3.0 on multi-location structure - /api/v1.0/{appNameId}/storegroups, /api/v1.0/{appId}/storegroups/{storeGroupId}/assignStores, /api/v1.0/properties/{propertyId}/stores, /api/v1.0/stores/{storeId}/clone, /api/v1.0/stores/{storeId}/propertyId/{propertyId} - and none of it moves stock. There is no transfer, issue, receipt, in-transit or approval object anywhere in either API version, and no inventory endpoint at all, even though the App permission catalogue (/v1.0/reference/getapp-1) shows a stock-item module exists. www.flipdish.com/pos-system asserts multi-outlet scope for inventory but describes no transfer workflow. Unresolved; the inventory manual is on help.flipdish.com, excluded by policy.

inventory-commissary

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference in addition to the v3.0 dump and www. Full-text search of the 27.6MB v1.0 corpus returns zero hits for commissary, central kitchen, production order, prep item and transfer cost, and v1.0 exposes no inventory or production endpoint - the only cross-store objects are store groups, properties and menu/catalogue assignment. Flipdish's published positioning (QSR, takeaway, kiosks, online ordering) makes a commissary model plausibly out of scope, but no source on either permitted host says so, and an API reference that omits inventory entirely cannot evidence what the inventory module does. help.flipdish.com, which holds that manual, is excluded by policy.

inventory-lot-traceability

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Zero hits for lot, batch number, traceability, recall or receiving across the 27.6MB v1.0 corpus, and no receiving or inventory endpoint exists to carry them; the only food-safety-adjacent data in either API version is menu allergen and nutrition information (Get allergens, Add or update menu nutrition by identifier). www.flipdish.com/pos-system/health-food-safety-management, read in full on 2026-08-09, describes opening/closing checks, cleaning checklists, temperature logs with photo evidence, incident logging and expiry/allergen/nutrition labels - no lot or batch capture and no recall trace - but that page is marketing copy, not an enumeration of the module's fields, so its silence is not evidence of absence. The help centre that would settle it is excluded by policy.

inventory-shelf-life-expiry

Flipdish's Health and Food Safety module has staff 'log opening and closing checks, appliance temperatures, and food expiry dates - all from one simple dashboard', and the kitchen printer prints 'clear labels showing expiry dates, allergen, and nutritional information'. So use-by dates are captured on prepped/labelled items and on logged stock. The shortfall: the page describes proactive alerting only generically ('alerts via email and SMS flagging any hazards or food safety issues') and names no expiring-soon report, no configurable lead time and no per-item expiry alert; nor does it say expiry is captured at receiving against supplier deliveries. This is a vendor feature page (grade C), not documentation - the module's actual fields are in the help centre, which is excluded on this record by policy. https://www.flipdish.com/pos-system/health-food-safety-management · retrieved 2026-08-09

inventory-bar-partial-bottle

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Zero hits for bottle, pour, liquor, weight-based, scale or flow meter across the 27.6MB v1.0 corpus; the v1.0 App Store app taxonomy (/v1.0/reference/getappstoreapp) enumerates partner categories as PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing and Other, with no beverage or hardware category. www.flipdish.com/pos-system/hardware names no scale and the integrations directory names no beverage-dispense partner, but both lists are explicitly open ('mix and match', 'Can't find what you're looking for?'). Flipdish sells to takeaways and QSR rather than bars, so this may be out of product scope, but no source states that and help.flipdish.com is excluded by policy.

inventory-cogs-gl-export

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. The App permission catalogue at /v1.0/reference/getapp-1 shows Flipdish ships a native accounting surface - Edit/ViewAccountsBills, Edit/ViewAccountsCategories, Edit/ViewAccountsCreditAccounts, Edit/ViewAccountsCreditBooks, Edit/ViewAccountsExpenses, Edit/ViewAccountsTransactionAccounts - plus ViewCostReports and ViewInventoryReports, and the App Store taxonomy (/v1.0/reference/getappstoreapp) includes an 'Accounting' partner category. What is still missing on both permitted hosts is any statement of an export format or GL account mapping: the only export endpoints in 1,064 v1.0 operations are payout-report CSVs (/api/v1.0/{appId}/reporting/reports/payouts3/{bankAccountId}/{payoutId}/export/orders, .../export/ledgerentries, .../export/possales, .../export/chargebacks) and a reporting CSV download (/reporting/v1.0/{appNameId}/csv/{csvId}), none of which is a QuickBooks, Sage Intacct or NetSuite format, and no GL-account field exists in any schema. www.flipdish.com/integrations names no accounting system but is an open-ended directory. Unresolved without the excluded help centre.

inventory-native-not-partner differentiator

The cited /docs/pos-features page is, despite the /docs/ path, a marketing feature list — I read it end to end and it is a flat bullet grid ('Inventory management', 'Recipe builder', 'Food sales and costs calculations') with no screenshots, no configuration detail, and no statement of first- vs third-party provenance. Flipdish's own integrations directory is dominated by other vendors' POS systems, so 'nothing contracted out' cannot be inferred from a bullet. First-party is plausible but undocumented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01 adversarially verified

inventory-menu-margin-linkage differentiator

Reporting joins 'food sales and costs' and profitability with best-selling item data; a per-item contribution-margin view with threshold flagging is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

reporting-realtime-dashboard

Reports available 'in real-time, from your mobile, POS, or back office'; a management app is a listed POS feature. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

reporting-eod-closeout

Partial: an end-of-day report is a first-class documented resource, but a narrow one. GET /api/v1.0/stores/{storeId}/endofdayreport takes a store and a date and returns StoreEndOfDayReport, whose published response enumerates OrderCount, OrderValue, OrderValueExcludingDeliveryFees, the collection/delivery split (CollectionOrderCount/Value, DeliveryOrderCount/Value) and the tender split (CashOrderCount/Value, PaidOnlineOrderCount/Value, and the same excluding delivery fees) plus StartTime, EndTime and Currency; the v1.0 App permission catalogue gates it as ViewSalesEndOfDayStatistics (/v1.0/reference/getapp-1). Shortfall: that schema carries no tax, no tips, no discounts, no refunds and no expected cash deposit, and tender resolution stops at cash vs paid-online - the sale-level fields for tax, tips, discounts and refunds exist only in the separate v3.0 Sales Management API, not in this report. Whether the merchant portal renders a richer single reconciling document is in-product behaviour documented in help.flipdish.com, which is excluded from this sweep by policy. https://developers.flipdish.com/v1.0/reference/getendofdayreport · retrieved 2026-08-09

reporting-pmix-modifier-level

Best-selling menu items, hourly sales and sales by channel/dispatch type/payment method are documented; modifier-level PMIX is not. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

reporting-comps-voids-audit

Partial: GET /api/v1.0/{appId}/events is a queryable audit feed filterable by storeId, storeIdList, storeGroupId, userId, userEmail, userName, voucherCode, eventType and a start/end date range. Its published examples show OrderRefundedEvent carrying RefundedAmount, a User object (UserId, UserName, UserEmail), IpAddress and CreateTime ('Store refunded 2,00 from 15,00 for an order (#1234)'), and OrderRejectedEvent carrying Reason ('TIMED_OUT') plus the same User block; VoucherCreatedEvent/VoucherUpdatedEvent are likewise user-attributed. The App permission catalogue exposes ViewOrdersAuditLogs and ViewVouchersAuditLogs as separate grants. Shortfalls against the claim as worded: refunds and rejections are the only order-side exception events - there is no comp or void object distinct from a refund, no price-override event, no manual-discount-applied event with an operator (voucher.applied carries no User at all), no manager/approver attribution anywhere, and no reason code on a refund. Whether the portal renders these as a single exception report is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getevents · retrieved 2026-08-09

reporting-cash-over-short

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Half the inputs are now documented: GET /api/v1.0/stores/{storeId}/endofdayreport returns CashOrderCount and CashOrderValue per store per day, i.e. expected cash from tendered transactions, and PaymentAccountType on an order enumerates Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen and GoogleWalletToken. The other half is absent from both API versions: full-text search of the 27.6MB v1.0 corpus returns zero hits for drawer, paid-out and counted cash, there is no till session, shift or float object, and no employee identifier exists on any order or payment, so per-drawer, per-shift and per-employee reconciliation cannot be expressed in the API. (The only cash-adjacent device endpoints, /api/v1.0/{appId}/kioskcashsettings/{deviceId} and kioskupdatecashsettings, configure kiosk cash acceptance and visibility, not reconciliation.) Drawer counting is a terminal and portal workflow documented in help.flipdish.com, which is excluded by policy.

reporting-labor-productivity

Wage cost is tracked live against sales; sales per labour hour by hour/department/employee is not documented. https://www.flipdish.com/pos-system/payroll-management · retrieved 2026-08-01

reporting-server-scorecards differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference, which contains a dedicated ElasticSearch-backed Reporting API the v3.0 corpus does not expose (/reporting/v1.0/{appNameId}/order/overview, /order/heatmap, /order/store, /order/platform, /order/deliverytype, /order/paymenttype, /order/rejectionreason, /stores/search, /voucher/search, /customers/overview). Its published query parameters are the complete dimension list: StoreId, DeliveryType, Platform, PaymentType, VoucherCodes, DeliveryZones, CurrencyFilter, GraphGranularity, UserTimezone and MainPeriod/ComparePeriod - there is no staff, server or employee dimension, and no order or sale schema in either API version carries an employee identifier (zero hits for StaffId, EmployeeId, ServedBy, CashierId across 27.6MB). That is positive evidence about the API surface only. The same corpus shows a payroll module exists in-product (Edit/ViewPayrollStaff, Edit/ViewPayrollRota, ViewPayrollReports in the App permission catalogue at /v1.0/reference/getapp-1), so staff records do exist somewhere the API does not reach, and www.flipdish.com/pos-system/reporting-and-analytics is marketing copy rather than an enumeration. The report screens are in the excluded help centre, so this stays unresolved rather than a finding of absence.

reporting-channel-profitability differentiator

Sales by channel and dispatch type plus profitability reporting; margin net of marketplace commission per channel is not documented. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01

reporting-multiloc-drilldown differentiator

Multi-location comparison reporting is documented ('full visibility on reports from all your sites from one place'); drill-down to an individual transaction is not stated, though listOrgSales/getSale provide it via API. https://www.flipdish.com/pos-system · retrieved 2026-08-01

reporting-custom-report-builder differentiator

The entire evidentiary basis is one marketing sentence: 'Tailor custom reports to suit the specific needs of your business so you can view only the information you need to see.' That describes column/filter selection on canned reports, not a dimension-and-measure report builder. No saved reports, no scheduling, no export — I confirmed the page makes no scheduling or export claim whatsoever. https://www.flipdish.com/pos-system/reporting-and-analytics · retrieved 2026-08-01 adversarially verified

reporting-scheduled-delivery

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Two new facts, neither decisive. (1) Flipdish's analytics is embedded Looker: /api/v1.0/{appId}/looker/dashboards lists dashboards and /api/v1.0/{appId}/looker/sso mints an SSO embed URL for an embedPath. Looker's own scheduling is not a Flipdish-documented feature and I will not infer it. (2) There is a pull-style export: /reporting/v1.0/{appNameId}/csv/{csvId} ('If successful will redirect to a download file') and the payout-report exports under /api/v1.0/{appId}/reporting/reports/payouts3/{bankAccountId}/{payoutId}/export/*. Against that, full-text search of the 27.6MB v1.0 corpus returns zero hits for recipient, cron, email report and report schedule; the only 'scheduled' objects in the entire corpus are scheduled push notifications (/api/v1.0/{appId}/pushnotifications/{scheduledPushNotificationId}), which are customer marketing. So no API schedules or delivers a report. Whether the portal emails reports on a cadence is documented only in help.flipdish.com's Reports collection, which is excluded from this sweep by policy.

reporting-raw-warehouse-export differentiator

Automated transaction-level extraction is documented, but not to a vendor-managed destination. The org-scoped read endpoints (GET /sales for an org, and per-property) return 'paginated complete sale objects for sync or export', sorted by createdAt descending with pageSize + opaque cursor and optional after/before UTC filters - a resumable incremental pull of the full sale payload. In push form, the v3 webhook catalogue's sale.created.v1 / sale.updated.v1 'carry the full sale payload inline' to an HTTPS callback URL you control, with at-least-once retries. Named shortfalls: no S3, SFTP, Snowflake or BigQuery destination exists anywhere in the 99-page developer corpus (zero hits for any of them) - the customer must build and host the receiver or the polling job; and both routes are gated, the Sales Management API carrying 'Beta ... Contact integrations@flipdish.com to request access' and the sale.* events marked 'this event is in closed beta - request access by emailing integrations@flipdish.com'. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-09

reporting-public-api differentiator

Self-service credentials verified first-hand: 'To interact with the Flipdish API you will need a Flipdish account. You can create one for free at https://portal.flipdish.com/signup', then avatar -> Developer tools -> OAuth apps -> Add New yields a Client ID and Secret Key, exchanged at POST https://api.flipdish.co/identity/connect/token with grant_type=client_credentials and scope=api. No signed partner agreement and no human in the loop for the v1.0 surface. Coverage: v1.0 publishes 1,067 documented operations spanning orders (getorders, getorderbyid, acceptorder, rejectorder, dispatchorder), customers, menus, stores and store settings, vouchers and loyalty, and payment settlement (reporting/reports/payouts3 overview, details and refundedOrders plus five CSV exports); v3.0 adds Org Management, Menu Management, Sales, Consumer Orders (still on v1.0), Operations Updates, Audit Logs, Webhook Subscriptions and Webhook Events at base URL https://api.flipdish.co. Maturity, now recorded: the v1.0 corpus marks its exceptions and only 8 of 1,064 pages carry a marker -- '[ALPHA - this endpoint is under internal development, it is not available just yet to use in your production system]' on order-ingest/submit, the two getconfiguredapps pages and five payout endpoints -- everything else is unmarked and shipped; on v3.0 the Sales API, Operations Updates and v3 webhooks are in closed beta, 'Email integrations@flipdish.com to request access and credentials'. No labor or timeclock endpoints exist, Flipdish shipping no labor product. The docs state no rate limits, no sandbox and no deprecation policy, so extensibility-published-rate-limits and extensibility-free-sandbox correctly remain unknown. https://developers.flipdish.com/docs/getting-started · retrieved 2026-08-09 adversarially verified

reporting-webhooks differentiator

Outbound webhooks to a customer-supplied HTTPS endpoint are real and self-serve (Portal Settings -> Webhooks, Owner or Managed Owner role), and the retry half is documented: 'Acknowledge with any 2xx', 'Retries are automatic (at-least-once semantics). Handlers must be idempotent', and the marketplace guide adds 'Flipdish times out after 10 seconds and retries'. Named shortfalls. (1) Signature verification is not shipped on the surface that publishes it: the same webhooks-v3 page that gives an HMAC-SHA256 verification code sample lists, in its delivery-contract table, '(planned) X-Flipdish-Signature -- HMAC-SHA256 signature for payload verification' and '(planned) X-Flipdish-Idempotency-Key' (page re-retrieved 2026-08-09, both lines still present). (2) The order and payment lifecycle events are not on a shipped tier: the v3 event catalogue marks only menu.published.v1, menu.validation.failed.v1, menu.item.snoozed/unsnoozed.v1 and sales_channel.snoozed/unsnoozed.v1 as 'Generally available'; sale.created.v1, sale.updated.v1 and sale.status.updated.v1 are Beta and llms.txt records them as 'in closed beta -- request access by emailing integrations@flipdish.com', while the legacy sales.* family is 'Deprecating soon' with 'Do not build new integrations against sales.*'. (3) The generally-available order-lifecycle webhook surface is v1.0 -- unmarked subscription CRUD at /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions, plus getwebhookeventnames, a test-fire endpoint and delivery logs carrying RetryCount, over order.created / order.accepted / order.rejected / order.refunded -- but v1.0 documents no signing scheme at all ('HMAC', 'signature' and 'X-Flipdish' each appear zero times across the 1,064-page v1.0 dump), and webhooks-v3 characterises legacy verification only as 'Legacy app secret, varied patterns'. So: signed-and-retried webhooks exist for menu events, order/payment events require closed-beta access, and the shipped order-event surface is unsigned. https://developers.flipdish.com/docs/webhooks-v3 · retrieved 2026-08-09 adversarially verified

reporting-api-not-upcharged differentiator

API access is self-serve and free: v1.0 Getting Started tells any user to create a Flipdish account 'for free at portal.flipdish.com/signup', then create an OAuth app under Developer tools and request client-credentials tokens against https://api.flipdish.co/identity/connect/token; no plan tier, per-location fee or revenue share is attached anywhere in the developer docs, and the add-on list on flipdish.com/pricing (kiosks, managed marketing, KDS, Uber Direct, customer feedback app, phone marketing) contains no API or data SKU. Raw transaction data is on the same footing: the v1.0 API ships GET /api/v1.0/orders and /orders/{id} (full order payloads including OrderItems, OrderItemOptions, Voucher, PaymentAccountType and TipAmount), /orders/summaries, /apm/statistics/orders/{aggregateDataBy} and the payouts3 reporting family with per-payout order, refund, chargeback and ledger-entry exports. None of these carry a maturity marker: the string 'Beta' appears zero times in the 1,064-page v1.0 corpus, and the only 8 pages marked '[ALPHA - ... not available just yet to use in your production system]' are order-ingest submit, getconfiguredapps x2 and five getpayout* balance endpoints. The v3.0 Sales Management API and its sale.* events are behind 'Contact integrations@flipdish.com to request access', but that is a beta-access gate on the newer surface, not a charge or a tier, and the shipped v1.0 surface already returns transaction detail. https://developers.flipdish.com/v1.0/reference/getorders · retrieved 2026-08-09 adversarially verified

reporting-tier-paywall differentiator

Re-checked 2026-08-09 on both permitted hosts including the 1,064-page v1.0 API reference. v1.0 does expose commercial objects - /api/v1.0/{appId}/subscriptions, /subscriptions/hasPaymentMethod, /api/v1.0/{appId}/invoices/ListSubscriptionInvoices, /api/v1.0/{appId}/appstore/apps/{appStoreAppId}/entitlements and /api/v1.0/orgs/{orgId}/kiosk/entitlements - but every one of them is an instance API over a merchant's own billing and entitlements; no schema publishes the plan catalogue, and no field maps a report to a tier. The App permission catalogue separates report grants (ViewSalesReports, ViewCostReports, ViewMenuReports, ViewInventoryReports, ViewPayrollReports, ViewSalesEndOfDayStatistics) but permissions are role grants, not plan tiers. On www, /pos-system publishes three POS tiers (Essentials from EUR 69/month, Pro from EUR 99, Advanced from EUR 199, billed annually per site) with one-line taglines, /pricing renders its plan comparison client-side so no per-tier feature matrix is in the served HTML, and the add-on list on /pricing (kiosks, managed marketing, KDS, Uber Direct, feedback app, phone marketing) contains no analytics SKU - weak evidence against a separate analytics add-on, but not a plan matrix. The breakdown lives in the excluded help centre or behind a sales quote.

reporting-history-retention differentiator

Re-checked 2026-08-09 across both corpora on developers.flipdish.com (the help-centre pages cited in the original rationale are excluded by policy and were not re-read). The v1.0 reference adds two more historical query surfaces and neither publishes a retention window: the Events API (GET /api/v1.0/{appId}/events) takes free start and end date-time filters with limit/page pagination and states no earliest available date, and the Reporting API (/reporting/v1.0/{appNameId}/order/overview) accepts MainPeriod.Start/End plus a ComparePeriod for arbitrary custom ranges with no documented bound. In v3.0 the org-wide sales endpoints accept after/before on createdAt with cursor pagination and likewise document no window, and their deprecation notes concern API versions rather than data ageing. Full-text search of the 27.6MB v1.0 corpus returns zero hits for retention period, data retention and archive tier. The claim requires a DOCUMENTED window of at least 24 months; none is published on either permitted host in either direction, so this is unresolved rather than a finding of absence.

reporting-anomaly-alerts differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. It shows Flipdish does compute anomaly-style flags, but vendor-defined ones on individual orders rather than operator-configured metric thresholds: the Order schema carries InFraudZone and UnusualHighValueOrder booleans (see the event examples on /v1.0/reference/getevents). Nothing in either API version defines a threshold, alert rule, subscription or notification recipient for a business metric - the 84-entry v1.0 event catalogue is order, store-config, menu, catalogue, voucher, campaign, user, printer, phone-call and webhook lifecycle only, with no metric or anomaly event, and the v3.0 webhook catalogue is 13 menu/snooze/sale events. The only outbound messaging primitives are customer-facing scheduled push notifications and SMS provider credentials. On www, the only proactive alerting published is food-safety email/SMS on /pos-system/health-food-safety-management; /pos-system/reporting-and-analytics is framed entirely as pull; /labs lists ingredient-driven auto-disabling as forward-looking. Not enough to assert absence in-product, and help.flipdish.com is excluded by policy.

reporting-nl-query

Flipdish's AI page lists four agents and marks the AI Copilot Agent 'Beta': 'Your personal analyst. An agent to chat with about your business ... "How many orders last night?" "What's my best seller this month?" Ask Flipdish Copilot in plain English and get a straight answer, no spreadsheets, no dashboards, no digging.' That is a natural-language assistant over the operator's own sales data, not a help-article bot - the page states every agent shares the platform's data layer (order history, menu data, customer profiles, revenue data). Named shortfalls: the vendor itself marks it Beta while the other three agents are 'Live'; the described output is a conversational answer explicitly 'no dashboards', so the claim's 'returns a figure or chart' is only half met; and nothing indicates it reaches labor/rota data, which sits in the separate payroll module. Grade C - this is a vendor feature page, and the product documentation that would confirm shipped behaviour is in the excluded help centre. Separately, Flipdish's MCP server (developers.flipdish.com/docs/connect-flipdish-mcp-server-to-claude) lets an external assistant query the account in plain language, but its documented tool areas are orgs/brands, sales channels, menus and opening hours - not sales analytics. https://www.flipdish.com/ai · retrieved 2026-08-09

reporting-guest-cohorts differentiator

Marketing CRM exposes customer value and order frequency per customer; new-vs-returning cohorts and lifetime-spend cohorting are not documented as reports. https://www.flipdish.com/marketing · retrieved 2026-08-01

reporting-sales-forecast differentiator

'Smart sales forecasts' is a named POS feature; granularity (daypart/hourly) and downstream consumption by scheduling are not documented. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

reporting-tip-tax-compliance

A Tips Report exists with total tips, delivery tips, pick-up tips, refunded tips, tips per store and tips per week, downloadable as CSV/PDF and schedulable by email (9585606). Shortfalls: it is store/channel-level only — no per-employee declared-versus-charged breakdown exists (the payroll calculator's per-staff outputs contain no tips field, 9585185), no tip-pool distribution detail exists anywhere in the enumerated 47-report catalogue, and there is no tip tax-liability summary — the separate Sales Tax Report covers sales tax by tax rate only (12549374). https://help.flipdish.com/en/articles/9585606-tips-report · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

multi-location-org-hierarchy

The hierarchy is enforced in the schema, not just implied by URL nesting. In the v3.0 Org Management OpenAPI, SalesChannel requires BOTH brandId and propertyId ('A sales channel is a digital - non physical - version of a property. It is usually composed of one brand'), properties are created under /orgManagement/orgs/{orgId}/properties with type Store|CentralKitchen, and brands under /orgManagement/orgs/{orgId}/brands -- so org > brand and org > property > salesChannel are first-class objects with their own CRUD and archive/unarchive. Reporting scopes to them: listOrgSales and listPropertySales are separate endpoints and sale.* webhook payloads carry orgId, propertyId, salesChannelId and brandId. Permissions scope to them too, on the v1.0 surface: the teammate model carries an AppAccessLevel enum (None, Owner, StoreOwner, ManagedOwner, Integrator, StoreManager, StoreStaff, StoreReadOnlyAccess, FinanceManger, Onboarding, Support) plus HasAccessToAllStores and an explicit StoreIds list, 'Store IDs the user has access to (if HasAccessToAllStores is false)'. Boundary: every v3.0 Org Management endpoint carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' https://developers.flipdish.com/reference/getsaleschannelbyid · retrieved 2026-08-09 adversarially verified

multi-location-central-menu-publish

Single-action fan-out is in the request body. POST /menuManagement/orgs/{orgId}/menus/{menuId}/revisions/{revisionId}/publish accepts 'selectedSalesChannelIds', described as an 'Optional list of Sales Channel IDs to publish to' with example ['sc1234','sc1235'] -- one call, a chosen set of destinations, omit it to publish everywhere the menu is referenced. Menus are org-level objects, so authoring is central by construction. The audit half: GET .../revisions lists every revision and the menu schema carries auto-generated createdAt, updatedBy ('Last updated by user'), updatedAt and revisionId; GET .../menus/{menuId}/published returns 'the revision from the most recent publish event for this menu (across all sales channels)' with a menuPublishId; GET .../menus/{menuId}/references returns every propertyName and sales channel using the menu; and GET .../revisions/{revisionId}/publishCheck is a pre-flight returning typed messages. Boundary: the whole Menu Management API carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' The per-channel POST .../salesChannels/{salesChannelId}/menuPublish the old note cited is the single-destination variant, not the fan-out. https://developers.flipdish.com/reference/post__menumanagement_orgs__orgid_menus__menuid_revisions__revisionid_publish_18 · retrieved 2026-08-09 adversarially verified

multi-location-local-override-policy differentiator

Partial: corporate menu control is real but the governance model is coarse-grained, not per-field. The v1.0 App schema publishes AppResourceSet, 'Constitutes a list of available resources', and its menu grants are exactly ViewMenu, CreateMenu, UpdateMenu, DeleteMenu, UpdateMenuLock, UpdateMenuItemsHideTemporarily and EditMenuImage - so the only sub-menu permission a location can be given is temporarily hiding items. The mechanisms that do vary a menu by location are: assigning a store its own (possibly cloned) menu (/api/v1.0/stores/{storeId}/menu/{menuId}, 'Clone a menu, (without attaching stores)', store.menu.assigned), the bulk show/hide item operations, and in v3.0 a price band per sales channel ('the price band that will be applied to the sales channel. If not provided, the default price band with code default.price.band will be applied', itself carrying a Beta notice) plus per-sales-channel item snooze. Shortfall: neither version defines a field-level override, a locked-attributes collection or a store-level patch of a corporate item - 'Lock/Unlock a Menu for Editing' is an editing lock on the whole menu, not per-field governance. Whether the merchant portal exposes franchisor field locks is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getapp-1 · retrieved 2026-08-09

multi-location-price-zones

Two of the claim's three axes are documented and the third is not. Menu Structure v3.0: 'Each item (CategoryItem or ModifierItem) can have multiple PricingProfiles, one per price band. Each profile defines separate prices for four dispatch types: Collection, Delivery, DineIn, and TakeAway.' The OpenAPI backs it -- BaseItemPricingProfileSchema carries priceBandId plus collectionPrice/deliveryPrice/dineInPrice/takeawayPrice with their own tax and taxable flags -- and the location-group binding is the required priceBandId field on SalesChannel, with price bands themselves listed org-wide via GET /orgManagement/orgs/{orgId}/priceBands. So one item record does carry different prices per location group and per order channel without duplication. The gap is the daypart. Correcting the previous note: the override model is documented, it simply is not a pricing lever -- AvailabilityOverrides 'control when and where a category or item is visible' by property, venue code, dispatch type, day-of-week flags and a fromTime/toTime window, and carry no price field. No time-of-day price schedule appears anywhere in the v3.0 menu schema. Beta Notice applies to the Menu Management API. https://developers.flipdish.com/docs/menu-structure-v3 · retrieved 2026-08-09 adversarially verified

multi-location-scheduled-publish differentiator

Partial: two of the three change types the claim names behave differently. Promos ARE future-datable - the v1.0 Voucher schema carries StartDate ('Voucher Starts On (Time in UTC)') and ExpiryDate ('Voucher Expires On (Time in UTC)') plus day-of-week ValidityPeriods and ChannelRestrictions (Ios, Android, Web, Kiosk, Pos, Google) - and loyalty campaigns carry per-store start times ('Stores this campaign applies to with campaign start time in Utc'). Rollback is documented: v1.0 exposes 'Get a Menus Checkpoints' and 'Restore a Menu to a checkpoint', and v3.0 exposes menu revisions with republish of a prior revision. Shortfalls: (a) menu and price changes have no scheduling field at all - no publishAt, effectiveFrom or scheduledAt exists anywhere in the 1,064-page v1.0 reference or the 99-page v3.0 dump, and neither publishMenuToSalesChannel nor the revision publish endpoint accepts a future time; (b) the promo scheduling that does exist is expressed in UTC, not interpreted in each target location's own timezone, even though stores and properties carry a timezone attribute used for opening hours. Whether the portal offers scheduled menu activation is help-centre material, excluded by policy. https://developers.flipdish.com/v1.0/reference/getvoucherbyid · retrieved 2026-08-09

multi-location-new-store-template differentiator

Cloning exists, but one level below the location. POST /orgManagement/orgs/{orgId}/properties/{propertyId}/salesChannels/{salesChannelId}/clone is documented as 'A cloned sales channel is a copy of an existing sales channel. This makes it easier to create similar sales channels quickly', and its only body field is the new channel's type, from the enum FlipdishKIOSK|FlipdishMobileApp|FlipdishWebApp|FlipdishPhoneAgent -- note POS is a valid SalesChannel type but is not clonable. Its sibling createLinkedSalesChannel goes further: the resulting channel gets a SalesChannelHierarchy of type Linked pointing at a primarySalesChannelId, which 'indicates if the sales channel is dependent on another or if updates to this channel will impact other linked channels', i.e. ongoing inheritance rather than a one-time copy. Shortfalls: a sales channel is 'a digital - non physical - version of a property', so this provisions an ordering channel, not a store; the property itself is created field-by-field via createPropertyForOrg with no template or clone operation anywhere in the v3.0 Org Management reference; taxes, roles, printers, modifiers and tenders are not named as cloned artefacts; and no expected time-to-open is published. Beta Notice applies. https://developers.flipdish.com/reference/clonesaleschannel · retrieved 2026-08-09 adversarially verified

multi-location-corp-vs-franchisee-roles differentiator

Partial: the model is delegated roles inside one tenant, not two tenants. The v1.0 Teammate schema carries AppAccessLevel with the enum None, Owner, StoreOwner, ManagedOwner, Integrator, StoreManager, StoreStaff, StoreReadOnlyAccess, FinanceManger, Onboarding, Support, plus HasAccessToAllStores ('The user has access to all stores for the app (including new stores that added later)') and StoreIds ('Store IDs the user has access to (if HasAccessToAllStores is false)'); the App schema adds PropertyOwner and PropertyManager and gates who may create each level (CreateTeammateOwner, CreateTeammateManagedOwner, CreateTeammateStoreOwner, CreateTeammatePropertyOwner, ...). Some franchisee-owned finance is supported: bank accounts are assignable per store (/api/v1.0/{appId}/bankaccounts/{bankAccountId}/store/{storeId}, ViewAssignedBankAccount, a FinanceManger role, per-account payouts and payout schedules). Shortfalls: there is no second tenant type for an independently-owned franchisee and no cross-org or cross-app visibility grant in either API version - a franchisee is a store-scoped teammate inside the franchisor's own App/Org, so the franchisee does not own a separate tenant for its employees or labor data, and v3.0's only cross-tenant operation is Transfer-brand, which moves a brand between orgs outright. The portal's own role matrix is in help.flipdish.com, excluded by policy. https://developers.flipdish.com/v1.0/reference/getteammatesbyappid · retrieved 2026-08-09

multi-location-royalty-calculation differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Zero hits for royalty, ad fund, franchise fee and marketing levy across the 27.6MB corpus, and the word franchise appears only in the boilerplate definition of an Org as 'a restaurant chain, franchise group, or independent restaurant business'. The financial surfaces v1.0 does add are the wrong ones: /api/v1.0/{appId}/invoices and ListSubscriptionInvoices are Flipdish billing the merchant, the payouts and payout-report families settle card takings to a merchant bank account, /api/v1.0/stores/{storeId}/feeConfig and /servicecharge configure consumer-facing fees, and /processingfeeconfigs configures payment processing rates - none computes an inter-party fee on net sales, and no fee-basis (gross vs net of discounts or third-party) field exists anywhere. Absence from an API with no franchise-management surface is not evidence about the portal, and help.flipdish.com is excluded by policy.

multi-location-royalty-collection

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. v1.0 is the version that carries Flipdish's banking plumbing and it is all merchant money-out: /api/v1.0/{appId}/customconnect/* (Stripe Custom Connect account creation, verification status, bank-account details, /update-payout-schedule/{stripeConnectedAccountId}/{interval}), /api/v1.0/{appId}/bankaccounts with per-store assignment, /api/v1.0/{appId}/payouts and the payouts3 report family. There is no direct-debit or ACH collection FROM a franchisee, no royalty or fee-ledger object, and no franchisee-visible statement anywhere in either API version; the only merchant-facing charges are Flipdish's own subscription invoices. Flipdish Capital, linked in the www footer, is merchant financing rather than franchise-fee collection. Nothing establishes presence or absence of a franchise-fee collection product; help.flipdish.com is excluded by policy.

multi-location-consolidated-reporting

'Get full visibility on reports from all your sites from one place'; listOrgSales returns sales across an entire org in one authenticated call. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-01

multi-location-normalized-item-rollup differentiator

The data model supports cross-location item rollup where locations share a menu. Menus are org-level objects published to individual sales channels; every sale references 'the exact menu revision it was placed against' and every line carries menuItemId (a UUID that 'must match an item in the menu/revision referenced by the sale's menuId/menuRevisionId') alongside a per-line unitPrice, so locally different prices do not break the item identity, and the org-wide read endpoints return complete sale payloads for the whole org in one query. Named shortfalls: the shared identifier is a per-menu UUID, not a corporate SKU - an org running two different menus across its estate has two different menuItemId sets for the same dish and no normalisation object is documented to bridge them; a store cannot locally rename an item in this model at all, so the claim's 'even when stores have renamed' case is unaddressed rather than solved; and the org-wide read endpoints are in beta behind 'Contact integrations@flipdish.com to request access'. Whether the portal's own reporting presents a cross-location item rollup is in the excluded help centre. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09

multi-location-cross-location-giftcard

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. The tender enumeration is now available in both versions and neither includes stored value: v1.0's PaymentAccountType enum is Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken, and v3.0's sale payment methods are Cash, Credit, Online, PhonePayment, ExternalPayment. No gift-card, stored-value or balance object exists in 27.6MB of v1.0 schemas. The one occurrence of the concept is telling but not conclusive: the v1.0 App Store app taxonomy (/v1.0/reference/getappstoreapp) lists partner categories PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other - so gift cards look like a third-party integration category, and a partner card scheme could redeem across locations and report liability without Flipdish documenting it (and could equally arrive as ExternalPayment). Since the capability may exist entirely outside the API surface and help.flipdish.com is excluded by policy, this is unresolved rather than a finding of absence.

multi-location-cross-location-loyalty

Loyalty and the customer record are brand-scoped, not per-location. The v1.0 LoyaltyCampaign schema is an app-level object (GET /api/v1.0/{appId}/campaigns/loyalty) whose Stores property is documented as 'Stores this campaign applies to with campaign start time in Utc', with OrdersBeforeReceivingVoucher, PercentDiscountAmount, MaxDiscount and campaign Statistics on the one campaign object; a per-store read (/api/v1.0/{appId}/campaigns/loyalty/{storeId}) returns the campaigns applying to that store rather than a store-owned campaign, and the App permission catalogue treats stamping as a single app-level grant (StampLoyaltyCardAgainstCampaignsConfigurations). The customer side matches: Customer is an app-level entity (CustomerId, RegistrationDate, PhoneNumber, marketing and payment consents) read via /api/v1.0/{appId}/customers/{customerId}, with 'Returns customers of the app to which you have access' and order history per customer across the app (/reporting/v1.0/{appNameId}/customers/orders, /api/v1.0/{appId}/events/customer/{customerId}). Caveat recorded rather than hidden: no stamp-balance object is published, so accrual scope is read from the campaign's own store list; and a chain running more than one Flipdish App would not share customers across them. https://developers.flipdish.com/v1.0/reference/getloyaltycampaignsforapp · retrieved 2026-08-09

multi-location-multi-brand differentiator

Multi-brand is modelled at the property, not at the terminal. POST /orgManagement/orgs/{orgId}/properties/{propertyId}/salesChannels creates 'a new sales channel under a specific org and linked to a property and brand', with brandId in the required array, and SalesChannel is described as 'a digital - non physical - version of a property ... usually composed of one brand ... and can have a different menu associated with it'. Since a property may hold many sales channels, one location can run several brands with distinct menus, and revenue separates because sale.* webhook payloads carry brandId (the v3 events overview notes brandId 'is included where sales.* payloads don't carry it'). Shortfalls: nothing in the developer documentation or on flipdish.com describes two brands sharing one physical terminal and cash drawer, separate per-brand receipt branding at the point of sale, or a brand-level P&L report; POS is a SalesChannel type, so a second brand at one till would mean a second POS sales channel, which is not documented as sharing hardware. Withdrawing the previous note's transferBrand evidence: that endpoint is tagged 'Private' in the spec and moves a brand from one org to another, which is unrelated to this claim. Beta Notice applies. https://developers.flipdish.com/reference/createsaleschannelfororgandproperty · retrieved 2026-08-09 adversarially verified

multi-location-multi-tax-jurisdiction

Richer than previously recorded, but built for a single-rate VAT regime. GET /api/v1.0/menus/{menuId}/tax returns MenuTaxDetails with TaxRates[] (each a named MenuTaxRate with a percentage Rate), a TaxType enum of IncludedInBasePrice|ExcludedFromBasePrice, and ItemTaxes, an 'ItemIds and TaxIds' map -- so several named rates coexist and different items carry different ones, which is the prepared-food-vs-grocery distinction the claim asks for. They are writable (POST /menus/{menuId}/taxrate Add/Update a Tax Rate, POST /menus/{menuId}/tax/type/{type}, Set tax rate for menu item, Set Tax Rate on OptionSetItem, and a delete that 'can only remove a tax rate that does not have items/optionSetItems attached'). On v3.0, GET /orgManagement/orgs/{orgId}/properties/{propertyId}/vat returns per-property isVatApplicable, isVatInclusive, vatCaption, vatPercentage and operativeVatBands, 'the allowed list of VAT values that can be applied to prices', example [0, 9, 13.5, 23]. Shortfalls, which is why this is not a yes: no rate stacking -- ItemTaxes maps an item to ONE tax id and PropertyVATInfo exposes a single vatPercentage, so US-style simultaneous state/county/city rates on one line are not expressible; the tax-rate set is bound to the menu, not to the location, so per-location tax differences require per-location menus, which cuts against central publishing; the v3.0 property VAT endpoint is read-only with no update counterpart; and per-location exemption exists only as the blunt isVatApplicable boolean, with no exemption certificate or customer-level exemption anywhere. Beta Notice applies to the v3.0 endpoint. https://developers.flipdish.com/v1.0/reference/getmenutaxdetails · retrieved 2026-08-09 adversarially verified

multi-location-config-audit-log differentiator

The v1.0 Events API is a corporate-queryable configuration audit log. GET /api/v1.0/{appId}/events (plus scoped variants /events/store/{storeId}, /events/menu/{menuId}, /events/user/{userId}, /events/order/{orderId}, /events/customer/{customerId}) filters by storeId, storeIdList, storeGroupId, userId, userEmail, userName, menuId, campaignId, voucherCode, eventType and a start/end date range, with limit/page pagination. Its published examples enumerate 84 event types, and the configuration ones carry a User block (UserId, UserName, UserEmail), CreateTime, IpAddress, StoreId/StoreGroupId and the changed object: StoreUpdatedEvent ('1234 updated store 1234'), store.service_charge.updated, store.fee_config.updated, store.tip.updated, store.opening_hours.updated, store.delivery_zone.created/updated/deleted, store.kiosk_setting.updated, store.published/unpublished/archived, menu.updated ('1234 updated menu 1234', whose Menu payload includes TaxRates), menu.bulk.edit, catalog.item.created/updated/archived, voucher.created/updated/deleted, campaign.loyalty.* and campaign.retention.*, teammate.invite.sent/accepted, teammate.updated/deleted, user.created/updated/deleted/login, and webhook_subscription.*. Read access is separately gated per domain by the App permission catalogue (ViewStoreAuditLogs, ViewMenuAuditLogs, ViewVouchersAuditLogs, ViewTeammatesAuditLogs, ViewFeeConfigurationsAuditLogs, ViewOrdersAuditLogs, ViewUserEventsAuditLogs, ViewCatalogAuditLogs and eleven more). Two things are NOT documented and are recorded here rather than assumed: no statement of immutability or retention, and no bulk export of audit entries (the CSV exports are payout and customer exports). Note this is the v1.0 surface - in v3.0 the only audit-log endpoint is the write-only POST /auditLogs/orgs/{orgId}, and the v1.0 store/order audit-log POSTs carry '[BETA - this endpoint is under development]'. https://developers.flipdish.com/v1.0/reference/getevents · retrieved 2026-08-09

multi-location-enterprise-api differentiator

listOrgSales returns transaction-level sales across all properties in an organisation from a single org-scoped OAuth token — no per-location credentials. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-01

multi-location-central-labor-policy

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. It confirms the module exists - the App permission catalogue at /v1.0/reference/getapp-1 names EditPayrollRota/ViewPayrollRota, EditPayrollStaff/ViewPayrollStaff, EditPayrollHoliday/ViewPayrollHoliday and ViewPayrollReports - matching www.flipdish.com/pos-system/payroll-management (shift and rota creation, real-time attendance, wage-cost tracking, holiday approve/reject). It settles nothing about rules: there is no labor endpoint at all among the 1,064 v1.0 operations or the 99 v3.0 pages, zero hits for clock-in, timecard, overtime, break or predictive scheduling across 27.6MB, and no schema in which such a rule could be scoped to a location or location group. Teammate access is scoped per store (HasAccessToAllStores/StoreIds), but that governs back-office access, not labor policy. Whether rules are enforced at the terminal is in-product behaviour documented in the excluded help centre.

hardware-commodity-devices differentiator

POS is marketed as cloud-based and 'runs on any device', but Flipdish also sells its own 15.6" registers and no supported third-party device list or minimum spec is published. https://www.flipdish.com/docs/pos-features · retrieved 2026-08-01

hardware-os-platforms

www.flipdish.com/posinstall names exactly one client operating system: 'Flipdish Windows application', offered as 'POS App 64bit' ('for anyone who would like to print their orders from a Windows PC and to be used for the PAR PixelPoint Integration') and 'POS App 32bit' ('to be used for the Oracle Micros RES3700 integration ... if your ODBC data source drivers are 32bit'). Shortfall: no minimum Windows version, no CPU/RAM/storage spec and no compatibility matrix are stated anywhere on www.flipdish.com, and no OS at all is named for the 15.6in register, the handheld, the 21.5in KDS or the K2/K2 Mini/D2S kiosks, which are sold as vendor-supplied appliances (pos-system/hardware). developers.flipdish.com carries no client-platform surface (zero occurrences of 'Android' or 'Windows' across the 99-page dump). https://www.flipdish.com/posinstall · retrieved 2026-08-09

hardware-handheld-purpose-built

Purpose-built handheld with integrated payment terminal and receipt printer, 'tough enough for fast-paced service'; no drop rating or IP rating is published. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

hardware-handheld-battery-swap differentiator

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference, which is the version that carries device management (/api/v1.0/{appId}/devices/enroll, /devices/assign, /devices/search, /devices/device/{deviceModel}/{deviceId}, plus the Hydra terminal family). Those schemas expose DeviceModel, DeviceId, DeviceName and a PinCode as opaque strings - there is no device catalogue, no model enum for terminals and no spec field, so no battery, charge-state or power attribute exists anywhere in the corpus (the only enumerated hardware models are the kiosk Bluetooth card readers). www.flipdish.com/handheld-pos and /pos-system/hardware, read in full on 2026-08-09, describe the handheld as 'Lightweight and compact' with a 'Swivel power base' that 'keeps it powered and transforms it into a countertop POS when docked' - a charging dock, not a battery claim - with no mAh figure, rated shift life or removable-battery statement. A device spec sheet would sit on help.flipdish.com, which is excluded by policy.

hardware-handheld-lte

'Built-in SIM connectivity means it keeps working wherever you need it.' https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

hardware-offline-mode

Vendor explicitly states: 'The Flipdish POS does not support an offline mode.' All hardware runs cloud-connected only. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

hardware-kds

First-party KDS product with station routing, drag-and-drop prioritisation, colour-coded modifiers, label printing and configurable ticket layout, plus a 21.5" kitchen display screen SKU. https://www.flipdish.com/pos-system/kitchen-display-system · retrieved 2026-08-01

hardware-kiosk differentiator

Three form factors (K2 24" floor/wall, K2 Mini 15" tabletop, D2S countertop) with integrated card readers and NFC; ADA/WCAG conformance is stated as an aim under the EAA with no ACR and admitted gaps. https://www.flipdish.com/online-ordering/kiosks · retrieved 2026-08-01

hardware-drive-thru

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. New and relevant: drive-thru is a first-class ORDER LOCATION concept - the Order schema's TableServiceCatagory enum is Generic, Villa, House, Room, Area, Table, ParkingBay, Gate, DriveThrough, Team (with PickupLocationType TakeOut, TableService, DineIn), and stores carry configurable location areas (/api/v1.0/{appId}/stores/{storeId}/location-areas/...) with an OrderDropOffLocation on the order. That is order routing, not the hardware the claim asks about: neither API version defines an outdoor menu board, order confirmation display, speaker or headset device, and no timer or speed-of-service measurement object exists (the order timestamps are PlacedTime, AcceptedFor and RequestedForTime, with configurable fulfillment states but no lane clock). www.flipdish.com/pos-system/hardware lists the full device line-up (15.6in register, customer display, card reader, KDS, printers, scanner, caller ID, cash drawer, RFID reader, K2/K2 Mini/D2S kiosks) with none of these, but the same page says hardware can be mixed and matched, so the catalogue is explicitly open and cannot carry a no. help.flipdish.com is excluded by policy.

hardware-printer-compatibility

Hardware line-up includes the Epson TM-20III thermal receipt printer, Brother QL-800 label printer and an 80mm cloud thermal kitchen printer — multiple manufacturers, not vendor-only. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

hardware-peripherals

Cash drawer, barcode scanner, RFID card reader, caller ID and a 10.1" customer-facing display are listed; by-weight scales and a formal published compatibility matrix are absent. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

hardware-p2pe-terminal

Partial: the card-entry architecture is documented, the compliance statement is not. The v1.0 API enumerates the supported card readers by model - DeviceType enum CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3, WISEPOS_E with a Status enum (Not_Connected, Connecting, Connected, Online...) on /api/v1.0/{appId}/cardreaders/kiosk/{deviceId}/bluetooth/status - and the payment path runs through Stripe Terminal: /api/v1.0/{appId}/payments/terminals/stripe/register and /unregister, /payments/terminals/stripe/{readerId}/processPaymentIntent, /stripeterminal/connectiontoken, /stripeterminal/location, with Emv as a PaymentAccountType on an order and firmware update endpoints per reader; status.flipdish.com publishes a component named 'Card Payments (Stripe)'. So card entry happens on an external reader driven by the app, not by keying into the POS. Shortfalls: (a) no PCI PTS listing reference, no validated P2PE solution listing and no statement of the merchant's SAQ type is published on either permitted host - the 27.6MB v1.0 corpus and the 4.6MB v3.0 corpus contain zero occurrences of PCI, P2PE and SAQ, trust.flipdish.com does not resolve in DNS and www.flipdish.com/security 404s (both re-probed 2026-08-09); (b) COTS_DEVICE in the same enum is a commercial-off-the-shelf device acceptance path, which cuts against the claim that the application device stays out of scope. The compliance documentation, if published, sits in the excluded help centre. https://developers.flipdish.com/v1.0/reference/getbluetoothterminalstatus · retrieved 2026-08-09

hardware-tap-to-phone differentiator

The hardware page FAQ states the requirement directly: 'Can I accept payments with the Flipdish POS? Yes. The Flipdish POS comes with integrated payments and you will need to purchase a Flipdish card reader to take payments.' The device catalogue on the same page offers only a 'Wifi-connected card reader' and mount, and /pos-system/payments answers 'What hardware is included?' with 'a suite of devices including compact, contactless terminals and handheld POS systems'. Neither Tap to Pay on iPhone nor Tap to Pay on Android is named anywhere on www.flipdish.com or in the 99-page developer dump. This is a first-party statement that a separate reader must be bought, not a technical enumeration; help.flipdish.com is excluded by policy and could in principle document a later capability. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-09

hardware-pricing-transparency differentiator

The hardware page enumerates SKUs with no prices anywhere; the US pricing FAQ defers hardware cost to a quote. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

hardware-ownership-vs-lease differentiator

US pricing FAQ refers to 'upfront costs for Flipdish hardware and implementation' with monthly installment options — implying purchase or financed purchase rather than a mandatory lease, but not stated explicitly. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

hardware-usable-after-churn differentiator

The Terms of Service answer this against the operator. Section 12.2: 'You may not use the Hardware to run any software not approved or issued by us. Breaching this will incur additional charges based on the preferential pricing we gave you for Hardware. We will notify you of charges at the time. This Section 12.2 survives' termination. Section 11.1 additionally retains title to all Hardware until full payment, and 11.3 lets Flipdish 'recover the Hardware delivered under retention of title or recover or detach such Hardware' on non-performance. So hardware bought from Flipdish is contractually - not necessarily technically - locked to Flipdish-approved software, and that lock is expressly stated to survive the agreement. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

hardware-rma-sla differentiator

The T&Cs publish a warranty term but no exchange SLA. Section 12.8: 'we warrant that on delivery and for a period of six (6) months from delivery, the Hardware will conform in material respects with its description and be free from material defects in design, material and workmanship'. Section 12.4.5: 'If we accept a claim of a Hardware fault due to manufacturing or workmanship defect, we may replace it free of charge or refund the purchase price, prorated for the defect'. Shortfall: no advance-exchange or depot-swap programme is offered and no turnaround time of any kind is stated; 12.3 makes returns discretionary ('Hardware is not returnable without our written consent and returns are at our sole discretion', and unboxed/used hardware is non-returnable); 12.4.4 imposes a 7-business-day inspection window on the buyer; and 12.1 puts maintenance on the operator 'unless maintenance is specifically included as a Service'. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

hardware-byod

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. It supplies the building blocks without answering the question: staff sign-in by PIN exists (/api/v1.0/accounts/login/pin, /accounts/pin, /accounts/password/pin, /accounts/password/resetpin) alongside SSO login; devices are enrolled and assigned with a DeviceModel and PinCode (/api/v1.0/{appId}/devices/enroll, /devices/assign, gated by EnrollClientDevices and AssignClientDevices in the App permission catalogue) and terminals log in by device id (/api/v1.0/hydra/{deviceId}/login); teammate access is scoped by role and StoreIds; and COTS_DEVICE appears in the card-reader DeviceType enum, which is a commodity-device acceptance path rather than a staff BYOD statement. What is absent from both permitted hosts is any statement that staff may run the ordering or payment app on a personal phone, and any documented BYOD permission or security model - DeviceModel is an opaque string and there is no device-ownership, MDM or personal-device field. www.flipdish.com/pos-system/hardware only offers to check existing till hardware compatibility 'with one of our experts'. help.flipdish.com is excluded by policy.

hardware-remote-device-management differentiator

The v1.0 API exposes a real remote device surface, but only for kiosks and their paired card readers. /api/v1.0/{appId}/cardreaders/kiosk/{deviceId}/bluetooth/status, /bluetooth/{terminalType}/checkForUpdate, /installUpdate, /cancelUpdate, /pair and /unpair give remote reader status, firmware-version checking and remote update install; /api/v1.0/{appId}/kioskiot/timeseries/query (operationId QueryTelemetrySeries) returns kiosk IoT telemetry; and /api/v1.0/kioskiot/connect and /api/v1.0/terminaliot/connect register devices. Shortfalls: every one of these endpoints is flagged '[BETA - this endpoint is under development, do not use it in your production system]'; nothing covers printers or KDS screens; there is no remote reboot and no staged rollout of updates; and no management console (as opposed to API) is documented on either permitted host. status.flipdish.com reports platform components, not individual devices. https://developers.flipdish.com/v1.0/reference/initiatekioskbluetoothupdateinstall · retrieved 2026-08-09

hardware-selfpour-scales

Re-checked 2026-08-09 against the 1,064-page v1.0 API reference. Zero hits for pour, tap wall, flow meter, dispense, keg and pour spout across the 27.6MB corpus; the enumerated device families are kiosks (kioskiot, kiosk settings, kiosk cash settings, kiosk Bluetooth card readers), Hydra terminals and printers, EMV/Stripe terminals and generic enrolled client devices, with no beverage hardware; and the v1.0 App Store partner taxonomy (/v1.0/reference/getappstoreapp) enumerates categories as PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other - no beverage or dispense category. The order schema has no automatic-pour or open-tab-charge concept. www.flipdish.com/pos-system/hardware and /integrations name no tap-wall or pour-spout partner but are explicitly open lists ('And more!', 'mix and match'), and Flipdish sells to QSR and takeaway rather than taprooms, so this is unresolved rather than absent. help.flipdish.com is excluded by policy.

hardware-callerid-integration

'Caller ID' is a listed hardware component in the Flipdish POS hardware line-up — relevant to phone-order-heavy takeaway operators. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01

extensibility-public-api-docs

developers.flipdish.com is fully public: API overview, error handling, webhooks guides, getting started, ~65 endpoint references, and an llms.txt index. No NDA, agreement or sales call required to read it. https://developers.flipdish.com/ · retrieved 2026-08-01

extensibility-api-access-cost differentiator

The developer documentation documents the entire acquisition path and it contains no plan, fee or per-location gate. 'Build a POS sales analytics integration' step 1: 'Sign up at https://portal.flipdish.com/signup. The portal provisions a brand-new org for the account at signup; this is the org you'll use as your sandbox.' Getting Started: 'To interact with the Flipdish API you will need a Flipdish account. You can create one for free at https://portal.flipdish.com/signup', then 'Click on your avatar and then on Developer tools ... Click on OAuth apps and then on the red Add New button', then request a client-credentials token. The published pricing page sells a single bundled plan from EUR 99 per site per month and enumerates its paid add-ons (Self-Service Kiosks, Managed Marketing, Kitchen Display System, Uber Direct, Customer Feedback App, Restaurant Marketing, Phone Marketing) - no API, developer or integration tier among them. Caveat: no page states in words that API access is included, so this rests on a documented ungated path rather than an explicit price statement. https://developers.flipdish.com/docs/build-a-sales-analytics-integration · retrieved 2026-08-09

extensibility-partner-revshare

www.flipdish.com/partner-sign-up publishes the shape of the commercial relationship but not its numbers: 'Discover how you can earn monthly commissions and offer a satisfyingly simple restaurant management solution to your client network', under the heading 'Learn about our Referral and Reseller Programmes'. Shortfall: no commission percentage, no referral fee, no revenue-share split and no per-location partner fee is published anywhere - the rate is gated behind a demo form and a phone number. On the marketplace side, the developer guides 'What is the Flipdish App Store?' and 'How to create a Flipdish App Store app?' walk the whole flow (OAuth app, listing fields, permission level, store selector, configuration type, validation call, approval) and state no listing fee, no revenue share and no monetisation model at all. https://www.flipdish.com/partner-sign-up · retrieved 2026-08-09

extensibility-free-sandbox differentiator

A free sandbox does exist and is documented: 'Sign up at https://portal.flipdish.com/signup. The portal provisions a brand-new org for the account at signup; this is the org you'll use as your sandbox', with no paid production account required, and 'The same OAuth credentials work in both modes'. Shortfall, and it is the words of the claim: the sandbox ships with no seeded data. 'POST /salesManagement/orgs/{orgId}/sales is how you seed test data into your sandbox so the analytics read path has something to return' - the developer must construct the fixtures. There is also no synthetic webhook trigger: 'The Webhook Service API does not expose a synthetic trigger today, so test against real events on your sandbox org.' The org is a real org on the production endpoints rather than a separate sandbox host, and App Store apps stay sandbox-only until a manual validation call and approval. https://developers.flipdish.com/docs/build-a-sales-analytics-integration · retrieved 2026-08-09

extensibility-oauth-partner-apps

OAuth2 client-credentials apps are created self-serve in the portal (Developer tools → OAuth apps) and docs include permission-request and tool-permission concepts; a published scope catalogue and per-operator revocable grants are not documented beyond scope=api. https://developers.flipdish.com/docs/getting-started.md · retrieved 2026-08-01

extensibility-webhooks-push

Two push-webhook surfaces, and the shipped one is v1.0. The v1.0 'Webhook events' page enumerates the available events - order.created, order.accepted, order.rejected, order.refunded, order.tip.updated, order.rating.updated, plus menu.created/updated, customer.created/updated/consent.updated and store.* - and 'Using webhooks' states the purpose plainly: 'notify you of an order so that you can automatically enter it into your POS'. Subscriptions are self-serve (portal Developer tools > Webhooks, or the /api/v1.0/{appId}/webhooks/ subscription endpoints), and none of the v1.0 pages carries a maturity marker: 'Beta' appears zero times across the 1,064-page v1.0 corpus. Polling is documented only as the fallback for integrators who cannot receive webhooks. The newer v3 catalog adds sale.created.v1 / sale.updated.v1 / sale.status.updated.v1 (marked Beta, access by request) and menu.published.v1 and the snooze events (marked 'Generally available'), while the older sales.* events are marked 'Deprecating soon'. Not every state in the claim is a discrete event - there is no separate 'paid' or 'voided' event, payment state travels on the order payload and cancellation shows as order.rejected or sales.cancelled - but created, modified, refunded and status transitions are all pushed. https://developers.flipdish.com/v1.0/docs/webhook-events · retrieved 2026-08-09 adversarially verified

extensibility-webhook-reliability differentiator

Retries and a delivery log are documented; cryptographic signing and a replay are not, on the surface that actually ships. On v1.0 (unmarked, i.e. shipped - 'Beta' appears zero times in the 1,064-page v1.0 corpus) authenticity is a static shared secret, not a signature: 'When you set a secret you'll receive the X-Verify-Token header in the webhook POST request.' Retry is stated but unscheduled: 'If a webhook is not successfully received, Flipdish will continue trying to send the webhook for 24 hours', with no backoff curve or attempt count published, and 'When over 50% of webhooks receive a non-2xx response over a 72 hour period, your webhook will be disabled'. The log half is met: the portal Webhook details section shows 'a list of all attempted webhooks and the respective HTTP status codes we received', GET /api/v1.0/{appId}/webhooks/{oauthAppId}/subscriptions/{webhookSubscriptionId}/logs returns the same programmatically, and .../events/{eventName}/test fires a sample event - but nothing documents re-delivering a missed event. The v3.0 guide adds an HMAC-SHA256-over-'${timestamp}.${rawBody}' scheme with a timing-safe comparison example, and it is explicitly at-least-once ('Retries are automatic ... Handlers must be idempotent'), but its own delivery-contract table marks the signature header as not yet shipped: '(planned) X-Flipdish-Signature - HMAC-SHA256 signature for payload verification' and '(planned) X-Flipdish-Idempotency-Key'. For missed deliveries v3 prescribes reconciliation rather than replay: 'Run a periodic reconciler using the org-wide list endpoints.' https://developers.flipdish.com/v1.0/docs/using-webhooks · retrieved 2026-08-09 adversarially verified

extensibility-order-injection-api

The write API exists and is documented to do what the claim asks, but neither version of it is available to an ordinary customer without asking Flipdish. On v3.0, POST /salesManagement/orgs/{orgId}/sales exists to 'Push sales from an external system (POS, marketplace, kiosk, ordering platform) into Flipdish so they appear in reporting, reconciliation, and the audit trail', carries an x-idempotency-key, fires sale.* webhooks, and sets a 'displayId' that is the 'short, human-readable label shown to restaurant staff on kitchen display systems (KDS) and printed on receipts' - so it is a first-class ticket by the claim's test. But the guide opens 'The Sales Management API is currently in beta. Endpoints may change. Contact integrations@flipdish.com to request access', and the org-wide query endpoints carry a second notice ('they may change without notice'). The older surface is a weaker gate, not an alternative: the only order-creation operation in the entire 1,064-page v1.0 reference is POST /api/v1.0/{appNameId}/order-ingest/submit, labelled '[ALPHA - this endpoint is under internal development, it is not available just yet to use in your production system]'; v1.0's other order operations (getorders, getorderbyid, acceptorder, rejectorder, dispatchorder) only act on orders Flipdish already created. An email-gated beta over an alpha endpoint is not a shipped, self-serve order-injection API. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09 adversarially verified

extensibility-menu-write-api differentiator

Writable on two surfaces, and the price field is in the body. v3.0: POST /menuManagement/orgs/{orgId}/menus (CreateMenuSchema) and PUT /menuManagement/orgs/{orgId}/menus/{menuId} 'Update menu keeping the same revision' (UpdateMenuSchema) both accept the full object -- categories[] with items, modifiers[] with modifierMembers, and pricingProfiles[] carrying priceBandId with collectionPrice, deliveryPrice, dineInPrice and takeawayPrice plus their tax fields -- alongside DELETE (archive a menu), POST .../snoozes and .../un-snoozes, GET .../publishCheck and POST .../revisions/{revisionId}/publish. v3.0 Menu Management carries 'Beta Notice: This endpoint is currently in beta and may change or be deprecated at any time without notice.' The v1.0 reference, which carries no such notice, supplies the granular equivalent: Create/Update/Delete menu section item, Create/Update/Delete menu item option set item, Set tax rate for menu item, Set Tax Rate on OptionSetItem, and set/get metadata on both. So writes are not merely whole-document replacement, and the capability does not depend on the beta surface. https://developers.flipdish.com/reference/put__menumanagement_orgs__orgid_menus__menuid_8 · retrieved 2026-08-09 adversarially verified

extensibility-data-symmetry differentiator

Symmetric for four of the five objects the claim names, in the v1.0 API; not for inventory, and not on the v3.0 surface. In the 1,064-page v1.0 reference (OpenAPI 'Flipdish Open API v1.0'): customers are read AND written - GET /api/v1.0/{appId}/customers/{customerId} (GetCustomerById), POST /api/v1.0/{appId}/customers (CreateCustomer, body CustomerCreateModel) and POST /api/v1.0/{appId}/customers/{customerId} (UpdateCustomerById, body CustomerUpdateModel); employees likewise - GET /api/v1.0/{appId}/teammates and /{id}, POST create (CreateTeammate), POST update (UpdateTeammate), DELETE (DeleteTeammate); menus are full CRUD (create/update/delete of menus, sections, section items, option sets, option set items, zones, catalog groups/items and products); orders are readable (GET /api/v1.0/orders, /orders/{id}) and writable (POST /api/v1.0/{appNameId}/order-ingest/submit - OrderIngestSubmitNewOrder - plus accept, reject, refund, dispatch and updatedeliveryinformation). Named shortfalls: (1) INVENTORY has no endpoint at all in either version - the only occurrences of the word in the v1.0 corpus are teammate permission enum values (ViewInventoryStockItems / EditInventoryStockItems, ViewInventoryPurchaseOrders / EditInventoryPurchaseOrders, ViewInventorySupplier, ViewInventoryTrackingProfiles, ViewInventoryReports), so the product has inventory that the API cannot read or write; (2) the guest data that reporting exposes is read-only - GET /reporting/v1.0/{appNameId}/customermanagement and its /details and /orders variants have no write counterpart; (3) loyalty is writable only as campaign configuration (POST/GET /api/v1.0/{appId}/campaigns/loyalty), with no per-guest stamp or points object to read or write; (4) on the newer v3.0 surface reads and writes are split across two products - the org-level Sales API is explicitly "read-only endpoints for querying sales" and directs you to the separate Sales Management API to "create, cancel, or update a sale", and both are in beta. Corpora: the 1,064-page v1.0 reference and the 99-page v3.0 reference, both from developers.flipdish.com llms.txt indexes, dumped 2026-08-09. This note replaces an earlier one asserting there were no customer, employee, loyalty or inventory endpoints at all, which was written against the v3.0 corpus only and is false against v1.0. https://developers.flipdish.com/v1.0/reference/createcustomer · retrieved 2026-08-09 adversarially verified

extensibility-published-rate-limits

Rate limiting is acknowledged and polling budgets are published, but no quota is. The POS integration guide states 'Do not retrieve the full menu frequently to check for changes as this endpoint this is an expensive operation and therefore highly rate limited', and gives numeric cadence guidance instead of limits: 'We recommend that you poll the menu version number once per minute or less frequently' and 'We recommend that you poll for new orders at most every 20 seconds and at least every 60 seconds'. Shortfall: no requests-per-minute or per-hour quota is stated for any endpoint; the Error Handling guide's list of 'common HTTP codes returned in case of errors' runs 400, 401, 403, 404, 409, 414, 500 and omits 429 entirely; and no rate-limit headers are documented - the strings 'rate limit', 'throttl', '429', 'quota' and 'X-RateLimit' appear nowhere in the 4.6MB, 99-page developer corpus. https://developers.flipdish.com/docs/build-a-pos-integration · retrieved 2026-08-09

extensibility-doordash-preferred differentiator

The researcher gave this score with NO source URL, violating the evidence bar — but I verified it independently and it is correct. The 2026 cohort (generated on performance as of 8 May 2026) is Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, UrbanPiper. Flipdish is absent; UrbanPiper, a Flipdish-listed integration, is present. Supplying the missing citation. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01 adversarially verified

extensibility-first-party-delivery-integrations differentiator

Score is right, source is wrong. /integrations does not name Just Eat, Uber Eats or Deliveroo anywhere. The correct citation is the order-management page: 'Receive and manage all your orders from Just Eat, Uber Eats and Deliveroo, while syncing menus, opening hours and more' and 'Update once in Flipdish POS, and see it go live on Just Eat, Uber Eats, and Deliveroo.' DoorDash and Grubhub confirmed absent from both pages. Partial stands. https://www.flipdish.com/pos-system/order-management · retrieved 2026-08-01 adversarially verified

extensibility-middleware-compatibility

Deliverect, ItsaCheckmate and UrbanPiper are all listed integrations, plus Zapier. https://www.flipdish.com/integrations · retrieved 2026-08-01

extensibility-accounting-connectors

Checked www.flipdish.com/integrations end to end on 2026-08-09: exactly three categories - Point of Sale (Captiva, CES, Clover, Epos Now, HioPOS, Lightspeed, Oracle Micros, PAR PixelPoint, Restaurant Manager, Revel, Revopos, Square, Squirrel, Toast, TouchBistro), Last Mile Delivery (Orkestro, Ondway, Nash, Stuart, VROMO) and Other (Deliverect, ItsaCheckmate, UrbanPiper, Zapier) - with no accounting or GL category, and each section ending 'And more! Can't find what you're looking for? Just get in touch with our friendly Sales team'. Pass 2 then searched the 1,064-page v1.0 API reference (developers.flipdish.com/v1.0/llms.txt, dumped 2026-08-09) as well as the 99-page v3.0 dump: zero occurrences of QuickBooks, Xero, Sage or 'journal', and no GL, ledger or accounting resource in either version. The only named third-party integrations anywhere in the v1.0 schemas are Stuart and Lightspeed. What v1.0 does add is that the platform has a marketplace slot for this: the App Store app schema (reference/getappstoreapp family, /api/v1.0/{appId}/appstore/apps) carries a Categories enum of PointOfSale, DeliveryAndLogistics, CRM, GiftCard, Accounting, LoyaltyAndMarketing, Other. So an accounting app category exists and no accounting app is named in any corpus I can read. That is not evidence that no vendor-maintained QuickBooks connector exists: the directory advertises its own incompleteness and defers to sales, the App Store contents are not published in the reference, and help.flipdish.com is excluded from this record by policy.

extensibility-payroll-export

Checked www.flipdish.com/pos-system/payroll-management and /integrations on 2026-08-09: Flipdish sells its own labour module ('With our payroll module, making and managing staff schedules is a breeze', 'See rota information and attendance records in real-time') and names no external payroll provider, and the integrations directory has no payroll category. Pass 2 searched the 1,064-page v1.0 API reference (developers.flipdish.com/v1.0/llms.txt, dumped 2026-08-09). It confirms the module is real: the teammate permission enum used across the accounts and teammates schemas includes ViewPayrollReports, EditPayrollHoliday, ViewPayrollHoliday, EditPayrollRota, ViewPayrollRota, EditPayrollStaff and ViewPayrollStaff. But there is no way to get the hours out over the API: 'timesheet', 'clock-in', 'clockin', 'attendance', 'shift', 'labour' and 'employee' all return zero occurrences in the 1,064 pages, no endpoint path contains rota or timesheet, and Gusto, ADP, Paychex and Paylocity are named nowhere. So the API offers no labour export, and the only export operations in v1.0 are financial (payouts, payout orders, refunds, chargebacks). Whether the payroll module itself exports to a named provider from the merchant portal is documented, if anywhere, on help.flipdish.com, which robots.txt disallows for ClaudeBot by name and which the user confirmed out of scope on 2026-08-09.

extensibility-bi-data-warehouse differentiator

Transaction-level data is fully extractable, but only by a pipeline the customer builds and runs. The v3.0 Sales API exposes org-level read endpoints described as 'paginated complete sale objects for sync or export' - List sales (org-wide), List sales for a property, Get a sale - and the sale.* webhook family 'delivers full sale payloads inline for every sale recorded on Flipdish, regardless of channel'. Flipdish publishes a whole guide for this, 'Build a POS sales analytics integration', covering onboarding, menu reference sync and reconciliation ('Run a periodic reconciler using the org-wide list endpoints'). Shortfall: there is no vendor-operated scheduled export at all - no S3, SFTP, warehouse or Snowflake destination is documented anywhere (zero occurrences of S3, SFTP or Snowflake in the 99-page corpus); the scheduling is advice to the integrator; the org-wide query endpoints carry the beta notice ('may change or be deprecated at any time without notice'); and the portal's own bulk file exports are limited to payout, order, refund and chargeback CSVs on v1.0. https://developers.flipdish.com/reference/sales · retrieved 2026-08-09

extensibility-app-marketplace

I read the full /integrations page. It is a static directory grouped by category (POS: Captiva, CES, Clover, Epos Now, HioPOS, Lightspeed, Oracle Micros, PAR PixelPoint, Restaurant Manager, Revel, Revopos, Square, Squirrel, Toast, TouchBistro; last mile: Okestro, Ondway, Nash, Stuart, VROMO; plus Deliverect, ItsaCheckmate, UrbanPiper, Zapier). Every entry routes to 'Contact sales', and the page says 'can't find your POS system? Just get in touch with our friendly Sales team.' The alternative is affirmatively enumerated: sales-gated directory, no browse-and-install, no per-app listings with ins https://www.flipdish.com/integrations · retrieved 2026-08-01 adversarially verified

extensibility-custom-fields-scripting

Operator-defined custom fields exist as arbitrary key/value metadata on menu objects, documented as a first-class integration mechanism: 'we allow you to store metadata alongside entities in the Flipdish menu. This means you can, if you wish, create a fully functional integration without creating any new datastore on your side ... you will save your associated product IDs/references as metadata for each MenuSectionItem or MenuOptionSetItem. This metadata will then be returned to you in each order notification webhook'. The v1.0 and v3.0 references back it with Get/Update/Delete menu item metadata, metadata-by-key and 'Get metadata for a specific menu item or modifier' endpoints. Shortfalls: it is API-only, so it is a developer facility rather than something an operator configures in the portal on either permitted host; it is scoped to menu entities - the same guide says 'It is not currently possible to add metadata to Customers'; it is unsafe for anything sensitive ('Metadata is not encrypted at rest'); and no vendor-hosted scripting or custom logic exists anywhere in the corpus - the extension model is external webhooks plus App Store apps you host yourself. https://developers.flipdish.com/docs/build-a-pos-integration · retrieved 2026-08-09

extensibility-headless-embedded

What exists is sale submission after the fact, not a headless transaction engine. The v3.0 Sales Management API accepts a completed sale 'from an external system (POS, marketplace, kiosk, ordering platform)' with items, charges, discounts and payment lines already priced by the caller, and Flipdish separately drives ordering on top of third-party POS systems. There is no documented API for a third-party UI to drive Flipdish's own transaction engine - no basket, pricing, tax-calculation, tender or payment-authorisation endpoints appear in either reference tree, and the 1,064-page v1.0 reference contains no consumer ordering or checkout operation at all. Access is a second limit: the Sales Management API states 'The Sales Management API is currently in beta. Endpoints may change. Contact integrations@flipdish.com to request access', and v1.0's only order-creation operation, order-ingest/submit, is marked '[ALPHA - ... not available just yet to use in your production system]'. https://developers.flipdish.com/docs/sales-management-api.md · retrieved 2026-08-09 adversarially verified

extensibility-api-versioning-deprecation

Versioning and supersession are handled in the open; a changelog and a notice policy are not. The API Overview states 'The current API version is v3.0. Consumer Orders endpoints remain available on v1.0', with separate v3.0 and v1.0 reference trees and llms.txt indexes, and superseded guides carry explicit banners pointing at the replacement ('Superseded by the v3.0 sales analytics guide ... this page is kept for reference only'). Shortfall: no changelog is published - developers.flipdish.com/changelog returns the site's 404 shell (74,060 bytes, against ~6.5KB for a real page), 'changelog', 'breaking change' and 'sunset' appear zero times in the 99-page corpus, and the 'Product updates' footer link goes to a Beamer widget rather than an API changelog. Worse for the claim, the stated policy on the many beta endpoints is the opposite of a notice period: 'This endpoint is currently in beta and may change or be deprecated at any time without notice', repeated on essentially every org, brand, property and sales-channel endpoint. https://developers.flipdish.com/docs/api-overview · retrieved 2026-08-09

extensibility-data-portability-exit differentiator

Most of the named data is retrievable through documented machine-readable endpoints at any time: complete paginated sale objects org-wide and per property (Sales API, 'paginated complete sale objects for sync or export'), full menu revisions plus 'Export menu in specific format', audit log queries, v1.0 customer list endpoints, and CSV exports of payouts, payout orders, refunds, chargebacks and other charges. Shortfalls: no contract-end export process or data package is documented anywhere; the menu export and the org-wide sales queries both carry the beta notice ('may change or be deprecated at any time without notice'); no format specification for a full historical dump is published; and the Terms of Service create no return obligation for operator business data - clause 14.2(f) covers only personal data processed by Flipdish as a processor ('at your choice, delete or return all such personal data processed on the termination'), while 5.6 provides that on termination 'all rights granted to you under this Agreement will cease immediately'. Extraction is therefore something the operator must do before the account ends, using beta endpoints, not an on-demand exit deliverable. https://developers.flipdish.com/reference/sales · retrieved 2026-08-09

reliability-offline-order-entry

Re-checked both permitted hosts on 2026-08-09. www.flipdish.com/pos-system, /pos-system/order-management, /pos-system/hardware and /handheld-pos make no offline claim; the closest statement is the handheld's 'built-in SIM connectivity means it keeps working wherever you need it', which is connectivity redundancy, not local operation. The 99-page v3.0 developer corpus has three occurrences of 'offline', all describing a sales channel being snoozed. Pass 2 searched the 1,064-page v1.0 API reference: its 74 'offline' hits are all device-connectivity status enums, not a local-operation mode. The documented terminal architecture there is entirely cloud-mediated - devices register and poll through /api/v1.0/hydra/registration and /api/v1.0/hydra/settings, get a realtime channel token from /api/v1.0/hydra/ably_token, attach to a store via /api/v1.0/{appId}/hydra/{deviceId}/attach/{storeId}, and card payment state is held server-side (/api/v1.0/{appId}/hydra/emvorderstate/{orderId}, /hydra/cancelemvpayment/{orderId}); HydraConnectionStatusChangedEvent reports Online / PossiblyOffline / Offline from cloud polling. That establishes the API path is cloud-only. It does not establish what the POS application does on-device when the link drops, which is in-product behaviour documented on help.flipdish.com - excluded from this record by policy - so this cannot be resolved from the API surface or the marketing site.

reliability-offline-card-auth differentiator

No offline mode exists, so offline card authorization is not possible. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-offline-decline-liability differentiator

Flipdish has no offline mode and no store-and-forward capability, so declined offline-transaction liability allocation does not apply. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-lan-degraded-multi-terminal differentiator

Checked www.flipdish.com/pos-system, /pos-system/hardware and /pos-system/kitchen-display-system on 2026-08-09: multi-terminal setups are sold (register plus handheld plus KDS plus printers) but no LAN topology, local server, peer-to-peer check sharing or degraded-mode behaviour is described on any of them. Pass 2 searched the 1,064-page v1.0 API reference in addition to the 99-page v3.0 dump. Every documented interaction is HTTPS to https://api.flipdish.co, and the device model is star-shaped rather than peer-to-peer: each device is a separately registered 'hydra' unit identified by deviceId, attached to a store by /api/v1.0/{appId}/hydra/{deviceId}/attach/{storeId} and reached over a cloud realtime channel (/api/v1.0/hydra/ably_token), with kiosks and terminals opening their own cloud connections at /api/v1.0/kioskiot/connect and /api/v1.0/terminaliot/connect. There is no local, LAN, peer, sync or shared-check surface, and no open-check or table resource in either version. That says the API cannot express LAN check sharing; it does not say the POS application lacks it. help.flipdish.com, whose network and setup articles are exactly where this would be answered, is excluded from this record by policy.

reliability-local-transaction-engine differentiator

Checked on 2026-08-09. www.flipdish.com/posinstall describes a 'Flipdish Windows application' only as a way to 'print their orders from a Windows PC' and to bridge the PAR PixelPoint and Oracle Micros RES3700 integrations - a local print/integration bridge, not a documented transaction engine. status.flipdish.com's components ('Core service', 'Flipdish POS', 'Flipdish Terminals', 'API', 'Kiosks', 'SIM Printers') are consistent with a cloud-hosted ordering path. Pass 2 read the 1,064-page v1.0 API reference. It shows there is on-site software - the 'hydra' device client, whose HydraConfig object carries MinimumVersion, Version, BuildNumber, GitSha, GitBranch and DeviceSettings (Volume, FontSize, Brightness) - but it is documented purely as a cloud-managed client: config is fetched from /api/v1.0/hydra/settings, the device registers at /api/v1.0/hydra/registration, realtime messaging runs through an Ably token issued by /api/v1.0/hydra/ably_token, and card-payment state lives server-side (/api/v1.0/{appId}/hydra/emvorderstate/{orderId}). No on-premise transaction engine, edge server or local order store is documented in either API version, and neither permitted host states that none exists. The earlier rationale's 'conflicts with cloud-only architecture' was an inference, not a source.

reliability-offline-kds-printing

Re-checked on 2026-08-09. www.flipdish.com/pos-system/hardware sells an '80mm Kitchen cloud printer' ('our cloud thermal kitchen printer streamlines your kitchen ops') alongside the 21.5in KDS, and status.flipdish.com carries distinct 'SIM Printers' and 'Star Micronics Integrations' components, which together indicate the print path is mediated by Flipdish cloud services and can fail independently of the POS. Pass 2 searched the 1,064-page v1.0 API reference. Printers appear there only as cloud-tracked objects in the event catalogue - printer.turned_on, printer.turned_off, printer.assigned_to_store and printer.unassigned_from_store (PrinterTurnedOnEvent, PrinterTurnedOffEvent, PrinterAssignedToStoreEvent, PrinterUnassignedFromStoreEvent) - and there is no printer endpoint path anywhere in the 1,064-page manifest, while 'kds' and 'kitchen' return zero occurrences in the whole corpus. So the platform models a printer's online state centrally and exposes no print-routing API, and neither permitted host states what a KDS or kitchen printer does with the internet down. help.flipdish.com, which documents printer setup, is excluded from this record by policy.

reliability-printer-fallback

Three passes, none of which found a fallback mechanism or a statement ruling one out. The printer documentation was read end-to-end on 2026-08-03 while still readable: the KOT/receipt troubleshooting guide prescribes manual reboot, cable checks and Configuration Wizard re-setup; KDS station settings let staff choose which printers attach to each station; the multi-station FAQ covers static routing only ('Three tickets will print from the one printer'). Nothing in that title census mentioned a backup printer, automatic failover or an unreachable-printer alert. On 2026-08-09 www.flipdish.com/pos-system/kitchen-display-system documents 'Prep stations - Prepare orders faster by sending them to different stations' and label printing, with no fallback or alerting. Pass 2 searched the 1,064-page v1.0 API reference: it publishes printer state transitions as subscribable events (printer.turned_on, printer.turned_off, printer.assigned_to_store, printer.unassigned_from_store), which an integrator could use to build their own alerting, but there is no printer endpoint family, no station or routing resource, and no automatic-reassignment field; 'fallback' occurs exactly once in the corpus and is a withFallback query parameter on the brand SMS-provider credential endpoint. help.flipdish.com is now excluded by policy, so the 2026-08-03 reading cannot be extended. Absence remains unproven.

reliability-sync-conflict-handling

The vendor documents no conflict-resolution behavior, and its own FAQ forecloses the scenario the claim describes: 'The Flipdish POS does not support an offline mode' — devices do not operate through a network partition, so no divergent offline edits arise to reconcile, and no last-write-wins/merge/operator-prompt behavior is documented anywhere; the only documented mitigation is 'setting up a backup hotspot network'. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-offline-feature-matrix

Flipdish POS does not support offline mode, so no offline-feature matrix exists. https://help.flipdish.com/en/articles/9585187-is-there-an-offline-mode-on-the-flipdish-point-of-sale · retrieved 2026-08-04 · not refetchable · site policy · graded B when read

reliability-public-status-page

The earlier 403 does not reproduce. status.flipdish.com returned HTTP 200 with a full Atlassian Statuspage body on 2026-08-09, with no login anywhere in the flow. It shows 'All Systems Operational' over a per-component breakdown - Core service (99.99% uptime), Web Ordering (100.0%), Flipdish POS (99.97%), Mobile App Ordering, Hosted Websites, API, Kiosks, Flipdish Terminals, Third Party POS Integrations (99.97%), Third Party Delivery Integrations, Star Micronics Integrations, Card Payments (Stripe), Telephony System, Support phone lines, DoorDash Drive Order Fulfillment, CDN, SIM Printers and more - each with 'Uptime over the past 90 days' and a 'View historical uptime' link. Historical state is public too: a 'Past Incidents' timeline on the front page and an archive reachable without credentials (status.flipdish.com/api/v2/incidents.json returns 50 incidents). Email, SMS, Slack and webhook subscriptions are offered. https://status.flipdish.com/ · retrieved 2026-08-09

reliability-contractual-uptime-sla differentiator

T&Cs provide the services on an 'as is' and 'as available' basis with no uptime guarantee and no service-credit remedy. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

reliability-incident-postmortems

Flipdish publishes root-cause summaries inside its Statuspage incident timeline, but nothing more formal. The 6 August 2026 'Communication service is down' incident closes: 'We identified the root cause as a failed deployment to our Communication Service, which impacted multiple communication-related services, including SMS delivery and payment links. The previous stable deployment has now been successfully restored', with an earlier 'Identified' update timestamped 21:34 BST and the resolution at 21:55 BST. Shortfall: it is not the norm. Reading the public archive (status.flipdish.com/api/v2/incidents.json, 50 incidents on 2026-08-09), most resolutions - including several rated critical, such as 'Intermittent failures accepting payments online' (12 Feb 2026) and 'Orders processing performance issues' (29 Oct 2025) - close with a bare 'This incident has been resolved' or an all-clear with no cause given. No separate written post-incident report, RCA document or postmortem archive is published on either permitted host. https://status.flipdish.com/ · retrieved 2026-08-09

reliability-247-live-support

Included support comprises a dedicated account manager, Help Centre articles, Flipdish Academy videos and email, WhatsApp and phone support; 24/7/365 coverage is not stated. https://www.flipdish.com/pricing · retrieved 2026-08-01

reliability-onsite-install differentiator

The Terms of Service settle it in Flipdish's own contract, section 12.9 Installation: 'If you decide to use our hardware installation services ... An assigned technician, whether internal or outsourced, will install the hardware at your specified location. Failure to have the premise available or prepared on arrival may incur additional charges ... Any necessary non agreed work including infrastructure or cabling modifications will incur additional charges and may result in the installation appointment being cancelled on arrival.' Section 4.3 lists 'Hardware installation and cabling services' as a chargeable outlay and 4.2 charges 'An initial set-up fee relating to activation and set-up ... for each initial provisioning of the Services'. The hardware page FAQ says the same in sales language: 'to make sure you are setup right, right from the get-go, our team will visit you in person and help with your hardware installation.' So it is real, first-party or via an outsourced technician, and priced as an extra rather than included. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

reliability-menu-build-service differentiator

Checked on 2026-08-09 and found only indirect hints, not a statement. www.flipdish.com/pricing promises 'From making sure you are set up properly from the start' and 'A dedicated account manager', without saying who builds the menu. The Terms of Service imply Flipdish receives menu data during onboarding - clause 3.1.8 warrants that 'all pricing relating to food and other items that you make available for sale through the Services or provide to us for onboarding is transparent' - and clause 4.2 charges 'An initial set-up fee relating to activation and set-up ... for each initial provisioning of the Services', but neither says a menu build is performed or included. A grep of the 1,719-URL English www sitemap and of the 28 cached www pages for 'onboard', 'menu build' and 'build your menu' turns up nothing beyond that T&C clause. The API cuts the other way in both versions: v3.0 offers bulk menu create/clone and an AI menu editor, and the 1,064-page v1.0 reference adds 'Create a new menu from xlsx file', 'Clone a menu, (without attaching stores)', clone menu section and section item, and menu/section/item image upload - i.e. menu construction is tooled as an operator self-serve job. That is not evidence about what the onboarding team does. help.flipdish.com, where an onboarding article would live, is excluded from this record by policy.

reliability-hardware-replacement-sla

A replacement remedy is published; a turnaround is not. Terms of Service 12.8 warrants the hardware for 'a period of six (6) months from delivery' and 12.4.5 provides that 'If we accept a claim of a Hardware fault due to manufacturing or workmanship defect, we may replace it free of charge or refund the purchase price, prorated for the defect but we will not have any further liability to you'. Shortfall: there is no advance-exchange or cross-ship programme, purchasable or included, and no turnaround time is stated anywhere - not next-business-day, not any figure. The surrounding clauses run the other way: 12.3 makes returns discretionary ('returns are at our sole discretion', used or unboxed hardware not returnable), 12.4.4 puts a 7-business-day inspection duty on the customer, 12.1 leaves maintenance to the operator 'unless maintenance is specifically included as a Service', and 13.1 disclaims any availability commitment ('as is' and 'as available'). https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

reliability-backup-restore

Checked on 2026-08-09 across both permitted hosts and both API versions. There is a restore primitive but it is not operator-facing: the v1.0 reference lists 'Get a Menus Checkpoints' and 'Restore a Menu to a checkpoint', and both are labelled '[PRIVATE API]' - one of 32 operations in the 1,064-page corpus carrying that label - so neither an operator nor their integrator can invoke them. Beyond that there is no backup surface at all: 'backup' occurs zero times in either the 99-page v3.0 dump or the 1,064-page v1.0 dump, and the remaining 'restore' hits concern webhook subscriptions ('Deleted subscriptions cannot be restored'). The only export operations in v1.0 are financial - /api/v1.0/{appId}/payouts/export and the per-payout orders, refunds, chargebacks and othercharges exports - which is settlement reporting, not a data backup. No RPO or RTO figure is published on either permitted host: www.flipdish.com/security 404s, trust.flipdish.com does not resolve in DNS, and the Terms of Service disclaim availability entirely (13.1: 'as is' and 'as available'), with clause 14.2(f) offering deletion or return of personal data only. Whether the merchant portal offers a self-service data download is documented, if anywhere, on help.flipdish.com, excluded from this record by policy.

reliability-pci-dss-4-attestation

Re-probed the security surface on 2026-08-09. trust.flipdish.com and security.flipdish.com do not resolve in DNS (NXDOMAIN). www.flipdish.com/security and /gdpr both 404. www.flipdish.com/legal is the vendor's own index of compliance material - 'This page provides access to our terms, policies and regulatory compliance information' - and lists exactly five documents: Flipdish Terms and Conditions, Privacy Policy, Cookie Policy, EU Digital Services Act and EU Accessibility Act. No Attestation of Compliance, no validated P2PE listing, no SOC report. The Terms of Service never mention PCI. Pass 2 searched the 1,064-page v1.0 API reference as well as the 99-page v3.0 dump: 'PCI', 'P2PE' and 'SAQ' return zero occurrences in both. status.flipdish.com shows card payments run through Stripe, whose own validation would not be Flipdish's attestation. Left unknown rather than no because /legal does not assert that it is exhaustive, an AoC is customarily released under NDA on request rather than published, and the merchant-facing compliance page where a vendor would say so sits on help.flipdish.com, excluded from this record by policy.

reliability-mfa-role-based-access

Role-based permissions in the portal are documented; MFA is not documented anywhere we may read. Two first-party statements establish the roles half: the v3 webhooks guide's prerequisites state 'Only users with the Owner or Managed Owner role in the Flipdish portal can create webhooks, as these roles include the Edit Webhooks permission', and the Flipdish MCP server guide states that a passed-through session token means 'your existing role-based permissions are enforced. You only ever see the data and actions your Flipdish account already allows.' Neither page carries a maturity marker. Nothing establishes the MFA half: 'MFA', 'two-factor', 'multi-factor' and 'authenticator' return zero matches across the 99-page v3.0 corpus, the 1,064-page v1.0 corpus and the www.flipdish.com pages retrieved, and the only place enforcement policy would be published is help.flipdish.com, whose robots.txt disallows our crawler by name. An earlier note also asserted 'per-module permissions in the POS'; that is withdrawn as unlocatable in any source we may retrieve. https://developers.flipdish.com/docs/webhooks-v3.md · retrieved 2026-08-09 adversarially verified

reliability-self-serve-training

Flipdish Academy videos plus a Help Centre article library are named as included support resources; an on-terminal training mode is not documented. https://www.flipdish.com/pricing · retrieved 2026-08-01

reliability-failover-terminal-role differentiator

Checked on 2026-08-09. www.flipdish.com/pos-system/hardware sells registers, handhelds, KDS screens and printers without naming a master, primary or server role. Pass 2 read the device surface of the 1,064-page v1.0 API reference, which is far larger than the v3.0 dump and still describes no terminal topology: a device is a 'hydra' unit that registers with the cloud (/api/v1.0/hydra/registration), pulls settings (/api/v1.0/hydra/settings, whose HydraConfig holds only version fields and Volume/FontSize/Brightness), attaches to and detaches from a store (/api/v1.0/{appId}/hydra/{deviceId}/attach/{storeId}), and is listed by type (/api/v1.0/{appId}/hydra/{deviceType}/list); card readers report Status of Not_Connected, Connecting, Connected, Online or Offline with serial number, software version and battery level. No role, master, primary, server, cluster, election or promotion field exists anywhere in the corpus, and kiosks and terminals each open their own independent cloud connection (/api/v1.0/kioskiot/connect, /api/v1.0/terminaliot/connect). Because no primary/secondary architecture is documented in the first place there is nothing to affirm or deny about automatic promotion, and the product manual (help.flipdish.com) that would describe multi-terminal setup is excluded by policy.

reliability-cellular-backup

The handheld has built-in SIM connectivity as a documented fallback; automatic cellular failover for fixed terminals is not documented. https://www.flipdish.com/handheld-pos · retrieved 2026-08-01

commercial-month-to-month-contract differentiator

'The Agreement ... continues for 12 months ... It then auto-renews for 12-month periods.' No month-to-month option is offered publicly. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-no-early-termination-fee differentiator

Termination outside the notice window incurs 'termination compensation of the monthly average of the previous 6 months' fees ... multiplied by the number of months remaining in the Term' — explicit liquidated damages. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-autorenew-terms-published

Publicly accessible T&Cs state the 12-month initial term, 12-month auto-renewal, and a 3-month written cancellation notice window. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-processing-not-bundled differentiator

Positive evidence of lock-in from the merchant Terms of Service rather than from silence. 1.3: 'You agree that we will be your exclusive provider of technological solutions similar or equivalent to any of the Services that you use.' 3.7: 'Flipdish may accept orders from End-Users on your behalf via the Services and collect payment from End-Users for such orders.' 4.9 Disbursements: 'we will arrange for the transfer of the total amount of payment card sales processed by us during the relevant sales period, less commission, charges and fees payable to us' - the settlement model presumes Flipdish processes the card sales. 4.5 grants Flipdish a right of setoff 'directly from any sales processed through the Services' and 4.7 makes Flipdish the party that manages Chargebacks. No clause anywhere in the T&Cs contemplates an operator-nominated acquirer or PSP. Corroborated commercially: the one published POS plan on www.flipdish.com/pricing (from EUR 99/month per site) lists 'Transparent transaction fees' and 'Integrated payments' as included, and the add-on list (Kiosks, Managed Marketing, KDS, Uber Direct, Customer Feedback App, Phone Marketing) contains no alternative-processor option; www.flipdish.com/pos-system/payments sells Flipdish Pay as 'one solution for online and in-store payments ... All under one roof. One brand.' and answers 'Do I need any extra software? Nope. Everything you need is built in.'; and www.flipdish.com/integrations has POS, last-mile-delivery and 'other' categories but no payments category and names no third-party processor. Caveat recorded honestly: help.flipdish.com is excluded from this record by policy, so a bespoke Client Agreement variation cannot be ruled out from public sources. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-09

commercial-interchange-plus-published differentiator

No processing rate of any kind — blended or interchange-plus — is published; only the phrase 'transparent transaction fees'. https://www.flipdish.com/pricing · retrieved 2026-08-01

commercial-rate-increase-clause differentiator

The opposite is published: 'The Fees may be varied by us at any time (acting reasonably)' plus 'an annual adjustment of up to 5% of your processing rate ... to reflect modest changes in operating costs', with no stated penalty-free exit on increase. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-pricing-published

Per-site subscription tiers are published in EUR and USD (bundle from EUR99/mo; website EUR49/USD119; website+app EUR79/USD199; kiosk EUR59/USD79, all billed annually, with higher monthly rates). Standalone POS pricing, per-additional-terminal pricing and every add-on remain quote-only. https://www.flipdish.com/pricing · retrieved 2026-08-01

commercial-module-unbundling differentiator

Online ordering, kiosk, KDS, Managed Marketing, Uber Direct, Customer Feedback App and Phone Marketing are separately packaged (some separately priced) and bundling is discounted — but independent mid-term cancellation is not offered given the 12-month term and 3-month notice. https://www.flipdish.com/pricing · retrieved 2026-08-01

commercial-hardware-purchase-outright

Hardware is bought upfront with optional monthly installments per the US pricing FAQ; no prices are published for any SKU, so 'at a published price' fails. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

commercial-hardware-not-locked differentiator

Selling third-party-branded SKUs is not the same as accepting hardware you already own. The hardware page lists 15 SKUs (Epson TM-20III (012A0), Brother QL-800, Artech caller ID, cash drawer, barcode scanner, RFID reader, K2/K2 Mini/D2S kiosks) but every one is a Flipdish-supplied item, and there is no supported-device list, no minimum spec, and no BYO statement anywhere — the researcher concedes this under hardware-commodity-devices and hardware-peripherals but then scores 'not locked' as yes. Specific model/firmware pinning (TM-20III with a part number) cuts the other way. https://www.flipdish.com/pos-system/hardware · retrieved 2026-08-01 adversarially verified

commercial-implementation-fee-published

The US pricing FAQ states there 'may be upfront costs for Flipdish hardware and implementation' that vary by need — acknowledged but never quantified, and never stated as $0. https://www.flipdish.com/us/pricing · retrieved 2026-08-01

commercial-data-export-self-serve

Custom reports and paginated sales APIs (listOrgSales, listPropertySales, getSale) let an operator pull transaction-level data; a documented full self-serve export of orders, line items, payments and labour to CSV is absent, and labour data is not in the public API at all. https://developers.flipdish.com/reference/listorgsales.md · retrieved 2026-08-01

commercial-export-customer-and-loyalty differentiator

Guest records are exportable, the other two datasets in this claim are not. The v1.0 Reporting API (OpenAPI 'Flipdish Reporting V1', server https://api.flipdish.co, OAuth2) documents GET /reporting/v1.0/{appNameId}/customermanagement - 'By passing in the appropriate query, you can receive filtered and paginated list of customers' - returning CustomerListItem objects with customerId, phoneNumber, name, totalOrders, totalOrderValue, currency, averageOrderValue, lastOrderDate and optedInForMarketing, filterable by store and currency; /customermanagement/details 'Returns the name, phone number and email' (CustomerDetail: customerId, phoneNumber, name, email) and /customermanagement/orders 'Returns the list of orders for a particular customer'. Named shortfalls: (1) no loyalty balance or point/stamp ledger is exposed in either API version - loyalty appears only as campaign configuration (/api/v1.0/{appId}/campaigns/loyalty and /campaigns/loyalty/{storeId}, LoyaltyCampaign create/read plus a StampLoyaltyCardAgainstCampaignsConfigurations teammate permission), with no per-guest stamp count or points balance object anywhere; (2) there is no gift-card resource at all - 'GiftCard' occurs in the 1,064-page v1.0 reference only as an App Store app-category enum value, so gift-card liability balances cannot be exported. Corpora: the 1,064-page v1.0 API reference and the 99-page v3.0 reference, both pulled from developers.flipdish.com llms.txt indexes on 2026-08-09. Whether the merchant portal offers CSV downloads of the same data is documented on help.flipdish.com, which is excluded from this record by policy, so this is scored on the API surface. https://developers.flipdish.com/v1.0/reference/get_reporting-v1-0-appnameid-customermanagement · retrieved 2026-08-09

commercial-post-termination-export-window differentiator

T&Cs provide that on termination Flipdish will 'at your choice, delete or return all such personal data processed' — a return right, but no defined number of days and no format commitment. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-data-ownership-clause differentiator

T&Cs state 'You retain ownership of all content and data provided by you', but the privacy policy positions Flipdish as controller of consumer ordering data, processing it 'for its own independent purposes, such as platform security, analytics, and service improvement' — so vendor use is not constrained to aggregated/de-identified purposes. https://www.flipdish.com/privacy-policy · retrieved 2026-08-01

commercial-source-available-selfhost

Proprietary hosted SaaS; no source availability or self-hosting option anywhere in Flipdish materials. https://www.flipdish.com/docs-inner/tac-2 · retrieved 2026-08-01

commercial-pci-p2pe-tokenization

Searched both permitted hosts and both API versions on 2026-08-09. The 99-page v3.0 dump and the 1,064-page v1.0 dump both return zero occurrences of 'PCI', 'P2PE' and 'SAQ'; the only two 'token' schema hits in v1.0 are a PasswordResetModel TokenId, not a payment token. Pass 2 did locate the card-present surface that v3.0 lacks: /api/v1.0/{appId}/cardreaders (reference/cardreaders_getreader) enumerates DeviceType values CHIPPER_2X, COTS_DEVICE, VERIFONE_P400, WISEPAD_3 and WISEPOS_E - the Stripe Terminal reader range, consistent with the Stripe dependency shown on status.flipdish.com - and exposes only SerialNumber, SoftwareVersion, Status, BatteryLevel and UpdateTime, with no PAN, token, encryption or key-management field. The PaymentAccountType enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) is the whole payment taxonomy. So hardware card entry on certified reader models is documented, but no validated-P2PE listing, no tokenization statement and no named merchant SAQ type is published anywhere I can reach: www.flipdish.com/legal enumerates only the T&Cs, Privacy Policy, Cookie Policy, EU DSA and EU Accessibility Act statements; the merchant T&Cs (/docs-inner/tac-2) mention PCI nowhere; /pos-system/payments sells Flipdish Pay on fees, payouts, fraud detection and tipping; a grep of the 1,719-URL English www sitemap for 'secur|certif|complian|iso|soc|attest' returns no trust page; trust.flipdish.com and security.flipdish.com are NXDOMAIN. Not recorded as absence, because a merchant-facing 'is Flipdish PCI compliant' article is exactly what help.flipdish.com would carry, and that host names ClaudeBot in robots.txt and was confirmed out of scope by the user on 2026-08-09.

commercial-pci-dss-4-controls

Checked both API versions and both permitted hosts on 2026-08-09. 'PCI', 'MFA', 'two-factor', 'authenticator' and 'SAML' return zero occurrences across the 99-page v3.0 dump and the 1,064-page v1.0 dump (the six 'OTP' hits in v1.0 are an OtpNumber field in getsupportedcountries - 'The phone number provided to Store staff which, in conjunction with a one-time-code, will connect them to the customer' - a masked-calling number, not authentication). Pass 2 did find two mechanisms the earlier pass could not see. First, v1.0 publishes POST /api/v1.0/csp/report (ContentSecurityPolicy_Report, CspReportRequest), a Content-Security-Policy violation-report collector, which shows CSP is deployed on Flipdish-hosted pages - but no page in either corpus frames it as Requirement 6.4.3 or 11.6.1 payment-page script integrity monitoring, and a report collector is not a change-and-tamper-detection commitment. Second, the account surface is documented - /api/v1.0/accounts/login, /api/v1.0/accounts/login/sso (LoginSso) and password reset - with no second-factor field anywhere, so there is no documented MFA-for-CDE control either way; API access itself is OAuth2 client credentials, which is application authentication, not human access to a cardholder data environment. On www.flipdish.com the /legal hub lists only the T&Cs, Privacy Policy, Cookie Policy, EU DSA and EU Accessibility Act statements; the merchant T&Cs at /docs-inner/tac-2 impose security obligations only by reference to GDPR Article 32, never to PCI DSS; trust.flipdish.com is NXDOMAIN. Because the operator-facing security notices for Flipdish's hosted ordering pages would sit on help.flipdish.com - excluded from this record by policy - absence on the developer and marketing hosts is not evidence that the controls are absent.

commercial-soc2-attestation

Materially better checked than before, still short of a verdict. www.flipdish.com/legal is the vendor's own 'Legal and compliance' hub - 'This page provides access to our terms, policies and regulatory compliance information' - and it links to exactly five artefacts: Flipdish Terms & Conditions, Privacy Policy, Cookie Policy, EU Digital Services Act statement, EU Accessibility Act statement. No SOC 2, no ISO 27001, no security overview, no report-under-NDA offer. A grep of the full 1,719-URL English www sitemap for 'secur|certif|complian|iso|soc|attest' returns only unrelated social-media blog posts. trust.flipdish.com and security.flipdish.com both fail DNS resolution (NXDOMAIN), and guessed paths /security, /trust and /dpa all return the site's 403 not-found response. The privacy policy references standard contractual clauses for EEA transfers but asserts no certification; the merchant T&Cs commit only to 'all security measures required pursuant to Data Protection Laws (including Article 32 of the GDPR)'. Pass 2 searched the 1,064-page v1.0 API reference in addition to the 99-page v3.0 dump: 'SOC 2' and 'ISO 27001' both return zero occurrences. Deliberately not called 'no': the claim is about whether the vendor STATES it holds an attestation, and a merchant-facing security FAQ making exactly that statement would live on help.flipdish.com, which names ClaudeBot in robots.txt and is excluded from this record by the user's 2026-08-09 decision.

commercial-privacy-dsar-tooling

The DPA half is satisfied: Section 14 of the merchant Terms of Service (www.flipdish.com/docs-inner/tac-2) is a data-processing agreement the operator executes by contracting - it defines Data Protection Laws, binds Flipdish as processor to confidentiality, 'all security measures required pursuant to Data Protection Laws (including Article 32 of the GDPR)', 'reasonable assistance to you, by appropriate technical and organisational measures, to respond to data subject rights exercised pursuant to Data Protection Laws (including Articles 15 to 22 of the GDPR)', breach and DPIA assistance, and 'at your choice, delete or return' of the data; 14.4 then allocates joint-controller responsibilities for the Ordering Process, expressly assigning to Flipdish the duty of 'responding to any data subject requests in accordance with the GDPR (including requests under Articles 15 to 22 GDPR)' for data it collects on the Flipdish Platform. The privacy policy adds standard contractual clauses for EEA transfers, available on request from the data-protection mailbox. The tooling half falls short on three named points. (1) Deletion is guest-initiated, not operator-operated: 'If you order online or via iOS, you can select Delete Account under the About my Data section.' (2) It does not cover every channel - 'Kiosk and Android Apps: please contact Flipdish Support' with a phone number plus either the most recent Order ID or the last four digits of the payment card, i.e. a manual, identity-verified email workflow rather than a self-serve one. (3) Nothing documents an operator-side console to LOCATE or EXPORT one guest's records: the complete 106-entry developers.flipdish.com API manifest exposes no customer or guest resource of any kind, so there is no programmatic access-request path either. Deletion is also global rather than per-merchant - 'an account deletion is irreversible and affects your account across all Flipdish-powered restaurants'. No CCPA/CPRA-specific mechanism (do-not-sell/share, authorised-agent handling) is described anywhere on the permitted hosts. https://www.flipdish.com/consumer-information/data-protection · retrieved 2026-08-09

commercial-wcag-kiosk-accessibility differentiator

A published accessibility statement targets 'WCAG 2.1 Level AA' across websites, mobile apps, kiosks and the ordering flow and commits to European Accessibility Act conformance, citing keyboard navigation and screen-reader compatibility — but there is no VPAT/ACR, no kiosk tactile/audio mode described, and Flipdish concedes 'Some parts of our products are not yet fully accessible.' https://www.flipdish.com/accessibility-statement · retrieved 2026-08-01

commercial-dual-pricing-compliant differentiator

Checked the merchant Terms of Service (www.flipdish.com/docs-inner/tac-2) end to end: it covers Fees, Payment Method, Availability of Proceeds, Chargebacks, End-User Refunds and Disbursements, and never mentions surcharging, cash discounting, dual pricing, convenience fees or card-network rules. www.flipdish.com/pos-system/payments describes Flipdish Pay as a 'low blended rate' across all card types 'even AMEX' - a blended rate is the opposite of the card-type discrimination this claim requires, but that is a pricing observation, not a statement about the feature. Pass 2 read the fee-configuration surface in the 1,064-page v1.0 API reference: POST and GET /api/v1.0/stores/{storeId}/servicecharge take a ServiceCharge object whose complete field set is StoreId, PercentageValue, Enabled, IsOptional, DisplayWithProcessingFee and IncludesVouchers - a flat percentage with no card-brand, debit or prepaid dimension - and the PaymentAccountType enum (Card, Cash, Ideal, Bancontact, Giropay, Eps, Emv, PayPal, PayGreen, GoogleWalletToken) draws no debit/credit/prepaid distinction, so automatic exclusion could not be expressed through the documented API. 'surcharge', 'cash discount' and 'convenience fee' return zero occurrences across both API versions. That is an API-shaped finding; the claim is about in-product POS behaviour - automatic debit and prepaid exclusion plus receipt and menu-board disclosure - which is configured in the merchant portal and documented on help.flipdish.com, excluded from this record by policy. Note also that Flipdish is Irish-headquartered, where surcharging consumer cards is restricted by EU law, and its US presence is one locale of the site with no US-specific compliance material on www.