Addmi

Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.

order-capture-split-merge

Vendor FAQ: 'For POS, you can accept card payments, cash, and split payments across multiple methods' — splitting payment across tenders is claimed first-party. Shortfall: splitting a check by item, by seat or by even N-way, arbitrary dollar/percentage splits, and merging checks or tables (including after partial payment) are documented nowhere; the 'Orders Screen in Point of Sale' help article that would settle this appears in the archived help-centre roster but was never captured, and the live portal (addmi.freshdesk.com) returns HTTP 404. https://addmi.com/faq · retrieved 2026-08-04

With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.

order-capture-offline-order-entry

NEW 2026-09-18 (329th): addmi.com has been REBUILT since the 310th-321st passes -- sitemap.xml now carries 2,218 URLs (1,890 tenant /b/ pages, 236 /e/ event pages, 92 non-tenant pages, all 92 fetched this pass). Two of the new pages carry the vendor's only offline statements about its OWN product. https://addmi.com/guides/food-truck-offline-pos (published 2026-08-12, live 200, 22 KB): 'Addmi keeps taking payments and stores orders locally, then syncs automatically when you are back online, so you keep selling through festival dead zones. Just know that digital wallets and QR-code payments usually still need a live connection.' and 'For a truck that wants fewer limits and its own data, Addmi offers offline mode with no monthly or per-terminal fee and automatic sync when the signal returns.' https://addmi.com/blog/festival-check-in-gate-entry-software: 'Addmi is built offline-first for exactly this reason -- the same design that lets its point of sale keep selling at a remote stall lets its check-in keep scanning at a dead-WiFi gate.' VERDICT: partial. Local order capture with automatic sync is asserted by the vendor for this product, so the claim's 'create orders' and 'keep selling' half is satisfied at grade C (vendor guide page, written to sell). SHORTFALL, three parts. (1) The last conjunct fails outright: no published offline scope exists. The vendor has NO documentation surface at all -- addmi.freshdesk.com/support/home, /support/solutions and /support/solutions/articles/65000163511 (the article the live /pricing and /contact pages still link to) all return 404 to curl with a browser UA today, and support./help./docs./developer.addmi.com do not resolve; the only offline text in the 92-page site census is marketing FAQ prose. (2) Modifiers and send-to-kitchen offline are nowhere asserted: tokenised controls over all 92 pages returned 0 hits for 'offline' within 200 chars of 'kitchen', 'modifier' or 'KDS'. (3) The vendor's own merchant dashboard CONTRADICTS the offline card half: the payment-processor picker chunk https://addmi.com/dashboard/js/6515.bd6d4fb9.js (live 200, 9.6 KB, re-fetched 2026-09-18) renders the footnote '*<span>OFFLINE</span> payment processing <span>not</span> supported' under each of the three self-serve processors it offers (Square, Stripe, PayPal -- the fourth tile is 'Other Payment Processors / Contact Us'), i.e. offline card processing is not supported on any gateway a merchant can self-onboard. POISON/CONTROLS: 'offline' occurs 438 times across the 92 pages but the overwhelming majority are competitor comparisons (Square's 24-hour cap, Toast's local-sync mode) and event check-in, not Addmi POS; the two Addmi-specific claims above are the only ones. The live anonymous OpenAPI 3.0.3 spec (api.addmi.com/api/docs/swagger-ui-init.js, 'Addmi API' v0.1.0, 6 paths: oauth2/authorize, oauth2/createToken, oauth2/refreshUsingToken, GET /menu, POST /transactions, POST /webhook) has 0 occurrences of 'offline' -- a 6-path integration API bounds nothing, recorded so nobody re-mines it. Retrieved 2026-09-18. https://addmi.com/guides/food-truck-offline-pos · retrieved 2026-09-18 adversarially verified

Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator

order-capture-kiosk-first-party

Not scored by this record.

Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.

order-capture-drive-thru

Not scored by this record.

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

order-capture-drive-thru-timers

Not scored by this record.

Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator

order-capture-voice-ai

Not scored by this record.

Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator

order-capture-throttling

Not scored by this record.

Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.

order-capture-scheduled-orders

Established at source grade from the merchant back office's anonymously served 'frontofhouse' settings chunk. A 'ManageScheduledPickup' editor saves com.addmi.catalog.settings.scheduledPickUp.update.v1 with the payload {enabled, required, duration, rollingDays, reminderInterval, hours, prepDuration, daysOfWeek}, behind the labels 'Enable Scheduled Pick Up', 'Require Scheduled Pick Up', 'Intervals in Which Orders Can Be Scheduled' (30/45/60-minute options), 'Pick up can be scheduled over N rolling day(s)' (1-14, default 3) and 'Restrict days scheduled pick up can be done'. A separate 'scheduled-delivery' editor saves com.addmi.catalog.settings.scheduledDelivery.update.v1 with {enabled, required, dropOffTime (default 12:00:00), cutOffDuration, daysOfWeek}, exposing 'Cut off time before drop off' of 30 mins / 45 mins / 1 hr. Each fulfillment carries a dueAt timestamp -- the fulfillment info reducer is combineReducers({type, label, dueAt, notificationMethods, delivery, dineIn, pickUp, shipping, roomService, togo}) -- and the back office's Orders screen renders a 'Scheduled For' column that prints dueAt or the literal 'Immediately' when it is null. So future-dated orders and per-channel lead times both exist. Two shortfalls keep this at partial. First, the scheduled-DELIVERY editor is rendered only inside an isTestBusiness() guard reading businessInfo.testBusiness, so in production the per-channel pair is pickup-only. Second, and decisive for this claim, nothing injects a scheduled order into the make queue at a computed fire time: prepDuration appears 15 times in the settings editor and ZERO times in the domain-model bundle's fulfillment or transaction reducers, no fireTime, holdUntil or scheduledFor token exists in any served chunk, and the KDS product page still says online and POS orders are 'sent right to the KDS'. Due time is stored and displayed; it is not shown to gate when the ticket fires. https://addmi.com/dashboard/js/3666.97a35c48.js · retrieved 2026-09-15 adversarially verified

Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator

order-capture-order-ready-signal

Not scored by this record.

Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.

order-capture-void-comp-controls

Not scored by this record.

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

menu-pricing-nested-modifiers

Addmi nests modifiers genuinely, but exactly TWO levels deep, and only the first level carries operator-settable selection counts. NESTING IS REAL, NOT A SECOND FLAT LEVEL: a modifier carries its own option group. The published OpenAPI 3.0.3 document (inlined in swagger-ui-init.js at the anonymous api.addmi.com/api/docs/) defines CatalogSubModifierSet {id, display, defaultID, order} and CatalogSubModifier {id, subModifierSetID, display, order, outOfStock, priceAdjustment}, the /menu response carries subModifierSets alongside modifierSets per listing item, and an ordered line item nests subModifiers[{subModifierSetID, subModifierID, subModifierDisplay, priceAdjustment}] UNDER each modifier choice. The merchant back office closes the loop: the linking entity is a sub-modifier-set assignment keyed {subModifierSetID, modifierID} (reducer, and actions com.addmi.catalog.submodifiersetassignment.create/.update/.delete/.copy.v1), and the Modifiers screen renders a per-modifier 'Submod Set' button plus an 'assign-sub-modifier-sets-to-modifier' dialog and a set-side 'Assign Modifiers' dialog. LEVEL ONE HAS MIN/MAX AND FORCED SELECTION: MenuListingModifierSet carries requiredModifiers ('The number of modifiers within the set that are required') and maximumModifiers ('The maximum number of modifiers within the set that can be selected'), plus preselectedModifierIDs, visibleModifierIDs, priceIncludedModifierIDs and hideModifiersOnReceipt; these live on the PER-ITEM assignment {modifierSetID, itemID, order, requiredModifiers, maximumModifiers, ...}, are edited per item in the item editor (a required-count select whose zero option is labelled 'None', a maximum input, and the validation 'Maximum modifiers cannot be less than pre-selected modifiers'), and are served live on tenant ordering pages (279/168/32 occurrences on three sampled tenants). SHORTFALL, against a claim asking for at least three levels each with independent min/max and a required flag: (1) THERE IS NO THIRD LEVEL. A sub-modifier cannot take a group of its own -- the sub-modifier row exposes only name, Default, Cost Multiplier and Out of Stock with no assign control, the assignment entity accepts only modifierID, and no sub-sub entity exists in the app's closed catalog namespace census (25 namespaceCatalog* entities), the 652-action catalogue, or the 64-schema spec. (2) LEVEL TWO HAS NO CONFIGURABLE COUNTS. There is no requiredModifiers/maximumModifiers counterpart on CatalogSubModifierSet or on the sub-set assignment reducer {id, businessID, subModifierSetID, modifierID, created, deleted, updated}; selection at level two is instead a single default-backed choice -- defaultID, rendered as a radio column and validated as compulsory ('You need to declare a default sub modifier for this set') -- so it behaves as exactly-one-required with no min/max, no multi-select and no per-item override (the item editor chunk contains zero sub-modifier references; sub-modifier sets are global to the business). CONTROLS/POISON: minSelect, maxSelect, forcedModifier, modifierGroup, nestedModifier and subSubModifier each tokenise to ZERO across the spec, the 3.5 MB merchant vendor bundle, the modifier and item-editor chunks and the action catalogue -- the vendor's vocabulary is requiredModifiers / maximumModifiers / defaultID, and searching the generic names alone would have manufactured a false zero on a capability that IS present. The menu-editor chunks were resolved from the dashboard router (route 'modifiers' = chunks 8440+2492; route 'item/:itemId' = 7583+8440+3006+3663+2317) and all were fetched, so the level-two absence is bounded to the shipped editor rather than to a chunk sample. Separately, the guest _nuxt bundles return zero for every one of these field names -- they read the Apollo catalog, not the REST schema -- so that zero is a corpus artefact, not evidence. ADOPTION CAVEAT: of 60 sampled live tenant ordering pages, 10 serve modifiers and none serve a non-empty subModifiers array. https://api.addmi.com/api/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified

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

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

Addmi gives a modifier a per-parent-item price override but no size dimension. In the OpenAPI 3.0.3 document inlined at api.addmi.com/api/docs (Addmi API v0.1.0, GET /menu), MenuListingModifierSet carries modifierOverrides, 'Optional price overrides for modifiers within the set', each MenuListingModifierSet_modifierOverrides = {modifierID: 'The ID of the modifier which this override applies to', priceAdjustment: Money}. The set is attached per item: the dashboard's CatalogModifierSetAssignment reducer is {id, businessID, modifierSetID, itemID, order, requiredModifiers, maximumModifiers, preselectedModifierIDs, visibleModifierIDs, priceIncludedModifierIDs, modifierOverrides, hideModifiersOnReceipt}, and the item editor's CatalogModifierSetCustomize component (props {value, itemPrice}) renders an 'Override Price?' control per modifier. So one shared modifier can be repriced per parent item without duplicating it, and the mechanism is in production use -- 1,559 populated modifierOverrides, zero empty arrays, in a single live tenant menu payload. SHORTFALL: the override tuple is keyed only by modifierID, with no variant/size dimension. Size is a separate axis (CatalogItemVariant {variantID, itemID, price, options} driven by appliedVariantOptionSets/variantOptionSets), and Addmi does ship variant-keyed pricing for ITEMS -- PriceOverride {id, variantID, price}, 'Represents a price override for an item variant', 155 such records in the same tenant -- but never extends it to modifiers; the dashboard's own override comparison helper sorts and diffs overrides by modifierID and priceAdjustment alone. A size-dependent topping price therefore still requires duplicate modifiers or items, so the size half of the claim fails. Bounded absence: across the whole fetched corpus (spec, the router-derived menu/modifier editor chunks 7583/8440/3663/4550/2317/2492/3006, and 4 live tenant menus) zero modifierOverrides occurrences carry variantID within 250 characters, against 1,161 carrying modifierID as a positive control; the 23 occurrences with variantID within 1,200 characters are all adjacent listing PriceOverride records, not structural links. Vocabulary control: 'size' tokenises to 10 hits in the spec -- 9 AssetImage.size plus one 'The size in bytes' description, all image bytes -- because the size concept is spelled 'variant'. https://api.addmi.com/api/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified

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

menu-pricing-topping-quantity-tiers

Addmi ships a first-class, operator-configurable price multiplier per modifier tier, distinct from adding the modifier twice. The merchant back office's Modifiers screen (dashboard route {path:'modifiers', name:'storeModifiers'}, chunk 2492) renders a Sub Modifier Set as a named, drag-ordered list under four column headers -- `Sub Modifier`, `Default`, `Cost Multiplier`, `Out of Stock`. The Cost Multiplier cell is an `input-percentage` (maxlength 5, placeholder `100%`) labelled `% of modifier price`, written by `handlerSubModifierPriceAdjustmentUpdate` as a rational percentage {rat:{n,d}} with `adjustmentDenominator` defaulting to 1e5; one option must be nominated the default ('You need to declare a default sub modifier for this set'); and the set is attached to a modifier via the per-modifier 'Submod Set' button and the set-level 'Assign Modifiers'. So Light 50% / Regular 100% / Extra 200% against one $2 topping is directly expressible. This is a DIFFERENT lever from quantity selection: the modifier row's separate `Qty` checkbox flips `CatalogModifier.modifierType` between `normal` and `quantity` (enum exactly ['normal','quantity'], 'Denotes whether quantity can be selected for the modifier'), which is the add-it-N-times mechanism the claim excludes, and the item editor confirms it with 'Make sure to enable Quantity for modifiers in your Modifier Sets.' The public OpenAPI spec corroborates the model: `CatalogSubModifier.priceAdjustment` is a `Percentage` -- NOT the `Money` carried by `CatalogModifier.priceAdjustment` and by `MenuListingModifierSet.modifierOverrides` -- `CatalogSubModifierSet` carries `defaultID` ('The ID of the default sub modifier'), and an ordered line item nests `subModifiers[{subModifierSetID, subModifierID, subModifierDisplay, priceAdjustment: Percentage}]` under each modifier choice alongside that choice's own `qty`. Addmi's own release post fixes the arithmetic: 'With sub-modifiers, you can attach very specific options and pricing adjustments to your item modifiers. For example, pizza topping modifiers can be set to add a 50% charge for ‘half a pizza’. In this case a $2 topping on a full pizza becomes $1 on half.' CAVEATS: Addmi ships the multiplier engine but NO tier vocabulary -- 'light', 'extra', 'double', 'regular', 'tier' and 'portion' each tokenise to zero across the modifier editor, the 220 KB spec, the 652-action catalogue, the merchant reducers and the release post -- so tier names are operator-typed, and the vendor's only worked example is fractional (half pizza) rather than intensity. Adoption is thin: of 60 sampled live tenant ordering pages, 10 carry modifiers and zero carry any sub-modifier. https://addmi.com/dashboard/js/2492.031a9f62.js · retrieved 2026-09-15 adversarially verified

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

menu-pricing-size-style-matrix

Not scored by this record.

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

menu-pricing-included-allowance

Not scored by this record.

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

menu-pricing-combos

Not scored by this record.

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

menu-pricing-upsell-prompts

Not scored by this record.

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

menu-pricing-86-propagation

Not scored by this record.

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

menu-pricing-countdown-auto-86

Not scored by this record.

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

menu-pricing-dayparting

Not scored by this record.

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

menu-pricing-channel-price-books

Not scored by this record.

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

menu-pricing-dual-pricing

Not scored by this record.

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

menu-pricing-allergen-nutrition

Not scored by this record.

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

menu-pricing-3p-menu-push

Not scored by this record.

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

menu-pricing-dynamic-pricing

Not scored by this record.

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

Not scored by this record.

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

payments-published-rates

Not scored by this record.

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

Not scored by this record.

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

Not scored by this record.

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

payments-emv-nfc

CLAIM: all first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay. VERDICT: partial. NEW SURFACE: the vendor's own hardware list. The live pricing page https://addmi.com/pricing says 'We don't sell hardware but we can help you find the right stuff!' and 'Important Always be sure to buy the exact models listed on our Support Page', and its 'Compatible Hardware List' link points to https://addmi.freshdesk.com/support/solutions/articles/65000163511-recommended-hardware-for-addmi, which is now 404 live but archived by Wayback (captures 20240229 and 20240915; article 'Created by: Addmi Team', 'Modified on: Tue, 6 Jun, 2023'). EVIDENCE (verbatim, archived vendor help article): '3) Supported Credit Card Readers: Square Contactless and Chip Card Reader; Square Dock for Contactless and Chip Card Reader; Stripe Card Reader M2; MagTek iDynamo 6 (Contact us for more information); MagTek tDynamo (Contact us for more information)'. The served merchant dashboard bundle (addmi.com/dashboard, 310th corpus) also carries the label 'WisePad 3' (a Stripe EMV/NFC reader) in its translation tables. MET: EMV chip plus contactless is stated by the vendor for its primary supported reader (Square). SHORTFALL: (1) Addmi has no first-party terminals at all -- every reader is a third-party device the merchant buys; (2) the vendor text states chip+contactless only for the Square readers, and says nothing about the Stripe M2 or MagTek devices' contactless support; (3) Apple Pay and Google Pay are never named for in-person acceptance -- the applepay/googlePay code found in the served web bundles initialises Square web-payment wallet buttons (sqPaymenTrequest, initializeApplePay), i.e. browser checkout, not card-present. Grade B: vendor help-centre text, read via Wayback because the live KB was retired while the live pricing page still links to it. Retrieved 2026-09-16. https://web.archive.org/web/2024/https://addmi.freshdesk.com/support/solutions/articles/65000163511-recommended-hardware-for-addmi · retrieved 2026-09-16 adversarially verified

Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator

payments-softpos-tap-to-pay

Not scored by this record.

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

Not scored by this record.

Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator

payments-offline-store-and-forward

Not scored by this record.

Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator

payments-offline-decline-liability

Not scored by this record.

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

Gift cards listed as included at no extra cost; cross-location balance and online-channel redemption not documented. https://www.addmi.com/pricing · retrieved 2026-08-01

A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.

payments-split-tender

Not scored by this record.

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

POS page documents 'Pin code access for employees', and the vendor FAQ documents full or partial refunds from the dashboard with a Payment & Refund report in the enumerated dashboard set — refunds and PIN-scoped employee access exist. Shortfall: no page documents role-based authorization gating voids, discounts or no-sales at the terminal, and no approver-identified immutable audit log is described anywhere; the 'Roles and Users' help article visible in the archived help-centre roster was never captured and the live portal (addmi.freshdesk.com) returns HTTP 404. https://addmi.com/products/point-of-sale · retrieved 2026-08-04

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

payments-chargeback-tooling

Not scored by this record.

Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator

payments-card-on-file

Not scored by this record.

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

payments-payout-timing

Not scored by this record.

Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.

payments-p2pe-pci4

Not scored by this record.

Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.

kitchen-station-routing

Routing is a first-class, merchant-authored property of the item. Addmi's published OpenAPI 3.0.3 document (inlined as swaggerDoc in the anonymous Swagger UI bootstrap) gives CatalogItem a string field initialStateID, "The initial fulfillment station of the item"; CatalogModifier carries the same field as "The ID of the initial fulfillment station for the modifier", and the transaction schemas echo it per line item (LineItemCatalogItem_catalogItem: "The ID of the initial fulfillment station of the store item") and per chosen modifier (LineItemCatalogItem_choices: "The ID of the initial fulfillment state") -- so the station travels with the ordered line, not just the menu record. The stations themselves are created and edited by the operator with no vendor involvement: the back-office SPA's 'stations' route (display 'Back of House') lazy-loads https://addmi.com/dashboard/js/9901.4bc61e90.js, fetched anonymously at HTTP 200, which renders a 'Display Station' table with 'Add Station', 'Create Fulfillment Station' / 'Edit Fulfillment Station' (field 'Station Name', maxlength 64), an 'Assign Items' action, an 'Items to Stations Assignment' table listing every catalog item under its category with checkboxes, Select All/Deselect All and 'Save and Assign Items', plus the guard 'This station cannot be deleted because it is being used in an Order Routing.' Those writes are the event-sourced actions com.addmi.catalog.fulfillmentstate.create/update/copy/delete.v1 and com.addmi.catalog.item.update.v1, whose reducer accepts initialStateID or initialStateIDs. One item may target several stations: the item and modifier reducers both hold {initialStateID, initialStateIDs, requiresExpediter}, the fulfillment aggregate holds {stateID, stateIDs, stationFulfills, requiresExpediter} and on com.addmi.catalog.fulfillment.fulfillStation.v1 completes only once every stateID in stateIDs appears in stationFulfills; the vendor's KDS page states the same behaviour in prose -- 'Double Fulfillment: One item being sent to multiple stations makes complex kitchens run smoother... it will be sent to all stations and completed individually at each station until the last station fulfills the order triggering a completed state.' Shortfalls and controls, none fatal because the claim's routing axis is disjunctive and the item leg is met outright: routing by ORDER TYPE and by REVENUE CENTER is unevidenced -- tokenised, orderType and revenue-cent* are zero across the spec, the 652 action types, the ~109 reducers and the stations chunk; category appears only as the grouping of the bulk item-assignment picker, i.e. a convenience for assigning many items, not a category-level rule; 'station' tokenises to 3 in the spec (all three inside the quoted fulfilment-station descriptions) and 0 as a bare word in the action/reducer corpora, with zero 'workstation' hits, so no substring trap. The in-app setup signpost, help article 65000166722 'order-fulfillment-stations', is dead: addmi.freshdesk.com returns 404 and the Wayback CDX for that host holds only 7 rows and two unrelated articles, so the documented setup path is the shipped UI itself rather than a published guide. Retrieved 2026-09-15. https://api.addmi.com/api/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified

An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.

kitchen-expo-consolidation

KDS feature page: 'Enabling Expediter mode on your kitchen display screen allows all stations fulfillment progress to be watched through their stages until completed either by the station or the expediter' — a consolidated multi-station expo view exists. Shortfall: the completion gate the claim requires is not documented; the vendor's own wording lets 'the station or the expediter' complete an order, and no page states completion waits until every contributing station has bumped its items. https://addmi.com/products/kitchen-display-system · retrieved 2026-08-04

Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator

kitchen-prep-time-pacing

Not scored by this record.

Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator

kitchen-order-throttling

Not scored by this record.

Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator

kitchen-channel-pause-propagation

Not scored by this record.

Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator

kitchen-order-ready-callback

Not scored by this record.

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

kitchen-bump-bar-hardware

The vendor's supported-hardware article enumerates every supported device class — iPads for 'Point of Sale Screen; Customer Facing Screen; Kitchen Display Screen; Server Handheld', supported printers (Star mC-Print3, SP700, TSP654IISK), supported card readers (Square, Stripe M2, MagTek), tablet stands and cash drawers — and contains no bump bar or keypad in any category. The KDS is an iPad app operated by touch ('Fulfill orders or individual items'), and no bump-bar input appears anywhere else on the vendor surface. Read from the Internet Archive's 2026-02-16 snapshot (article last modified 2023-06-06); the live portal addmi.freshdesk.com returns HTTP 404 as of 2026-08-04. https://web.archive.org/web/20260216092012/https://addmi.freshdesk.com/support/solutions/articles/65000163511-recommended-hardware-for-addmi · retrieved 2026-08-04

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

kitchen-all-day-counts

Not scored by this record.

Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.

kitchen-sla-alerts

Not scored by this record.

If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator

kitchen-printer-fallback

Not scored by this record.

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

kitchen-offline-operation

Not scored by this record.

Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator

kitchen-item-build-screens

Not scored by this record.

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

kitchen-recall-refire

Not scored by this record.

Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator

kitchen-order-modification-alerts

Not scored by this record.

Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator

kitchen-guest-ready-notification

Not scored by this record.

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

kitchen-waste-logging

Not scored by this record.

Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.

kitchen-speed-of-service-reporting

Not scored by this record.

Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.

kitchen-prep-forecasting

Not scored by this record.

Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).

delivery-dispatch-board

The vendor's delivery capability is its DoorDash courier partnership: 'We are partnered with DoorDash to provide the best customer experience while keeping things simple for your business', and the enumerated behaviour is that delivery orders 'are displayed in your POS', 'respect your inventory settings' and 'are displayed in your reports'. Drivers are DoorDash's, not the operator's — no driver roster, driver availability, dispatch/expo screen or multi-order run batching exists anywhere on the vendor surface, and the only delivery article in the archived help-centre roster is 'DoorDash Delivery Support'. https://addmi.com/products/online-ordering · retrieved 2026-08-04

Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.

delivery-address-validation

Not scored by this record.

Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.

delivery-daas-dispatch

Not scored by this record.

Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator

delivery-3p-direct-integration

Not scored by this record.

Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.

delivery-3p-injection

Not scored by this record.

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

delivery-menu-push

Not scored by this record.

Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).

delivery-86-sync

Not scored by this record.

Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.

delivery-store-pause

Not scored by this record.

Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator

delivery-3p-reconciliation

Not scored by this record.

Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator

delivery-injection-error-visibility

Not scored by this record.

Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.

delivery-tracking-page

Not scored by this record.

Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator

delivery-promise-time

Not scored by this record.

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

Online ordering included with a flat 38-cent fee passed to the guest, so no percentage marketplace commission to the operator; branded-domain support not documented. https://www.addmi.com/pricing · retrieved 2026-08-01

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

digital-menu-single-source

One catalog, one editor, one write path. (1) SERVED GUEST STATE: the live tenant ordering page addmi.com/b/911drinkspot.-OK-0eWaoGfx2X3CTNEB server-renders its whole Apollo cache inline as window.__NUXT__, and the guest store is built from a SINGLE GraphQL query, businessCatalogPageForTimestamp(id:"/business/-OK-0eWaoGfx2X3CTNEB", ts:{iso}), returning one object {availabilities, availabilityAssignments, items, variants, inventories, assetImages, modifiers, subModifiers, listings, modifierSetAssignments, settings, businessHours, topSellers, allCategories}. Every Listing row served to the guest carries the POS fields and the store fields together: catalogCategoryID, storeCatalogCategoryID, hideFromPOS:false, hideFromStore:true, featuredInStore:false. (The __NUXT__ payload is minified-alias encoded; its invocation decodes as a=null, b="id", c=false, d=true, so those booleans are the literal served values.) One record drives both channels and they differ only by visibility booleans, not by a duplicated menu. (2) BACK OFFICE: the merchant dashboard SPA has exactly ONE menu section, route path "menu" (route names storeMenu -> storeItems, storeItemNew, storeItemCSV "Import Items", category, modifiers); no second, channel-specific menu builder exists anywhere in its route table, and the only POS-named routes are labour and till screens (posTills, posTimecards, posShiftReviews). The item editor chunk saves a single entity through createListing/updateListing against /listing/<id>, and exposes the channel choice as one checkbox, $gettext("Hide from online store"), bound to hideFromStore: an item is created once and is on the online store unless the operator opts it out. (3) PUBLIC API: api.addmi.com/api/docs/ documents one GET /menu, "Retrieve the menu for a given timestamp", returning GetMenuResponse -> MenuListing -> {item: CatalogItem, category: CatalogCategory, variants, inventories, taxes, priceOverrides, modifierSets}, with CatalogCategory.hideFromStore documented as "Denotes that this category should not be visible on the store" -- the same single catalog with a store-visibility flag, not a second menu. CHANNEL SCOPE: Addmi ships no kiosk and no branded native ordering app, so the first-party digital surface is the web store and its QR dine-in mode on the same /b/ page; "kiosk" occurs ZERO times across the entire retrieved corpus (marketing pages, dashboard bundles, OpenAPI spec, tenant ordering pages). NAMING TRAP: "store" in the dashboard route names (storeItems, storeMenu) is the back-office section prefix for the BUSINESS, not the guest web store that hideFromStore refers to; the two senses collide and only the checkbox label disambiguates them. NOT EVIDENCE FOR THIS CELL: the vendor blog "One Menu Synced Across Every Delivery App" ("Addmi is the source of truth for your menu... the menu syncs out to your connected delivery apps through Otter") is about THIRD-PARTY marketplaces; and the served eightySix field and the availabilityAssignment priceOverrides belong to menu-pricing-86-propagation and menu-pricing-channel-price-books, neither of which is scored for Addmi. https://addmi.com/b/911drinkspot.-OK-0eWaoGfx2X3CTNEB · retrieved 2026-09-15 adversarially verified

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

Not scored by this record.

Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.

digital-account-saved-payment

One-tap reorder of a previous order IS shipped in the first-party web ordering client, and a tokenized card IS stored for membership subscriptions, but there is no guest account and no saved-address book. Evidence is the vendor's own served ordering client. Its webpack runtime (a2e5a56.modern.js) enumerates 242 lazy chunks; all 242 were fetched anonymously (7.41 MB) and censused. REORDER (met): the store page component (chunk 493f037) calls getPurchasedCarts({businessID}) -> POST /api/carts/getPurchasedCarts and passes purchased-carts into the cart component; chunk eef1b4f computes mostRecentCart, raises an overlay on mount when a purchased cart exists and the active cart is empty, screens items with isItemUnavailable against current listings, and dispatches createCartFromPurchasedCart({purchasedCartID, currentCartID, fulfillmentMethod}) -> POST /api/carts/createCartFromPurchasedCart; chunk 9b29a63 renders the purchased-cart list with per-cart reorder. Four chunks (6439209, 8ef3d1a, a493f7b, 37277c2) render a $gettext("Order again")/"Order Again" button bound to orderAgainRoute on the receipt/feedback pages, and the cart error dictionary carries cart.unableToReorder = "One or more items cannot be reordered automatically". SAVED PAYMENT (met, but only for memberships): chunk d342db2 holds savedPaymentMethod state set from the POST /api/verifyCode response ({savedPaymentMethod}, keyed by membershipID/paymentSubscriptionID) and renders the payment form only when loadPaymentForm && savedPaymentMethod; chunk 1da9371 ships the com.addmi.paymentmethod.create/update/delete.v1 entity with {type: PaymentMethodType.card, card, merchantID, listID} inside the guest app itself; the eager bundle's gateway component branches on a Stripe SetupIntent (submit() tests clientSecret.indexOf("seti_") and calls stripe.confirmSetup), which is Stripe's store-a-card-for-later primitive, and the public client posts /api/updateMembershipPayment and /api/reactivateMembership against paymentSubscriptionID. SHORTFALLS: (1) there is NO guest account -- no guest registration, password or session credential anywhere in the 242-chunk census; purchased carts are resolved server-side from the anonymous /api/session/ensureSession cookie plus businessID, and identity for memberships is a one-time emailed code (sendVerificationCode/verifyCode), not a login. The vendor states the model on its online-ordering page: 'Customers do not need to create an account to order.' (2) saved ADDRESSES are absent: savedAddress and addressBook tokenise to ZERO across all 242 chunks, and a delivery place is entered per order via setFulfillmentInfo. (3) the stored card is evidenced only for membership/subscription auto-renewal, not for the ordering checkout, where the Square path tokenizes a per-transaction card_nonce with no store-for-later call. TWO GATEWAYS, not one: the client ships BOTH Square Web Payments (web.squarecdn.com/v1/square.js; card, applePay, googlePay, cashAppPay, masterpass, secureremotecommerce) and Stripe Elements, selected by gateway.config -- gatewayToken is a wrapper that carries a Square card_nonce, a Stripe paymentIntent OR a Stripe setupIntent, so it is not per se a per-transaction nonce. POISON: 'reorder' as a token is worthless here -- 48 of 242 chunks match it and nearly all are drag-and-drop list reordering; the vendor's vocabulary is purchasedCart and 'Order again'. 'vault' matches only the image file img/vault-stability-addmi-pos-480.jpeg ($gettext 'Addmi POS vault'). 'signIn'/'signing' in the lazy chunks is blog prose ('before signing') and the ToS phrase 'signing up for an Addmi account', which is the MERCHANT account. In the eager bundle all 22 'login' hits are merchant-side (ActionBusinessAccountLogin, ActionVenueAccountLogin, LoginMethod enum of DashboardPassword/PosPassword/PosSessionResume/PosPIN/PosScan, and a nav Login button to /dashboard/auth/). https://addmi.com/_nuxt/9442fe0.modern.js · retrieved 2026-09-15 adversarially verified

Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator

digital-upsell-engine

Not scored by this record.

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Not scored by this record.

Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.

digital-fulfillment-modes

Not scored by this record.

Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.

digital-qr-table

Not scored by this record.

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

Not scored by this record.

Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator

digital-voice-ai-phone

Not scored by this record.

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

digital-drivethru-ai

Not scored by this record.

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

digital-sms-ordering

Not scored by this record.

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

Not scored by this record.

Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.

digital-apple-business-connect

Not scored by this record.

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

Not scored by this record.

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

Not scored by this record.

Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.

digital-promo-parity

Not scored by this record.

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

Not scored by this record.

Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.

digital-checkout-pci-sca

Not scored by this record.

Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator

digital-surcharge-transparency

Not scored by this record.

Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.

guest-loyalty-unified-profile

Addmi keeps one guest entity that spans its channels, resolves the loyalty wallet by phone or email, and ships a duplicate-merge -- but the merge is email-only, operator-initiated, and does not fold point balances. The back office carries a Contacts module ('Contacts -- View and manage CRM') over a BusinessContact {id, businessID, entityID, address1, address2, city, company, custom, email, firstName, lastName, occupation, phone, state, zip, notes, -validation, created, updated, deleted}, and a loyalty point wallet {id, businessID, businessContactID, ownerName, ownerEmail, ownerPhone, points, timeOptedOut, created, deleted, updated} keyed to that contact, folded by com.addmi.catalog.loyalty.pointwallet.{addPoints,deductPoints,redeemPoints,optOut}.v1. IDENTITY RESOLUTION IS PHONE-OR-EMAIL: the contact-details loyalty panel (dashboard chunk 4350) resolves the wallet through a server-side GraphQL resolver -- query pointWallet($businessEntityID: ID!, $businessContactEntityID: ID!, $email: String, $phone: String) { pointWallet: catalogLoyaltyPointWalletForBusinessContact(businessEntityID, businessContactEntityID, email, phone) { id points } } -- i.e. the wallet is matched to a guest by contact entity PLUS email PLUS phone, and a new wallet id is minted only when that lookup misses. CROSS-CHANNEL: the same wallet is exercised from the first-party web ordering client, which posts /api/carts/applyLoyaltyRewardToCart {authors, cartID, businessID, rewardID, pointWalletID} and /api/carts/optOutOfLoyalty and holds loyaltyPoints in cart state (https://addmi.com/_nuxt/9442fe0.modern.js and its 8e00c83 sibling), so a web order and a register order accrue to one wallet rather than to per-channel records; the shared transaction event model carries ACTION_REF_SET_WALLET_ID(walletID) and ACTION_REF_SET_LOYALTY_INFORMATION next to Ref.purchaseApp, 'The source from which this transaction originates from'. DEDUP: the Contacts chunk https://addmi.com/dashboard/js/2185.45dd815c.js ships a 'Merge Duplicate Customers' modal ('There are %{contacts} customers with duplicate data') over a server-side query getDuplicates -> duplicateBusinessContacts(businessEntityID). SHORTFALLS: (1) that dedup matches on EMAIL ONLY -- the client groups on email.trim().toLowerCase() and the duplicate query selects {id, entityID, businessEntityID, firstName, lastName, email, count, updated{ms}, groupAssignments{id, businessContactGroupID}} with no phone field -- so phone-only guests are deduped by nothing, even though wallet LOOKUP does take phone; (2) the merge is OPERATOR-INITIATED, not automatic: an admin opens the modal and clicks Merge, and the survivor is just the record with the greatest updated.ms; (3) mergeDuplicates re-points businessContactGroupID list memberships onto the survivor and deletes the rest via batchActions, but chunk 2185 contains ZERO occurrences of wallet, pointWallet, loyalt or transaction, so point balances are not folded and transaction history is not re-pointed; (4) kiosk is not a channel Addmi sells -- across a COMPLETE census of all 454 lazy dashboard chunks (19.8 MB), the guest ordering client and every marketing page, 'kiosk' and 'Kiosk' tokenise to ZERO, as do self-serve, self-service, unattended and tablet ordering, so 'spanning channels' here means POS plus web store and QR dine-in. METHOD: this dedup is invisible to an action-type census -- it defines no new com.addmi.*.v1 action but composes existing primitives (deleteBusinessContactGroupAssignment, contact delete, group-assignment create) through batchActions. CONTROLS/POISON: over all 454 chunks, 'duplicateBusinessContacts' and 'mergeDuplicates' occur in exactly ONE chunk (2185), and 'dedup' and 'byPhone' are zero; the 34 other files matching 'merge' are library boilerplate -- chunk 3959's 30 hits are SheetJS XLSX cell merges (mergeCell, !merges), and chunk-vendors' 40 are v-calendar popover, Firebase RTDB merge(), vee-validate _merge and vue-i18n mergeLocaleMessage, with 'duplicate' there being vue-router 'duplicated' navigation and Firebase 'duplicate-app'. com.addmi.business.contact.convert.v1 is NOT a guest merge but the uniform event-sourcing snapshot primitive every entity carries. https://addmi.com/dashboard/js/chunk-vendors.08aeeb98.js · retrieved 2026-09-15 adversarially verified

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

guest-loyalty-thirdparty-identity-attach

Not scored by this record.

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

Loyalty is a first-party included feature at no extra cost; supported accrual models are not documented. https://www.addmi.com/pricing · retrieved 2026-08-01

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

guest-loyalty-offline-behavior

Not scored by this record.

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

guest-loyalty-offer-stacking-rules

Not scored by this record.

Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator

guest-loyalty-targeted-offers

Not scored by this record.

Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator

guest-loyalty-rfm-segmentation

Not scored by this record.

Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.

guest-loyalty-lifecycle-automation

Addmi ships two of the claim's three named lifecycle triggers as always-on, operator-toggled automations, but neither is delivered as a configurable campaign and the third is absent. LAPSED WIN-BACK: the merchant back office's Email Campaigns screen (route {path:'email', name:'marketing', modules:['marketing']}, lazy chunk 2834 via the webpack hash map in index.b265f90a.js) renders a block headed 'Automated Email Marketing' whose ONLY control is a single checkbox (id 'return-notif', v-model returnNotificationsInput) labelled verbatim 'Notify customers that have not visited your place in 30 days'. That is an always-on recurring send, not a one-off blast, and it is the exact win-back automation the claim names -- but the 30-day window is hard-coded into the label, there is no audience, content, offer or cadence control on it, and the surrounding screen gates sending behind a paid tier ('You must subscribe to Email Marketing to use this service', 'You have exceeded your free limit'). BIRTHDAY: the membership level editor (routes 'level/create'/'level/:levelId', chunk 9412) ships a 'Free 1 item on birthday' checkbox (birthdayItemChecked) with an 'Apply Items' catalog picker (itemIDsForBirthday), alongside 'Free item' (numAllowedFreeItems + freeItemsOccurrences, placeholder '0 or blank for indefinite') and 'Award gift card' (awardGiftCardChecked). The level's own GraphQL query confirms the persisted model: settings { freeBirthdayItem { active itemIDs } freeItems { active numAllowed itemIDs occurrences } giftCard { active amount { amount currency } occurrences } }, and the member form carries dateOfBirth as a first-class predefined field (chunks 932/5948, 'D.O.B.'). So a birthday reward is real and configurable -- but it is an ENTITLEMENT attached to a paid membership LEVEL, granted at redemption, not a triggered campaign or message, and it reaches only enrolled members of that level. SHORTFALL, the reason this is partial and not yes: (1) first-visit thank-you does not exist -- 'firstVisit' tokenises to ZERO across the whole 456-file back office and the 'Automated Email Marketing' block contains no second toggle; (2) the win-back automation is a single fixed-window on/off switch with no configurability; (3) the birthday reward is a membership-level perk rather than a campaign, so neither trigger is authorable as a campaign -- the campaign builder itself (campaignobjective/campaignaudience/campaigndesign/campaignreview, chunks 4265/1329/8056/7926) is MANUAL-SEND only, offering 'Send Now', 'Save as Draft' and 'Next' with no trigger or schedule entity. VENDOR CLAIM RECONCILED: addmi.com/features states under Membership Management 'Free items on birthdays or visit milestones'; the birthday half is confirmed in shipped source, while the 'visit milestones' half is NOT implemented as a visit trigger -- the nearest shipped mechanisms are freeItems.numAllowed/occurrences (a per-plan entitlement count, not visit-driven) and the loyalty earn rule whose type enum is exactly {amountSpent, Visit} rendering '%{points} per visit' / '%{points} per visit with %{amount} min' (chunk 2785), i.e. points accrual toward a redeem rule, not a milestone automation. CONTROLS AND POISON: this note rests on an exhaustive census -- all 454 lazy chunks named in the index bundle's webpack hash map were fetched (454/454 at HTTP 200, 21.5 MB) and searched with tokenised, not substring, controls. 'birthday' is 34 tokenised hits (102 raw) and is REAL, not locale noise: 14 hits are translated dictionaries of the same 'Free 1 item on birthday' string and the live control sits in chunk 9412. 'milestone' tokenises to ZERO (12 raw hits are all the plural 'milestones'), and every one of those 12 is POISON: they live in chunk 9417, route 'adminactivationfunnel' with meta {auth:true, admin:true}, which is ADDMI'S OWN INTERNAL merchant-acquisition CRM -- 'Every signup and where they stand ... its stage, milestones, drip status, revenue', 'Signups to real revenue', 'Addmi revenue (our cut)' -- tracking BUSINESSES, not guests, so its 'Drip'/'Milestones' timeline is not a merchant-facing tool. 'lapsed' (0 tokenised, 17 raw = 'collapsed'/'handleDelayElapsed'), 'winback', 'win-back', 'anniversary', 'birthdays', 'dormant', 'reengage' and 'autoSend' all tokenise to ZERO -- and on this corpus those zeros prove nothing about the capability, because Addmi's own vocabulary for the feature is the sentence 'have not visited your place in 30 days'. 'dob' is 10 tokenised of 100 raw (the rest are 'Cordoba'/'addObserver'); 'automated' is 88 tokenised but almost all locale-dictionary entries, the load-bearing English instance being the 'Automated Email Marketing' heading in chunk 2834; 'trigger' is 38 tokenised and is entirely Vue/jQuery render internals ($(...).trigger('reflow')). SCOPE: this corpus is the merchant BACK OFFICE bundle; the Addmi POS is a separate native app, so these findings bound what the back office configures, not the whole product. https://addmi.com/dashboard/js/index.b265f90a.js · retrieved 2026-09-15 adversarially verified

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

guest-loyalty-native-email-sms

Not scored by this record.

Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.

guest-loyalty-consent-management

Not scored by this record.

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

guest-loyalty-10dlc-registration

Not scored by this record.

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

guest-loyalty-campaign-attribution

Not scored by this record.

Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator

guest-loyalty-data-export-portability

Not scored by this record.

Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator

guest-loyalty-review-capture-routing

Not scored by this record.

Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.

guest-loyalty-referral-program

Not scored by this record.

Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator

guest-loyalty-wallet-pass

Not scored by this record.

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Not scored by this record.

Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.

guest-loyalty-redemption-fraud-controls

Not scored by this record.

Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator

guest-loyalty-ai-offer-recommendation

Not scored by this record.

Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.

guest-loyalty-stored-value-gift

Not scored by this record.

Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.

labor-clock-in-at-pos

'Time Cards' listed as an included feature; PIN/badge mechanics and whether clock-in happens at the terminal are not documented. https://www.addmi.com/pricing · retrieved 2026-08-01

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

labor-photo-punch-verification

Not scored by this record.

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

labor-geofenced-mobile-punch

Not scored by this record.

Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator

labor-offline-time-punch

Not scored by this record.

Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.

labor-granular-rbac

Resolved to partial off the merchant dashboard's role-editor chunk, served anonymously (no source maps on this host). Roles are operator-authored rather than fixed tiers: the routes 'role/create' (display 'Create a Role') and 'role/:roleId' both sit under meta.modules ['accessControl'] and are backed by ActionRoleModule Create/Update/Delete/Copy ('com.addmi.rolemodule.*.v1'); the role entity reduces to {id, businessID, name, display, backEndModules, frontEndModules, posModules, allBackEndModules, allFrontEndModules, allPOSModules} and the editor renders a checkbox per permission with select-all toggles. The POS grant surface is a closed 14-value enum, each entry a discrete labelled action: 'Access to Sales Activity / Payments' (viewSalesActivity), 'Apply Discounts and Comps' (applyDiscounts, desc 'Allow users to apply discount and comps'), 'Delete or Void Submitted Orders' (voidOrders), 'Issue Refunds' (issueRefunds), 'Manage Tills & Open Cash Drawers' (manageTills, desc 'Allow users to manage tills and open cash register. Override only for opening cash drawer.'), 'Manage All Open Tickets' (closeOpenTickets), 'View Reports' (viewReports), 'Settle All Payments Awaiting Tip' (settleTips), 'Manage Settings in the POS' (manageSettings), 'Correct Orders in the POS' (orderCorrection, desc 'move items, change server, and move checks on an order'), 'Adjust Payments' (paymentAdjustment, desc 'adjust nontip amount, move payment to another order, or completely void the payment'), 'Adjust Shift Reviews' (serverShiftReviewAdjustment), 'Re-Open Completed Order' (reopenCompletedOrder) and 'Adjust Time Cards' (timeCardAdjustment) — alongside a 14-value BackEndModules enum (accessControl, business, users, catalog, admission, events, invoices, membership, marketing, subscriptions, transactions, fundraising, reports, contacts) and a 3-value FrontEndModules enum. These are enforced gates rather than labels: four of the fourteen descriptions end 'Users with no permission need manager Override.' Six of the seven actions the claim enumerates are therefore individually grantable — void, comp, discount, refund, drawer open and report access. SHORTFALL, two parts. (1) There is no price-change permission anywhere in the closed enum — the token 'price' tokenises to zero occurrences in the role-editor chunk, and the nearest neighbours are explicitly something else (orderCorrection is moving items/servers/checks, paymentAdjustment is the tendered amount) — so item price override cannot be granted or withheld as its own right. (2) The claim's per-location half is absent: the role carries businessID only, a businessaccount row carries a single 'role' field scoped to one businessID, and no store/location entity exists among the 652 back-office action types, so a multi-location operator re-authors roles per business rather than scoping one role matrix across locations. Granularity is also coarser than the claim's list in two places — comp is not separable from discount, and opening the cash drawer is not separable from till management, though the latter carries its own manager-override path. BOUND: the enum is hardcoded in the role editor and is closed over the only served surface on which roles are authored, so it bounds what an operator can GRANT; the POS itself is a native app (com.addmi.pos) outside this corpus, so the price-change gap is not asserted as a product-wide absence of any price gate. CONTROL: 'permissions' occurs 340 times in the 3.5 MB vendor chunk and all 340 are Apache-licence boilerplate ('governing permissions and limitations under the License') — re-measured this pass at 340/340, zero evidential hits. This cell claims nothing about who approved an override or whether approvals are queryable; labor-manager-override-audit remains unknown. https://addmi.com/dashboard/js/8017.60d73dbb.js · retrieved 2026-09-15 adversarially verified

Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.

labor-manager-override-audit

NEW 2026-09-17: the retired Freshdesk home (Wayback 20240915075248, 94 article links) lists "Roles and Users" (65000168599-roles-and-users), its Spanish twin 65000181348-roles-y-usuarios, and "Time Cards" (65000168862). Wayback id_ fetches of 65000168599-roles-and-users (2023 and 2024) return the not-archived 404 page; CDX for addmi.freshdesk.com/support/solutions* lists only 65000163511 and 65000182851. The lead cannot be read. crt.sh for addmi.com (22 names) probed at / and /swagger, /swagger/index.html, /api-docs, /openapi.json, /docs, /v3/api-docs, /robots.txt and a nonsense path: api.addmi.com 404 everywhere, auth 404, biz 301 -> addmi.com, tprox 307 -> addmi.com, onboarding/eks-elb 400, file.addmi.com 403 (S3), stage/ops-*/vpn/tschnepp no response. Two LISTABLE S3 buckets: iab.addmi.com (IsTruncated=true; hashed per-business image uploads, no documents) and image.addmi.com (185 keys, complete: brand icons, distributor/reseller agreement PDFs, addmi-onesheet-foodtruck-2023.pdf, case-study-Fatwood-BBQ--Addmi.pdf, clubexpress onesheet). App Store lookup (artist of id1187349472): only "Addmi Point of Sale" com.addmi.addmi-pos 1.5.9 and "Addmi Ticketing"; no DS/KDS listing; no com.addmi.* on Google Play (404). None of these mentions override, approval or audit. Retrieved 2026-09-17. || 329th: NEW 2026-09-18 (329th): the operator-QUERYABLE surface was censused for the first time and holds no approver attribution anywhere. The 202 GraphQL documents embedded in the 454-chunk merchant-dashboard bundle set were extracted and searched: zero fields named approvedBy, authorizedBy, overrideBy, performedBy, actorID or manager* exist in any of them; the only 'override' fields are commercial or catalog ones (priceOverride on memberships, modifierOverrides, ticketOverrides, locationDeliveryOverrides, businessClientsWithFeeRulesOverride) and 'approvalInfo { accepted rejected autoRejectAt }' is ONLINE-ORDER acceptance, matching the action types com.addmi.transaction.detail.approvalinfo.ACCEPT/REJECT/AUTO_REJECT.v1 -- a homonym of manager approval, named here so it is not re-mined. The two reports where an override would surface enumerate their own columns and neither carries an operator: discountItemsReport rows are {appliedCount, payerFirstName, payerLastName, payerEmail, moneyEffectivePaidAmount, discountEntityID, discountName, discountAmount, currency} (https://addmi.com/dashboard/js/1813.d9d9e222.js, live 200, 14.4 KB, re-fetched 2026-09-18), and the paginated transactions report attributes an order to the SERVER who owns it ({serverEntityID, serverNameGiven, serverNameFamily, serverName, voided{iso}, countItemsVoided, countItemsDeleted}) -- i.e. the void is timestamped and tied to the ticket's server, never to the manager who authorised it. 'audit' occurs 0 times in the dashboard's complete 4,827-key English string table (no audit-log or activity-trail screen; the 16 'Activity' keys are sales activity and email-marketing activity), and the live 6-path Addmi API spec has 0 'audit'. Per-employee attribution of the authenticator does exist in principle -- businessAccount carries {employeeID, pinCode, scanToken, lastAccess} per person, so override PINs are individual rather than one shared manager PIN. HELD unknown: the four override-gated permissions live in the native POS app (com.addmi.addmi-pos), which no corpus covers, so whether the app records and exposes the approving manager cannot be determined; what is now established is that nothing in the back office lets an operator query it. Retrieved 2026-09-18. adversarially verified

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

labor-native-scheduling

Not scored by this record.

Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator

labor-demand-labor-forecast

Not scored by this record.

Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator

labor-realtime-labor-percent

Not scored by this record.

Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator

labor-overtime-prevention

Not scored by this record.

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

labor-minor-labor-rules

Not scored by this record.

Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator

labor-qualified-tips-w2-reporting

Not scored by this record.

Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator

labor-native-payroll

Not scored by this record.

Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).

labor-payroll-export-formats

Not scored by this record.

Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator

labor-shift-swap-workflow

Not scored by this record.

Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator

labor-server-performance-metrics

Not scored by this record.

Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.

inventory-recipe-bom-costing

Addmi tracks stock per SELLABLE VARIANT, so there is no ingredient layer for a recipe to be built from. The published OpenAPI 3.0.3 spec states it verbatim: Inventory.id is 'The inventory ID. This ID is the same as the item variant which this inventory applies to', and the schema is closed at {id, track, stateQuantities}, with Inventory_stateQuantities closed at {inStock}. The merchant back office agrees and is equally closed: the inventory action set is exactly SIX (com.addmi.inventory .create/.delete/.adjustment/.physicalCount/.setThreshold/.updateTracking, all .v1), the Inventory reducer folds {entityID, businessID, unit, stateQuantities, customQuantities, track, threshold, thresholdCrossed, created, deleted, updated}, its stateQuantities sub-reducer is closed at {inStock, hold, sold, returnedByCustomer, soldOnline, orderedFromVendor, receivedFromVendor, inTransitTo, waste, unlinkedReturn, custom}, and the adjustment-reason dropdown is a closed list of {received, restock, damage, loss, theft, recount}. Both conjuncts of the claim fail: there is no component/BOM link of any kind (buildsFrom, madeFrom, portionSize, batchSize, subitem, linkedInventory, inventoryLink and depletes all tokenise to zero across every fetched bundle), and nothing recalculates. CORRECTION TO THE PRIOR RATIONALE: it is NOT true that Addmi has 'no cost field at all'. A cost field exists, but on the sellable variant rather than on inventory -- the CatalogItemVariant reducer is {id, businessID, itemID, name, display, sku, price, order, ggleapSeconds, ggleapBalance, options, eightySix, productionCost, created, deleted, updated}, and the item editor (chunk 2317, routes storeItemEdit/storeItemNew) renders productionCost as an input-money labelled 'Cost' with a productionCostOverride. That is a single flat number an operator types per variant -- a manually maintained unit cost, not a plate cost rolled up from components, and it is exactly the spreadsheet-maintained figure this claim asks the POS to replace. The cost field is unpublished: productionCost tokenises to ZERO in the OpenAPI document. CENSUS BOUND TO THE PUBLISHER'S OWN MANIFEST, NOT TO WHAT HAPPENED TO LOAD: the action-type list alone would NOT be a safe census -- lazy chunks demonstrably introduce novel action types, since chunk 8017 carries four com.addmi.rolemodule.* types found in neither the eager vendor chunk nor actions.txt. The zero is instead bound to the eager Vue router table, a complete manifest of all 454 lazy chunks, which names exactly two inventory routes (storeInventory, admissionInventory) and no recipe, ingredient, prep or costing route; storeInventory resolves to n.e(6627) and storeItemEdit/storeItemNew to n.e(2317), and both chunks were fetched and read. A 384-entry gettext label census over those fetched inventory and item screens yields the complete merchant inventory vocabulary -- Track Inventory, Add/Remove Stock, Restock, Restock Return, Stock Received, Recount, Inventory Re-Count, Current Stock, Out of Stock / 86, Inventory Low Alert, Threshold crossed, Quick Modify Inventory, Adjust Inventory, Cost -- and contains zero instances of recipe, ingredient, yield, prep, theoretical, variance, batch or portion. CONTROLS/POISON, run tokenised over every corpus the verdict leans on: 'bom' returns 62 hits that are 100% POISON (bombs, bomb, shitsbomb, brbom, autobom, bomedpn and other minified garbage) with not one bill-of-materials sense; 'yield' returns 76 hits that are ALL the JavaScript keyword (71 yield, 4 shouldYield, 1 yields); 'recipe' returns 2 hits and BOTH are inside swagger-ui's bundled ICANN TLD list ('...oldnavy|organic|philips|recipes|rentals|reviews...'), i.e. third-party library data, not Addmi content; 'component' returns 1859 hits that are all Vue/React framework symbols; 'consumes' returns 36 hits that are all the OpenAPI keyword inside swagger-ui-bundle.js. CONTRARY VENDOR CLAIM, DISCLOSED: Addmi's own App Store listing for Addmi Point of Sale (id 1499904685) reads 'Inventory Control: Stay on top of ingredients and supplies with automated alerts and reporting, so you're never caught off guard' -- the only use of the word 'ingredients' anywhere in the corpus. It is marketing prose that maps onto the shipped low-stock threshold alerting and inventory reports, and it asserts no recipe, no sub-recipe and no cost rollup; it does not disturb the no. The vendor's features page claims only 'Inventory reports', and the partners page lists MarketMan, indicating ingredient-level control is delegated to a third party rather than native. https://addmi.com/dashboard/js/chunk-vendors.08aeeb98.js · retrieved 2026-09-15 adversarially verified

Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.

inventory-unit-conversion-yields

Addmi's inventory model has no unit-of-measure layer at all: an inventory record carries exactly ONE unit, and the merchant cannot even set it. In the eagerly-loaded dashboard vendor chunk the inventory entity folds as combineReducers({entityID, businessID, unit, stateQuantities, customQuantities, track, threshold, thresholdCrossed, created, deleted, updated}); the unit reducer defaults to the literal string 'Unit', is assigned only on creation (case ActionInventoryCreate: return t.unit), and on both other paths merely asserts consistency against the stored value -- case ActionInventoryPhysicalCount: return o(e, t.count.unit), e and case ActionInventoryAdjustment: return o(e, t.adjustment.unit), e -- where o() throws Error('can not modify quantity with different unit!') with code 'inventory.badUnit', status 400. That is the exact inverse of a conversion: counts and adjustments must arrive in the SAME unit, and mixing units is a 400 error. At the application layer the field is not even a variable: the item editor (dashboard chunk 2317.91c99334.js, 138 KB, reached from routes storeItemNew and storeItemEdit) hard-codes unit:"Unit" as a string literal in every action it emits -- createInventory(this.authors, '/<variantID>', this.businessID, "Unit", t.track) and every adjustment {from, to, scalar, unit:"Unit", reason} -- and the CSV item importer (chunk 8400.ea0f687f.js, route storeItemCSV, 'Item Upload / CSV Template / CSV Upload') does the same, with template columns Category, Description and Regular (price) and no unit, case or pack column. The merchant-facing inventory UI is a track toggle plus a quantity: 'Track Inventory', 'Current Stock', 'Add Stock', 'Remove Stock', 'Inventory Low Alert', 'Alert At', and a CLOSED adjustment-reason dropdown of five -- Stock Received, Restock Return, Damage, Theft, Inventory Re-Count. There is no purchase/recipe/count unit, no conversion factor and no yield percentage anywhere. 'waste' exists but is a QUANTITY BUCKET in stateQuantities alongside inStock, hold, sold, returnedByCustomer, soldOnline, orderedFromVendor, receivedFromVendor, inTransitTo, unlinkedReturn and custom -- damage/theft/loss move scalars from inStock to waste -- i.e. a count of wasted stock, never a yield percentage applied to a raw-to-usable conversion. The published OpenAPI 3.0.3 spec (api.addmi.com/api/docs/swagger-ui-init.js) exposes even less: Inventory is closed at {id, track, stateQuantities}, and Inventory_stateQuantities at {inStock}. The Inventory Stock report (chunk 8821.b0729a55.js, GraphQL query AddmiDashboardInventoryAdjustmentReport -> businessInventoryAdjustReport) renders columns Date/Time, Employee, Item/Variant Name, Category, Reason, Stock -- no unit column. CENSUS: the zero is bound to the whole inventory module, not to a convenience sample. I resolved the Vue router's lazy-chunk map and fetched every previously-unfetched inventory-bearing chunk -- 6627 (storeInventory), 8400 (storeItemCSV), 2317 (storeItemNew/storeItemEdit), 4550 (storeItems), 3700 (reports--inventory), 8821 (reports--inventory--stock), 1861 (admissionInventory) and the shared 2055/3663/7583/8440 -- and uom, unitOfMeasure, conversionFactor, purchase/recipe/count/base/stock unit, caseSize/packSize/perCase/unitsPerCase, yield, recipe and ingredient tokenise to ZERO in all of them, as they do in the published spec. CONTROLS/POISON: EVERY control was re-run over EVERY corpus including the 3.5 MB bundle, and four of them are traps. 'unit' is 75 hits in the vendor chunk and only 6 are real: the rest are date-fns/moment TIME units (ordinalNumber({unit:'year'|'quarter'|'month'|'week'|'hour'})) and the ISO 4217 currency table, where 'Bond Markets Unit European Composite Unit (EURCO)', 'ADB Unit of Account' and minorUnit are money, not measure -- and in the dashboard app chunk all 6 hits are the word 'United'. 'conversion' is 113 hits in the vendor chunk and 113 in the guest bundle, and EVERY ONE is the lead-to-customer payload key of ActionAccountConvert / ActionBusinessContactConvert / ActionResellerConvert (t.conversion), never unit conversion -- the proposer tested this control only against the spec, and testing it against the bundle was the single most likely way to overturn this cell. 'yield' is the JS reserved-word list in the vendor chunk and generator syntax in the guest bundle; 'pound' is 12 currency names (Egyptian, Sudanese, Sterling); 'portion' is the accounting.js MIT licence header; 'shrinkage' is CSS flex-shrink; 'case' is 5,017 switch statements. Tokenised, the real count is zero. https://addmi.com/dashboard/js/chunk-vendors.08aeeb98.js · retrieved 2026-09-15 adversarially verified

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

inventory-theoretical-vs-actual

Not scored by this record.

Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator

inventory-realtime-depletion

Not scored by this record.

Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator

inventory-86-auto-sync

Not scored by this record.

Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.

inventory-count-modes

Addmi has no inventory counting MODE of any kind: counting is one reason code on a single-item quantity edit. The merchant dashboard's item editor (lazy chunk 2317.91c99334.js, 138 KB, routes storeItemNew/storeItemEdit) renders a CLOSED adjustment-reason dropdown whose last option is 'Inventory Re-Count' (value "recount"); selecting it relabels the single numeric input from 'Add Stock'/'Remove Stock' to 'Current Stock', replaces the running math helper '%{currentStock} + %{delta} = %{result}' with the transient hint 'Previously %{currentStock}', and emits com.addmi.inventory.physicalCount.v1 for that ONE item variant with {scalar: <typed figure>, unit: "Unit"}. The reducer in the eagerly-loaded vendor chunk confirms the semantics: case i.ActionInventoryPhysicalCount: return a(0, t.count.scalar) -- inStock is REPLACED by the typed figure -- against case i.ActionInventoryAdjustment: return a(e, s("inStock", t.adjustment)), which applies a signed delta across named state buckets. That is absolute quantity editing, not a count: there is no count session, count sheet, count subset, schedule, cadence or due-date object anywhere. The inventory domain is closed at six actions -- create, delete, adjustment, physicalCount, setThreshold, updateTracking -- declared together in the shared action module (t.ActionInventoryPhysicalCount="com.addmi.inventory.physicalCount.v1" etc.), and the inventory entity folds as combineReducers({entityID, businessID, unit, stateQuantities, customQuantities, track, threshold, thresholdCrossed, created, deleted, updated}). The dashboard's own storeInventory route is an UNIMPLEMENTED STUB: chunk 6627.5c7f9981.js is 414 bytes rendering only <div class="inventory"><h1>{{$route.name}}</h1></div>. HISTORY -- the one conjunct that partly holds: counts are not overwritten. The Inventory > Stock report (route reports--inventory--stock, chunk 8821.b0729a55.js) runs GraphQL query AddmiDashboardInventoryAdjustmentReport -> businessInventoryAdjustReport(businessEntityID, start, end) selecting {time{iso}, variantOptions, accountEntityID, accountNameGiven, accountNameFamily, catalogCategoryName, catalogItemName, catalogItemVariantName, adjustFrom, adjustTo, adjustScalar, adjustUnit, adjustReason}, rendered over a merchant-chosen date range as columns Date/Time, Employee, Item/Variant Name, Category, Reason, Stock, with reasonMap {received:'Received', restock:'Restock', damage:'Damange'[sic], theft:'Theft', loss:'Loss', recount:'Recount'}. Every re-count is therefore a separate timestamped, employee-attributed row. But there is NO VARIANCE: the row carries the new absolute figure and the reason, never expected-vs-counted; a physicalCount action carries no from/to at all, so adjustFrom/adjustTo are empty on precisely the recount rows; and variance, discrepanc, overage and shortage tokenise to ZERO across 55 corpora / 12.8 MB. The only 'Previously N' is a live hint in the edit form, not a stored or reported figure. The published OpenAPI 3.0.3 spec exposes even less: Inventory is closed at {id, track, stateQuantities}, Inventory_stateQuantities at {inStock}, and none of its six paths (/oauth2/authorize, /oauth2/createToken, /oauth2/refreshUsingToken, /menu, /transactions, /webhook) is a count endpoint. CENSUS: the zero is bound to the whole inventory module, not a sample -- the Vue router's lazy-chunk map was resolved and every inventory-bearing chunk fetched: 6627 (storeInventory), 8400 (storeItemCSV), 2317 (storeItemNew/storeItemEdit), 4550 (storeItems), 3700 (reports--inventory), 8821 (reports--inventory--stock), 1861 (admissionInventory) and the shared 2055/3663/7583/8440. CONTROLS/POISON: cycleCount, spotCount, 'count sheet', stocktake, cadence, parLevel, countSession, 'count history' and 'audit trail' are zero in every corpus; the surviving near-misses are ALL traps. 'cycle' is NOT zero in the 3.5 MB vendor bundle that this citation names (3 tokens, 7 substrings), but every hit is plumbing: Firebase 'object contains a cycle', 'Promise-chain cycle', JSON '__cycle__', json-stable-stringify's cycles option, Intl hourCycle and Vue _lifecycleHooks. 'schedul' is 42 hits of Firebase token-refresh and reconnect schedulers, Firestore gcScheduler/indexBackfillerScheduler, Apollo scheduleQueueConsumption, and the ordering features scheduledPickUp/scheduledDelivery -- never inventory scheduling. 'recurring' is recurringDonationOptions/allowRecurringDonations (fundraising); 'frequency' is PostFrequency {daily, weekly, monthly} (social posting); 'weekly' is labour RuleType.weeklyHours. 'onHand' matches onHandleClick and 'sheet' matches the xlsx worksheet-table component -- both inside the stock report itself, the two places a careless search would manufacture a false positive. https://addmi.com/dashboard/js/chunk-vendors.08aeeb98.js · retrieved 2026-09-15 adversarially verified

Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.

inventory-mobile-count-offline

Not scored by this record.

Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator

inventory-vendor-catalogs-edi

Not scored by this record.

Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator

inventory-invoice-ocr

Not scored by this record.

Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator

inventory-price-change-alerts

Not scored by this record.

Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator

inventory-par-auto-suggest

Not scored by this record.

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

inventory-waste-logging

Not scored by this record.

Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.

inventory-cogs-gl-export

Not scored by this record.

Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator

inventory-native-not-partner

Not scored by this record.

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

inventory-menu-margin-linkage

Not scored by this record.

Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.

reporting-realtime-dashboard

KDS feature page: 'Access reports such as Sales, Labor, Payment & Refund, Transactions, Discounts, and Loyalty' and 'Reports are available on your Addmi dashboard and can be accessed from anywhere with an internet connection' — an off-premise cloud dashboard exists. Shortfalls: refresh latency is undocumented (no live/real-time claim anywhere, only 'historical reports' on the quick-serve page), and the vendor's own /app page lists no owner/manager mobile app — only Ticketing and POS apps — so off-premise mobile access is browser-only. https://addmi.com/products/kitchen-display-system · retrieved 2026-08-04

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

POS page lists 'Till and end of day features' and documents a 'Server Shift Close Out' in which servers 'have restricted view of their assigned transactions and daily tips only and are required to settle lingering orders before clocking out' — an end-of-day/close-out process exists. Shortfall: the contents of the close-out are undocumented; no page shows a single document reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types and expected cash deposit, and the 'Addmi Summary Reports' / 'Addmi Sales Summary Reports' help articles visible in the archived help-centre roster were never captured (live portal returns HTTP 404). https://addmi.com/products/point-of-sale · retrieved 2026-08-04

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Vendor's own App Store copy claims 'detailed reports on sales, popular items, and peak hours' — item-level product reporting is claimed, at marketing grade only. Shortfall: no modifier-level breakdown, no quantity/gross/net columns, and no daypart or revenue-center filters are documented anywhere; the dashboard report set enumerated on the POS and KDS pages (Sales, Labor, Payment & Refund, Transactions, Discounts, Loyalty) contains no PMIX report. https://apps.apple.com/us/app/addmi-point-of-sale/id1499904685 · retrieved 2026-08-04

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

Not scored by this record.

Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.

reporting-cash-over-short

Not scored by this record.

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

Not scored by this record.

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

Not scored by this record.

Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.

reporting-scheduled-delivery

Not scored by this record.

Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator

reporting-public-api

Not scored by this record.

Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator

reporting-webhooks

Not scored by this record.

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

Not scored by this record.

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

Not scored by this record.

Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator

reporting-history-retention

Not scored by this record.

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

Not scored by this record.

Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.

reporting-nl-query

Not scored by this record.

Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator

reporting-guest-cohorts

Not scored by this record.

Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator

reporting-sales-forecast

Not scored by this record.

Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.

reporting-tip-tax-compliance

Not scored by this record.

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

Not scored by this record.

The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator

hardware-commodity-devices

Not scored by this record.

Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.

hardware-os-platforms

Addmi publishes a recommended/exact-model compatibility list in support docs and insists on those models; OS names and minimum versions were not retrievable. https://www.addmi.com/pricing · retrieved 2026-08-01

Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.

hardware-handheld-purpose-built

Not scored by this record.

The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator

hardware-handheld-battery-swap

Not scored by this record.

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

hardware-handheld-lte

Not scored by this record.

Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).

hardware-offline-mode

Vendor's food-truck guide (published 2026-07-23) markets 'Offline-friendly card acceptance — sales continue when the signal at the curb does not.' Shortfall: only card acceptance is claimed to survive an outage; nothing documents that kitchen printing or cash-sale recording continue, and the claim's requirement that the vendor document which functions degrade is unmet — the same guide tells buyers to 'confirm exactly what still works offline before you commit' while publishing no such degradation list for Addmi itself. The supported-hardware article's documented mitigation for low-connectivity sites is an iPad Wi-Fi + Cellular, i.e. alternative connectivity rather than a described offline mode. https://addmi.com/guides/food-truck-pos-system · retrieved 2026-08-04

Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.

hardware-kds

Kitchen display included at no extra cost as a first-party feature; bump-bar input, station routing and course timing not documented. https://www.addmi.com/pricing · retrieved 2026-08-01

Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator

hardware-kiosk

Not scored by this record.

Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.

hardware-drive-thru

Not scored by this record.

Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.

hardware-printer-compatibility

Not scored by this record.

Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.

hardware-peripherals

Not scored by this record.

Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.

hardware-p2pe-terminal

Not scored by this record.

Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator

hardware-tap-to-phone

Not scored by this record.

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

hardware-pricing-transparency

Not scored by this record.

Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator

hardware-ownership-vs-lease

Not scored by this record.

Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator

hardware-usable-after-churn

Not scored by this record.

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

hardware-byod

Not scored by this record.

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

extensibility-public-api-docs

Addmi serves a public, anonymous API reference at https://api.addmi.com/api/docs/ -- a Swagger UI page, HTTP 200, 3,106 bytes, no login, no NDA and no sales call (re-fetched 2026-09-15 under two user agents; api.addmi.com/robots.txt returns 404, so no crawl bar applies). The page's ./swagger-ui-init.js (220,499 bytes, also anonymous) inlines the complete OpenAPI 3.0.3 document: info.title 'Addmi API', version 0.1.0, description 'The API for integrating with the Addmi system'; servers [https://api.addmi.com/api/v0]. Six operations -- GET /oauth2/authorize, POST /oauth2/createToken, POST /oauth2/refreshUsingToken, GET /menu, POST /transactions, POST /webhook -- each carrying a summary, parameters or a request body, per-status responses (400/401/403/5XX) and a declared security scheme (basicAuth, or bearerAuth JWT); 64 component schemas, and all 64 $refs in the document resolve. So the reference is complete as published and machine-consumable before purchase, which is what this table-stakes claim asks. Two caveats a reader should have. (1) The surface is small and versioned 0.1.0 -- menu read, transaction post and one inbound webhook receiver, with no employee, inventory, payment or reporting endpoints -- so it documents an integration API, not the whole product. (2) It is undiscoverable from Addmi's public marketing: it appears in none of the 2,215 URLs in addmi.com/sitemap.xml, the partners page and the 165 KB terms never use the token 'API', and the only reference to it anywhere is the merchant dashboard's own API Settings chunk (addmi.com/dashboard/js/2639.726fddd6.js), which renders 'Documentation:' anchored to this exact URL. PROBE POISON, recorded so no later pass repeats it: the bare path /api/docs 301s to /docs/, which 404s -- an earlier pass's 'no API reference' rests on that false negative -- while conversely EVERY path under /api/docs/ (/api/docs/zzqqnonsense, /openapi.json, /swagger.json, /schema/) returns the byte-identical 3,106-byte Swagger shell (same sha256), so those 200s are a path-prefix catch-all and the spec exists only inside swagger-ui-init.js. This also falsifies the record's sources.jsonl note on addmi.com/partners that Addmi has 'no developer program, API or app marketplace'. https://api.addmi.com/api/docs/ · retrieved 2026-09-15 adversarially verified

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

extensibility-api-access-cost

Not scored by this record.

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

extensibility-free-sandbox

Not scored by this record.

Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).

extensibility-oauth-partner-apps

Addmi publishes an OAuth 2.0 authorization-code flow, but none of the claim's qualifying conjuncts. MET: the anonymous OpenAPI 3.0.3 document inlined as swaggerDoc in api.addmi.com/api/docs/swagger-ui-init.js (220,499 bytes, retrieved 2026-09-15) defines GET /oauth2/authorize ('After authorization, you will be redirected to the provided redirectURI with an authorization code'; required client_id and redirect_uri, optional state), POST /oauth2/createToken ('Use Basic Authorization passing in the base64 encoding of clientID:clientSecret. Access tokens expire after 24 hours while refresh tokens expire after 30 days') and POST /oauth2/refreshUsingToken; the dashboard bundle confirms https://api.addmi.com/oauth2 is Addmi's own service, not a vendored SDK. NOT SCOPED: the tokens 'scope', 'scopes', 'consent', 'grant_type' and 'permission(s)' occur ZERO times word-boundary in the entire 220,499-byte file; securitySchemes are only {basicAuth: http basic, bearerAuth: http bearer JWT} with NO scheme of type oauth2 at all, so the document contains no mechanism by which a scope could be declared, and every protected operation carries an empty scope array. The merchant's own API-credential entity carries no scope field either: com.addmi.business:api.create/update/delete.v1 over a reducer of {id, businessID, clientID, webhookURLs, created, deleted, updated}. NOT OPERATOR-GRANTED IN THE CLAIM'S SENSE: the clientID/clientSecret pair is issued to the MERCHANT in its own back office (addmi.com/dashboard/js/2639.726fddd6.js, 'API Settings': a disabled Client ID input, a masked Client Secret with Show/Hide, a merchant-editable 'Callback URLs' list, and a 'Documentation:' link to the spec above), so a third party integrates by being handed the operator's own secret - which is the credential sharing the claim explicitly excludes, not a per-app grant with a consent screen. NO REVOCATION SURFACE: no revoke endpoint exists in the closed six-path spec (/oauth2/authorize, /oauth2/createToken, /oauth2/refreshUsingToken, /menu, /transactions, /webhook), and the API Settings screen exposes no revoke or regenerate control - its only delete handlers are handleDeleteCallbackURL and handleDeleteWebhookURL, and it renders a single credential pair with no per-app list. The event model does carry a per-businessAPIID delete action, so server-side per-credential deletion may exist, but it is neither surfaced in the back office nor documented. No developer portal resolves (developer., developers., docs. and portal.addmi.com all return nothing) and no app marketplace or partner directory exists; addmi.com/partners is a logo wall of named integrations (Club Express, MarketMan, Intuit QuickBooks, Otter, Square, Stripe) with a contact form. POISON: 'oauth' elsewhere in the merchant bundle is NOT Addmi's - oauthAccessToken/oauthTokenSecret/INVALID_OAUTH_CLIENT_ID and revokeAccessToken (providerId 'apple.com') are the Firebase Auth SDK, and 'squareposoauth2error' is a Square route; the integration-settings chunk's permission and revocation strings ('Allows our app to read content...', 'You can always manage or revoke access to the integration') are FACEBOOK's scopes and Facebook's revocation, not Addmi's; and 'permissions' in chunk-vendors is 340 hits of Apache-licence boilerplate. https://api.addmi.com/api/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified

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

extensibility-webhooks-push

Addmi's published OpenAPI 3.0.3 document ('Addmi API' v0.1.0, server https://api.addmi.com/api/v0, inlined as swaggerDoc in the anonymous Swagger UI that the merchant dashboard's own API Settings screen links to as 'Documentation:') defines POST /webhook, 'These are the requests that will be sent to your server if you have webhooks configured'. Its requestBody is a closed anyOf of exactly three variants, each pinned by a single-value type enum: 'catalogItemVariant.eightySix.updated', 'catalogModifier.outOfStock.updated' and 'catalogSubModifier.outOfStock.updated', whose data.object resolves to CatalogItemVariant, CatalogModifier and CatalogSubModifier respectively. There is no discriminator, no additionalProperties, no free-string type fallback, no OpenAPI 'webhooks' or 'callbacks' key, and no fourth variant. Every pushed event is therefore catalog availability (86 / out-of-stock); no order lifecycle event -- created, modified, paid, voided or refunded -- is among them, so the claim shortfalls on every conjunct rather than partly. The absence is bounded to the outbound surface, not merely unfound: the merchant-side webhook configuration is a bare repeatable webhookURLs list on the dashboard API Settings screen ('+ Add Webhook', placeholder 'https://') with no event-type, topic or subscription selector, backed by the GraphQL query businessAPIByBusinessEntityID {id, webhookURLs} and a single ActionBusinessAPICreate/Update carrying {clientID, webhookURLs}; 'webhook' appears in none of the 652 com.addmi.*.v1 action types. There is no richer subscription model behind a tier for the spec to be a subset of. Nor is polling an alternative: the document has six paths in total -- GET /oauth2/authorize, POST /oauth2/createToken, POST /oauth2/refreshUsingToken, GET /menu, POST /transactions ('Create a new transaction in the Addmi system', inbound) and POST /webhook -- so an integrator can neither receive order events nor read them back. CONTROLS: the token 'event' occurs zero times in the 220,499-byte document, both as a raw substring and tokenised (it is not hiding inside 'eventually'). POISON, recorded so a later pass does not misread it: 'order' occurs 145 times raw / 122 tokenised and is almost entirely the catalog sort-order integer ('"order": 6', 'The sort order of the modifier') plus the onlineOrderingClosed* settings and orderNumber / orderNumberPrefix / orderNumberError on the transaction Ref -- there is no Order schema in the document at all. Retrieved 2026-09-15; the live fetch is byte-identical to the cached copy (MD5 6BF9BEDA8124AB380E74559C2FE566A2). https://api.addmi.com/api/docs/swagger-ui-init.js · retrieved 2026-09-15 adversarially verified

Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator

extensibility-webhook-reliability

Not scored by this record.

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

Not scored by this record.

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

extensibility-doordash-preferred

Not scored by this record.

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

Not scored by this record.

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

extensibility-middleware-compatibility

Not scored by this record.

Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.

extensibility-accounting-connectors

Not scored by this record.

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

extensibility-payroll-export

Not scored by this record.

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

extensibility-app-marketplace

Not scored by this record.

The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.

extensibility-headless-embedded

Not scored by this record.

A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator

extensibility-data-portability-exit

Not scored by this record.

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

reliability-offline-order-entry

Vendor legal text, not marketing, now carries the on-terminal half of this claim. Addmi's Terms define the mechanism: '"Offline Credit Card Transactions" means the situation when encrypted credit card transaction information that is stored locally on a device when the proper network connection is unavailable. An attempt to facilitate the transaction can be made when the connection is restored', and 'addmi may offer a feature that facilitates transacting Offline Credit Card Transactions with the Services.' The shipped domain model corroborates that this is a live product state rather than boilerplate: the merchant dashboard bundle carries a first-class action 'com.addmi.transaction.tender.OFFLINE.v1' whose reducer returns TenderStatus.offline, a member of the closed status enum alongside authorized, declined, captured, voided and prepayPreAuth; tender and transaction attempt actions carry a ProcessingType of 'local' or 'server' (com.addmi.transaction.processItemCreation.v1 among them). Shortfalls, all three unresolved: (1) what is documented is the TENDER, not the TICKET -- offline order entry itself is asserted only at marketing grade, by the vendor guide sentence 'Addmi keeps taking payments when the network drops, stores orders locally, and syncs automatically when you are back online' (addmi.com/guides/food-truck-offline-pos, Aug 2026); (2) ticket routing and check printing while offline are documented nowhere -- the archived Freshdesk roster contains no offline article and the live portal 404s; (3) the terms say Addmi 'may offer' the feature and disclaim all liability for it on an 'As Is' and 'As Available' basis, so per-merchant availability is not established. https://addmi.com/tos · retrieved 2026-09-15 adversarially verified

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

reliability-offline-card-auth

Not scored by this record.

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

Not scored by this record.

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

reliability-offline-kds-printing

NEW 2026-09-17: crt.sh for addmi.com (22 names) probed at / and /swagger, /swagger/index.html, /api-docs, /openapi.json, /docs, /v3/api-docs, /robots.txt and a nonsense path: api.addmi.com 404 everywhere, auth 404, biz 301 -> addmi.com, tprox 307 -> addmi.com, onboarding/eks-elb 400, file.addmi.com 403 (S3), stage/ops-*/vpn/tschnepp no response. Two LISTABLE S3 buckets: iab.addmi.com (IsTruncated=true; hashed per-business image uploads, no documents) and image.addmi.com (185 keys, complete: brand icons, distributor/reseller agreement PDFs, addmi-onesheet-foodtruck-2023.pdf, case-study-Fatwood-BBQ--Addmi.pdf, clubexpress onesheet). App Store lookup (artist of id1187349472): only "Addmi Point of Sale" com.addmi.addmi-pos 1.5.9 and "Addmi Ticketing"; no DS/KDS listing; no com.addmi.* on Google Play (404). Case study: "By choosing the Star Micronics TSP143III with a USB connection to a cellular iPad for the POS, Fatwood can use their printer without requiring network connectivity" -- the printer needs no LAN, but the iPad is on cellular data, so this says nothing about kitchen routing during an internet outage. Wayback id_ fetch of 65000165417-printing-with-ads: not archived (404). Retrieved 2026-09-17. || 329th: NEW 2026-09-18 (329th): APP-LEVEL CENSUS OF THE STORE APP, and it does not settle this cell. iTunes lookup of the publisher shows the KDS is not a separate product: the ten iPad screenshots of 'Addmi Point of Sale' (com.addmi.addmi-pos 1.5.9, released 2026-08-13) were downloaded at full resolution (2000x0w, 0.26-0.57 MB each) and read as images; screenshot 002 is captioned '3 Apps in 1 -- Install a single app for multiple duties' over POINT OF SALE, KITCHEN DISPLAY SYSTEM and CUSTOMER FACING DISPLAY, and the KDS pane's footer bar reads 'Default Station | Fry Station | Kitchen ... 12 Fulfillments / Orders / Recall / Settings' beside a green cloud-with-check status pill that also appears in the POS header of screenshots 001 and 011. So the KDS is a mode of the same iOS binary and shows a cloud/connection indicator, but a screenshot cannot say what it does when that indicator goes red. The dashboard's complete 4,827-key English string table contains exactly two 'offline' keys, neither about the kitchen ('*<span>OFFLINE</span> payment processing <span>not</span> supported', the processor-picker footnote, and 'Canceling an event date ensures that it remains offline...'), and the station entity is a cloud record ('fulfillmentStates { id name display emailsEnabled emailAddresses }'), matching the setup string 'To use the Addmi Display System (Kitchen Display System) to display your orders, please add a station on the Settings page'. The vendor's rebuilt site (2,218-URL sitemap, 92 non-tenant pages fetched) has 0 hits for 'offline' within 200 chars of 'kitchen'/'KDS'/'station', and the KB is gone (addmi.freshdesk.com/support/home, /support/solutions and the /pricing-linked article 65000163511 all 404 to curl with a browser UA today). HELD unknown: this is an absence of publication, not evidence that kitchen routing stops offline, and no censused surface covers the native app's behaviour during an outage. Retrieved 2026-09-18. adversarially verified

The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.

reliability-printer-fallback

CLAIM: automatic failover to a backup printer/KDS when a kitchen printer is unreachable, with staff alerts. VERDICT: unknown (unchanged). NEW SURFACE CHECKED 2026-09-16: the retired Freshdesk KB (addmi.freshdesk.com, live 404) survives in Wayback only as its home page (capture 20240915075248), which lists 94 article links, including 'Printing with ADS' (65000165417), 'How to Configure a Printer' (65000179326), 'Addmi DS Troubleshooting' (65000173203), 'Addmi DS Settings and Setup' (65000165419) and 'Order Fulfillment Stations and DS App' (65000166722) -- exactly the articles that would settle this cell. Their BODIES ARE NOT ARCHIVED: 54 of the 94 article URLs were probed at Wayback and all but the hardware article returned the not-archived page (~4.7 KB), and the Wayback CDX index for addmi.freshdesk.com (q310-addmi/cdx_addmi.freshdesk.com.txt) lists only two article captures, 65000163511 (hardware list: 'Supported Printers: Thermal: Star Micronics mC-Print3 (MCP31L) Impact: Star Micronics SP700 Label: Star Micronics TSP654IISK', no failover text) and 65000182851 (gift cards). Also read: all 19 posts under https://addmi.com/news (no printer text) and addmi.com/support (a contact form only; no KB). The KB is a gated-by-absence corpus (titles without bodies), so no 'no' may be published. Retrieved 2026-09-16. || 321st: NEW 2026-09-17: crt.sh for addmi.com (22 names) probed at / and /swagger, /swagger/index.html, /api-docs, /openapi.json, /docs, /v3/api-docs, /robots.txt and a nonsense path: api.addmi.com 404 everywhere, auth 404, biz 301 -> addmi.com, tprox 307 -> addmi.com, onboarding/eks-elb 400, file.addmi.com 403 (S3), stage/ops-*/vpn/tschnepp no response. Two LISTABLE S3 buckets: iab.addmi.com (IsTruncated=true; hashed per-business image uploads, no documents) and image.addmi.com (185 keys, complete: brand icons, distributor/reseller agreement PDFs, addmi-onesheet-foodtruck-2023.pdf, case-study-Fatwood-BBQ--Addmi.pdf, clubexpress onesheet). App Store lookup (artist of id1187349472): only "Addmi Point of Sale" com.addmi.addmi-pos 1.5.9 and "Addmi Ticketing"; no DS/KDS listing; no com.addmi.* on Google Play (404). No failover/backup-printer text on any of these; Wayback retries of 65000165417-printing-with-ads (404 not archived) and 65000179326-how-to-configure-a-printer (no response). Retrieved 2026-09-17. || 329th: MERGE HOLD (proposed no/B, held unknown): The census is of the BACK-OFFICE dashboard (4,827 strings, 202 GraphQL docs). The store-level native iOS app (com.addmi.addmi-pos), where a print failure would be handled, is in no corpus; a back-office census does not bound the store-level POS (325th rule). The printer schema having no fallback field is recorded as the bound so far. PROPOSAL AS WRITTEN: NEW 2026-09-18 (329th): the printer DATA MODEL, read out of the merchant dashboard's own GraphQL documents, cannot express a fallback target. https://addmi.com/dashboard/js/208.188bc8d7.js (live 200, 13.5 KB, re-fetched 2026-09-18) carries the catalog-settings query verbatim: 'printerConfig {\n ipAddresses\n }\n\n printers {\n id\n name\n ipAddress\n port\n }' -- four fields per printer, plus a flat list of IPs, and nothing else. The station entity in the same document set is 'fulfillmentStates {\n id\n name\n display\n emailsEnabled\n emailAddresses\n }': a station carries no printer reference at all, so there is no per-station primary printer to fail over FROM, let alone a secondary. VERDICT: no. Automatic failover to a backup printer or KDS station, with staff alerts, cannot be configured and no alert exists. BOUND: the surface censused is the Addmi merchant dashboard (addmi.com/dashboard), which is where printers are authored -- its own UI strings are 'Enter the Details of the printers you are using.', 'Printer %{printerCount}' and 'Your printers have been saved!', and the back-office action-type enumeration exposes exactly two printer verbs, com.addmi.catalog.settings.printerConfig.update.v1 and com.addmi.catalog.settings.setPrinters.v1, out of 652 distinct com.addmi.*.v1 action types. The corpus is the 454-chunk dashboard bundle set fetched to a fixpoint in the 310th (454/454 ok, 0 fail, 21.5 MB) plus its complete 4,827-key English UI string table (extracted this pass from the locale chunk 8767) and the 202 GraphQL documents embedded in those chunks. CONTROLS, tokenised, case-insensitive, over all three: 'backup' 0 hits in the 4,827 keys; 'fail-over'/'failover' 0; 'redundant' 0; 'secondary' 0 in any printer context; the 17 'fail' keys are all payment/void/capture failures ('Capture Failed', 'Void Tender Failure', 'Tip Adjustment Failed') -- POISON NAMED: 'fail' is a payments word in this app, not a device word. The vendor's own KDS feature page https://addmi.com/products/kitchen-display-system enumerates ten KDS features (no extra cost, online+POS orders to KDS, fulfillment-method filter presets, customer SMS, print receipts and tickets for incoming online orders, fulfil orders or individual items, Expediter Screen, Fulfillment Summary Bar, Fulfillment Warning Threshold, Double Fulfillment) and failover is not among them; 'Double Fulfillment' is a ROUTING feature (one item to multiple prep stations, each completing independently), not a fallback. The live 6-path Addmi API spec has 0 'printer'. RESIDUAL RISK, stated: the store-level app (com.addmi.addmi-pos 1.5.9, iOS, which per its App Store screenshots also runs the KDS and the customer display) is a native binary not in any corpus, so an undocumented, unconfigurable in-app retry is not excluded -- but the claim's own wording is failover for 'a configured kitchen printer', and no such configuration or alert exists on the only surface where printers are configured. Retrieved 2026-09-18. adversarially verified

The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).

reliability-offline-feature-matrix

Not scored by this record.

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

reliability-public-status-page

Not scored by this record.

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Not scored by this record.

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

reliability-menu-build-service

Not scored by this record.

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

reliability-hardware-replacement-sla

Not scored by this record.

The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.

reliability-pci-dss-4-attestation

Not scored by this record.

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

reliability-mfa-role-based-access

Not scored by this record.

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

reliability-self-serve-training

Not scored by this record.

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

reliability-cellular-backup

Not scored by this record.

Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator

commercial-month-to-month-contract

Not scored by this record.

Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator

commercial-no-early-termination-fee

Not scored by this record.

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

Addmi's publicly served Terms and Conditions state the renewal term in all caps: 'IF YOU SUBSCRIBE TO THE SERVICES FOR A TERM (THE "INITIAL TERM"), THEN THIS AGREEMENT WILL BE AUTOMATICALLY RENEWED FOR ADDITIONAL PERIODS OF THE SAME DURATION AS THE INITIAL TERM AT ADDMI'S THEN CURRENT FEES FOR SUCH SERVICES UNLESS YOU OPT OUT OF THE AUTO RENEWAL IN ACCORDANCE WITH section 9.6 BELOW.' The fees section states the cancellation window: the subscription 'will automatically commence on the first day following the end of such period (each a "Renewal Commencement Date") and continue for an additional equivalent period, at addmi's then current price', and 'You agree that your subscription will be subject to this automatic renewal feature unless you cancel your subscription at any time prior to the Renewal Commencement Date. If you do not wish your subscription to renew automatically, or if you want to change or cancel your subscription, please contact us at team@addmi.com.' It also fixes the effect of cancelling: 'You may not cancel your subscription prior to the end of your then current subscription term... you will not be eligible for a prorated refund.' The Termination section repeats that 'The subscription term will automatically renew in accordance with this Agreement.' Both conjuncts of the claim are therefore public and diligenceable before signing: the renewal term (an equal period at then-current fees) and the notice window (none required; cancel any time before the Renewal Commencement Date). Two caveats that do not defeat the claim: the all-caps clause conditions opting out on 'section 9.6', and the published document contains no numbered sections at all -- a dangling cross-reference, leaving the email above as the only stated opt-out mechanism; and Addmi's default model is $0 software with per-transaction fees, so these clauses bite only where 'by mutual agreement, a monthly subscription model is applied'. https://addmi.com/tos · retrieved 2026-09-15 adversarially verified

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Not scored by this record.

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

Not scored by this record.

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

Not scored by this record.

Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).

commercial-pricing-published

Exact figures published: $0/month, 19c POS and 38c online per transaction, 2% membership/invoicing, 3% ticketing capped at $39. https://www.addmi.com/pricing · retrieved 2026-08-01

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

commercial-module-unbundling

Not scored by this record.

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

No hardware lease is possible because Addmi sells no hardware — you buy listed models yourself — but Addmi publishes no hardware price list. https://www.addmi.com/pricing · retrieved 2026-08-01

Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator

commercial-hardware-not-locked

Not scored by this record.

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

Not scored by this record.

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

Not scored by this record.

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

Not scored by this record.

Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator

commercial-data-ownership-clause

Not scored by this record.

Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.

commercial-pci-p2pe-tokenization

Not scored by this record.

Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.

commercial-pci-dss-4-controls

Not scored by this record.

Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.

commercial-privacy-dsar-tooling

Not scored by this record.

Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator

commercial-wcag-kiosk-accessibility

Not scored by this record.

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

Not scored by this record.