Thanx

menu-pricing-nested-modifiers

Nested modifiers exist in Thanx-built ordering. The Square direct-to-POS entry (2026-07-10) answers "What pricing and modifier options are supported?" with "Item-based pricing, size-based pricing, nested modifiers, priced modifiers, and modifier images are supported, along with dynamic pricing by handoff mode"; the Deliverect-powered ordering entry (2026-08-11) lists "Menu flexibility - supports nested modifiers, item/modifier/option-based pricing, custom category banners"; and the web-ordering accessibility entry (2026-04-27) shows maximum-selection rules reaching the guest, with "modifier limits ('choose up to 3')" now announced to screen readers. Shortfalls, both material to the claim as worded: (1) no nesting DEPTH is published anywhere - "nested" is asserted, three levels is neither claimed nor shown; (2) per-level minimum counts and forced-selection flags are neither documented nor configurable in Thanx. On every documented Thanx ordering path the menu is authored upstream and imported: Square ("managing menu pricing, imagery, item availability, handoff modes, store hours ... all live in Square - one source of truth"), Deliverect ("Already use Deliverect for menu management"; "we import and validate your menu - categories, items, modifiers, and images"), Toast ("Menu management all in Toast ... All management of your menus should be done in Toast") and Olo ("One source of truth: you configure availability once in Olo"). Thanx publishes no menu-authoring surface of its own. On Square, "categories support only one level - subcategories flatten into their parent", which is a category limit rather than a modifier one but is the only level-depth statement the vendor publishes. https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

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

Thanx authors no modifier and no modifier price. The only modifier structure in the entire 168-page closed docs census is an INBOUND basket field whose own labels foreign-key it to the partner: 'Modifier ID in your system / POS', 'Modifier name', 'Modifier price adjustment', 'Base price of the item before modifiers'. It is a flat array with no parent-size axis and no matrix, and Thanx receives it rather than configures it. The silence is load-bearing because this endpoint IS Thanx's complete item/modifier data model — there is no menu, item, catalog or product resource anywhere in the Consumer, Partner or Loyalty API. Absent from Thanx, delegated to the POS: a guest ordering through a Thanx branded app sees size-priced toppings only if Square, Toast, Olo or Deliverect models them upstream. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

menu-pricing-fractional-placement differentiator

Thanx owns no menu object in which a pizza could be sectioned. The basket item schema is 'Item ID in your system / POS' + name + a single decimal 'Item amount' + categories + a flat modifier array with 'Modifier price adjustment' — no fraction, section, half, quarter or placement field, and no per-section price. Because this is the whole of Thanx's published item model and the docs census is closed, the absence bounds the product and not merely one integration. Delegated, not merely unaddressed: docs.thanx.com/consumer/best-practices/loyalty puts the menu with the ordering provider ('having a menu configured with the digital ordering provider'), so any half-and-half construct is the provider's. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

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

Thanx runs no item-pricing engine. The basket schema shows every price arriving already computed by the sender — 'Item amount', 'Modifier price adjustment', 'Base price of the item before modifiers', subtotal 'before taxes & tips' — and the only pricing logic Thanx executes is reward discount calculation (types amount, percent, item, fixed_price), which prices a reward and never a split item. No menu, item or product resource exists in the closed 168-page reference. Delegated to the upstream POS/ordering provider that composed the price. Grade B: this is an absence over the published API bearing on a product capability, and help.thanx.com merchant configuration docs remain 401-walled. https://docs.thanx.com/loyalty/create-update-basket.md · retrieved 2026-09-04 adversarially verified

menu-pricing-topping-quantity-tiers

The modifier object Thanx defines has exactly four fields — 'Modifier ID in your system / POS', 'Modifier name', 'Modifier price adjustment', 'Base price of the item before modifiers' — with no quantity, tier or multiplier field, and it is inbound. There is no create/update endpoint for a modifier anywhere in the closed 168-page census, so Thanx cannot configure light/regular/extra/double pricing; it can only be told the resulting adjustment. Delegated to the POS rather than absent from the guest experience. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

menu-pricing-size-style-matrix differentiator

A two-axis price grid requires an item Thanx authors; it authors none. Its item is inbound and flat — 'Item ID in your system / POS', 'Item name', 'Item amount', 'categories that describe this item' — with no variant axis at all, let alone two with per-cell overrides. The only size vocabulary Thanx publishes is a reward that can target a product at 'base level or through size modifiers', i.e. reward targeting against somebody else's variant, which is why the 2026-09-02 pass correctly refused to answer this claim off one axis. Absent from Thanx, delegated to the POS catalog. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

menu-pricing-included-allowance differentiator

An included-modifier allowance with overage charging is item-composition configuration, and Thanx configures no item. Its most granular rules surface is the reward-applicability engine, whose published fields are the reward 'value' ('amount → dollars off; percent → percentage; item → dollar value of the free item; fixed_price → target price'), a 'Maximum discount cap', and 'Product IDs the reward is restricted to (item-redeem and BOGO)'. That is a complete enumeration of what Thanx can evaluate against a basket and it contains no allowance, overage or substitution-credit construct — nor could it, since Thanx receives the composed item price rather than composing it. Delegated to the POS. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/qualifying-baskets · retrieved 2026-09-04 adversarially verified

menu-pricing-combos

Reopened 2026-09-04 on audit. The evidence cited for 'no' is the Square direct-to-POS 'Not yet available' list, which names combos alongside card-linked loyalty registration, Thanx Universal Promo Codes, group ordering and checkout upsell — features that demonstrably exist on other Thanx stacks. Read consistently with digital-group-ordering (scored partial off this same sentence), the list implies a combo capability exists on the non-Square ordering back ends and is merely unavailable on Square. The basket schema's flat item/modifier array bounds what a partner sends Thanx after pricing, not what the Thanx-rendered ordering menu supports, so it does not license an absence finding. Nothing published describes a component swap price delta or automatic conversion of eligible a-la-carte cart items, so a positive verdict is equally unsupported. adversarially verified

menu-pricing-upsell-prompts differentiator

The Deliverect-powered ordering entry (2026-08-11) states "Smart upsells built in - guests see relevant add-ons at checkout, whether merchant-configured or AI-suggested based on order history", so a suggestive-sell rail exists in the Thanx ordering experience and can be operator-configured. Shortfalls against the claim as worded: (1) the prompt is a CHECKOUT add-on rail, and nothing published describes configuring it per ITEM; (2) it is not universal across Thanx ordering - the Square direct-to-POS entry (2026-07-10) lists "checkout upsell (static or AI-powered)" under "Not yet available" and repeats it ("Group ordering, checkout upsell, and the utensils opt-in prompt aren't currently available on Square"), so availability varies by ordering integration rather than being configurable per channel; (3) Thanx sells one channel, its own web and app ordering, and publishes nothing about POS or kiosk prompts; (4) no attach-rate reporting on upsell prompts appears in the reporting entries (Insights Lab / All Reports, digital order reports, campaign reporting), which report loyalty, revenue and campaign metrics. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

menu-pricing-86-propagation

Automatic propagation exists, one-directional and inbound. Toast multi-menu entry (2026-04-29): "Changes sync in ~5 minutes: new items, 86s, and schedule changes are all reflected in Thanx automatically", with Toast visibility "respected at every level ... across menus, categories, items, and modifiers". Deliverect entry (2026-08-11): "Items and modifiers that are 86'd can be automatically greyed out or hidden from the menu, based on the brand's setting in Deliverect ... Menu changes take a few minutes to sync from Deliverect to Thanx." Square entry (2026-07-10): "86'd items and modifiers automatically hide or grey out in the ordering experience". Thanx adds an operator display control - Settings > Ordering > 86'd Items, choosing "Display as Not Available" or "Hide Unavailable Items", effective "immediately on the next menu load" (2026-04-09). Shortfalls: (1) the 86 ACTION happens in the POS or middleware and Thanx only reflects it - Thanx does not 86 an item and cannot push one to a POS, KDS, kiosk or third-party marketplace; (2) the reach is a single surface, Thanx-built web and app ordering; (3) on Olo the item never arrives unless the merchant enables Olo's "include disabled" setting, and the display control itself was Olo- and Toast-only at launch; (4) the display setting is "global per brand. All locations share the same preference. Location-specific overrides are not supported at this time." https://thanx.launchnotes.io/announcements/toast-multi-menu-visibility-now-available · retrieved 2026-09-01

menu-pricing-countdown-auto-86 differentiator

Thanx holds no item record and no stock quantity: the item it receives carries only id ('Item ID in your system / POS'), name, price, categories and modifiers, with no quantity or availability field, and the closed 168-page reference defines no menu, catalog or inventory resource on which a par count could live. Its published behaviour is display of 86'd state arriving from Toast, Olo, Square or Deliverect, controlled by a brand-global visibility toggle with no per-location override. A decrementing countdown with scheduled auto-restore is an inventory function of the upstream system. Delegated to the POS. Grade B: absence over the published API applied to a product capability, with merchant configuration docs 401-walled. https://docs.thanx.com/loyalty/create-update-basket.md · retrieved 2026-09-04 adversarially verified

menu-pricing-dayparting

Scheduling works, and is evaluated against fulfilment time rather than browse time. Olo entry (2026-08-27): "Thanx now reads the availability rules you've already set on your items in Olo - time of day, day of week, and date ranges - and filters your Thanx ordering menu against the time the guest wants their food"; categories left empty are hidden. Toast entry (2026-04-29): multiple Toast menus including "time-of-day and day-of-week scheduling", and "if a customer orders at 9am for 11am pickup, they see the lunch menu". Square entry (2026-07-10): "time-of-day menus (breakfast, lunch, dinner) and day-of-week specials like a Taco Tuesday menu". Shortfalls: (1) the schedule is authored upstream, not in Thanx - "There's nothing to turn on in your Thanx dashboard", "All management of your menus should be done in Toast"; (2) on Olo it is not self-serve at either end - the merchant must have Olo enable "showunavailableitems" ("it isn't self-service, and it isn't something Thanx can flip or see on your behalf") and a Thanx CSM must switch it on per brand; (3) the claim's PRICE limb is unaddressed - every published schedule governs menus and item availability, never a scheduled price change; (4) "non-continuous daily hours are not available" on the Square path; (5) no statement anywhere that schedules evaluate in each location's own timezone; (6) a guest's cart is not re-validated when they change the order time ("Cart items aren't cleaned up automatically yet"). https://thanx.launchnotes.io/announcements/show-only-what-s-available-time-based-menu-visibility-for-olo · retrieved 2026-09-01

menu-pricing-channel-price-books

Channel-varying price and menu exist, on one axis. Square direct-to-POS entry (2026-07-10): supported options include "dynamic pricing by handoff mode" - a different price for pickup versus delivery - though on that same path "Pickup and Delivery draw from the same menu (no handoff-specific menus)". Deliverect entry (2026-08-11): menu flexibility "supports ... handoff-specific menus (e.g., a different menu for pickup vs. delivery)". Shortfalls: (1) the only published axis is handoff mode; there is no dine-in, kiosk or per-marketplace price book, and Thanx operates none of those channels; (2) the percentage-markup limb belongs to the upstream POS - the Toast entry answers "Can I use a price markup for DoorDash while keeping standard prices on Thanx? Yes. Toast supports per-partner price markup", i.e. Thanx is one destination of somebody else's markup rule rather than the engine that applies it; (3) no price-book configuration surface exists in the Thanx dashboard. On every documented Thanx ordering path the menu is authored upstream and imported: Square ("managing menu pricing, imagery, item availability, handoff modes, store hours ... all live in Square - one source of truth"), Deliverect ("Already use Deliverect for menu management"; "we import and validate your menu - categories, items, modifiers, and images"), Toast ("Menu management all in Toast ... All management of your menus should be done in Toast") and Olo ("One source of truth: you configure availability once in Olo"). Thanx publishes no menu-authoring surface of its own. https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

menu-pricing-dual-pricing differentiator

Two independent grounds, both from the same primary schema. Thanx stores one price per item and receives it — a single decimal 'Item amount' foreign-keyed as 'Item ID in your system / POS' — so there is nowhere to hold a cash/card price pair. And Thanx settles nothing: 'payments' is an inbound array of 'Last 4 digits of the payment method', 'Issuer', 'Amount used with the payment method' and an authorization timestamp, describing a charge made elsewhere. 'Receipt' in Thanx means a guest-uploaded loyalty receipt image, not a printed check. Absent from Thanx on both the menu and the tender side; item-level dual pricing is the POS's to configure and print. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

menu-pricing-versioning-effective-dates differentiator

There is no menu to stage, preview or roll back: no menu, item, catalog or price resource exists in the closed 168-page API census, and the only item Thanx handles is inbound and transient ('Item ID in your system / POS'). Effective-dating in Thanx applies to offers, not items — points products carry 'exchange_start_at'/'exchange_end_at' and baskets carry an order_timestamp so 'Thanx can determine if a reward will be valid in the future'. That is campaign scheduling, not menu versioning. Delegated to the POS/ordering provider that owns the catalog. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-04 adversarially verified

menu-pricing-franchise-hierarchy differentiator

A central corporate menu template with field-level override governance requires a menu object Thanx does not have; no menu, item or catalog resource exists in the closed 168-page reference. Thanx's multi-location model is data-side only: Partner API get-merchants/get-locations, a Merchant-Key per brand, and location-scoped rewards via 'Thanx Location UID — Providing this information allows Thanx to apply reward location restrictions'. Supporting but analogical: the one location-varying setting Thanx does govern runs the opposite way — the 86'd-item display preference is 'global per brand. All locations share the same preference. Location-specific overrides are not supported at this time.' Menu governance belongs to the upstream catalog. Grade B: that quote governs display, not menus, and the primary argument is an absence over the published API. https://docs.thanx.com/llms.txt · retrieved 2026-09-04 adversarially verified

menu-pricing-allergen-nutrition

Thanx stores no per-item attribute. The item it receives carries only id, name, price and 'categories that describe this item', and the closed 168-page census defines no menu or product resource on which an allergen flag or calorie count could live. The corpus's seven 'allergens' hits are confirmed false positives: each is a consumer attribute tag carrying a sibling user_id with values gluten/soy/dairy/honey, describing the guest for segmentation rather than the dish. 'calorie' 0 and 'nutrition' 0 across the docs corpus. All three limbs of the claim — per-item storage, publication to third-party menus, derivation from recipe components — belong to the POS or ordering provider that owns the catalog. Grade B: an absence over the published API bearing on a product capability. https://docs.thanx.com/loyalty/create-update-basket.md · retrieved 2026-09-04 adversarially verified

menu-pricing-recipe-linkage differentiator

Thanx's complete published data model is an enumerable list of ten entities — campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases, rewards, legacy loyalty reward progress — and it contains no product, recipe, ingredient, bill-of-materials or cost object. The purchases table records authorization_amount and settlement_amount only, with no cost or item persistence. 'theoretical' 0 and 'inventory' 0 across the docs corpus. Since Thanx does not even own the menu item, it cannot link one to a recipe or deplete theoretical stock. Absent from Thanx; this is inventory-system territory Thanx explicitly places outside itself. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/data/overview · retrieved 2026-09-04 adversarially verified

menu-pricing-3p-menu-push

Thanx cannot push a menu because it holds none and has nowhere to push it. No menu, item, catalog or product resource exists in the closed 168-page reference, and the item it handles is inbound and foreign-keyed ('Item ID in your system / POS'). Separately, Thanx connects to no marketplace: its own enumeration of connected platforms is 'Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct' — DoorDash and Uber appear only as white-label couriers — and 'Grubhub' is zero across 102 changelog entries, 124 www.thanx.com pages and the 168-page docs census. No per-item sync status or rejection-error surface for outbound menus exists; the only sync-error surface is inbound and Toast-only. Delegated to whichever POS or menu-management layer owns the catalog. Grade B. https://docs.thanx.com/llms.txt · retrieved 2026-09-04 adversarially verified

menu-pricing-dynamic-pricing

The Square direct-to-POS entry (2026-07-10) answers "What pricing and modifier options are supported?" with "Item-based pricing, size-based pricing, nested modifiers, priced modifiers, and modifier images are supported, along with dynamic pricing by handoff mode" - item price varying automatically with the fulfilment channel the guest picks, which is the channel limb of this claim. The Deliverect path carries the same idea as a menu rather than a price rule: "handoff-specific menus (e.g., a different menu for pickup vs. delivery)" (2026-08-11). Shortfalls: (1) the only rule input published is handoff mode - nothing varies price by time of day or by demand, and the day-part mechanisms Thanx documents (Toast multi-menu, Olo item availability) switch menu VISIBILITY, not price; (2) no floor or ceiling guardrail is documented anywhere in the 101 changelog entries or the 168-page docs corpus; (3) the price itself is authored in Square, not in Thanx - "pricing, imagery, availability, handoff modes, and store hours all live in Square - one source of truth for your menu". https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

payments-processor-choice differentiator

Thanx runs no payment processing of its own: card payments for Thanx Ordering are taken by whatever processor sits under the chosen ordering path. The Square direct-to-POS entry (2026-07-10) sells this as "One payment processor with Square Payments: No need to separate payment processors for in-store and online"; the Deliverect-powered ordering entry (2026-08-11) says "Guests pay by credit card through Deliverect Pay (hosted payments)" and that Deliverect "connects to more POS systems and payment processors than other ordering middleware"; and the developer Pay-at-Table guide has the merchant's own "on-premise ordering and payment systems" take the money. Shortfall: no list of supported processors or gateways is published anywhere on docs.thanx.com or www.thanx.com, and the processor is not a free merchant choice within a path - it is whatever the chosen ordering integration carries (Square Payments on Square, Deliverect Pay on Deliverect), provisioned through a Thanx CSM. https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

payments-published-rates differentiator

Retrieved www.thanx.com/pricing on 2026-09-01 (HTTP 200, 184,777 bytes) and read the extracted page text: it carries no price of any kind - no card rate, no software rate - only ROI marketing, customer quotes and a "Request a demo" lead form (first name, company email, number of locations). Thanx also sells no card processing to publish rates for: its own release notes put payments on Square Payments (2026-07-10) or Deliverect Pay (2026-08-11), i.e. the merchant's own processor. There is therefore no published card-processing price, flat or interchange-plus. https://www.thanx.com/pricing · retrieved 2026-09-01

payments-dual-pricing differentiator

Thanx is not the payment acceptor: 'Payments made through Stripe or other payment service providers (aggregators) will not trigger accrual because the transaction is processed under the provider's merchant ID rather than the merchant's own.' It therefore prints no guest check and no receipt, and it stores one price per item, inbound ('Item amount' under 'Item ID in your system / POS'), so it cannot hold a cash/card pair either. Both halves of the claim fail on Thanx's own architecture rather than on silence. Absent from Thanx; dual pricing is the POS's to store and the processor's to charge. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/overview/guides/pay-at-table · retrieved 2026-09-04 adversarially verified

payments-surcharge-guardrails differentiator

Thanx provides no surcharging engine and structurally cannot: it does not authorize card transactions, it observes them. Its purchase record is of 'purchases made by your customers that have been detected by the Thanx platform', with settlement_amount defined in the third person as what the issuing bank 'transfers from the cardholder's account to the payment processor'. The record carries no BIN, card product code, debit/credit flag or fee field, and 'surcharge' is 0 across both the 728 KB docs corpus and the 124-page site corpus including all 18 contracts. Counterargument considered and recorded: a Thanx dashboard might expose a per-location toggle over Stripe's or Square's engine, but the claim's subject is the engine's BIN exclusion and cap enforcement, which is the processor's; Thanx supplies none of it. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-04 adversarially verified

payments-emv-nfc

No first-party terminals; card-linking rides the operator's existing acquirer.

payments-softpos-tap-to-pay differentiator

Thanx accepts no card payment on any device. Its docs treat payment acceptance as external by positive statement — POST /purchases is 'the only way to create a sandbox purchase without going through a live POS or payment processor' — and the closed 168-page census contains no charge, capture, authorize, void or refund endpoint; the sole payment construct is an inbound description of a charge taken elsewhere (issuer, last4, amount, authorized_at). 'Tap to Pay', 'NFC', 'contactless' and 'card reader' are 0 across the marketing corpus and Thanx ships no hardware. Card-present acceptance belongs to Square Payments, Stripe or Deliverect Pay. Grade A: rests on a positive documented statement about where acceptance occurs. https://docs.thanx.com/overview/sandbox-faq · retrieved 2026-09-04 adversarially verified

payments-pay-at-table

Thanx ships no payment hardware. Its own Pay-at-Table developer guide describes the complete flow and it is guest-phone only: "The guest scans a QR code placed on their table", is taken to a digital checkout, and "completes payment from their mobile device", the guide's stated job being to connect "your on-premise ordering and payment systems with the Thanx loyalty platform" - the payment system is the integrator's. The merchant-facing route has the same shape: the 2026-04-07 announcement adds Thanx loyalty to Sunday's QR pay-at-table checkout for brands running Toast, NCR or Micros/Oracle POS. No handheld, no tip prompt on a Thanx device and no device-side check splitting appears in the 168 documentation pages or the 101 release notes. https://docs.thanx.com/overview/guides/pay-at-table · retrieved 2026-09-01

payments-qr-guest-pay differentiator

The flow exists but Thanx supplies only the loyalty half of it. The 2026-04-07 Sunday announcement: the guest "scans QR code at their table and lands in Sunday's checkout experience", authenticates by SMS, "sees their check, current points balance, and any available reward", applies a reward "then pays", and "Points are automatically recorded in Thanx"; guests may "split by items or split in half". The developer guide at docs.thanx.com/overview/guides/pay-at-table documents the same pattern for a partner building it directly on the Consumer and Loyalty APIs. Shortfalls: the QR checkout, the card capture and the closing of the check belong to the third party (Sunday's pay-at-table product, or the integrator's own on-premise payment system), not to Thanx; the Sunday route is limited to brands on Toast, NCR or Micros/Oracle, and on NCR and Micros/Oracle "guests can only enroll into loyalty"; and only "get $ off entire purchase" rewards surface in that checkout. https://thanx.launchnotes.io/announcements/thanx-now-integrates-with-sunday-guests-earn-and-redeem-rewards-at-the-table · retrieved 2026-09-01

payments-tip-adjust

Genuinely absent, not delegated — Thanx designs tips out of its model by explicit instruction. The basket guide tells partners 'Include tax; exclude tips.' and 'Do not send the order's grand total (which includes tips).'; the basket subtotal is defined as 'before taxes & tips'; and the guide's common-mistakes table lists 'payments[].amount includes tips' as an error to be corrected by computing 'subtotal + tax - discounts'. 'gratuity' is 0 across the 728 KB docs corpus and the purchases data model has no tip column. A pre-auth-then-adjust flow is an authorization operation Thanx never performs — it holds no charge, capture or void endpoint and receives only an 'authorized_at' timestamp for a charge taken elsewhere — and no unadjusted-tips manager screen can exist because no tip records exist. Grade A: the verdict rests on positive documented instructions, not on an absence. https://docs.thanx.com/loyalty/create-update-basket.md · retrieved 2026-09-04 adversarially verified

payments-tip-pooling differentiator

Thanx has no tip allocation engine; it tags orders so that someone else's does the work. The 2026-08-14 "Toast Revenue Centers" release exists so that "tip distribution runs without manual cleanup", and states the mechanism plainly: "Tip-distribution platforms like Tip Haus read the Revenue Center on each order to route tips correctly. With one configured, tipped Thanx orders route automatically instead of being corrected order by order." Distribution is thus performed by a third-party tip platform reading Toast. Consistently, the Loyalty API is instructed to exclude tips from basket amounts and the purchase data model carries no tip field, so Thanx holds no per-employee tip data to allocate or export to payroll - it models no employees at all. https://thanx.launchnotes.io/announcements/toast-revenue-centers · retrieved 2026-09-01

payments-offline-store-and-forward differentiator

Thanx never captures a card, online or offline, so it cannot store and forward one. Its own docs place acceptance outside the platform positively: POST /purchases is 'the only way to create a sandbox purchase without going through a live POS or payment processor', and the basket payment object is an inbound description of a charge someone else took (issuer, last4, amount, authorized_at). No charge, capture, authorize, void or refund endpoint exists in the closed 168-page census. The platform is a synchronous hosted API with explicitly no durability guarantees of its own: webhook receivers must 'respond to requests within 15 seconds', 'webhooks are not configured to retry', and 'delivery of any single event is not guaranteed'. 'offline' is 0 in the docs corpus. Store-and-forward with per-transaction and cumulative limits is the card acceptor's function. Grade A: the verdict follows deductively from a positive documented statement, not from silence. https://docs.thanx.com/overview/sandbox-faq · retrieved 2026-09-04 adversarially verified

payments-offline-decline-liability differentiator

Resolved 2026-09-02 against the complete public Thanx surface, which is now enumerated on every axis: the 168 pages of docs.thanx.com (identically listed by /llms.txt and /sitemap.xml), the 101 dated thanx.launchnotes.io entries, the 12 dated www.thanx.com/releases/ posts (drained to a fixpoint by link-crawl, with fabricated slugs returning the 131,509-byte 404 control), the 19 www.thanx.com/help-center/ pages, and - newly read - the whole Thanx contract set that the vendor's own index at www.thanx.com/additionalterms010125va and its sitemap enumerate: the Merchant Agreement effective 2.20.26, the 2024 terms, the API Addendum, the Data Processing Addendum, the Merchant Reward Opportunity Terms, the Delivery Services Terms and the Toast Ordering Integration Addendum. Nothing in any of them allocates the loss on a declined stored transaction, and the string "offline" appears exactly once in the entire corpus, in the 2024 terms, about an SMS signup prompt "displayed online or offline". The Merchant Agreement instead disclaims the whole area: section 12.2 disclaims "ANY AND ALL LIABILITY FOR THE ACTS, OMISSIONS AND CONDUCT OF ANY THIRD PARTIES, INCLUDING ... THIRD PARTY CREDIT CARD NETWORKS", and section 7's Fees article is subscription invoicing only. Thanx is not the party capturing the card - the Toast Ordering Integration Addendum puts processing with Stripe under a merchant-held Stripe Connected Account, the Square path on Square Payments and the Deliverect path on Deliverect Pay - so there is no Thanx-side offline decline to allocate, and no post-reconnect report of failed offline payments appears anywhere on the published surface. Scored as a no on the claim as worded, which asks whether the vendor PUBLICLY DOCUMENTS this: it demonstrably does not, across a surface enumerated by the vendor's own manifests. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-02

payments-gift-cards

API docs describe stored gift cards with real-time balance tracking — the platform 'fetches the current balance' whenever card details are requested — but Thanx 'integrates with external gift card providers to manage card validation and balance checking', and the merchant gift-card configuration exposes an external purchase link rather than native issuance. Shortfall: cards are third-party-provider-issued (e.g. the Yiftee partnership), not first-party, and cross-location and online-ordering redemption depend on the external provider. https://docs.thanx.com/consumer/gift-cards/overview.md · retrieved 2026-08-04

payments-house-accounts

Genuinely absent rather than delegated, and the delegation argument does not apply here: the guest account is the object Thanx does own, and it has no credit limit, running balance or statement facility. Its two stored-value surfaces are enumerable and both are prepaid or non-monetary — points accounts and points transactions in the data model, and a gift-card wallet holding no ledger of its own ('Balance information is fetched in real-time from gift card providers to ensure accuracy'; states are only active/archived). 'house account', 'on account' and 'credit limit' are zero across the 124-page site corpus and all 18 contracts, and the reward terms run the other way ('Points shall have no cash value'). No A/R or periodic-invoice artifact exists anywhere in Thanx. Grade B: the account object's completeness is established by enumeration over the published API. https://docs.thanx.com/llms.txt · retrieved 2026-09-04 adversarially verified

payments-split-tender

Thanx Ordering does settle one order with more than one tender, but under hard caps well below eight and with no splitting of a check. Square path (2026-07-10 entry): "A guest can pay with one gift card and cover the remainder with one credit card; splitting across multiple gift cards or credit cards isn't supported", and "Pay with cash or in-store, and splitting a payment across multiple cards or multiple gift cards are not available." Deliverect path (2026-08-11 entry): "Split-payment support includes up to 3 gift cards that can be applied in addition to a credit card." Shortfalls: a maximum of two tenders on Square and four on Deliverect, one credit card in either case, and no by-seat, by-item, by-even-share or by-arbitrary-amount splitting in Thanx's own checkout - where splitting exists at the table it is the partner's (Sunday, 2026-04-07: "Guests can split by items or split in half"). https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

payments-refund-void-controls

Positive absence by enumeration of the product's entire public surface, on the same basis as labor-granular-rbac and labor-manager-override-audit: the complete docs.thanx.com index (llms.txt: consumer/partner/loyalty APIs, webhooks, data exports), the platform and digital-ordering product pages, and the consumer-only help centre contain no register, terminal or drawer function. The controls this claim describes — manager-PIN authorization of voids, refunds, discounts and no-sales, written to an approver-identified audit log — are register workflows, and Thanx has no register: those transactions occur on the operator's separate POS (Toast, Square, Olo integrations). A no-sale drawer event cannot exist in a product with no cash drawer. Refunds of Thanx first-party digital orders presumably happen somewhere operationally, but no role-gated approval or audit-log surface for them is documented anywhere public.

payments-chargeback-tooling differentiator

Thanx holds no dispute data and no transaction record from which evidence could be assembled. Its purchase row is a closed 18-column enumeration — ids, location fields, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider — with no dispute, chargeback, reason-code, fee or line-item column; baskets are transient; and the webhook event list (purchases, reward-issued, reward-batch-completed, communication-settings, sms-subscriptions) is a real enumeration containing no dispute event. 'chargeback' 0 and 'dispute' 1 across the 728 KB docs corpus. The Toast addendum allocates the function away: 'Payment refunds and disputes shall be handled by Stripe in accordance with its published dispute and refund policies'. Counterargument recorded: a dashboard merely LISTING processor disputes would be consistent with that contract, but the claim requires evidence submission assembled from the transaction record, which Thanx does not hold. Grade B: contract text is B under the evidence rules and the remainder is API enumeration. https://docs.thanx.com/llms.txt · retrieved 2026-09-04 adversarially verified

payments-card-on-file differentiator

Saved cards exist in the Thanx ordering checkout, but the vault and the reuse boundary belong to the payment partner. The 2026-08-11 Deliverect-powered ordering entry states "Guests pay by credit card through Deliverect Pay (hosted payments). Keep in mind that Deliverect's tokenization requires CVV re-entry on saved cards" - so cards are tokenized against the guest profile and the merchant never holds the PAN. The 2026-07-10 Square entry likewise supports "gift cards stored on file (currently Valutec, with more providers planned)". Shortfalls: the tokenization is the ordering/payment partner's rather than Thanx's, so a token does not travel across ordering paths; saved cards still require CVV re-entry on the Deliverect path; and no reuse for phone orders or in-store is documented, since in-store payment runs on the merchant's POS. The only card Thanx itself stores is a card-link enrolment (docs.thanx.com/consumer/cards/create-card, vaulted by Basis Theory and enrolled with Visa/Mastercard/Amex) used to detect purchases for points, never to charge. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

payments-payout-timing differentiator

Resolved 2026-09-02 from the Thanx contract set, a first-party surface no earlier pass had read, enumerated by www.thanx.com/sitemap.xml and fetched HTTP 200 at 150-182 KB against a 404 control of 131,509 bytes. The governing Merchant Agreement effective 2.20.26 has a complete Fees article (7.1 Invoices; Payment, 7.2 Taxes, 7.3 Late Payments, 7.4 Suspension, 7.5 Third-Party Services Fees) that runs in the opposite direction to a deposit schedule: "Thanx will invoice Merchant, and Merchant shall pay, for all Fees pursuant to the terms of the Order Form", with suspension for invoices "more than thirty (30) days past due". Thanx never holds the merchant's card receipts, so it has no deposits to schedule or accelerate: the Toast Ordering Integration Addendum states "Payment processing services for Merchants through the Toast Integration are provided by Stripe, Inc." and requires the merchant to "establish and maintain a Stripe Connected Account", with orders "processed by Stripe, subject to Stripe's deduction of its payment processing fee"; the Square path runs on Square Payments (2026-07-10 release) and the Deliverect path on Deliverect Pay (2026-08-11). Funding timing on every documented path is the merchant's own processor's, under the merchant's own processor agreement. No deposit schedule and no next-day or instant-funding option is published by Thanx, and the contracts show there is none to publish. Consistent with this record's existing no on payments-published-rates. https://www.thanx.com/toia062822va · retrieved 2026-09-02

payments-multi-entity-routing differentiator

Thanx moves no funds, so it routes none. settlement_amount is defined as an observed third-party movement — 'The purchase amount the issuing bank transfers from the cardholder's account to the payment processor, who then transfers the money to the acquiring bank' — and no bank-account, payout, MID-mapping or settlement-destination field exists anywhere in the closed 168-page census ('payout' 0, 'bank account' 0, 'split settlement' 0 across the site corpus and all 18 contracts). Where MIDs appear it is for matching, not depositing: 'merchant location MIDs must be onboarded within Thanx to guarantee points accrual'. Thanx's multi-entity model is real but data-side only (get-merchants/get-locations, per-brand Merchant-Key, location-scoped reporting). Absent from Thanx; settlement routing is a property of the merchant's own Stripe/Square/Deliverect account, and the Toast addendum requires the merchant to hold that Stripe Connected Account itself. Grade B on the 2026-09-04 audit ruling: this is an absence over the published API reference bearing on a product capability, and Thanx's merchant-facing configuration docs remain behind a 401 wall at help.thanx.com, so grade A is reserved for verdicts entailed by a positive documented statement. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-04 adversarially verified

payments-p2pe-pci4

Thanx publishes a compliance assertion earlier passes missed while probing www.thanx.com/security (HTTP 404) and /faqs: the Thanx Data Platform section of www.thanx.com/open-platform-apis states 'Enterprise-grade security and compliance - SOC 2 Type 2 and PCI DSS Level 1 certified, with continuous monitoring to protect your guest data' and 'Built on cloud-native infrastructure with SOC 2 Type 2 and PCI DSS Level 1 compliance', and the same pair appears on the home page, /enterprise-loyalty-program-management-software and /growth-brands as 'SOC 2 Type II certified, PCI DSS Level 1 Service Provider'. A Level 1 service provider is assessed annually by a QSA and that assessment produces an Attestation of Compliance, so the AoC half of the claim has a first-party basis. Two shortfalls, both material as the claim is worded: (1) NO POINT-TO-POINT ENCRYPTION is offered or even claimed - 'P2PE' and 'point-to-point' occur zero times across the 124-page www.thanx.com corpus, the 168-page docs.thanx.com dump and the 101 changelog entries, and card capture belongs to Stripe on the Toast path (www.thanx.com/toia062822va: 'Payment processing services for Merchants through the Toast Integration are provided by Stripe, Inc.'), to Square Payments and to Deliverect Pay, so Thanx is not a P2PE solution provider; (2) no DSS VERSION is published and nothing states an AoC is furnished to merchants on request - the only audit clause in the 18-page contract set is the DPA's (www.thanx.com/dpa01012025va, 'Thanx will make available to Merchant at Merchant's request reasonable information which is necessary to demonstrate compliance with this DPA'), which is data protection, not PCI. Graded C because the assertion sits on vendor product pages; help.thanx.com remains 401-walled, so a merchant-facing security page could say more. https://www.thanx.com/open-platform-apis · retrieved 2026-09-02

delivery-driver-roster

Migrated from the 2026-08-01 research pass; no source URL was recorded.

delivery-dispatch-board

Migrated from the 2026-08-01 research pass; no source URL was recorded.

delivery-route-map differentiator

Thanx brokers couriers and runs no dispatch of its own. Its Deliverect-powered ordering release (11 Aug 2026) states verbatim: 'Does Thanx process the delivery courier's orders and invoices? No. Deliverect Dispatch selects and manages the courier (e.g., Uber or DoorDash). Thanx doesn't choose the courier or process its orders/invoices - that stays between you and Deliverect.' The published contract agrees: www.thanx.com/deliveryservices08222023vc is four sentences whole - 'Thanx-managed delivery services are powered by Doordash. Thanx charges $7.99 per delivery... Thanx integrates with delivery partners such as Olo Dispatch and Vromo.' Every published mode is a courier network or a third-party dispatch platform, so there is no multi-stop run inside Thanx to sequence. The June 2026 Operations Center release enumerates the complete operator tool set - Locations, POS Configuration, Delivery & Location Settings, Ordering Error Report, Alert Banner, End User Support Report - and contains no dispatch screen or map. https://thanx.launchnotes.io/announcements/ann_lSNOxJpjiq6GK · retrieved 2026-09-04

delivery-driver-tracking differentiator

What Thanx surfaces from couriers is a stage model, not a position. Live Updates (22 Jul 2026): 'your guests will see a live status tracker on their home screen - order placed, preparing, ready, picked up or delivered', and 'Thanx will standardize the experience across all providers and will give you the option to implement manual timers between stages'. Provider FAQ: 'Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct. The level of detail guests see depends on what each provider sends us - some give us exact prep stages, others give us time-based estimates.' Offering manual timers as a substitute for provider signal is the opposite of GPS. Thanx also has no driver-facing app to capture position from - it sells no driver software - and 'driver' occurs zero times across 102 changelog entries and exactly once in the closed 728 KB / 168-page docs census, where it means MongoDB Atlas drivers. https://thanx.launchnotes.io/announcements/ann_A1cFC3ph4X8ES · retrieved 2026-09-04

delivery-zones-polygon differentiator

The April 2026 Settings release enumerates every ordering and loyalty control in the Thanx dashboard, and the entire delivery-geometry surface is one routing default: 'Delivery defaults: Define how delivery orders are routed. Require customers to order from the nearest eligible location, or give them the flexibility to order from any store.' The June 2026 Operations Center release confirms the page has only three sections - 'Delivery & Location Settings - A single page combining your Delivery Default, Location Selection, and Ordering Configuration (read-only reference) settings.' No polygon, radius, ZIP-list or isochrone control appears in either enumeration, and the June 2025 nearest-store release treats zones as something the brand holds elsewhere ('especially helpful for brands with strict delivery zones'). This is what closes the objection prior passes raised: the dashboard settings surface is published in the changelog, not only behind the help-centre login. https://thanx.launchnotes.io/announcements/ann_VukuVzMEtQHnS · retrieved 2026-09-04

delivery-zone-pricing

The delivery fee a guest sees is quoted per order by the courier, not read off a Thanx zone table: 'Delivery handled for you, with pricing upfront - Deliverect Dispatch selects the courier (Uber, DoorDash, and others) and guests see a live delivery quote - availability, price, and ETA - right at checkout.' Thanx's own published delivery price is flat and unzoned - www.thanx.com/deliveryservices08222023vc, 'Thanx charges $7.99 per delivery', with no band, distance, minimum or promise-time term in the whole document. The April 2026 Settings release, which enumerates every dashboard ordering control, contains no per-zone fee, order minimum or quoted-promise-time field; quote times are a partner function in Thanx's own directory (www.thanx.com/partners/curbit, filed under its 'Dynamic Quote Times' department). https://thanx.launchnotes.io/announcements/ann_lSNOxJpjiq6GK · retrieved 2026-09-04

delivery-address-validation

Thanx's own dated release (2025-06-19): 'We've enhanced the delivery checkout experience with address autocompletion. Customers now see smart, real-time suggestions as they type - making it faster and easier to enter a valid, properly formatted address ... This update helps eliminate issues caused by incomplete or incorrect addresses (e.g., missing unit numbers), which can lead to failed deliveries.' The companion release the next day (thanx.launchnotes.io/announcements/default-delivery-logic-2, 2025-06-20) resolves that address against the estate: guests are 'automatically assigned to the closest delivery-capable location based on their address', or may be allowed to 'select any delivery-enabled store'. So an address IS structured and matched to a serving location at order time. Shortfall, and it is the second half of the claim: neither entry names a mapping/geocoding service, and nothing published says an OUT-OF-ZONE address is rejected or flagged before the order is accepted - eligibility is expressed only as which locations are 'delivery-capable', and on every documented path (Olo, Toast, Deliverect, Square) the zone itself is owned by the ordering provider, not by Thanx. The merchant help centre that would settle it is SSO-walled (help.thanx.com Help Center API returns 401). https://thanx.launchnotes.io/announcements/address-autocompletion-for-ordering-2 · retrieved 2026-09-01

delivery-driver-comp differentiator

Thanx's published Delivery Services terms (version effective 8-16-2023, incorporated into the Merchant Agreement effective 2.20.26 by section 7.5.2) define the entirety of its delivery offering: "Thanx supports, and Merchant may elect to offer, food delivery via third-parties for orders initiated on Merchant's Thanx ordering experience. Thanx-managed delivery services are powered by Doordash. Thanx charges $7.99 per delivery. This rate is subject to change. Thanx integrates with delivery partners such as Olo Dispatch and Vromo. Thanx does not charge for deliveries managed by these services, though these additional services have separate fees charged to Merchant directly by such delivery partners." Both published modes are third-party courier networks, so there is no Thanx-dispatched driver whose mileage, per-delivery reimbursement or retained tips Thanx could track, and the courier's economics are explicitly not Thanx's - the help-centre Deliverect guide states "Deliverect selects and manages the courier (Uber, DoorDash, and similar) based on your configuration" and "Thanx doesn't choose the courier or process courier invoices". Thanx's own partner directory places in-house delivery management outside the product, with Cartwheel (www.thanx.com/partners/cartwheel) sold as the "enterprise-grade delivery management platform ... to optimize both in-house and third-party delivery operations". Nor is there a wage surface for a payroll export to feed: Thanx employs no one on the restaurant's behalf and 'payroll', 'mileage' and 'reimbursement' appear in none of the 18 published contract documents, the 168-page docs corpus, the 101 changelog entries, the 12 release posts or the 19 help-centre pages. https://www.thanx.com/deliveryservices08222023vc · retrieved 2026-09-02

delivery-cash-reconcile

The claim presumes a driver Thanx dispatches and a cash tender Thanx sees, and the published contract set excludes both. Thanx's Delivery Services terms (effective 8-16-2023, incorporated into the Merchant Agreement effective 2.20.26 at section 7.5.2) state that "Thanx supports, and Merchant may elect to offer, food delivery via third-parties", with Thanx-managed delivery "powered by Doordash" at "$7.99 per delivery" and the alternative being integrations with "delivery partners such as Olo Dispatch and Vromo" - every courier is a third party's, so no driver banks cash with the operator through Thanx and no per-driver over/short figure can arise. Payment likewise never lands with Thanx: the help-centre Deliverect guide says "Payments flow through Deliverect Pay, a hosted payment experience, with the resulting payment attached to the order at checkout", the Square path settles through Square Payments, and the changelog lists pay-in-store / pay-on-arrival as not supported, so the ordering channel takes no cash tender at all. 'Cash', 'settle up', 'over/short' and 'drawer' occur zero times in the 18 published contract documents, the 12 release posts and the 19 help-centre pages. https://www.thanx.com/deliveryservices08222023vc · retrieved 2026-09-02

delivery-daas-dispatch

Thanx's dated release for the Deliverect ordering path (2026-08-11): 'Delivery handled for you, with pricing upfront - Deliverect Dispatch selects the courier (Uber, DoorDash, and others) and guests see a live delivery quote - availability, price, and ETA - right at checkout', with guests choosing 'pickup, delivery, or curbside' in the Thanx experience. The Square path is the same shape: 'Guests may choose pickup or delivery (via DoorDash or Uber Direct)' and 'Only Pickup and third-party Delivery (DoorDash, Uber Direct) are available' (2026-07-10 thanx-and-square-direct-to-pos-ordering). Courier state returns into the order record: Live Updates works with 'Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct', driving guest-visible 'out for delivery' and 'picked up/delivered' stages (2026-07-22 and 2026-08-24 entries). Shortfall, and it is what the claim's word 'natively' asks about: the courier connection is not Thanx's. The same Deliverect release answers 'Does Thanx process the delivery courier's orders and invoices? No. Deliverect Dispatch selects and manages the courier (e.g., Uber or DoorDash). Thanx doesn't choose the courier or process its orders/invoices - that stays between you and Deliverect.' Thanx is the ordering front end; the DaaS relationship, the quote and the invoices belong to the middleware or POS (Deliverect, Olo Dispatch, Square). https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

delivery-daas-fallback differentiator

Hybrid dispatch presupposes an in-house driver pool to overflow FROM, and Thanx's published Delivery Services terms (effective 8-16-2023, incorporated into the Merchant Agreement effective 2.20.26 at section 7.5.2) enumerate its delivery modes and neither is in-house: "Thanx supports, and Merchant may elect to offer, food delivery via third-parties for orders initiated on Merchant's Thanx ordering experience. Thanx-managed delivery services are powered by Doordash. Thanx charges $7.99 per delivery ... Thanx integrates with delivery partners such as Olo Dispatch and Vromo." DaaS is not the fallback path here, it is the only path. Courier selection is also explicitly somebody else's: the help-centre Deliverect guide says "For delivery orders, Deliverect selects and manages the courier (Uber, DoorDash, and similar) based on your configuration" and "Thanx doesn't choose the courier". Consistent with that, Thanx sells in-house delivery management as a partner's product rather than its own (www.thanx.com/partners/cartwheel, "optimize both in-house and third-party delivery operations"), and 'overflow', 'fallback' and 'wait threshold' occur zero times in the 18 contract documents, the 168-page docs corpus, the 101 changelog entries, the 12 release posts and the 19 help-centre pages. https://www.thanx.com/deliveryservices08222023vc · retrieved 2026-09-02

delivery-3p-direct-integration differentiator

Thanx's own enumeration of the platforms it connects to names no marketplace: 'Which ordering and delivery providers does this work with? Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct.' DoorDash and Uber appear there only as DaaS couriers; 'Grubhub' occurs zero times across 102 changelog entries and all 124 www.thanx.com pages. The marketing enumeration matches - www.thanx.com/digital-experiences, 'Native integrations with Toast, Olo, Square, Deliverect and Qu power a restaurant online ordering system' - and the same page's FAQ casts marketplaces as the thing to move away from ('charge 15-30% commission per order and own the customer relationship'). The Merchant Agreement effective 2.20.26 closes the Services exhaustively at section 1.11: 'the Thanx Platform, Branded App, Web Ordering, and Thanx API'. https://www.thanx.com/digital-experiences · retrieved 2026-09-04 adversarially verified

delivery-3p-injection

Thanx has no marketplace channel to inject from, and the only order flow it documents runs the other way - out of its own guest experience and into the POS: 'Guests order on a Thanx powered web, mobile or app ordering experience... After checkout, guests see "Order submitted" if the restaurant doesn't confirm within 5 seconds. Confirmation can take up to 10 minutes.' Thanx is also not the POS; its orders land in Toast, Square, Olo, Deliverect or Qu. Nothing across the closed 168-page docs census, 102 changelog entries, 124 site pages or the 18 published contracts describes a DoorDash, Uber Eats or Grubhub ticket arriving through Thanx, and marketplace order injection appears in the corpus only as a partner's product (www.thanx.com/partners/onosys). https://thanx.launchnotes.io/announcements/ann_lSNOxJpjiq6GK · retrieved 2026-09-04

delivery-menu-push

Thanx consumes menus, it does not publish them. Square direct-to-POS (10 Jul 2026): 'managing menu pricing, imagery, item availability, handoff modes, store hours, and operational config in a single source of truth... pricing, imagery, availability, handoff modes, and store hours all live in Square - one source of truth for your menu.' Olo (27 Aug 2026): 'One source of truth: you configure availability once in Olo. The Thanx ordering experience follows it.' Deliverect (11 Aug 2026): 'Menu changes take a few minutes to sync from Deliverect to Thanx.' The April 2026 Settings release describes Thanx's own menu screen as a read-only mirror: 'Ordering configuration: See exactly what ordering parameters like menu item images, category order, and pricing you can configure directly with your ordering provider and have Thanx honor automatically.' There is no Thanx master menu, and no marketplace connection to publish one to. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

delivery-86-sync

Thanx receives 86 state and controls only how it renders in its own guest menu: '86ed item visibility control: Brands can now choose how 86ed (out-of-stock) items and modifiers appear on customer-facing online ordering menus. The display options include grayed out items or items completely hidden from view.' The inbound direction is stated per stack - Deliverect: 'Items and modifiers that are 86'd can be automatically greyed out or hidden from the menu, based on the brand's setting in Deliverect'; Square: 'Thanx validates each order against your live Square menu, pricing, and availability'. Nothing pushes item or item-option availability OUT of Thanx, and Thanx holds no marketplace connection to push it to, so the DoorDash certification requirement the claim cites does not bear on this vendor. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

delivery-store-pause

The claim asks for pausing each connected third-party marketplace from inside the product with timed auto-reactivation. Thanx connects to no marketplace — its own enumeration is 'Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct', with DoorDash and Uber as couriers only and Grubhub at zero across all corpora — so there is nothing to pause. The only ordering on/off control Thanx publishes governs its own channel, is Toast-only, and carries no timer: Operations Center (23 Jun 2026), 'Locations... For Toast merchants only, see also ordering status for locations, upcoming schedule overrides, enabled menus and the ability to disable ordering at locations.' Store status otherwise appears only as a Deliverect field Thanx reads. Note on the Operations Center release: it inventories the contents of that one dashboard tab, not the whole dashboard, and is treated here as corroboration rather than as the load-bearing enumeration. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

delivery-3p-reconciliation differentiator

An explicit published vendor denial, verified verbatim: 'Does Thanx process the delivery courier's orders and invoices? No. Deliverect Dispatch selects and manages the courier (e.g., Uber or DoorDash). Thanx doesn't choose the courier or process its orders/invoices — that stays between you and Deliverect.' Scope note: that denial concerns the courier's orders and invoices on the Deliverect stack, and is adjacent to rather than identical with the claim's marketplace-payout reconciliation. The verdict is carried by three things together — that denial, the absence of any marketplace channel whose deposits could be matched to sales (connected platforms are Toast, Olo, Deliverect, Square plus DoorDash Drive and Uber Direct as couriers; Grubhub zero everywhere), and the fact that Thanx processes no payments. www.thanx.com/restaurant-reporting-software organises its '100+' reports as system health, strategic insights, measured outcomes and program integrity and names no settlement, payout, commission, marketing-fee or missing-order report; 'commission' and 'payout' occur zero times in the 18 published contracts. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

delivery-injection-error-visibility differentiator

Thanx's dated release for the Operations Center (2026-06-23) puts failure visibility in a named operator screen: 'Ordering Error Report - Review unaccepted carts and ordering errors across your locations', alongside 'POS Configurations - For Toast merchants only ... See menu errors and notices in this view. Menu errors are grouped by menu, not by location', and a Locations view that, for Toast merchants, shows 'ordering status for locations, upcoming schedule overrides, enabled menus and the ability to disable ordering at locations'. Access is location-scoped with view-vs-edit permissions. Injection failure is also surfaced to the guest rather than swallowed: on the Deliverect path 'Status updates to Order placed successfully or We couldn't confirm your order. If an order is rejected, the guest gets an email and can tap Retry This Order' (2026-08-11). Shortfalls: this covers Thanx's OWN first-party ordering pipeline, not third-party marketplace channels (no per-channel connection-status indicator is published anywhere); the menu-error and location ordering-status views are Toast-only; and no proactive alerting to the operator on failure is documented - the Alert Banner in the same screen is a guest-facing message the operator writes, not a failure alert. The merchant help centre that would settle the alerting question is SSO-walled (help.thanx.com Help Center API returns 401). https://thanx.launchnotes.io/announcements/new-in-dashboard-operations-center · retrieved 2026-09-01

delivery-tracking-page

Live Updates shipped 2026-08-24: 'From the moment an order is placed, your guests will now see a live order tracker in your app and on the web showing that their order has been confirmed', with 'Preparing, ready, out for delivery, and picked up/delivered ... configurable today so that you can decide how much of the order journey your guests will follow' and the full stage set enabled 2026-09-02; 'Delivery and order cancellation updates are on by default.' The announcement release (2026-07-22) names the providers that feed it - 'Toast, Olo (including Olo Dispatch), Deliverect, and Square, plus delivery via DoorDash Drive and Uber Direct' - and adds per-step push notifications with operator-customisable copy. The surface is the brand's own app and web ordering experience, not a marketplace app. Shortfalls: (1) it is ORDER state, not driver state - no driver location or map is published anywhere, and Thanx notes 'The detail guests see (exact prep stages vs. estimated times) depends on what your ordering provider sends Thanx', with manual timers offered as a substitute where the provider sends nothing, so 'driven by real order and driver state' is only partly met; (2) delivery is by push notification and in-app tracker, with no SMS link documented; (3) 'the restaurant's own domain' is not universally satisfied - on the Deliverect path a 'custom web ordering domain' is listed as coming soon, not shipped (2026-08-11). https://thanx.launchnotes.io/announcements/it-s-here-live-updates-real-time-order-status-and-tracking · retrieved 2026-09-01

delivery-promise-time differentiator

Two dated releases show a dynamic, not fixed, quote. Toast path (2025-06-24): 'Customers using Toast Integrated Ordering can now throttle orders via Toast Quote Times. Thanx will respect all of Toast's supported Quote Time strategies including: Manual, Order price, Kitchen Capacity, SmartQuote' - i.e. the promise time varies with kitchen load. Deliverect path (2026-08-11): 'guests see a live delivery quote - availability, price, and ETA - right at checkout', and 'Time slots are generated from your store's opening hours in Deliverect, adjusted for prep time. A store that's open or busy accepts orders (busy just adds a prep delay).' Shortfalls: the number is computed upstream and honoured by Thanx, not produced by Thanx - the courier ETA belongs to Deliverect Dispatch ('Thanx doesn't choose the courier') and the quote strategy to Toast, where 'Kitchen Capacity and SmartQuote strategies are in a limited release with Toast'; no driver-availability or zone drive-time input is documented on any path; and on the Square path Thanx states 'order throttling isn't available' at all (2026-07-10), so the capability is not uniform across paths. https://thanx.launchnotes.io/announcements/toast-quote-times-1 · retrieved 2026-09-01

delivery-offline-behavior

The one outage statement Thanx publishes says ordering simply stops: 'the Thanx platform (dashboard + all guest-facing web and app experiences) will be down for scheduled maintenance... you won't be able to receive orders for ~1 hour, so we recommend planning accordingly... online ordering and in-store loyalty via POS will be unavailable during this time.' There is no degraded-mode document: 'offline', 'outage' and 'internet' occur zero times across the closed 168-page / 728 KB docs census, 102 changelog entries, 124 www.thanx.com pages and the 18 published contracts, and the Merchant Agreement effective 2.20.26 has no service-level article. Structurally Thanx has nothing to document here either - it assigns no drivers and settles none ('Thanx doesn't choose the courier or process its orders/invoices'). The claim asks whether the vendor documents this; it does not. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

digital-first-party-web

Digital ordering product page: 'Choose our best-in-class white-label food ordering system, or build your own custom experience using Thanx APIs', with 'Native integrations with Toast, Olo, Square, Deliverect and Qu power a restaurant online ordering system that captures 100% of digital transactions and syncs seamlessly with your existing tech stack' - branded first-party web and app ordering writing into the operator's own POS. Commission-free by contrast rather than by statement: the same page's FAQ frames third-party marketplaces as charging '15-30% commission per order' and the platform FAQ counts 'reduced third-party commissions (as you shift sales to owned channels)' as Thanx savings, while /pricing prices the platform on restaurant count and AUV. No per-order commission is published anywhere; none is disclaimed either. https://www.thanx.com/digital-experiences · retrieved 2026-08-08

digital-menu-single-source

Thanx's own announcement (linked from thanx.com/press as its release, 2026-07-07) describes exactly this architecture for the direct-to-Square path: 'Thanx connects directly to the Square POS, eliminating middleware entirely. Orders and core catalog data sync from Square to the Thanx ordering experience, reducing the operational overhead of maintaining a separate ordering system. A single source of truth in Square reduces errors and simplifies operations'; and 'restaurants retain full operational control: managing core menu, pricing, imagery, availability, handoff modes, store hours, and delivery integrations with Uber and DoorDash directly through Square, with changes propagating in real time to the digital ordering experience.' Shortfalls, both material: (1) this is the Square integration only - the same release says 'For brands that prefer a middleware approach, Thanx also supports multiple providers' and 'Thanx also supports ordering integrations with Toast, Olo, Deliverect, and Onosys', where the menu of record is the middleware's, not the POS's, and no equivalent single-source statement is published; (2) it was not yet shipped at announcement - 'The new ordering integration, available directly to Square, will launch this quarter for qualifying restaurant brands.' Grade D: this is vendor press-release text carried by trade press, not admin documentation; the complete developer-doc index (docs.thanx.com/llms.txt, re-retrieved 2026-08-08) still contains no menu-management page at all, and help.thanx.com now returns 401 from its Zendesk API and a Cloudflare interstitial to browsers, so no merchant menu guide is publicly readable. Retrieved with a desktop browser user-agent; the page 403s to plain fetchers. https://www.qsrmagazine.com/news/thanx-announces-direct-to-pos-first-party-ordering-integration-with-square/ · retrieved 2026-08-08 · not refetchable · site policy · graded D when read

digital-native-app differentiator

First-party dated release note, 2026-04-30: 'The Thanx app platform is built on React Native ... It's fully live across both iOS and Android', 'The updated app is live on the App Store and Google Play', 'Guests receive it through their normal automatic app updates', and 'All existing loyalty features - points, rewards, offers, ordering - continue to work exactly as before'. The app is per-brand, not a shared marketplace app: the 2026-04-09 note ('Turn your app into your strongest marketing channel') says 'Every detail of your app is customizable - colors, icons, borders, shadows, imagery', with nav order, content blocks and merge tags configured in the merchant's own dashboard under Digital Experiences > Brand & Content > App Home Page; the 2026-03-19 App Download Activity report states 'Only downloads for the same merchant that sent the campaign are' counted, i.e. one app listing per merchant; and the 2025-12-04 Valutec note describes saving gift cards 'in Thanx-branded apps'. Ordering runs inside that app - the Deliverect note (2026-08-11) has 'Guests order on a Thanx powered web, mobile or app ordering experience' and the 2026-08-24 Live Updates note puts the order tracker 'in your app and on the web'. Distinct from a mobile web page: Thanx also sells an explicitly app-less web enrollment surface (rewards.thanx.com/[your_handle], 2025-08-07), which is described as the no-app alternative to this app. https://thanx.launchnotes.io/announcements/your-loyalty-app-runs-better-on-the-latest-android-and-ios-devices · retrieved 2026-09-01

digital-account-saved-payment

Accounts, saved tokenized cards and one-tap reorder are all documented. Card enrollment best practices: 'when we're taking payment for digital ordering, and the customer selects "save card and earn rewards" we attempt to tokenize the card with the ordering provider AND with the card network (Visa et. al.)', with the PAN vaulted through a named 'secure card vaulting partner' (Basis Theory) on secure.api.thanx.com/cards. The product page adds 'Persistent login and one-click reorder keep guests logged in and help them instantly reorder past favorites' and 'passwordless checkout'. Shortfall: saved addresses. No address book, saved delivery address or address-validation surface appears in the complete docs index, on the ordering product page (whose only named fulfillment feature is Flybuy tracking for 'curbside or in-store pickup') or in the consumer-only help centre, so the address limb of this claim is unmet. https://docs.thanx.com/consumer/best-practices/enrollment.md · retrieved 2026-08-08

digital-upsell-engine differentiator

Release note, 2026-08-11: 'Smart upsells built in - guests see relevant add-ons at checkout, whether merchant-configured or AI-suggested based on order history.' That is both limbs the claim asks for on the suggestion side: rules/merchant-configured and personalised-from-history. Corroborated by the Square note (2026-07-10), which lists 'checkout upsell (static or AI-powered)' among features 'Not yet available' on that integration and repeats 'Group ordering, checkout upsell, and the utensils opt-in prompt aren't currently available on Square' - i.e. static and AI-powered upsell are standing features of the other Thanx ordering stacks. Shortfalls, both named: (1) no attach-rate reporting on the suggestions themselves - the digital-order reporting Thanx does publish is 'Orders by client', 'Orders by handoff mode' and 'Top 25 items in digital orders' (Insights Lab, 2026-06-17 and 2025-12-16), none of which attributes revenue or attach rate to an upsell impression; (2) unavailable on the direct-to-Square ordering stack. www.thanx.com/digital-experiences corroborates the mechanism at grade D only ('AI-powered upsells deliver dynamic recommendations at checkout based on cart contents and guest history'). https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

digital-scheduled-pacing

Scheduled orders: Square note (2026-07-10) FAQ 'Can guests schedule orders ahead of time? Yes. Guests can place an order for a future time, and one-click reorder makes repeat ordering faster', and the Olo time-based menu note (2026-08-27) confirms scheduled orders are a first-class case - 'scheduled orders are filtered against the pickup or delivery time the guest selected'. Pacing: on Toast, 'Customers using Toast Integrated Ordering can now throttle orders via Toast Quote Times. Thanx will respect all of Toast's supported Quote Time strategies including: Manual, Order price, Kitchen Capacity, SmartQuote' (2025-06-24); on Deliverect, 'Time slots are generated from your store's opening hours in Deliverect, adjusted for prep time' and a busy store 'just adds a prep delay'. Shortfalls: (1) the pacing is the POS's, not Thanx's - Thanx respects Toast's quote-time strategy rather than exposing its own per-daypart order/item caps, and the two capacity-aware strategies (Kitchen Capacity, SmartQuote) 'are in a limited release with Toast'; (2) on the direct-to-Square stack 'order throttling isn't available ... turn off online ordering directly in Square POS during peak periods'; (3) on Deliverect 'Guests can only place ASAP orders. Order scheduling is not yet available and coming soon.' No Thanx-side surface that automatically closes a time slot when the kitchen saturates is documented. https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

digital-fulfillment-modes

Deliverect-powered ordering note, 2026-08-11: 'Guests choose pickup, delivery, or curbside (Tableside coming soon)', with 'handoff-specific menus (e.g., a different menu for pickup vs. delivery)' and 'Time slots are generated from your store's opening hours in Deliverect, adjusted for prep time'. Mode-specific pricing is documented on the Square stack: 'Item-based pricing, size-based pricing, nested modifiers, priced modifiers, and modifier images are supported, along with dynamic pricing by handoff mode' (2026-07-10). Curbside arrival check-in is real and named: 'Flybuy continues to power arrival detection for pickup and curbside orders' (Live Updates note, 2026-07-22), and handoff mode is a reporting dimension across 'pickup, delivery, curbside, and more' (Insights Lab NPS by handoff mode). Shortfall: the dine-in / QR table-ordering handoff is not in the flow - it is listed under 'Coming soon: Tableside handoff mode' on Deliverect and 'tableside, drive-thru, and curbside are not supported on Square', so on the direct-to-Square stack only pickup and third-party delivery (DoorDash, Uber Direct) exist. No Thanx ordering stack is documented as offering all four modes. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

digital-qr-table

Primary integration guide: 'This guide explains how to integrate a digital, QR code-based Pay at the Table experience using our APIs ... When a guest scans a QR code at their table, they're prompted to sign up or sign in to their loyalty account. Once authenticated, the integration retrieves their account and order details, allowing them to earn and redeem rewards during checkout', with the flow enumerated (scan, branded checkout, create-or-sign-in, review order, apply rewards, pay, points accrue) and bound to Create or Update Basket / Get Account / Qualifying Rewards for a Basket. A shipped instance is dated and named: the Sunday integration (2026-04-07) has 'Guest scans QR code at their table and lands in Sunday's checkout experience ... Guest sees their check, current points balance, and any available reward ... Guest applies a reward if eligible, then pays', available 'for those brands using Toast, NCR or Micros/Oracle POS', with 'Guests can split by items or split in half' (when splitting in half only the transaction total reaches Thanx). Shortfalls: (1) Thanx supplies the loyalty layer, not the scan-to-pay surface - the guide is written for the partner building 'a digital checkout experience branded for the merchant', and Thanx's own ordering stacks list tableside as coming soon (Deliverect) or unsupported (Square); (2) 'Only get $ off entire purchase rewards will surface in Sunday's checkout'; (3) on NCR and Micros/Oracle 'guests can only enroll into loyalty' - no earn or redeem; (4) refunds 'cannot be processed through Thanx's API via Sunday'; (5) tipping is not mentioned in either the guide or the integration note, so the tipping limb of the claim is unevidenced. https://docs.thanx.com/overview/guides/pay-at-table · retrieved 2026-09-01

digital-kiosk differentiator

Positive absence by role, from the primary API reference rather than from silence. The Loyalty API overview states the API 'is designed to provide POS, online ordering, and kiosk providers' the endpoints they need; docs.thanx.com/overview/intro cards it as 'Support integrations with digital ordering and kiosk providers'; and the integration guide's kiosk path is explicitly about a third party's device - 'Extend loyalty to self-service kiosks. The kiosk software allows guests to: Identify themselves (e.g., by phone number or QR code). View and redeem rewards. Apply rewards before payment', adding 'Kiosks follow the same integration path for POS'. In that model the menu, modifier logic, accessibility and payment all belong to the kiosk vendor and Thanx contributes guest identification and discount application only. Nothing Thanx ships is a kiosk: across the 168-page developer documentation set (enumerated identically by /llms.txt and /sitemap.xml on 2026-09-01) and 101 dated changelog entries, the only kiosk mentions are these integration statements plus a PAR beta caveat ('Supported on staff-facing registers; handhelds and kiosks may work depending on your specific hardware'), and the product navigation on www.thanx.com lists no kiosk product. Unattended EMV is structurally impossible here for the same reason this record already scores payments-emv-nfc no - Thanx sells no terminals and card-linking rides the operator's existing acquirer. https://docs.thanx.com/loyalty/overview · retrieved 2026-09-01

digital-group-ordering

Group ordering is a Thanx ordering feature, and the vendor twice publishes it as unavailable on named stacks. Square direct-to-POS: 'Not yet available: card-linked loyalty registration, Thanx Universal Promo Codes, group ordering, checkout upsell (static or AI-powered) and combos', restated in the FAQ as 'Group ordering, checkout upsell, and the utensils opt-in prompt aren't currently available on Square'. Deliverect: 'Not currently supported: drive-thru, digital wallets (Apple Pay/Google Pay), pay-in-store/pay-on-arrival, group ordering'. SHORTFALL: availability is stack-dependent and absent on two of the five ordering back ends Thanx supports (Square direct and Deliverect), and no published source describes the claim's per-person or total spend cap or its split-versus-single payment behaviour. Consistency note: the same Square sentence also names combos, so menu-pricing-combos is scored by the same rule as this cell. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

digital-catering-portal differentiator

Catering is never named as a Thanx capability anywhere, and the one place it is addressed is a denial — though a Square-scoped one, in the Square direct-to-POS FAQ: 'Can catering brands use Square with Thanx? Catering is limited to a separate menu category on Square — a full catering solution isn't available.' Nothing on any other stack supplies one: catering menus, minimums, lead-time rules, quotes, proposals, deposits, house accounts and ACH terms occur zero times across the closed 168-page docs census, 102 changelog entries, 124 www.thanx.com pages and the 18 published contracts ('catering' has two changelog hits — this FAQ and a points-cap example). Catering ordering appears in Thanx's own corpus only as a partner's product (www.thanx.com/partners/onosys). Unlike group ordering, catering never appears in a 'not yet available on Square' list of real Thanx features, so no cross-stack existence inference is available. https://thanx.launchnotes.io/ · retrieved 2026-09-04 adversarially verified

digital-voice-ai-phone differentiator

Two dated release notes describe a live named partnership. 2026-06-01: 'The Thanx-Kea integration connects your loyalty program to Kea's Voice AI phone ordering system ... Guest calls your Kea-enabled restaurant and places an order with the Voice AI', with points accruing automatically 'as the order moves through fulfillment' and no staff action ('No script changes, no awkward pauses, no staff training required'). 2026-07-15 adds redemption on the call itself: 'Kea checks the caller's available Thanx rewards, applies an eligible one before the order is submitted', points-for-product exchange runs the same way, and 'points accrue on the net (post-discount) amount when the order reaches the billed state'. Setup is credentialled by Thanx (Merchant Data Waiver Agreement, credentials issued into the Kea Brand Portal, location mapping). Shortfalls: (1) the ordering capability is Kea's product, not Thanx's - Thanx contributes identification, reward application and accrual, and no Thanx-native voice ordering exists; (2) neither note states that the completed order is injected into the POS - the only order-path language is that the order 'moves through fulfillment' and reaches 'the billed state', so the without-staff-transcription-into-the-POS limb of the claim rests on Kea's own architecture, which Thanx does not document; (3) when the caller is not already enrolled the loyalty attach still depends on them opening a post-call SMS payment link. https://thanx.launchnotes.io/announcements/kea-integration-update-reward-redemption · retrieved 2026-09-01

digital-drivethru-ai

Drive-thru is not a handoff mode Thanx captures orders in at all, let alone an AI voice lane. Square: 'Handoff: Only Pickup and third-party Delivery (DoorDash, Uber Direct) are available - tableside, drive-thru, and curbside are not supported on Square.' Deliverect: 'Not currently supported: drive-thru, digital wallets (Apple Pay/Google Pay), pay-in-store/pay-on-arrival, group ordering'. Thanx's published order-capture channels are 'web, mobile, and even kiosk and tableside (through partners like Bite, Grubbrr, Sunday, and Up 'N Go)', and its only voice-AI relationship is Kea on the phone channel, where Thanx contributes loyalty enrolment and reward redemption through a post-call SMS payment link rather than order capture. 'Headset', 'lane' and 'order confirmation board' occur zero times across all four first-party surfaces. https://thanx.launchnotes.io/announcements/ann_QC2KqTCnbCgJV · retrieved 2026-09-04

digital-sms-ordering

The contract defines the ordering product as a web interface only - section 1.14: 'Web Ordering means a web ordering interface produced by Thanx that connects to certain third party online ordering platforms enabling Program Participants to execute orders through a web interface' - and section 1.11 closes the Services at 'the Thanx Platform, Branded App, Web Ordering, and Thanx API'. SMS in Thanx is a marketing and enrolment channel, never a menu: the API reference exposes it only as a boolean under marketing_general in communication settings and as the /webhooks/sms-subscriptions opt-in event, whose page says 'Thanx does not synchronize downstream SMS marketing opt-in status'; section 7.5.1 charges 'pass-through fees from the SMS service provider' for in-store enrolment. The one SMS link that carries a checkout is Kea's post-call payment link for an order already placed by voice. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-04

digital-google-order differentiator

Thanx does not manage location listings; it routes the Google Business Profile relationship to Marqii, and the published scope of that integration is reviews only: 'Marqii Review Generation sends an SMS to guests shortly after their order closes, inviting them to leave a public review (Google, Facebook, or TripAdvisor)', and 'A location needs a connected POS and a connection to Google, Facebook, or TripAdvisor - or a First Party Review form set up.' No ordering-link provisioning exists anywhere: the April 2026 Settings release enumerates every brand-level integration control and its only Google entry is 'Facebook and Google Analytics: Connect your Meta pixel and Google tags to track ordering conversion metrics.' All 119 'google' hits in the closed 168-page docs census are GCP, BigQuery, Sheets, GCS, Drive links, Google SSO or Google Play; 'Google Business', 'Business Profile' and 'Order with Google' occur zero times on all four first-party surfaces. https://thanx.launchnotes.io/announcements/ann_kvgZfrbxO4gR1 · retrieved 2026-09-04

digital-apple-business-connect

Same finding as Order with Google and from the same enumeration: the only listings-adjacent integration Thanx publishes is Marqii, scoped to review generation - 'You choose where reviews go - Send guests to Google, Facebook, TripAdvisor, or a private first-party form, set per location' - with no listing, place-card or ordering-action provisioning, and no Apple destination among them. Apple appears across the closed 168-page docs census, 102 changelog entries, 124 www.thanx.com pages and the 18 contracts only as an app store (Merchant Agreement section 5.3 publishes the Branded App 'on both iOS and Android platforms') and as Apple Pay; 'Apple Business Connect', 'Apple Maps' and 'place card' occur zero times on every one of them. https://thanx.launchnotes.io/announcements/ann_kvgZfrbxO4gR1 · retrieved 2026-09-04

digital-loyalty-attach

Deliverect ordering note, 2026-08-11: 'Your loyalty program, wherever guests order - all loyalty features work as usual, including hidden menu, card-linked loyalty, and Universal Promo Codes. Every digital purchase earns points'; and 'Guests keep their login - standard Thanx login, SSO, and persistent login carry over; guests can jump straight to the menu and enroll in loyalty at checkout.' Enrollment at checkout, not post-purchase. The Square stack states the same from the other direction (2026-07-10): 'Guests log in with their existing Thanx account online or in app and order straight from the menu ... Rewards apply automatically as discounts at checkout'. The identity is the in-store identity: the same Thanx account earns at the register through the direct POS integrations (Toast, Square, NCR Aloha, PAR Brink, Genius for Enterprise, Qu), in-store enrollment at the POS writes into it by SMS or email (2026-02-19), card-linked loyalty attaches in-store card purchases to it, and the memberships data model carries one user_id per merchant with an alternate_pos_id mapped into Toast's APPLIED_LOYALTY_ID (docs.thanx.com/data/models/memberships). Redemption inside the digital flow is documented mechanically, not just asserted: rewards apply as checkout discounts, points-product exchange is available, and points accrue on the net post-discount total. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

digital-subscriptions

Enumeration from the schema, not from silence. The memberships model is the guest record Thanx exports, and its attribute list is complete and published: merchant_id, user_id, signup_program_id, first_name, last_name, email, birthday, zip_code, tier_status, is_user_joined, has_registered_card, is_signup_merchant, user_joined_at, user_entered_crm_at, email_last_opened_at, merchant_uid, user_uid, phone, alternate_pos_id. There is no plan, price, billing, renewal, entitlement or paid-tier field, and tier_status is documented as earned rather than bought - 'There are three tiers: Bronze, Silver, and Gold', with the tier configuration endpoint defining each by 'spend_threshold ... How much the user needs to spend to be part of the tier' (docs.thanx.com/consumer/tiers/get-configs). The full set of exported data models is likewise enumerated at docs.thanx.com/data/overview - campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases, rewards, legacy loyalty reward progress - with no subscription, plan or recurring-billing entity among them. Across the 168-page docs set the string 'subscription' occurs only as the LaunchNotes release-notes subscription snippet and the SMS-subscriptions marketing-consent webhook, and no changelog entry in 101 describes recurring guest billing. No recurring delivery-fee waiver, per-period item entitlement or paid loyalty tier exists in the documented platform. https://docs.thanx.com/data/models/memberships · retrieved 2026-09-01

digital-promo-parity

Release note, 2026-06-24: 'Universal Promo Codes lets you create, distribute, and track promotional codes that redeem across channels - all from your Thanx dashboard ... The same code works at the register and in online ordering, with unified reporting - no need for middleware offer management.' Defined once against a reward template (% off, $ off, free item, free delivery, or BOGO) with 'validity window, location restrictions, and minimum spend'; redeemed 'Online: Guests enter the code at checkout in Toast or Olo ordering; Thanx validates it in real time and applies the discount to the subtotal' and 'In-store: A cashier enters the code at the register'. Channel eligibility control is documented separately on rewards themselves: 'Set the Redemption Method (online, in-store, or both)' (Fixed Price Rewards, 2026-05-22). Shortfalls, all first-party and explicit: (1) parity is per-integration, not universal - the note's own supported-platform matrix is 'Online ordering: Toast, Olo, Deliverect - coming soon; In-store (POS): NCR Aloha, PAR (Brink), Genius for Enterprise (Xenial), Toast - coming soon, Qu - coming soon', ending 'Not supported: Square POS'; (2) reward types do not all cross - 'Bonus points, hidden menu items, and access passes aren't eligible' for promo codes, and on the Sunday pay-at-table channel only 'get $ off entire purchase' rewards surface; (3) Olo requires the operator to email their Olo rep before codes can be enabled; (4) kiosk, one of the three channels the claim names, is not a Thanx surface at all (see digital-kiosk). https://thanx.launchnotes.io/announcements/introducing-universal-promo-codes-one-code-every-channel · retrieved 2026-09-01

digital-guest-data-ownership differentiator

Ownership is stated in the primary docs: 'We are firm believers that data within the Thanx platform belongs to our customers. As a result, it's our responsibility to make it as easy to use as possible - both within the Thanx dashboard via tools and reporting as well as in downstream data systems.' Bulk export is real and enumerated: SFTP exports are 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', 'available to all Thanx merchant customers', in single-file (10 million records) or multi-file form ('Eliminates the 10 million record limit', 5GB files); plus Snowflake Secure Data Sharing ('a direct Snowflake-to-Snowflake share') and Thanx Connex into 20+ named destinations (Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, MotherDuck, Delta Lake, Iceberg, Postgres, MySQL, MongoDB, SQL Server, Oracle, S3, GCS, Azure Blob, SFTP, Google Sheets). The fields the claim names are covered by published schemas: memberships (email, phone, birthday, zip, tier, joined dates), communication-preferences, and purchases. The 2025-12-16 release note confirms 'SFTP data exports now include phone numbers' and that 'The previous 10-million-row export cap has also been removed'. Shortfalls against the claim's 'without a fee or vendor approval': (1) consented phone data is gated on the vendor - the memberships schema says of phone, 'This column will be empty unless the SMS opt-in consent was signed and enabled by Thanx staff'; (2) provisioning is not self-serve - 'please reach out to your Thanx success manager directly and they can set this up', and multi-file exports likewise 'reach out to your Thanx success manager'; (3) no page in the developer docs or in the 101 dated changelog entries states that export or Connex is included at no additional charge, so the no-fee limb is unevidenced in either direction. Self-serve customer-list upload exists in the other direction (2026-05-06), which does not bear on export. https://docs.thanx.com/data/overview · retrieved 2026-09-01

digital-checkout-pci-sca

Hosted capture is documented per stack: on Deliverect, 'Guests pay by credit card through Deliverect Pay (hosted payments)', with 'Deliverect's tokenization requires CVV re-entry on saved cards' (2026-08-11); on Square, guests 'pay by card, Apple Pay, Google Pay, or gift card' through Square Payments, with 'One payment processor with Square Payments' (2026-07-10). Thanx's own card handling is tokenized and vaulted off the merchant page - the enrollment best-practices doc describes attempting 'to tokenize the card with the ordering provider AND with the card network', the loyalty-models doc has 'During a digital checkout, Thanx securely tokenizes the guest's payment card', and this record's existing digital-account-saved-payment cell cites the named vaulting partner (Basis Theory) on secure.api.thanx.com/cards. Card-brand compliance work is visible in passing: 'Visa, Mastercard, and Amex logos now appear in the payment flow at checkout' for Worldpay compliance (2025-12-16). Shortfalls, covering every limb the claim asks for beyond hosted capture: (1) no PCI DSS compliance statement of any version is published - 'PCI' has zero hits across all 168 pages of docs.thanx.com and all 101 dated changelog entries; (2) nothing addresses the PCI DSS 4.0 client-side script-integrity requirements effective March 2025, and the 2026-07-08 security release note covers internal vulnerability scanning, credential scanning and dashboard access controls only; (3) '3DS' and '3-D Secure' have zero hits in either corpus, so strong customer authentication is unevidenced. A compliance or security page, if one exists, would sit in the SSO-walled merchant help centre (help.thanx.com 302s to dashboard.thanx.com; Help Center API 401, re-probed 2026-09-01). https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

digital-surcharge-transparency differentiator

Thanx's entire published fee surface is free text the operator writes: 'Get ahead of fee questions: Add a note explaining service charges or surcharges so customers aren't surprised at the end of checkout', and 'Clarify tax display: If your tax line items are calculated in a way customers might find confusing, a quick explanation prevents order total confusion.' There is no fee configuration behind it: the April 2026 Settings release enumerates every dashboard ordering control - ordering configuration, ordering error messages, delivery defaults, location selection, receipt settings, 86ed visibility, scannable codes, in-store enrolment, in-store purchase tracking, terms and policies, analytics tags - and not one is a service-fee, surcharge, dual-pricing or cash-discount control. 'Surcharge', 'dual pricing' and 'cash discount' occur zero times in the 18 published contracts, and nothing anywhere addresses card-brand rules or jurisdictions where surcharging is prohibited. https://thanx.launchnotes.io/announcements/ann_jXpfhzBXaPkSb · retrieved 2026-09-04

guest-loyalty-unified-profile

The unified profile is real: the CRM page states 'Every guest gets a unified profile with purchase history, item preferences, visit frequency, loyalty tier, points balance, rewards redeemed, sentiment scores, order channel, and location preferences', in-store purchases attach through card-linked loyalty or POS check-in, and the docs confirm 'digital purchases are automatically tracked without requiring enrollment of a card'. Shortfall: the identity key is the registered card, not a phone/email match, and dedup is manual. Thanx's own enrollment guide documents that a card 'cannot be registered for loyalty benefits for another account' and that the common case of one guest creating accounts under two email addresses produces two profiles - 'Our support team can help the customer resolve the issue by merging accounts.' It further instructs merchants to swallow the duplicate-card error at checkout and let the purchase go through unenrolled. That is a documented dedup rule, but it is a block-and-escalate rule, not the automatic merge under one identity this claim requires; kiosk attaches only via partner ordering providers (Bite, Grubbrr, Sunday, Up 'N Go) through the Loyalty API. https://docs.thanx.com/consumer/best-practices/enrollment.md · retrieved 2026-08-08

guest-loyalty-thirdparty-identity-attach differentiator

Positive absence by schema and by mechanism, over the developer-documentation surface docs.thanx.com enumerates twice (llms.txt and sitemap.xml agreed exactly on 168 pages, 2026-09-01). The exported purchases model enumerates the whole channel domain as "The channel through which this purchase was made. (`digital`, `instore`)", and its pos_id / pos_provider fields are "Only present when a purchase is created via an in-store check-in"; there is no marketplace, aggregator or third-party channel. The pay-at-table guide states the accrual rule directly: a user "will accrue points only if the transaction is processed directly through the card network. Payments made through Stripe or other payment service providers (aggregators) will not trigger accrual because the transaction is processed under the provider's merchant ID rather than the merchant's own" - which is precisely the DoorDash / Uber Eats / Grubhub settlement path. Those three brands appear nowhere in the 168 doc pages; where the release notes name them it is as couriers behind first-party delivery (DoorDash Drive, Uber Direct) or as the "third-party marketplaces you don't control" Thanx positions against. No documented path carries marketplace guest identity into a Thanx profile. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-01

guest-loyalty-accrual-models

All three accrual models are documented as merchant configuration in the primary API reference, not inferred from marketing. GET /loyalty_statuses returns 'status.type' as an enum: 'Whether the user earns progress via how much they spend or how many times they visit. Returns spend or visit', with 'status.threshold' = 'How much the user needs to spend or how many visits the user needs to make to earn the reward' - that is spend-accrual and visit/punch-count accrual as a per-merchant switch. Spend tiers are separate and explicit: GET /tier_configurations returns bronze_tier / silver_tier / gold_tier hashes each carrying 'spend_threshold' = 'How much the user needs to spend to be part of the tier' (sample response: 0 / 1500 / 3000). Points-per-dollar is the points system: the Points Integration guide defines a points experience as 'configuration that defines the currency that a user can earn points torward, including the conversion rate', with GET /points_multipliers returning a time-bounded 'factor' (e.g. 1.9 for a date range). The product page corroborates in operator language - 'Create points programs with optional tiers' and 'Points programs with optional tiered structures unique to your brand. Change your program anytime at zero additional cost with self-service tools' (thanx.com/loyalty, retrieved 2026-08-08). No custom development and no bolt-on loyalty vendor: loyalty is the Thanx product itself. https://docs.thanx.com/consumer/loyalty/get-loyalty-statuses.md · retrieved 2026-08-08

guest-loyalty-tiers differentiator

Get Tiers Configurations returns bronze_tier / silver_tier / gold_tier hashes each carrying "spend_threshold: How much the user needs to spend to be part of the tier", and Get Tier Statuses returns level (bronze|silver|gold), "progress: Amount spent so far", "expires_at: Current tier status expiration in ISO8601-format" and action_text ("Spend $100 before the end of the year to earn Silver."). Promotion and demotion are therefore automatic and threshold-driven, with an explicit status expiry in the schema. Thanx's own tier article (www.thanx.com/help-center/understanding-guest-tier-programs-how-status-based-loyalty-works-in-thanx) states "Status is held for 12 months from the date it's achieved, not from the start of the calendar year" and works an example where "Original Gold status expires. Guest hasn't hit $1,000 yet this year - they drop back to Silver." Two limits worth recording: the tier level is a fixed three-value enum (bronze/silver/gold, renamed by the merchant) rather than an arbitrary ladder, and qualification is spend-only - no visit-count threshold appears anywhere in the schema. https://docs.thanx.com/consumer/tiers/get-configs · retrieved 2026-09-01

guest-loyalty-offline-behavior differentiator

The mandatory POS/Kiosk pre-certification self-check is a closed enumeration of everything a POS integration must implement, and its Error Handling section is four lines - 'Handle authentication failures gracefully / Handle reward redemption errors (expired, already used) / Handle basket submission errors / Display meaningful error messages to end users' - with no queue, cache, store-and-forward or reconcile-on-reconnect requirement, alongside a General rule that 'API requests are only issued in response to end-user interactions (no rapid polling)'. The flow it certifies is synchronous (Create Access Token, Get Account, Create or Update Basket). 'Offline', 'outage' and 'connectivity' occur zero times in the closed 168-page / 728 KB docs census, and the only outage statement Thanx publishes is the August 2026 maintenance notice that 'in-store loyalty via POS will be unavailable'. The vendor nowhere documents whether lookup, accrual and redemption queue or block on connectivity loss. https://docs.thanx.com/assets/Pre_Cert_Checklist_POS_Kiosk.md · retrieved 2026-09-04

guest-loyalty-offer-stacking-rules differentiator

Positive evidence of absence, not silence. Create or Update Basket states "A promo code cannot be combined with a reward or points product. Supplying both returns a 400 - apply one or the other, not both", and the documented 400 body is literally "A promo code cannot be combined with a reward or points product". The consumer loyalty guide says of the cart "Only one reward can be applied at a time (when one is applied we toggle the other off)", and the precedence it documents is a fixed platform sort (earned rewards first, then affordable marketplace rewards, lowest cost first, then soonest expiry), not operator configuration. The two documented offer-creation surfaces expose no combinability field at all: Create Promotion takes discount_type, discount_value, minimum_spend, maximum_discount, redemption_venue, starts_at/ends_at, a code pool and day/hour redemption_restrictions; the Universal Promo Codes release (2026-06-24) states the rules you set are "validity window, location restrictions, and minimum spend". Exclusivity is enforced by the platform; it is not exposed as configuration. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-01

guest-loyalty-targeted-offers differentiator

Dated first-party release entries describe the mechanism, not just the name. SegmentAI (public beta 2026-01-22) takes a natural-language audience description - the vendor's own example is "customers who visited in the last 30 days but haven't made a purchase in 2 weeks" - and "automatically translates your description into accurate segment targeting rules". The 2026-03-04 release adds segments over modifier purchase behaviour ("Customers who ordered a Chicken Bowl with Guacamole", digital orders only, Olo or Toast brands); the 2026-03-25 release adds location and user-tag pickers, timezone awareness and a targeting-confirmation step. Saved segments are consumed by campaigns ("Save the segment and submit for admin approval. Once approved, it's ready to use in any campaign"), and the 2026-02-03 release adds an Audience toggle on automated campaigns to include guests already in the segment at activation. The published partner API agrees: Issue Rewards posts a campaign_id, a variant_id and an explicit identifiers array of up to 10,000 users, so issuance is audience-scoped by construction. https://thanx.launchnotes.io/announcements/segmentai-beta-1 · retrieved 2026-09-01

guest-loyalty-rfm-segmentation differentiator

The Insights Lab "Point Activity by Lifecycle Stage" report (2025-08-06) breaks earning, redemption and expiry down by stage - "See which lifecycle stages (like Engaged or Churned) are earning, redeeming, or letting points expire" and "View the current outstanding points balance by lifecycle stage" - so the stages are computed by Thanx and handed to the operator. They are also directly actionable: Scheduled & Targeted Content Blocks (2026-02-19) lets a block "Show a block to a specific audience - VIPs, new members, lapsed guests, or any custom segment", and the 2026-04-09 release states "You can target content by loyalty tier, visit frequency, or lifecycle stage - right from your dashboard." The vendor's public segmentation guide names the ladder and its thresholds ("new members or Acquisition", "Developing guests or Activation - one or two purchases", "Active regulars or Engaged - three or more purchases", "At-risk guests - visit frequency declining", "Lapsed guests - no purchase in 45-90+ days") and states "Lifecycle segments are pre-built based on industry benchmarks so you're not starting from scratch. The platform handles the dynamic filtering, the real-time audience updates, and the campaign triggers automatically." Scored on the two dated release entries; the help-centre page sits on the marketing host and is corroboration only. https://thanx.launchnotes.io/announcements/new-in-thanx-insights-lab-point-activity-by-lifecycle-stage-report · retrieved 2026-09-01

guest-loyalty-lifecycle-automation

Always-on triggered lifecycle automation is enumerated as product, not marketed in the abstract. Marketing automation page: 'Prebuilt lifecycle templates: Launch proven activation, retention, and winback campaigns with pre-configured triggers and goals'; 'Set up automated campaigns that trigger the moment guests enter your target segment, then run continuously without manual effort'; 'Event-based triggers: Launch campaigns automatically the moment guests qualify based on their behavior or purchase patterns'. The CRM page supplies the three exemplars this claim names - '75+ ready-to-use segments organized by customer lifecycle stage' for 'cart abandonment, win-back, VIP recognition, birthday campaigns', with timing baked in ('Hasn't made a second purchase after 7 days', 'Last visit 30+ days ago') and 'Real-time segment updates so automations trigger at exactly the right moment'. First-visit, lapsed win-back and birthday are each covered. Grade C: first-party product pages, not admin documentation - Thanx publishes no merchant admin guide. https://www.thanx.com/restaurant-personalization-solution · retrieved 2026-08-08

guest-loyalty-native-email-sms differentiator

Email is native and first-class: the campaigns data model carries unique sent / delivered / opened / clicked email counts per campaign and per variant A-D, and dated releases cover an email builder with merge tags (2025-03-20), video and countdown blocks (2025-05-14), five AI copy generators inside the builder (2025-01-08) and a configurable reply-to address on marketing and transactional email (2026-07-06). SMS is the shortfall. The SMS Subscriptions webhook exists to hand the opt-in outward: "These webhooks are sent when a user opts into SMS marketing. Thanx does not synchronize downstream SMS marketing opt-in status and users are only prompted to enter a phone number for SMS marketing once. SMS marketing partners are expected to manage confirmation of SMS marketing consent." The campaigns model's aggregate unique_sent_sms_users and unique_delivered_sms_users columns are annotated "(Deprecated)", and every SMS path described in 2026 releases runs through a third party - Klaviyo "for email and/or SMS marketing", Marqii sending the review-invite SMS, Kea sending the post-call payment link. Push notification is a fully native third channel. Left partial rather than no because per-variant SMS counters remain in the same schema undeprecated. https://docs.thanx.com/webhooks/sms-subscriptions · retrieved 2026-09-01

guest-loyalty-consent-management

The communication_preferences export enumerates its whole field set: eleven per-topic booleans split by channel (enabled_email_reward_earned, enabled_email_marketing_general, enabled_notification_feedback_available and so on) plus created_at and "updated_at: The date and time the communication preference was last updated by the user". The consumer and partner APIs both read and write these (marketing_general carries separate email and sms keys), and Get Communication Setting by UID needs no authentication, so an email footer link can serve a preference centre. Two named shortfalls. First, source of consent is captured nowhere in the model - the nearest field is memberships.signup_program_id, "the unique identifier of the program that resulted in a user creating an account", which records enrollment origin, not per-channel consent origin. Second, revocation does not propagate across all channels: the SMS Subscriptions webhook states "Thanx does not synchronize downstream SMS marketing opt-in status ... SMS marketing partners are expected to manage confirmation of SMS marketing consent", and memberships.phone "will be empty unless the SMS opt-in consent was signed and enabled by Thanx staff". STOP/START handling is documented only for partner-sent SMS (Marqii). Separately, from 2026-05-01 every merchant must upload or link its own Privacy Policy, Terms and Conditions and Consumer Opt-out documents in the dashboard. https://docs.thanx.com/data/models/communication-preferences · retrieved 2026-09-01

guest-loyalty-10dlc-registration

Left unknown deliberately. '10DLC', 'A2P', 'brand registration' and 'campaign registration' occur zero times across the closed 168-page docs census, 102 changelog entries, 124 www.thanx.com pages and the 18 published contracts, so the DOCUMENTATION limb fails outright — but the HANDLING limb is live and points the other way, so a `no` would be unsafe. Thanx sends SMS itself as a campaign channel; an unnamed 'SMS service provider' sits in the chain with pass-through fees (Merchant Agreement section 7.5.1); the phone column in the data export 'will be empty unless the SMS opt-in consent was signed and enabled by Thanx staff'; and the Marqii release instructs 'On Thanx, make sure SMS opt-in is enabled. Work with your Thanx CSM to configure.' A CSM-gated, signed-consent enablement is consistent with Thanx carrying carrier registration on the brand's behalf. The answer would sit in the walled help.thanx.com merchant help centre (Zendesk Help Center API 401, /hc/* 302 to a dashboard.thanx.com SSO login), whose Wayback CDX index holds only 55 rows, none touching SMS, and the Additional Terms section the 2026 agreement cites for Third Party Services Fees is not among the published addenda.

guest-loyalty-campaign-attribution differentiator

The exported campaigns model carries "net_revenue: The net revenue was generated from customers who received the campaign and made a purchase in the following 14 days" per campaign, together with per-variant reach counters (unique sent / delivered for email, push and SMS across variants A-D, plus a combined any-channel pair). Incrementality is structural rather than inferred: Create Campaign takes "between 1 and 4 variants" where "Control variants (named \"Control\") do not require a reward_template_id", and the reward-issued webhook stamps every reward with its campaign and variant, so redeemed rewards join back to the campaign that issued them. The rewards export carries the reward state machine (active, delivered, used, refunded, retired, fraudulent) and the issuing program_type. Universal Promo Codes reporting adds the code-level view: "See codes generated, distributed, and redeemed; redemption by channel; and revenue impact - all in your Rewards reporting" (2026-06-24). Purchases carry authorization_amount and settlement_amount, so the revenue side is actual check money rather than a model. https://docs.thanx.com/data/models/campaigns · retrieved 2026-09-01

guest-loyalty-data-export-portability differentiator

The substance is there and was re-verified 2026-09-01: SFTP exports "are a snapshot of the entire data set resident within the Thanx platform in CSV format", refreshed once every 24 hours and "available to all Thanx merchant customers"; the memberships model exports first_name, last_name, email, phone, birthday, zip_code, tier and account timestamps, and purchases carry settlement_amount, location and channel. The overview opens "We are firm believers that data within the Thanx platform belongs to our customers." One count in the previous note is corrected: it said sixteen Connex destinations are documented, which is the row count of the overview's own table and under-lists the site - twenty-three /data/connex/ destination pages are published (the table omits AWS Postgres, AWS MySQL, Redshift Serverless, S3-Compatible, MotherDuck, Delta Lake, Iceberg, MongoDB, Oracle and SFTP). Snowflake Secure Data Sharing is documented separately. The correction widens the export surface and does not disturb the verdict, because the shortfall is the self-serve half of the claim and every documented route is gated on the account team: SFTP - "please reach out to your Thanx success manager directly and they can set this up"; multi-file exports - "To configure multi-file exports for your account, please reach out to your Thanx success manager"; Connex - "please reach out to your Thanx success manager directly and they can work with you on the specifics". Contact PII is gated further: memberships.phone "will be empty unless the SMS opt-in consent was signed and enabled by Thanx staff" (re-read in the memberships column reference today). No fee is stated for any route, and no API endpoint returns a bulk guest list. The inbound direction was explicitly de-gated in 2026-05 ("Upload customer lists yourself, no support ticket required"), which is the vendor's own pointed counterpart. https://docs.thanx.com/data/overview · retrieved 2026-09-01

guest-loyalty-cdp-event-api differentiator

The webhooks section documents an outbound stream with published payload schemas: purchases (fired on detection of a qualifying purchase, re-sent through authorization and settlement), reward-issued (carrying user, reward, campaign and variant), reward-batch-completed, communication-settings and sms-subscriptions. "These webhooks allow for integrating platforms to respond in realtime to changes to data resources in the Thanx platform"; endpoints must be HTTPS and answer within 15 seconds, and enablement is by email to developer.support@thanx.com. The partner API is written for exactly the audience this claim names - Promotions Overview opens "Promotions let a partner (for example, a marketing platform such as Klaviyo) issue discount codes to a merchant's customers" - and the shipped Klaviyo offer-management integration (2026-03-31) is the worked instance, with Thanx reward objects landing on Klaviyo profiles as metrics that trigger flows. Reliability caveat carried on the cell: delivery is "not exactly-once", "failed deliveries are not retried", "Duplicates are the common case", and the docs direct you to bulk data transfer to backfill anything missed. https://docs.thanx.com/webhooks/overview · retrieved 2026-09-01

guest-loyalty-review-capture-routing differentiator

The trigger half is native and documented: "The Thanx feedback system targets customers shortly after they make a purchase, selecting a random group each day to ask a single question: How likely are you to recommend [merchant name] to a friend?", scored 0-10 with an optional written comment, and "When Thanx receives a purchase record a number of details are considered to determine if a customer should be prompted to give feedback." Private service recovery is real: each rating "is linked directly to the consumer so their purchase history can be viewed", the partner Respond to Feedback endpoint "will trigger a message to the Thanx customer on behalf of the merchant" (one response per record), and the nps-feedback model exports the ratings. The shortfall is the routing itself. No score threshold appears anywhere: the native flow keeps every rating private and the design guidance runs the other way ("add support links throughout your experience to reach customers before they go to google or yelp to complain"). Public review capture arrives only through the Marqii integration (2026-07-27), which SMSes every opted-in guest about two hours after any order closes and sends them to "Google, Facebook, TripAdvisor, or a First Party Review form" chosen per location - "You choose one publisher destination ... per location" - gated by a cooldown, not by a rating. https://docs.thanx.com/consumer/best-practices/feedback · retrieved 2026-09-01

guest-loyalty-referral-program

Existence is established from the exported schema rather than from marketing: program_type enumerates "automated campaign - referral program" alongside birthday program, exclusive deals, intro offer and the loyalty variants, and the same value recurs in the rewards model, so referral-issued rewards are attributed to a referral program in the merchant's own data export. The certification and sandbox pages list "invite" among the fraud-protected reward types (intro, invite, birthday, winback, newsletter), which are the types Thanx guards by card fingerprint. Shortfall: the three mechanics this claim itemises are undocumented anywhere readable. No per-guest referral code or link appears in the consumer or partner APIs - the only code primitives are promotion pools, and the docs say the API cannot even tell you a single-use code has been handed out ("the API only knows whether a code has been redeemed ... not whether you have already handed it out"). There is no referrer or referred-guest field in the rewards or purchases models to carry first-order attribution, and no two-sided issuance primitive (Issue Rewards posts one variant to one identifier list). The referral pages on www.thanx.com (/refer-a-friend, /customer-referral, /referral-terms-and-conditions) are Thanx's own partner and customer referral offers, not product documentation. https://docs.thanx.com/data/models/programs · retrieved 2026-09-01

guest-loyalty-wallet-pass differentiator

Thanx's published answer to identifying a guest without an app download is a QR code and a linked payment card, not a wallet pass: the April 2026 Settings release lists 'Scannable codes: Enable QR codes so customers can quickly identify themselves at the POS during in-store visits' alongside card-linked receipt settings, with no wallet pass among the Settings page's controls. The consumer API census (168 pages; sitemap and llms-full.txt agree exactly) carries payment-card linking (a different mechanic), push registration, check-in codes and deep linking, but no pass-provisioning endpoint; 'Apple Wallet', 'Google Wallet', 'PassKit' and 'wallet pass' occur zero times there, in 102 changelog entries and in the 18 contracts, and the only changelog 'wallet' is 'digital wallets (Apple Pay/Google Pay)' listed as unsupported on Deliverect. Counterargument recorded and weighed: www.thanx.com/blog/apple-wallet-loyalty is STILL LIVE (HTTP 200, re-fetched 2026-09-04) and states in the first person 'any merchant can have their own Apple Wallet loyalty card — in less than 2 days'. It is discounted because its content self-dates to the September 2015 iOS 9 Passbook-to-Wallet rebrand ('Apple Wallet arrives in full force today', 'Passbook... had to literally be rebranded'), predates Thanx's restaurant era, and is contradicted by every current developer, changelog and contract surface. Scope note: the Settings release enumerates the Settings page, not every guest-identification control. https://www.thanx.com/blog/apple-wallet-loyalty · retrieved 2026-09-04 adversarially verified

guest-loyalty-privacy-rights-tooling

The propagation half is shipped and specific (2026-05-08): "When a customer requests account deletion, their email is recorded on your merchant-specific suppression list - so if that email appears in a future import, it will be automatically excluded"; it is "automatically enabled for all merchants; no setup is required"; suppression is per-merchant; the readable address is visible under Customers > Suppressions for a rolling 30 days and is then "permanently cleansed" leaving an anonymised record; the designated CCPA opt-out contact receives a weekly digest; import summaries report how many contacts were skipped; and "Re-uploading their email in a contact list does not override the suppression." Two shortfalls. First, deletion is not admin self-serve: the consumer Delete User endpoint "submits a request for account closure ... The Thanx support team will review the request and interface directly with that user to complete account closure", and the same release notes that "Blocking or deactivating a user from your merchant dashboard only removes their membership - it does not trigger suppression." Second, the access half of the claim is undocumented - no subject-access export of one guest's record appears in the consumer API, the partner API or the exported data models, and no admin screen for it is described. https://thanx.launchnotes.io/announcements/marketing-suppression-list-for-users-with-deleted-accounts-1 · retrieved 2026-09-01

guest-loyalty-redemption-fraud-controls

What is documented is platform-side and real: "When testing fraud-protected reward types (intro, invite, birthday, winback, newsletter), use a unique, real card per test account. Shared test cards ... match on card fingerprint across accounts and merchants, which flags the reward as fraudulent and makes it disappear on activation", and the sandbox FAQ calls this "Thanx's fraud engine". The error table carries REWARD_FRAUDULENT ("You appear to have already used one of these rewards") and REWARD_ALREADY_USED; the rewards export carries a fraudulent state; card registration is one-account-per-card by design ("That would allow two customers to get credit for the same purchase ... This prevents fraud (intentional or otherwise)"); the points-transactions export enumerates a clawback reason; Revoke Issuance Job is described as "Useful for error correction and fraud prevention"; and a basket id "keys the redemption and makes retries idempotent, so resending the same basket will not redeem twice". Shortfall: not one of the four controls the claim itemises is documented - no redemption velocity or rate limit on a guest, no manager-approval step on manual point adjustments (points_transactions records source and reason but no approver), no employee self-redemption flag, and no audit-log surface. Role-based dashboard permissions shipped 2026-04-13 (No Access / Can View / Can Manage per feature area, location-scoped) but that release describes no action log. https://docs.thanx.com/consumer/usage/certification · retrieved 2026-09-01

guest-loyalty-ai-offer-recommendation differentiator

Target audience: SegmentAI "automatically generates the segment logic" from a plain-English description and is in general use rather than on a roadmap - the 2026-04-30 release removes the previously mandatory Thanx review ("After months of battle testing our SegmentAI engine, we have removed the requirement for Thanx review of AI-generated segments", justified with "About 90-95% of reviewed segments pass without any modifications"), and merchants can auto-approve all future AI segments. Its capabilities were extended twice in shipped releases (modifier-behaviour segments 2026-03-04; location and tag pickers, timezone awareness and an explicit targeting-confirmation step 2026-03-25). Offer content: five AI generators ship inside the email builder - "Smart Text Generation", "Smart Buttons", "Smart Headings", "Magic Images" and "Smart Alt Text" - "now available directly in the email builder" (2025-01-08). Send timing is the one axis of the three with no AI evidence. Deliberately not relied on: "RecoveryAI", which the 2026-07-22 entry describes as launching in a few weeks, is a roadmap statement. https://thanx.launchnotes.io/announcements/skip-the-wait-ai-generated-segments-can-now-activate-instantly · retrieved 2026-09-01

guest-loyalty-stored-value-gift

The profile-tied half holds: the Gift Cards API lets a user add, view and manage cards inside the branded app, cards are active or archived per user, "Balance information is retrieved in real-time whenever gift card details are requested", points can be earned on orders paid by gift card (2026-07-07), and dated releases add Valutec for Toast online-ordering brands (2025-12-04) and Olo gift cards to "store, track and apply from your app" (2026-07-08). The shortfall is that the stored value is not native. The same overview states "The Thanx platform integrates with external gift card providers to manage card validation and balance checking", and the merchant configuration endpoint exposes "External purchase links: Direct users to a URL where they can purchase gift cards" plus card artwork - so issuance, funding and the ledger sit with the provider while Thanx supplies the wallet, the balance read and the tender. Cross-location redeemability therefore follows from the provider's programme and is nowhere asserted by Thanx; the Deliverect ordering release lists "Deliverect's own native gift card API (Valutec)" under "Not currently supported", and the Square direct-to-POS release states splitting a payment across multiple gift cards is unavailable. Consistent with the sibling cell payments-gift-cards, scored partial on 2026-08-04 from the same passage. https://docs.thanx.com/consumer/gift-cards/overview · retrieved 2026-09-01

labor-clock-in-at-pos

Migrated from the 2026-08-01 research pass; no source URL was recorded.

labor-photo-punch-verification differentiator

A photo or facial-verification capture is an attribute of a timecard entry, and Thanx has no timecard. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. Zero occurrences across the 778,290-character corpus of: punch, timecard, time card, payroll, overtime, clock-in, gratuity, inventory, recipe, ingredient, supplier, purchase order, par level, waste or commissary; the single occurrence of 'employee' is a tag-key case-sensitivity example. All 101 dated first-party announcements on thanx.launchnotes.io (2025-01 to 2026-08, read in full) fall under the vendor's own 11-area product taxonomy - Integrations, Ordering, Loyalty, Guest Engagement, Marketing Automation, Toast, ThanxAI, Offers & Rewards, Reporting & Insights, Org Management & Settings, App Experience - which contains no labor or inventory area. help.thanx.com is walled (302 to a dashboard.thanx.com SSO login; its Help Center API returns 401), so the merchant admin UI is not directly readable; the finding rests instead on the platform's own enumeration of the data it holds. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-geofenced-mobile-punch

Mobile clock-in with location validation presupposes a punch record; Thanx records none. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. Zero occurrences across the 778,290-character corpus of: punch, timecard, time card, payroll, overtime, clock-in, gratuity, inventory, recipe, ingredient, supplier, purchase order, par level, waste or commissary; the single occurrence of 'employee' is a tag-key case-sensitivity example. The only location surface in the consumer SDK is guest-facing pickup and location search, not staff punching. help.thanx.com is walled (302 to a dashboard.thanx.com SSO login; its Help Center API returns 401), so the merchant admin UI is not directly readable; the finding rests instead on the platform's own enumeration of the data it holds. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-offline-time-punch differentiator

Offline punch capture and reconciliation presupposes a timekeeping store; Thanx has none. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. Zero occurrences across the 778,290-character corpus of: punch, timecard, time card, payroll, overtime, clock-in, gratuity, inventory, recipe, ingredient, supplier, purchase order, par level, waste or commissary; the single occurrence of 'employee' is a tag-key case-sensitivity example. Thanx also ships no terminal or register software of its own - it rides the operator's POS (Toast, Square, Olo, Deliverect, Qu, PAR, NCR Aloha and Xenial integrations are the ones announced). help.thanx.com is walled (302 to a dashboard.thanx.com SSO login; its Help Center API returns 401), so the merchant admin UI is not directly readable; the finding rests instead on the platform's own enumeration of the data it holds. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-granular-rbac

Positive absence by enumeration of the product's entire public surface: the complete docs.thanx.com index (consumer/partner/loyalty APIs, webhooks, data exports), the platform page (card-linked loyalty, CRM, marketing automation, digital ordering layered over the operator's existing POS) and the consumer-only help centre contain no register or terminal function at all. The per-action register permissions this claim enumerates (void, comp, discount, refund, drawer open, price change) have no surface to exist on — those actions occur on the third-party POS Thanx integrates with (Toast, Square, Olo). Roles inside the Thanx marketing dashboard are undocumented, but they are not the register RBAC this claim describes.

labor-manager-override-audit

Same enumeration basis as labor-granular-rbac: Thanx's documented product (loyalty/CRM, digital ordering, APIs, webhooks, data exports — per the complete docs.thanx.com index and platform page) includes no register or front-of-house workflow, so there are no manager overrides or approvals to attribute or audit; voids, comps and overrides happen on the operator's separate POS. The attributed, immutable override audit trail this claim describes cannot exist in the product as publicly documented.

labor-native-scheduling differentiator

Thanx holds no timekeeping data to schedule against and publishes no scheduling surface. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. All 101 dated first-party announcements on thanx.launchnotes.io (2025-01 to 2026-08, read in full) fall under the vendor's own 11-area product taxonomy - Integrations, Ordering, Loyalty, Guest Engagement, Marketing Automation, Toast, ThanxAI, Offers & Rewards, Reporting & Insights, Org Management & Settings, App Experience - which contains no labor or inventory area. The word 'schedule' appears in the changelog only for campaign and content-block scheduling ('scheduled targeted content blocks'), never for staff shifts; every 'shift' token in the developer docs is part of 'Redshift', a data-export destination. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-demand-labor-forecast differentiator

The data-model reference enumerates every object Thanx holds and exports: 'Campaigns, Communication Preferences, Memberships, NPS Feedback, Points Accounts, Points Transactions, Programs, Purchases, Rewards'. There is no schedule, shift, employee, labor-hour or forecast model, so there is no input or output a labor forecast could be built from. Corroborated on the merchant console itself: 'forecast' and 'staffing' occur zero times in dashboard.thanx.com/static/js/main.568d2c06.js (7,999,311 chars, fetched 2026-09-04); the only 'labor' strings are RecoveryAI ROI marketing ('Est. labor cost saved'), and the console's role list (Admin, Location manager, Marketing manager, Customer service, Accountant) contains no scheduling surface. This is an enumeration of the right object — the platform's own data models — not an absence of search hits. https://docs.thanx.com/data/overview · retrieved 2026-09-04 adversarially verified

labor-realtime-labor-percent differentiator

Labor cost as a percentage of sales requires wage and hours data, and Thanx holds the sales side only. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. This is the sibling case to labor-demand-labor-forecast and lands the other way for a stated reason: a staffing recommendation takes sales as its input, which Thanx has, whereas a labor percentage needs wages and hours, which the completeness sentence says the platform does not hold. Thanx also ships no manager view or POS screen of its own on which such a figure could be displayed during service. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-overtime-prevention differentiator

An overtime warning or block at clock-in requires both a clock-in and accumulated hours; Thanx has neither. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. Zero occurrences across the 778,290-character corpus of: punch, timecard, time card, payroll, overtime, clock-in, gratuity, inventory, recipe, ingredient, supplier, purchase order, par level, waste or commissary; the single occurrence of 'employee' is a tag-key case-sensitivity example. help.thanx.com is walled (302 to a dashboard.thanx.com SSO login; its Help Center API returns 401), so the merchant admin UI is not directly readable; the finding rests instead on the platform's own enumeration of the data it holds. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-break-compliance-by-state differentiator

Meal and rest break rules, break attestation and missed-break premium flags all attach to timecard entries. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. Zero occurrences across the 778,290-character corpus of: punch, timecard, time card, payroll, overtime, clock-in, gratuity, inventory, recipe, ingredient, supplier, purchase order, par level, waste or commissary; the single occurrence of 'employee' is a tag-key case-sensitivity example. No jurisdictional labor-rule configuration exists anywhere in the published surface. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-fair-workweek-support

Predictive-scheduling support requires a published schedule to measure advance notice against; Thanx publishes no schedules and holds no shift data. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. All 101 dated first-party announcements on thanx.launchnotes.io (2025-01 to 2026-08, read in full) fall under the vendor's own 11-area product taxonomy - Integrations, Ordering, Loyalty, Guest Engagement, Marketing Automation, Toast, ThanxAI, Offers & Rewards, Reporting & Insights, Org Management & Settings, App Experience - which contains no labor or inventory area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-minor-labor-rules

Minor-labor enforcement acts at scheduling and at clock-in; Thanx performs neither. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. No employee record, date of birth, age or availability field exists in any of the nine tables. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-tip-pooling-rules

Thanx does not ingest tips at all, let alone pool them. The basket-lifecycle integration guide is explicit that the loyalty-eligible amount is 'subtotal + tax - discounts', instructing integrators to 'Include tax; exclude tips' and 'Do not send the order's grand total (which includes tips)'. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. - no tip, employee or shift table exists. The vendor's own account of tip handling on its orders points outward: the Toast Revenue Centers announcement (2026-08-14) says 'Tip-distribution platforms like Tip Haus read the Revenue Center on each order to route tips correctly', i.e. distribution is performed by a third-party platform off the operator's POS data, not by Thanx. https://docs.thanx.com/overview/guides/basket-lifecycle · retrieved 2026-09-01

labor-tip-distribution-audit-trail

There is no per-shift, per-employee tip ledger to export because Thanx holds neither shifts, employees nor tips. The Toast Revenue Centers announcement (2026-08-14) describes the point of the feature as letting an external tool do this work: 'Tip distribution works without intervention. Tip-distribution platforms like Tip Haus read the Revenue Center on each order to route tips correctly.' Corroborating: the basket-lifecycle API guide instructs integrators to exclude tips from the amount sent to Thanx, and docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. https://thanx.launchnotes.io/announcements/toast-revenue-centers · retrieved 2026-09-01

labor-qualified-tips-w2-reporting differentiator

W-2 Box 12 code TP and Box 14b reporting is a payroll-export capability, and Thanx neither runs payroll nor receives tip amounts. The basket-lifecycle guide tells integrators to 'Include tax; exclude tips' and not to send the grand total 'which includes tips', so no tip figure - cash or charged - ever enters the platform. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. No occurrence of 'payroll', 'W-2', 'tipped occupation' or 'gratuity' exists in the 168-page corpus. https://docs.thanx.com/overview/guides/basket-lifecycle · retrieved 2026-09-01

labor-native-payroll differentiator

Thanx does not process payroll: there is no wage, tax, deduction or direct-deposit entity. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Thanx is a loyalty/CRM and digital-ordering platform sold alongside the operator's POS; it ships no payroll product, and the vendor's own product navigation on www.thanx.com lists no labor area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-payroll-export-formats

Thanx has no timecards, wages or tips to export and names no payroll provider integration. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. A second under-listing on the same host is corrected here rather than repeated: the overview's Thanx Connex destination TABLE has sixteen rows, but the site publishes twenty-three /data/connex/ destination pages (the extras are AWS Postgres, AWS MySQL, Redshift Serverless, S3-Compatible, MotherDuck, Delta Lake, Iceberg, MongoDB, Oracle and SFTP). Enumerating the larger set does not change the answer: every destination is a warehouse, database, object store, SFTP target or Google Sheets, and none is a payroll provider. No Gusto, ADP, Paychex or QuickBooks payroll integration appears anywhere in the 168-page corpus. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-shift-swap-workflow differentiator

Shift swaps and open-shift claims presuppose a schedule and an employee-facing app; Thanx's only apps are guest-facing loyalty and ordering. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. There is no shift, schedule, role-eligibility or overtime concept in the platform and no manager approval workflow over one; "shift swap" and "shift trade" return zero hits across the whole documentation corpus. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-digital-onboarding-i9

New-hire onboarding, W-4 and I-9 collection and E-Verify are HR functions with no surface in Thanx; the platform's only person entity is the guest (memberships). Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "W-4", "I-9" and "E-Verify" return zero hits across the documentation corpus, and the twenty-one "onboarding" hits are all consumer onboarding and authentication guidance for the guest app. https://docs.thanx.com/data/overview · retrieved 2026-09-01

labor-server-performance-metrics differentiator

Thanx cannot report by server or cashier because it never receives that dimension. The purchases data model is a complete column enumeration - purchase_id, purchase_uid, merchant_id, user_id, card_id, order_id, location_id, location_name, location_street, location_zip, location_category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider - with no employee, server, cashier, void, comp or line-item field, and the schema policy at /data/changelog governs every export column. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Thanx's reporting product (Insights Lab) is guest- and location-centric across every report named in the changelog; none is by server. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-01

inventory-recipe-bom-costing

Migrated from the 2026-08-01 research pass; no source URL was recorded.

inventory-unit-conversion-yields

Migrated from the 2026-08-01 research pass; no source URL was recorded.

inventory-theoretical-vs-actual differentiator

Theoretical-versus-actual variance needs recipes, physical counts and receipts; Thanx holds none of the three. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-realtime-depletion differentiator

Thanx tracks no ingredient on-hand quantities to deplete, and "inventory", "ingredient", "recipe" and "on-hand" return zero hits across the corpus. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-86-auto-sync differentiator

Thanx is a downstream consumer of 86 state, not a producer of it: it holds no ingredient or on-hand data from which to trigger an 86, and it does not push availability to the POS or to third-party delivery menus. The 86'd items visibility control announcement (2026-04-09) describes the whole of its 86 surface as a display setting on its own menus - 'Brands can now choose how out-of-stock items and modifiers display on their Thanx digital ordering experiences', either 'Display as Not Available (default)' greyed out or hidden entirely, with a category hiding when every item in it is 86'd. The 86 decision itself arrives from the POS or ordering middleware. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. https://thanx.launchnotes.io/announcements/live-86ed-items-visibility-control · retrieved 2026-09-01

inventory-count-modes

Migrated from the 2026-08-01 research pass; no source URL was recorded.

inventory-mobile-count-offline

There is no counting app because there is no inventory ledger to count into; Thanx ships no operator-side mobile app at all. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "count sheet", "barcode" and "stock count" return zero hits (the corpus's "count" tokens are "account"). Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-vendor-catalogs-edi differentiator

Thanx transmits no purchase orders and receives no supplier invoices. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "supplier", "distributor", "purchase order", EDI on a word boundary, "Sysco", "US Foods" and "Performance Food Group" all return zero hits across the corpus; the 161 apparent EDI matches in an earlier substring count were fragments of other words and are withdrawn. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-invoice-ocr differentiator

Thanx ingests no supplier invoices; "invoice" returns zero hits across the corpus. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. The only document-ingest surface in the platform is consumer receipt upload for loyalty credit, which credits a guest's points and writes nothing to any inventory or accounts-payable ledger. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-price-change-alerts differentiator

Per-item purchase price history across invoices requires a receiving and accounts-payable ledger; Thanx has none. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. The only cost concept published anywhere in the platform is the rewards model's estimated_cost, whose definition states the value is based on COGS defined by the merchant or on estimated margins - cost is an input the operator supplies, not a per-item received price Thanx tracks over time. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-par-auto-suggest differentiator

Thanx maintains no par levels and generates no suggested purchase orders. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "par level", "reorder point" and "purchase order" return zero hits across the corpus. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-waste-logging

There is no waste or spoilage workflow, no inventory ledger to debit and no waste-cost line to report. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "waste", "spoilage" and "shrink" return zero hits across the corpus. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-transfers

Inter-location transfers require an on-hand balance at each location to credit and debit; Thanx stores per-location purchase and loyalty data only. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Every "transfer" token in the corpus was read in context today: all seventy-nine word-boundary matches refer to data-pipeline transfer windows, transfer service accounts or funds settlement, never to stock movement. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-commissary

Thanx supports no production, issuing or transfer-cost model. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. "commissary", "central kitchen", "prep item" and "production" return zero hits across the corpus; Thanx's multi-location model is a brand's locations for loyalty, ordering and reporting, not a supply chain. Thanx's order pipeline submits orders into the operator's POS (Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect); any inventory function lives in that POS or its inventory partner, not in Thanx. The vendor's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI, with no inventory or supply-chain area. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-lot-traceability

No lot or batch capture exists because there is no receiving step to capture it at. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity. Verified independently on 2026-09-01 by fetching every page under /data/ as markdown (37 pages) and the whole published documentation corpus in one request from docs.thanx.com/llms-full.txt (725,958 bytes, 200 page bodies, a superset of the 174 pages listed in docs.thanx.com/llms.txt): zero occurrences of 'lot number', 'batch number', 'traceability', 'recall', 'inventory', 'recipe' or 'supplier' anywhere in it, and zero in the /data/ pages. All 101 dated first-party announcements on thanx.launchnotes.io fall under the vendor's own 11-area product taxonomy (Integrations, Ordering, Loyalty, Guest Engagement, Marketing Automation, Toast, ThanxAI, Offers & Rewards, Reporting & Insights, Org Management & Settings, App Experience), which contains no inventory area. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-shelf-life-expiry

Thanx tracks no use-by dates on goods. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity. Verified independently on 2026-09-01 by fetching every page under /data/ as markdown (37 pages) and the whole published documentation corpus in one request from docs.thanx.com/llms-full.txt (725,958 bytes, 200 page bodies, a superset of the 174 pages listed in docs.thanx.com/llms.txt): zero occurrences of 'shelf life', 'use-by', 'use by', 'spoilage' or 'inventory'. The platform's only expiry concepts are guest-facing and I re-read them on the model pages - expiration_at and retired_at on the rewards model, and points expiration on points_transactions - not product shelf life. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-bar-partial-bottle

Partial-bottle counting by weight or fraction presupposes a beverage inventory ledger and a scale integration; Thanx has neither. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. - zero occurrences of 'bottle', 'scale', 'pour' or 'liquor'. Thanx sells no hardware of any kind. https://docs.thanx.com/data/overview · retrieved 2026-09-01

inventory-cogs-gl-export

Thanx neither computes COGS nor holds accounts-payable invoice detail, so there is nothing to export in an accounting system's format. Its own rewards data model defines the single cost field it publishes as derived from someone else's numbers: estimated_cost is 'The estimated cost of the reward. This value is based on COGS defined by the merchant, or estimated margins.' docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. - no GL account, item-category mapping or AP entity exists. The published export destinations are warehouses and file stores plus SFTP CSV; no QuickBooks, Sage Intacct or NetSuite integration appears in the corpus or the 101 changelog entries. https://docs.thanx.com/data/models/rewards · retrieved 2026-09-01

inventory-native-not-partner differentiator

Thanx delivers no inventory or recipe costing at all - natively or otherwise - so the native-versus-partner question resolves to absence rather than to a partner dependency. docs.thanx.com/data/overview states the SFTP export is 'a snapshot of the entire data set resident within the Thanx platform' and lists nine models - campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards - each with a published column reference and all governed by one schema-change policy at /data/changelog. That list UNDER-LISTS the vendor's own documentation and is not itself the enumeration: a tenth published model, /data/models/loyalty-reward-progress-legacy, returns HTTP 200 and is carried by docs.thanx.com/llms.txt while being absent from this page's list (verified 2026-09-01; a fabricated /data/models/ slug returns 404 at 4 bytes). The argument rests on the self-completeness SENTENCE quoted above, never on the bullet count. No timecard, shift, tip, inventory, recipe, supplier or invoice entity appears in any of them, and the only staff-related field in the whole schema is nps_feedback.responded_by, 'The name of the staff member who responded to the user' - a free-text name on a guest-feedback row, which is not an employee entity and carries no hours, wage, role or identifier. Enumerated the entire published Thanx developer documentation: 168 pages, independently enumerated twice on 2026-09-01 by docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml, which agreed exactly (zero pages in one and not the other, all 168 fetched 200, a fabricated slug 404s). Its only top-level trees are consumer, partner, loyalty, webhooks, data, ai and overview. - zero occurrences of 'inventory', 'recipe' or 'ingredient'. The one cost figure the platform publishes, rewards.estimated_cost, is explicitly 'based on COGS defined by the merchant', i.e. costing is performed outside Thanx and supplied to it. All 101 dated first-party announcements on thanx.launchnotes.io (2025-01 to 2026-08, read in full) fall under the vendor's own 11-area product taxonomy - Integrations, Ordering, Loyalty, Guest Engagement, Marketing Automation, Toast, ThanxAI, Offers & Rewards, Reporting & Insights, Org Management & Settings, App Experience - which contains no labor or inventory area. https://docs.thanx.com/data/models/rewards · retrieved 2026-09-01

inventory-menu-margin-linkage differentiator

Contribution margin per menu item requires recipe cost joined to item sales mix; Thanx holds neither. Re-fetched docs.thanx.com/data/models/purchases on 2026-09-01: it publishes the complete column list for the purchases model - purchase_id, purchase_uid, merchant_id, user_id, card_id, order_id, location_id, location_name, location_street, location_zip, location_category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider - with no item, quantity, modifier or cost field, so a Thanx purchase record carries a total but not a basket. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity; none of the ten carries recipe or ingredient cost. Verified independently on 2026-09-01 by fetching every page under /data/ as markdown (37 pages) and the whole published documentation corpus in one request from docs.thanx.com/llms-full.txt (725,958 bytes, 200 page bodies, a superset of the 174 pages listed in docs.thanx.com/llms.txt): zero occurrences of 'recipe', 'ingredient', 'line item' or 'inventory'. No margin-threshold alerting appears in the schema changelog at /data/changelog, whose only 2025-2026 entries add pos_id, pos_provider, alternate_pos_id, redemption_pos_order_id, redemption_pos_provider and reward discount/estimated_cost accuracy. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-01

reporting-realtime-dashboard

Thanx runs a browser merchant dashboard whose purchase data lands fast: the in-store purchase-data announcement states 'In-store data updates in near real-time, typically within 2 minutes of a transaction' and that item-level in-store check-in data 'flows automatically into Thanx', appearing in Segments, the Guest Profile account-activity tab and Feedback order details; the sandbox FAQ's latency table gives production purchase processing as 'Near real-time' against 15-30+ minutes in sandbox (docs.thanx.com/overview/sandbox-faq). Revenue and order views exist in the dashboard (Revenue at select location(s), Orders by client / by handoff mode with day/week/month/quarter/year grouping). Shortfalls, both material: (1) the feed is not a sales feed - it covers loyalty-identified purchases (check-in, card-linked or Thanx digital orders) and the Weekly location summary warns 'Capture rate data will populate only for merchants using an integrated POS or uploading POS data to the dashboard', so unidentified walk-in sales are simply absent; (2) no merchant-facing mobile app is documented anywhere on docs.thanx.com, thanx.launchnotes.io or www.thanx.com - the Thanx apps are guest apps, and the off-premise limb of this claim is unmet. https://thanx.launchnotes.io/announcements/in-store-purchase-data-now-available-for-qu-square-par-and-ncr-brands · retrieved 2026-09-01

reporting-eod-closeout

Migrated from the 2026-08-01 research pass; no source URL was recorded.

reporting-pmix-modifier-level

Item-level product mix exists in a narrow form. The 2025-12-16 platform-data entry names 'Top 25 items in digital orders' as one of three digital-ordering campaign reports made 'available to all merchants using Thanx digital ordering - not just Olo customers', and the 2026-02-05 in-store data entry adds that check-in transactions now carry 'the specific items, quantities, and amounts from each order' for Toast, Qu, Square, PAR and NCR brands. Shortfalls: (1) it is a top-25 list scoped to digital orders, not a full PMIX of every item; (2) nothing at modifier level is reported - modifiers surface only as a SegmentAI targeting input ('build segments based on modifier purchase behavior', 2026-03-04), and the same in-store entry says 'Segment AI for SKU data currently targets online ordering only'; (3) no daypart or revenue-centre filter is documented - the digital order reports offer day/week/month/quarter/year grouping and a location table only, and Toast Revenue Centers is an outbound tagging setting so Thanx orders reconcile in TOAST's reporting, not a Thanx report dimension; (4) card-linked transactions 'record the total transaction amount only, not individual items'. https://thanx.launchnotes.io/announcements/platform-data-improvements-sftp-reports-and-credit-card-logos · retrieved 2026-09-01

reporting-comps-voids-audit

Thanx has no register and no employee or manager record, so there is nothing for this audit to be attributed to. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. The only discount Thanx holds is the rewards model's per-reward discount field, which the 2025-05-30 SFTP changelog entry says reflects the discount reported back by the POS provider; there is no applying employee, no approving manager, no reason code, no price-override and no void concept. Thanx's own loyalty-models guide puts the comp on the other side of the integration, naming "Manager comp" as the POS-side mechanism by which staff apply a Thanx reward at the register. Consistent with this record's existing no on labor-clock-in-at-pos, labor-granular-rbac and reporting-eod-closeout. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-cash-over-short

Thanx never touches a cash drawer. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Nothing in the resident data set records a tender type, a drawer, a declared count or a paid-out: purchases arrive from the card networks, from Thanx-managed digital ordering or from POS check-in and carry only authorization_amount and settlement_amount. Drawer reconciliation stays on the POS the brand already runs (integrations documented for Toast, Square, Qu, PAR/Brink, NCR Aloha, Olo, Deliverect). No dashboard can reconcile counted against expected cash from data that records neither. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-labor-productivity

Thanx holds no clocked hours and no employee record, and this claim names the POS time clock as its input. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. The claim's stated input - actual clocked hours from a POS time clock - has no representation in the resident data set, and this record already scores no on labor-clock-in-at-pos. This is why the reporting/dashboard objection that moved labor-demand-labor-forecast to unknown does not reach here: that claim takes SALES as its input and Thanx demonstrably holds sales, whereas sales per labor hour and labor cost as a percentage of sales cannot be computed from data the platform's own completeness sentence says it does not hold. Thanx's own product navigation on www.thanx.com enumerates Loyalty, Digital Ordering & Apps, Marketing Automation, CRM & Segmentation, Offer Management, Guest Recovery, Reporting & Analytics, Thanx Data Platform and ThanxAI - no labor area - which corroborates without carrying the finding. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-server-scorecards differentiator

Per-server metrics require a server identity on the sale, and no purchase in the Thanx export carries one. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Purchases are attributed to a merchant, a location, a guest and a card or POS order id - never to the person who rang the sale - so average check, items per check and attachment rate are reported by Thanx per LOCATION and per GUEST instead, and tips have no field at all. The dashboard objection does not reach this cell either: a per-server cut cannot be computed from data with no server dimension, and nps_feedback.responded_by (a free-text staff name on a feedback reply) is not attached to purchases. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-channel-profitability differentiator

Channel reporting exists but is two-valued and gross. The 2026-06-17 digital order reports entry states 'Brands can now view orders, purchases, revenue, and unique active customers by channel and by location with this dynamic date grouping in the Insights Lab', covering the 'Orders by client' and 'Orders by handoff mode' reports (handoff modes named elsewhere as pickup, delivery, curbside and more), and 'Revenue at select location(s)' shows 'weekly net revenue attributed to loyalty members, broken down by in-store and digital channels' (2025-08-06). 'Channel preference' is a Recommended report (2026-08-12). Shortfalls: the platform's channel field is a two-value enum, 'digital' or 'instore' (docs.thanx.com/data/models/purchases), so dine-in, first-party delivery and each third-party marketplace are not separated; and no commission, fee or margin field exists in any of the nine exported models, so nothing is reported net of marketplace commission. https://thanx.launchnotes.io/announcements/digital-order-reports-new-date-grouping-and-location-filtering · retrieved 2026-09-01

reporting-multiloc-drilldown differentiator

Consolidated multi-location comparison is documented in detail. The report catalogue ('Insights Lab is now All reports', 2026-08-12) names Weekly location summary, Activation by location, Revenue at select location(s) and Active customers at select location(s) among Recommended reports, each filterable to one or more locations; the digital order reports carry 'a location table at the bottom of each report ... across all your locations'; Engaged customers per location and Active customers at select location(s) are explicitly designed to be 'used side by side' (2026-01-23); and the 1st Purchases and App Adoption by Location report offers an interactive map plus detailed per-location tables to 'compare app adoption rates across locations'. Shortfall: the drill-down stops at the location. No report is documented as drilling through to an individual transaction; the only transaction-level view named anywhere is the per-guest one (Customers > All Customers > Account Activity, and Feedback order details), which is reached from a guest record rather than from a group total. Access is also location-scoped by role, so a location user sees only assigned locations. https://thanx.launchnotes.io/announcements/update-insights-lab-is-now-all-reports-with-favorites-built-in · retrieved 2026-09-01

reporting-custom-report-builder differentiator

What Thanx ships is a curated catalogue with filters and saved views, not a builder. All reports is 'organized into three sections: Browse all reports to search your full report catalog, Favorite reports ... and Recommended reports', and a favourite can be saved with 'a custom name and description, which is useful for saving a specific filtered view' - the worked example is Top 50 customers filtered to one location and saved as 'Top 50 customers - Sandy UT, last 1yr', which reopens to that exact filtered view (2026-08-12). Filters themselves are per-report and fixed: date range, one or more locations, and a 'Group dates by' control (day/week/month/quarter/year). Shortfall: a non-developer cannot choose dimensions and measures. There is no field picker, no measure selection and no blank-canvas report anywhere in the announcement archive; the documented route to a report that does not exist is to ask Thanx for it - the Insights Lab launch entry instructs merchants to 'Request new reports if you can't find what you're looking for' (2025-06-12). Note that the merchant help centre is walled (help.thanx.com/hc/en-us 302s to a dashboard.thanx.com SSO login and its Help Center API returns 401), so a builder documented only to signed-in merchants would not be visible here. https://thanx.launchnotes.io/announcements/update-insights-lab-is-now-all-reports-with-favorites-built-in · retrieved 2026-09-01

reporting-scheduled-delivery

Scheduled email delivery exists, in one folder. The Weekly location summary 'is designed to be delivered weekly to franchisees, regional leaders, and location managers who may not have access to the Thanx dashboard', and 'Email deliveries can be scheduled by accessing the report in the Summary Reports folder in the Insights Lab' (2025-10-28). Shortfalls against 'any report ... on a defined cadence and recipient list': the documented scheduling surface is the Summary Reports folder rather than the whole catalogue; the recipient list is not self-service - the same entry says 'If you have questions about subscribing colleagues to this email report, please contact Customer Success at success@thanx.com'; and no cadence choice beyond the report's own weekly design is documented. The merchant help centre that would carry the admin procedure is walled (help.thanx.com 302 to SSO, Help Center API 401), so a broader scheduler may exist unseen. https://thanx.launchnotes.io/announcements/new-in-thanx-insights-lab-weekly-location-summary · retrieved 2026-09-01

reporting-raw-warehouse-export differentiator

Directly documented, and broader than the claim asks. docs.thanx.com/data/overview: 'For access raw data from the Thanx platform, we provide the following access mechanisms' - SFTP Exports ('updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format ... available to all Thanx merchant customers', with multi-file exports removing the 10M-record cap and splitting into 5GB files 'Recommended for programmatic integrations and automated data pipelines'), Snowflake Secure Data Sharing (account-to-account share, no copy, AWS us-east-1 only), and Thanx Connex, 'fully managed loading of structured Thanx data directly into a variety of data destinations' - a 16-row destination table covering Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, Postgres/AWS Postgres, MySQL/AWS MySQL, SQL Server, S3, S3-compatible, Google Cloud Storage, Azure Blob Storage and Google Sheets. 'Thanx manages creation of data schema, ongoing syncing of data, and fully managed schema management'; setup ends 'Wait for your data ... incremental data will be synced every 24 hours' (docs.thanx.com/data/connex/setup). The exported grain is transaction-level: the purchases model is one row per purchase with authorization_amount, settlement_amount, channel, location and pos_id. A published schema-management policy and a dated schema changelog back it (docs.thanx.com/data/changelog). Not manual CSV download, and to a customer-controlled destination as the claim requires; the only frictions are a 24-hour cadence and setup coordinated through a Thanx success manager. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-public-api differentiator

Thanx publishes a real, complete REST reference - 168 pages on docs.thanx.com (llms.txt and sitemap.xml agree exactly, all 168 fetched 200 on 2026-09-01), covering a Consumer API (users, SSO, cards, rewards, points, tiers, purchases, receipts, gift cards, feedback), a Partner API (merchants, locations, users, subscribers, campaigns, promotions, reward templates, issuance jobs), a Loyalty API for POS/kiosk baskets, and webhooks, with request and response schemas and per-endpoint examples. Two shortfalls against this claim as worded. Coverage: orders and payments are present (Loyalty API baskets, POST /purchases, purchase webhooks) but there is no menu API and no labor API at all - the 168-page index contains no menu-management or labor page, and Thanx's own model is that the menu lives in the POS or middleware. Credentials: not self-service. The integration guide routes a new developer through Partnerships scoping, then 'Thanx provides sandbox credentials and access for testing' from Developer Support, then a certification review - 'You demo your integration via video call ... You must submit a product guide ... Once complete, Thanx provides production API keys'. The sandbox FAQ repeats it: 'Sandbox credentials (client ID, client secret, merchant key, partner token, and test user) are provided by Thanx Developer Support during onboarding.' There is no signup form and no self-issued key. https://docs.thanx.com/overview/integrating · retrieved 2026-09-01

reporting-webhooks differentiator

Outbound webhooks are documented with a signed payload and a purchase lifecycle, but retry is documented as absent rather than as behaviour. Present: HTTPS POST to a customer-supplied endpoint with optional static query parameters; six event families (purchases, reward-issued, reward-batch-completed, communication-settings, sms-subscriptions); a purchase payload carrying id, user, merchant, location, purchased_at, amount, order (id and provider enum OLO|Toast|Other) and products; and signature verification - 'each webhook request includes a X-Thanx-Signature header ... a hex-encoded HMAC-SHA256 signature of the request payload, using a webhook secret', with Ruby and Python verification examples. Payment lifecycle is covered: 'a single purchase is re-sent as it moves through authorization and settlement, and across payment rails'. Shortfalls: (1) 'By default, webhooks are not configured to retry if the receiving server responds with an error. Any missed data can be collected via bulk data transfer mechanisms' - delivery is 'best-effort ... so delivery of any single event is not guaranteed', duplicates are 'the common case', and the payload 'carries no delivery sequence or timestamp'; (2) enablement is not self-service - 'If you are an existing integration partner, please reach out to our team at developer.support@thanx.com to have webhooks enabled'; (3) product detail may be missing from the first delivery, since purchase webhooks fire 10 minutes after capture and in-store item data may not have landed. https://docs.thanx.com/webhooks/overview · retrieved 2026-09-01

reporting-api-not-upcharged differentiator

Raw data is stated as included; the API side is gated by process rather than by a published fee. In favour: SFTP exports, the whole-platform CSV snapshot, are 'available to all Thanx merchant customers' with no fee mentioned (docs.thanx.com/data/overview), and Thanx does state inclusion explicitly when it applies elsewhere ('included with your Thanx plan at no extra charge', Genius for Enterprise, 2026-04-01; App-less 'available to all Thanx brands at no extra charge', 2025-08-07). Shortfalls: (1) API access is not simply included - production keys follow a Partnerships scoping engagement and a certification review (docs.thanx.com/overview/integrating), and bulk partner data access additionally requires that 'a Master Data Agreement (MDA) must be in place and a merchant must grant explicit data access approval'; (2) the richer export routes - multi-file exports, Snowflake Secure Data Sharing and every Thanx Connex destination - are each arranged through a success manager who will 'work with you on the specifics', and no commercial terms are published for them; (3) Thanx publishes no plan or tier structure at all (www.thanx.com/pricing prices on restaurant count and AUV), so nothing states these are outside a per-location fee or revenue share. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reporting-tier-paywall differentiator

The reporting Thanx does ship is not tier-gated. The analytics suite is stated as universal: Insights Lab is 'Available to all merchants expect [sic] Malls (due to additional data sharing restrictions)' (2025-06-12), the campaign reporting suite carries the same availability line (2025-12-01), and digital-ordering campaign reports were opened to 'all merchants using Thanx digital ordering - not just Olo customers' (2025-12-16). No analytics add-on SKU appears anywhere in 101 announcements or 168 doc pages, and www.thanx.com/pricing publishes no plan tiers at all - it prices on restaurant count and AUV. Shortfalls: (1) access is role-gated, 'Available to admins (to ensure sensitive data isn't being shared across roles)', with location users scoped to their own locations; (2) Mall merchants are excluded outright, including from Favorites and Recommended reports; (3) three of the four report families this claim names - labor vs sales, PMIX and comps/voids - are not Thanx surfaces at all (see reporting-labor-productivity, reporting-pmix-modifier-level, reporting-comps-voids-audit), so only the multi-location limb can be tested against a tier; (4) with no published plan structure, the absence of a higher-tier requirement is inferred from universal-availability statements rather than from a plan matrix. https://thanx.launchnotes.io/announcements/introducing-thanx-insights-lab · retrieved 2026-09-01

reporting-history-retention differentiator

Thanx states no retention window in months anywhere it publishes. The changelog answer previously cited for this cell — 'How far back does the data go? Back to when your POS integration launched or when your brand went live on Thanx, whichever is later. NCR merchants already have this data from launch — no backfill needed.' — is the scope of a one-time BACKFILL announced alongside item-level in-store purchase data for Qu, Square, PAR and NCR check-in brands, read in full 2026-09-04; its sibling answers are 'Which brands get this?', 'Does backfilled data generate loyalty points? No' and 'How quickly does in-store data appear?'. It is not a retention policy and names no number of months. What is established: transaction detail is queryable over an open-ended window in the console — the shared dateRangeFilter offers 'Last 30 days', 'Last 90 days', 'Past Year', 'All time' and 'Custom date range', behind which sit a 'Purchases' report and an 'All purchases by SKU' tab (dashboard.thanx.com/static/js/main.568d2c06.js, 7,999,311 chars, read 2026-09-04) — and no truncation or archive-retrieval fee is documented: docs.thanx.com/data/overview calls SFTP exports 'a snapshot of the entire data set resident within the Thanx platform', the 10-million-record cap applies only to single-file exports and multi-file exports 'eliminate' it, and the Merchant Agreement's Fees article names only SMS and delivery charges. SHORTFALL: no documented retention window of any length for transaction-level detail. The only 24-month affordance in the product is the '6 months / 12 months / 24 months / All time' timespan selector on the lifecycle conversion-rate chart — a cohort metric, not a transaction-detail report — and the shared date filter tops out at 'Past Year' before 'All time'. https://thanx.launchnotes.io/announcements/in-store-purchase-data-now-available-for-qu-square-par-and-ncr-brands · retrieved 2026-09-04 adversarially verified

reporting-anomaly-alerts differentiator

The webhook catalogue is the platform's complete push-notification surface and every event is a resource change, not a metric deviation: purchases, reward-issued, reward-batch-completed, communication-settings, sms-subscriptions — 'These webhooks allow for integrating platforms to respond in realtime to changes to data resources in the Thanx platform.' The merchant console confirms there is no threshold-alert configuration on any report: 'anomaly' occurs zero times in dashboard.thanx.com/static/js/main.568d2c06.js (read 2026-09-04), and its only threshold objects are reward thresholds, a RecoveryAI daily credit cap and a guest complaint threshold. What the console does ship is event-based, not metric-based: 'Review your order feedback notifications — Choose who gets notified about feedback that isn't handled automatically.' Proactive email exists; an operator-configured metric threshold or deviation alert does not. https://docs.thanx.com/webhooks/overview · retrieved 2026-09-04 adversarially verified

reporting-nl-query

Thanx ships an AI assistant over the operator's own guest and purchase data, but it answers with an audience rather than a figure. SegmentAI is 'Thanx's AI-powered segment builder' (Customers > SegmentAI): a merchant describes a target in natural language and Thanx generates segment rules over its own data, with location and user-tag pickers, timezone awareness and an explicit restatement of the targeting criteria before creation (2026-03-25); 'View segment' opens 'a popup showing the segment summary, rules, and a sample of the included customers' (2026-04-13); segments can target in-store purchase behaviour by item name, category, frequency or spend and modifier purchase behaviour (2026-02-05, 2026-03-04); and AI-generated segments can now activate without Thanx review (2026-04-30). Shortfalls: the output is a segment and a customer sample, not a figure or chart answering an ad-hoc analytical question; nothing lets an operator ask a question of the reporting data - the report catalogue is browsed, starred and filtered, and the documented route to an answer a report does not give is 'Request new reports'; and there is no labor data to query at all. The only natural-language interface on docs.thanx.com is the Docs MCP Server (docs.thanx.com/ai/overview), which searches the API documentation - explicitly the generic-help-article case this claim excludes. https://thanx.launchnotes.io/announcements/new-in-segmentai-view-segment-details-in-builder · retrieved 2026-09-01

reporting-guest-cohorts differentiator

This is the centre of the Thanx product and it is documented report by report. Cohorts: the Days to 1st, 2nd and 3rd Purchase report gives 'Three cohort tables ... joining to 1st, 1st to 2nd, and 2nd to 3rd. Each table shows the percentage of customers who converted within 30, 60, 90, 120, 150, and 180 days', with 'rows are joined month cohorts' and heat-mapped cells (2026-04-02). Lifetime spend: Top 50 customers ranks guests by 'Total spending, Digital spending, In-store spending, Avg check, Visits, Locations visited', filterable by location and time frame (2025-07-31), with customer names added (2026-01-26). New versus returning: 1st Purchases and App Adoption by Location shows 'how many customers made their first purchase at each location' (2025-08-06), while Engaged customers per location defines engaged as 'loyalty members with 3+ lifetime purchases who have purchased in the last 90 days' and Active customers at select location(s) counts unique members purchasing weekly by digital and in-store channel (2026-01-23). Visit frequency is the Visits column and the activation definition ('3+ purchases within their first 120 days'). All of it is tied to identifiable guest records: the underlying memberships model carries user_id, name, email, phone, birthday, zip, tier_status and user_joined_at, and the Guest Profile shows a guest's item-level purchase history under Account Activity. Available to all merchants except Malls, to admin roles. https://thanx.launchnotes.io/announcements/new-in-thanx-insights-lab-days-to-1st-2nd-and-3rd-purchase-report · retrieved 2026-09-01

reporting-sales-forecast differentiator

The merchant console's own application bundle (/static/js/main.568d2c06.js, 7,999,311 chars, fetched 2026-09-04) contains the string 'forecast' zero times, across every report, chart, campaign and metric label in the product. Its analytics vocabulary is uniformly retrospective — 'Retention rate over time', 'Activation funnel (all time)', 'Revenue capture rate', 'Purchases', 'All purchases by SKU' — and its two named AI agents are SegmentAI and RecoveryAI (segmentation and guest recovery). 'Forecast' is likewise zero across the closed 168-page docs.thanx.com corpus and the 124-page www.thanx.com corpus. Thanx also holds no scheduling or purchasing workflow for a forecast to feed. The console is the right object for a claim about a forecast 'exposed in the reporting UI', and it does not contain one. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

reporting-tip-tax-compliance

Thanx holds no tip, employee or tax-jurisdiction data. Enumeration basis, re-measured first-hand 2026-09-01. The load-bearing sentence is the self-completeness assertion, not a bullet count: docs.thanx.com/data/overview states the SFTP export files "are a snapshot of the entire data set resident within the Thanx platform in CSV format". The earlier note's "exactly nine tables" is WITHDRAWN as false - the page's own Models list names nine but under-lists its own documentation, and a tenth published model, /data/models/loyalty-reward-progress-legacy, returns 200 and is carried by both docs.thanx.com/llms.txt and docs.thanx.com/sitemap.xml. All ten models were read column by column today: campaigns, communication_preferences, memberships, nps_feedback, points_accounts, points_transactions, programs, purchases, rewards and loyalty_reward_progress_legacy (the tenth carries only merchant_id, user_id and loyalty_reward_progress, and is itself loyalty data). The correction does not touch this claim: no timecard, shift, wage, tip, drawer, tender, paid-out, inventory, recipe, ingredient, supplier, purchase-order or invoice column exists in any of the ten. Purchases carry merchant_id, user_id, card_id, order_id, location_id/name/street/zip/category, authorization_amount, settlement_amount, channel, purchased_at, pos_id, pos_provider; rewards carry program, user, state, timestamps, estimated_cost and discount. One further overstatement is corrected: the export is not wholly staff-blind - nps_feedback.responded_by is "The name of the staff member who responded to the user" - but it is a free-text name on a feedback reply with no employee id, role, wage, hours or shift, and cannot carry any of the attribution this claim needs. Corroborating term census re-run today over docs.thanx.com/llms-full.txt (725,958 characters in one request, covering exactly the 168 pages on which llms.txt and sitemap.xml agree with zero difference): zero occurrences of payroll, time clock, clocked, timecard, wage, direct deposit, shift swap, W-4, I-9, inventory, recipe, ingredient, supplier, purchase order, EDI (word-boundary), invoice, waste, depletion, par level or commissary; "employee" occurs once, in an AWS tag-key case-sensitivity example. help.thanx.com was re-probed today and is genuinely walled (302 to /hc, then a Cloudflare "Just a moment..." 403; its Help Center API returns 401 "Couldn't authenticate you"), so the merchant dashboard is unreadable to us and is not being treated as evidence either way. Declared-versus-charged tips per employee additionally requires the employee record this platform does not have, and the single tip reference in the whole archive hands the function to somebody else: "Tip-distribution platforms like Tip Haus read the Revenue Center on each order to route tips correctly", which is why the 2026-08-14 Toast Revenue Centers feature exists. Tax is the same shape - Thanx orders are submitted into the operator's POS and no tax model, jurisdiction field or liability report exists on the Thanx side. https://docs.thanx.com/data/overview · retrieved 2026-09-01

multi-location-org-hierarchy

Thanx shipped role-based permissions on 2026-04-13: 'create custom roles with exactly the right level of access for each person on your team and scope those roles to specific locations... A franchisee sees only their stores... A regional manager sees their territory and nothing else.' Feature areas are Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences and Reporting, each set to No Access / Can View / Can Manage. Shortfalls, both stated in the same entry: (1) there is no named group or region OBJECT - scoping is done by assigning a list of individual locations to each USER ('Locations can also be assigned to users... If no locations are assigned, the user will have brand-wide access'), so a 'territory' is an ad hoc per-user list, not a first-class three-level hierarchy that other things can be scoped to; (2) reporting is not scoped by it - 'Insights Lab and Looker Labs reports don't support location scoping in this release', and 'Guest profiles are visible in full regardless of location assignment'. The object model confirms two tiers only: both the consumer and partner Get Locations endpoints return a location with merchant_id, address, name and phone and no parent, group, region or district field. https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

multi-location-central-menu-publish

Thanx is not the menu system of record and publishes no corporate menu-authoring surface. The Toast multi-menu announcement (2026-04-29) says brands 'can now launch and operate on Thanx using their existing menu structure', that 'Menu management all in Toast: Enable and manage all menus in your Toast dashboard', 'All management of your menus should be done in Toast', and that changes (new items, 86s, schedule changes) 'sync in ~5 minutes' into Thanx; the older alternative it replaces is a single 'Thanx-specific menu' whose new menus had to be enabled by Thanx staff, not published by the brand. The Olo entry (2026-08-27) is the same shape: 'you configure availability once in Olo. The Thanx ordering experience follows it.' The 2026-04-09 Settings-page entry enumerates the dashboard's ordering controls and describes menu configuration as belonging elsewhere: 'See exactly what ordering parameters like menu item images, category order, and pricing you can configure directly with your ordering provider and have Thanx honor automatically.' Nothing in the 168-page docs.thanx.com corpus or the 101 dated changelog entries describes authoring a corporate menu, publishing it to a chosen set of locations in one action, or a publish/version history of what was pushed, when and by whom. https://thanx.launchnotes.io/announcements/toast-multi-menu-visibility-now-available · retrieved 2026-09-01

multi-location-local-override-policy differentiator

The console's Ordering management screen states the authoring model outright: 'These locations are ingested from your ordering provider. View each location to troubleshoot errors.' The only per-location controls it offers are 'Enable ordering at this location' / 'Disable ordering at this location' plus a read-only 'Menu status' column and an error list; 'Automatic updates happen every 15 minutes' (dashboard.thanx.com/static/js/main.568d2c06.js, read 2026-09-04). There is no item editor, no price field, no per-field lock and no override object anywhere in the 8 MB bundle — Thanx holds no editable menu catalogue, so there is nothing for corporate to lock or for a store to override. That matches the release stream ('All management of your menus should be done in Toast'; Square as 'a single source of truth'). https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

multi-location-price-zones

One of the claim's three axes is documented as supported, so a flat `no` is too strong. The Square direct-to-POS entry (2026-07-10) answers "What pricing and modifier options are supported?" with "Item-based pricing, size-based pricing, nested modifiers, priced modifiers, and modifier images are supported, along with dynamic pricing by handoff mode" - one item record carrying a different price for pickup versus delivery, honored automatically in the Thanx ordering experience; the Deliverect entry (2026-08-11) carries the same idea as "handoff-specific menus (e.g., a different menu for pickup vs. delivery)". Shortfalls: (1) no per-location-group price tier and no daypart price rule is published anywhere - Toast dayparting is achieved with separate menus, which duplicates the item record, and the per-partner markup that exists on that path is Toast's own lever ("Toast supports per-partner price markup"), not a Thanx one; (2) Thanx authors no pricing at all - the 2026-04-09 Settings entry places it outside the dashboard ("See exactly what ordering parameters like menu item images, category order, and pricing you can configure directly with your ordering provider and have Thanx honor automatically"), so every tier is created and versioned in the POS or middleware, not in Thanx; (3) the one documented lever is enumerated only for the Square path, and that page frames its own list as a per-integration delta ("What's different on Square"). https://thanx.launchnotes.io/announcements/thanx-and-square-direct-to-pos-ordering · retrieved 2026-09-01

multi-location-scheduled-publish differentiator

Partial and only on the promo/content half. Scheduled & Targeted Content Blocks (2026-02-19) add to every app home-page block a 'Content Display Window (start date, end date, or both)' plus audience targeting: 'You can schedule a holiday promotion to run December 1-25 and disappear automatically when it ends.' Time-varying menus exist too, but the schedule is authored in the ordering provider and only read by Thanx: for Toast, 'time-of-day and day-of-week menus' with 'schedule changes... reflected in Thanx automatically' (2026-04-29), and for Olo, item time-of-day, day-of-week and date-range availability filtered against the guest's requested fulfilment time (2026-08-27). Shortfalls: (1) no price change can be scheduled in Thanx at all, since menu pricing is configured with the ordering provider (2026-04-09 Settings entry); (2) the scheduling controls are dates on a content block, with no statement anywhere in either first-party corpus that a future activation is interpreted in each target location's own timezone - the only timezone statement in the developer docs is that purchase timestamps are UTC; (3) no rollback or revert-after-activation mechanism is documented - a block is edited or its display window changed, and there is no version history. https://thanx.launchnotes.io/announcements/scheduled-targeted-content-blocks · retrieved 2026-09-01

multi-location-new-store-template differentiator

Locations are not provisioned in Thanx at all, so there is no configuration to clone: the console's Ordering management screen says 'These locations are ingested from your ordering provider' and 'Automatic updates happen every 15 minutes', and the bundle (read 2026-09-04) contains no location-creation form, no clone or duplicate-location action, and none of the objects the claim names — no tax, printer, tender or modifier configuration exists in the product to be templated. The Merchant Agreement covers adding a location contractually only ('Merchant may add Locations by providing written notice to Thanx at least fifteen (15) days prior to the desired launch date'), and the only published time-to-open — www.thanx.com/implementation's 'Go live in 90 days' — is the brand's first launch, not a new store's. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

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

The 2026-04-13 role-based permissions release is built for exactly this shape: 'Your dashboard can now mirror how your organization is actually structured whether that's a corporate team, regional managers, franchise operators, or outside agency partners... A franchisee sees only their stores.' Roles carry per-feature-area access (Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences, Reporting) at No Access / Can View / Can Manage, are assigned to users, and are then restricted to an assigned set of locations; the Operations Center entry (2026-06-23) confirms 'Access is location-scoped with view-vs-edit permissions, so any location specific users will only see their assigned locations.' Shortfalls: (1) this is delegated access within ONE merchant tenant, not a distinct franchisee tenant - only admins of the brand account can create roles and assign locations, a location manager 'cannot assign roles to their own staff', and there is no separate franchisee-owned account; (2) the franchisee-owned data the claim names does not exist in Thanx - the platform holds no employee, banking, payroll or labor objects (none appear among the exported data models: campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases, rewards); (3) the same entry warns the separation is incomplete - 'Insights Lab and Looker Labs reports don't support location scoping in this release' and 'Guest profiles are visible in full regardless of location assignment'. https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

multi-location-royalty-calculation differentiator

Thanx has no franchise-finance surface. The 2026-04-13 permissions release enumerates the dashboard's functional areas in full - 'Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences, and Reporting' - and none is financial; the 2026-04-09 Settings entry enumerates every configurable setting (ordering configuration and error messages, delivery defaults, location selection, receipts, 86ed visibility, scannable codes, in-store enrollment, in-store purchase tracking, terms and policies, Meta/Google analytics) with no fee, royalty or ad-fund basis among them; and the 2026-06-23 Operations Center entry enumerates the operator toolset with no billing or statement tool. The published data models are campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases and rewards - the purchases model carries authorization_amount, settlement_amount, channel and location fields but nothing that would define a royalty basis (no comps, no third-party split, no net-of-discount derivation). The string 'royalt' occurs zero times across the 168-page docs.thanx.com corpus and the 101 dated changelog entries. https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

multi-location-royalty-collection

No fee-collection surface exists. The dashboard's own permission feature areas (Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences, Reporting; 2026-04-13) include nothing financial, and the entry mentions billing only as something to withhold from an agency user ('without exposing billing') - i.e. Thanx's own subscription billing, not franchisee fee collection. The 2026-04-09 Settings enumeration and the 2026-06-23 Operations Center enumeration likewise contain no statement, invoice, ACH or payout tool. In the Loyalty API Thanx computes a discount and hands it back for the ordering platform to apply ('Ordering partners are expected to apply the discounts returned by this endpoint'); settlement_amount in the purchases export is described as money the issuing bank transfers to the operator's processor and acquiring bank, not money Thanx moves. Zero hits for royalty, ACH or debit collection across the 168-page docs corpus and the 101 dated changelog entries. https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

multi-location-consolidated-reporting

Above-store reporting is real but narrow. The 2026-06-17 entry adds to the Insights Lab Digital Orders reports a 'Group dates by' control (day, week, month, quarter, year) and 'a location table at the bottom of each report shows order history broken down by individual location... shows order history across all your locations for the selected time period', summarised as 'Brands can now view orders, purchases, revenue, and unique active customers by channel and by location'. The Revenue at Select Location(s) report (2025-08-06) shows 'weekly net revenue attributed to loyalty members, broken down by in-store and digital channels', filterable by date range and 'by one or more locations' and fully exportable; the Weekly Location Summary (2025-10-28) emails franchisees, regional leaders and location managers 'average check size, purchase volume, customer activation, and app adoption at the location level'. Shortfalls: (1) the denominator is loyalty-attributed and digital-order revenue, not the store's whole sales ledger - the same entry notes 'Capture rate data will populate only for merchants using an integrated POS or uploading POS data to the dashboard'; (2) labor, voids and item mix are absent entirely (Thanx holds no employee object, and the purchases export has no line items and no void field, only a voided basket state); (3) comparison is a location table, not a ranked view with variance flags; (4) as of the 2026-04-13 permissions release these reports 'don't support location scoping', so they are corporate-only views. https://thanx.launchnotes.io/announcements/digital-order-reports-new-date-grouping-and-location-filtering · retrieved 2026-09-01

multi-location-normalized-item-rollup differentiator

Chain-wide item-level rollup exists: the console ships an 'All purchases by SKU' report tab, its Reports section is described as 'Access to all reports. Report data is displayed for all locations', and the segment builder queries the warehouse merchant-wide — endpoint '/api/v1/merchants/:merchant_id/snowflake/query', params {table_name:'te_order_items', fields:['item_name'], distinct:true}, with modifiers filtered by 'filter_field:"item_name"' (main.568d2c06.js, read 2026-09-04). SHORTFALL: the rollup key is the item's NAME, not a canonical corporate item ID — 'item_id' occurs zero times in the entire console bundle, and the API's inbound basket carries only the POS's own item identifier. A location that renames an item therefore produces a separate distinct value rather than merging under a shared corporate ID, which is exactly the case the claim tests. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

multi-location-cross-location-giftcard

A gift card in Thanx is an account-level, brand-level object, not a per-location one: cards are stored against the consumer's account and 'can be used for purchases at participating merchants', and the merchant gift-card configuration returned by GET /gift_cards/merchant_config is merchant-scoped (state, external purchase link, card background) with no per-location field - so nothing in the model ties a card to the location that sold it. Shortfalls against the claim as worded: (1) Thanx neither issues nor holds the value - 'The Thanx platform integrates with external gift card providers to manage card validation and balance checking... Balance information is retrieved in real-time whenever gift card details are requested', and merchants point guests at an 'external purchase link' to buy cards, so redeemability across the brand is the external provider's property (the integrations announced are Valutec for Toast online-ordering merchants, 2025-12-04, and Olo gift cards, 2026-07-08); (2) no outstanding-liability balance and no inter-store settlement or redemption reconciliation between owners is documented anywhere in the 168-page docs.thanx.com corpus or the 101 dated changelog entries - the only gift-card reporting mentioned is that points can now be earned on orders paid with a gift card (2026-07-07). https://docs.thanx.com/consumer/gift-cards/overview · retrieved 2026-09-01

multi-location-cross-location-loyalty

One profile per guest per brand, shared across every location. GET /account returns 'all of the user's usable rewards plus affordable points products', and location_id is documented as an OPTIONAL query parameter - 'Providing this information allows Thanx to return rewards that can be used at this location' - i.e. a filter over one brand-wide account, not a partition of it. The points balance is likewise account-level (GET /points/balance returns 'the user's current balance of the currency of the points experience'), and purchase history is a single stream carrying a location_id per row: the purchases export gives purchase_id, user_id, merchant_id and 'location_id - the unique identifier for the location associated with the purchase. A location may not always be available.' Card-linked in-store earning is explicitly brand-wide: enrolling a card 'will synchronize their purchases at participating locations with their account to earn rewards'. Registration is enforced at brand level too - a card 'cannot be registered for loyalty benefits for another account', with Thanx support merging duplicate accounts. https://docs.thanx.com/loyalty/get-account · retrieved 2026-09-01

multi-location-multi-brand differentiator

Thanx cannot operate two brands on one terminal and drawer because it supplies neither. Its POS/Kiosk guide is written for the third party that owns the hardware - 'This integration connects the POS or kiosk system with the Thanx loyalty platform so that customers can seamlessly identify themselves during checkout' - and lists what the integrator receives (Client ID, Client Secret, Merchant ID, Merchant Key, Partner Token) and the three endpoints to call. The location record confirms the POS is always someone else's: loyalty_redemption_type is direct ('Thanx has an API integration built with the POS'), indirect ('POS partner has built an integration to Thanx') or none. Where multiple brands do appear, they are modelled as SEPARATE MERCHANTS keyed per request, not as one terminal serving two: 'a shared or multi-brand storefront that sends the wrong brand's key on billed sees that call fail rather than silently accruing to the wrong merchant' (basket lifecycle guide), and Get Merchants returns one id/handle/name per brand. No cash drawer, terminal, till or receipt-printer object appears anywhere in the 168-page docs corpus. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

multi-location-multi-tax-jurisdiction

Tax reaches Thanx as an already-computed amount supplied by the integrating POS, never as a rate Thanx configures: 'payments[].amount = subtotal + tax - discounts ... Include tax; exclude tips. Do not send the order's grand total.' Across the whole 728 KB docs corpus 'tax' appears only as this payload arithmetic and a basket subtotal caveat — there is no tax object, tax rate, jurisdiction or exemption field in any endpoint. The merchant console matches: 'tax_rate' occurs zero times in main.568d2c06.js (read 2026-09-04) and 'Tax' appears only as a display line on order detail and as an inclusion note on revenue metrics. Thanx's own terms disclaim the function: 'Thanx is not obligated to nor will Thanx determine the applicability of any taxes, or calculate, report, or remit any taxes to any tax authority.' No per-location tax configuration exists in the product. https://docs.thanx.com/overview/guides/basket-lifecycle · retrieved 2026-09-04 adversarially verified

multi-location-multi-currency-locale

The published money schemas are single-currency and carry no currency code. The Loyalty API defines the basket subtotal as 'The subtotal of the basket in USD (before taxes & tips)' and repeats it on the qualifying-baskets endpoint ('Basket subtotal in USD (pre-discount)'); items[].price, modifiers[].price and payments[].amount are bare decimals with no currency field. The purchases data model likewise exports authorization_amount and settlement_amount as plain numbers with no currency column, so a warehouse consumer could not tell one currency from another, and no reporting-currency conversion is described in any of the three export mechanisms (SFTP, Snowflake data share, Connex). Every one of the 18 occurrences of 'currency' in the 168-page docs corpus refers to the NAME of a points program's unit - 'points experiences are configuration that defines the currency that a user' earns, with currency_primary/currency_secondary singular and plural label fields, and points_program_currency in the points-transactions model - not to money. Nor is any per-location language or locale setting documented: the docs' only language references are the terms-and-conditions copy a brand supplies and the natural-language docs MCP server. https://docs.thanx.com/loyalty/create-update-basket · retrieved 2026-09-01

multi-location-config-audit-log differentiator

The corporate console is the object this claim asks about, and it carries no such log. In main.568d2c06.js (7,999,311 chars, read 2026-09-04): 'audit log', 'audit trail', 'activity log', 'change history', 'updated_by' and 'changed_by' all occur zero times; the seven 'audit' hits are privacy-policy text and a CCPA disclosure table, and every 'Activity' label is guest or campaign activity ('Activity by campaign', 'Account Activity tab'). The exportable side is equally settled: docs.thanx.com/data/overview enumerates the nine models Thanx publishes downstream and none records configuration changes. The April 2026 RBAC release governs who may act ('custom roles ... scoped to specific locations') without recording the act. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

multi-location-enterprise-sso differentiator

The back-office console's own login is a bare password form: 'Log in to Thanx', 'Email', 'Password', 'Forgot your password?', 'Invalid username/password combination. Try again.' — with no federated option. Across the full 7,999,311-char bundle (fetched 2026-09-04) 'SAML' = 0, 'SCIM' = 0, 'identity provider' = 0, and no IdP vendor string (Okta, Auth0, WorkOS, OneLogin, Ping, Azure AD) appears; back-office identity is in-product RBAC only (Admin, Location manager, Marketing manager, Customer service, Accountant). The product's only 'SSO' features are for other subjects: guest OAuth ('Thanx SSO authenticates the user via a password-less flow using email authentication', docs.thanx.com/consumer/sso/overview) and a Zendesk JWT hand-off that logs merchants into the Help Center. No SAML/OIDC federation and no deprovisioning mechanism exists for above-store users. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

multi-location-enterprise-api differentiator

Transaction-level, brand-wide, one credential. The purchases model - delivered as purchases.csv over SFTP and as the purchases table via Connex - carries one row per purchase with purchase_id, purchase_uid, merchant_id, user_id, card_id, order_id, location_id, location_name, location_street, location_zip, authorization_amount, settlement_amount, channel (digital|instore), purchased_at in UTC, and pos_id/pos_provider; location is a COLUMN, so a single export spans every location in the brand with no per-location credential. Three documented delivery mechanisms exist (docs.thanx.com/data/overview): SFTP CSV exports refreshed every 24 hours, 'a snapshot of the entire data set resident within the Thanx platform', single-file up to 10 million records or multi-file up to 5GB per part; Snowflake Secure Data Sharing, 'a direct Snowflake-to-Snowflake share' (AWS us-east-1 only); and Thanx Connex, 'fully managed loading of structured Thanx data' into 16 named destinations including Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, Postgres, MySQL, SQL Server, S3, GCS, Azure Blob and SFTP, with Thanx managing schema creation and migration. The overview page lists nine models (campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases, rewards) with a schema changelog at /data/changelog, but that list is a floor and not a census: a tenth model page, /data/models/loyalty-reward-progress-legacy, is published and carried by llms.txt while absent from it (verified 2026-09-01). The count is not load-bearing here -- this verdict rests on the Partner API scoping below. Separately the Partner API issues one OAuth token that spans scope: GET /partner/merchants 'will return all accessible merchants records' and GET /partner/locations 'all accessible location records', with merchant_id only as an optional filter. Two caveats short of a full ledger: syncs are 24-hourly, not real time, and setup is arranged through a Thanx success manager rather than self-serve. https://docs.thanx.com/data/models/purchases · retrieved 2026-09-01

multi-location-central-labor-policy

There is no labor surface to configure. The dashboard's own permission feature areas, enumerated in full on 2026-04-13, are Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences and Reporting - the 'users' Thanx knows about are dashboard operators and guests, not hourly employees. The 2026-04-09 Settings enumeration (ordering configuration, error messages, delivery defaults, location selection, receipts, 86ed visibility, scannable codes, in-store enrollment, in-store purchase tracking, terms and policies, analytics) and the 2026-06-23 Operations Center enumeration (Locations, POS Configurations, Delivery & Location Settings, Ordering Error Report, Alert Banner, End User Support Report) contain no scheduling, timekeeping or labor tool. The nine published data models are campaigns, communication preferences, memberships, NPS feedback, points accounts, points transactions, programs, purchases and rewards - there is no employee, shift, punch or break object to hold a rule or a violation. Overtime, break enforcement and predictive scheduling occur zero times across the 168-page docs corpus and the 101 dated changelog entries. Enforcement at the terminal is impossible in any case: the terminal belongs to a third-party POS or kiosk vendor that calls Thanx (docs.thanx.com/overview/guides/pos-kiosk). https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

extensibility-public-api-docs

docs.thanx.com is fully readable with no login, partner agreement or sales gate: Consumer API, Partner API ('privileged APIs supporting custom integration use-cases' — the docs themselves are open even though credentials are gated), Loyalty API for ordering/kiosk providers, webhooks and data exports, with a complete machine-readable page index published at /llms.txt. Individual endpoint references (partner token creation, webhooks overview, gift cards) were each fetched directly without authentication. https://docs.thanx.com/overview/intro · retrieved 2026-08-04

extensibility-api-access-cost differentiator

The contract set answers the shape of this question even though no price is published anywhere. The Thanx API Addendum (version effective 10-19-2022) opens: "This API Addendum (the 'Addendum') applies if you elect to use the Thanx API as selected in the Order Form to connect your application to the Thanx Platform." The Merchant Agreement effective 2.20.26 matches - section 1.11 defines Services as "the products and services made available to Merchant pursuant to the plan specified in the Order Form, including, as applicable, the Thanx Platform, Branded App, Web Ordering, and Thanx API", and section 3 applies the Additional Terms "to the extent the Thanx API or additional integrations are selected in the applicable Order Form". So API access is a per-deal Order Form election under a separate addendum rather than something every subscription carries: the named shortfall. Two facts keep this from being a no. The agreement's Fees article enumerates the additional charges a merchant is subject to - section 7.5, 'Third-Party Services Fees', lists exactly two, SMS pass-through fees for POS in-store enrollment (7.5.1) and third-party delivery (7.5.2) - and API access is not among them; and the reference itself is public and ungated (168 pages at docs.thanx.com, with www.thanx.com/open-platform-apis advertising "Well-documented APIs enable your technology partners to access Thanx data"). No figure is published either way: www.thanx.com/pricing carries no price of any kind and states pricing is "based on factors like restaurant count, average unit volume, and the platform capabilities you need", so whether the election carries an incremental or per-location fee is set per deal. The addendum also restricts use (no competing product, Thanx pre-approval of card-enrollment screens, versioned deprecation at Thanx's discretion). https://www.thanx.com/apiaddendum062822va · retrieved 2026-09-02

extensibility-partner-revshare

Partially published. www.thanx.com/partner-referral, headed 'Partner Referral Program', states: 'Know a restaurant (with 6 or more locations) in need of an upgrade? Introduce them to Thanx and earn a credit back on your monthly Thanx fees equal to 10% of their first-year subscription revenue.' The linked terms at www.thanx.com/referral-terms-and-conditions put numbers on it: '10% of first-year revenue up to $10,000', a limit of ten referral payouts per restaurant brand per year, the referred brand live at least 90 days, and a 180-day lead-exclusion window. Shortfall, and it is the half the claim is really about: those terms are scoped to 'Thanx customers working in a professional capacity in the restaurant industry' - a merchant-to-merchant referral bounty, not partner or marketplace terms. For the technology partners themselves, www.thanx.com/partnerships lists the directory with no fee, revenue share or per-location partner charge anywhere on it, and docs.thanx.com/partner/overview routes every commercial question to partnerships@thanx.com. https://www.thanx.com/referral-terms-and-conditions · retrieved 2026-09-01

extensibility-free-sandbox differentiator

A free, seeded sandbox does exist and is available to developers who own no paid production account -- the shortfall is that credentials are issued by Thanx rather than self-served. The hosts are api.thanxsandbox.com and thanxsandbox.com, and the 'Sandbox Gotchas & FAQ' documents the environment in detail: purchase processing runs on a lower-priority worker pool (15 minutes, commonly 30+, against near-real-time in production), and two endpoints exist only there -- POST /rewards/grant ('Sandbox only. The endpoint is disabled in production.') and POST /purchases ('Sandbox only'; 'the only way to create a sandbox purchase without going through a live POS or payment processor'). The environment is SEEDED and provisioned by the vendor rather than built by the developer: 'Sandbox credentials (client ID, client secret, merchant key, partner token, and test user) are provided by Thanx Developer Support during onboarding', and campaigns are pre-configured -- 'Ask Dev Support for the hashids of the campaigns set up on your sandbox merchant.' The recipients are integration partners, i.e. developers with no Thanx subscription of their own, and nothing published prices the sandbox. SHORTFALL: there is no self-serve registration and no published sandbox signup URL. Access runs through the Partnerships team, who 'coordinate kickoff meetings and integration scoping' ('to start an integration with us, reach out to partnerships@thanx.com'), while Developer Support supplies 'Sandbox credentials and environment setup' alongside 'Certification reviews'; production API keys follow a video-call demo and a submitted product guide. A developer cannot obtain credentials from the documentation alone. https://docs.thanx.com/overview/sandbox-faq.md · retrieved 2026-09-01

extensibility-oauth-partner-apps

Partner API tokens are scoped — the token-creation endpoint requires the 'auth.create' scope, responses carry 'the API scopes granted to the access token', and a Get Scopes endpoint returns the scopes accessible to the current credentials. Shortfall: issuance is a proprietary X-ClientId + bearer token-generation flow, not an OAuth 2.0 operator-consent grant; long-lived non-expiring tokens are supported and token revocation is undocumented for partners. A standard OAuth 2.0 authorization-code flow with token revocation is documented only for consumer SSO, not third-party partner apps. https://docs.thanx.com/partner/auth/create-token.md · retrieved 2026-08-04

extensibility-webhooks-push

Push webhooks exist and are near-real-time (receiving servers must respond within 15 seconds), but the complete documented event catalogue is purchases (fired when 'Thanx detects a qualifying user purchase'), reward issued, reward batch completed, SMS subscriptions and communication settings — no order-lifecycle events (created/modified/paid/voided/refunded). Delivery is also best-effort and not exactly-once: 'failed deliveries are not retried'. https://docs.thanx.com/webhooks/overview.md · retrieved 2026-08-04

extensibility-webhook-reliability differentiator

Authored 2026-09-01 from the vendor's own webhook reference, read whole (5,535 b). The claim is CONJUNCTIVE -- signed AND documented to retry with backoff AND a replayable event log -- and Thanx satisfies the first while explicitly denying the other two, in its own words. SIGNED: yes, and properly. 'The X-Thanx-Signature is a hex-encoded HMAC-SHA256 signature of the request payload, using a webhook secret that can be provided by the Thanx team', with worked Ruby and Python verification examples. RETRY: no. 'By default, webhooks are not configured to retry if the receiving server responds with an error.' The Delivery Semantics section says it again and harder: 'Webhook delivery is not exactly-once. The same event can be delivered more than once, and each individual delivery is best-effort -- failed deliveries are not retried ..., so delivery of any single event is not guaranteed.' REPLAYABLE EVENT LOG: no. There is no event log, replay window or redelivery control anywhere in the reference; the stated recovery path is a different mechanism entirely -- 'Any missed data can be collected via bulk data transfer mechanisms', which the page's own first line identifies as 'standard SFTP data exports'. A nightly bulk export is not a replayable event log, and the document itself frames it as the fallback for what the webhooks dropped. The reference also puts the burden on the consumer: 'Design your consumer to be idempotent ... The payload carries no delivery sequence or timestamp, so treat the last delivery you receive for an id as the current state.' So duplicates are expected, ordering is not carried, and a loss is permanent as far as the webhook channel is concerned. This is a `no` STATED BY THE VENDOR rather than inferred from silence, which is the strongest form this verdict takes. Also recorded: endpoints must be HTTPS and answer a POST within 15 seconds, and webhooks are enabled by request to developer.support@thanx.com rather than self-serve. https://docs.thanx.com/webhooks/overview.md · retrieved 2026-09-01

extensibility-order-injection-api

Absence established by direction and by API-schema enumeration, not by silence. The published API surface is bounded twice over: docs.thanx.com/llms.txt and /sitemap.xml each enumerated exactly 168 pages on 2026-09-01, agreeing page for page, and every endpoint has its own reference page. Nothing in that set accepts an order into a point of sale. The POS / Kiosk Integration Guide makes the arrow point the other way: 'the POS sends the current basket with "checkout" state to the Create or Update Basket endpoint', then '"placed"', then '"billed"', which 'indicates that the order has been transmitted to the POS and the user's credit card has been charged'. Thanx is the loyalty overlay the POS calls, and the sibling endpoint /loyalty/qualifying-baskets is described as 'a read-only dry-run over the same applicability check, which redeems nothing'. The nearest write, POST /partner/purchases, 'submits a purchase to Thanx for processing. This allows for issuance of loyalty points to the given user' - merchant_id, user_id, amount, purchased_at, optional location_id and an array of product strings, recorded after the fact. No ticket object, no course or routing field, no printer or KDS target, and no fire-to-kitchen semantics exist anywhere in the reference. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

extensibility-menu-write-api differentiator

API-schema enumeration. The developer documentation index (174 items, of which 168 are pages, confirmed page for page by docs.thanx.com/sitemap.xml on 2026-09-01) covers the Consumer, Partner and Loyalty APIs, webhooks, data exports and data models. It contains no menu, item, modifier or price resource in any of the three APIs - the only catalogue-shaped read is GET /consumer/points/products, the points-redemption catalogue, and baskets accept items the caller has already priced. Corroborated by the vendor's own dated product announcements: the Deliverect release note says 'Menu changes take a few minutes to sync from Deliverect to Thanx. If a change isn't showing, confirm it published in Deliverect and that the item's PLU and menu mapping are correct', and the Toast note maps 'Menu Groups in Toast' to 'Categories in Thanx'. Thanx sits downstream of the POS or middleware that owns the menu and exposes no write path to items, modifiers or prices. Recorded honestly: merchant dashboard menu editing, if any exists for Thanx-hosted ordering, would be documented only in the SSO-walled help centre - but the claim is specifically about API write access, and the API is fully enumerated. https://docs.thanx.com/llms.txt · retrieved 2026-09-01

extensibility-data-symmetry differentiator

Measured against the whole published endpoint set (168 pages, dual-manifest bounded on 2026-09-01). Symmetric: users (create, get, update, delete), tags (get, upsert, delete, on both users and purchases), purchases (create, get), rewards (get, activate, finalize, grant, update), communication settings (get, update), feedbacks (get, update), cards (create, get, delete), gift cards (create, get, delete), campaigns and promotions (create, list, get, plus code generation and issuance-job revoke). Shortfall: an entire read-only tier has no write counterpart - GET /partner/merchants, GET /partner/locations, GET /consumer/locations, GET /features, GET /signup-programs, GET /reward-templates, GET /tiers/configs, GET /points/experiences, GET /points/products and GET /points/multipliers are all retrieval-only, and the points guide states points products 'are configured in the merchant dashboard'. Three of the claim's five named objects - menu, employees, inventory - have no representation in the API in either direction, so symmetry over them is vacuous rather than satisfied. https://docs.thanx.com/llms.txt · retrieved 2026-09-01

extensibility-published-rate-limits

Quotas and throttling are published as specific numbers: 'Integration partners should not exceed a rate of 5 requests per second and 2,000 requests per 15 minutes. These default rate limits are hard-limits and APIs will return 429 Too Many Requests once these limits are crossed. Rate-limited API requests can and should be retried. One such strategy to handle this is through an exponential backoff strategy.' The same figures are restated in the campaign reward-issuance and subscriber-ingestion guides, and an increase can be requested from developer.support@thanx.com. Shortfall, and it is exactly the third limb of the claim: no rate-limit headers are documented. docs.thanx.com/consumer/usage/headers and docs.thanx.com/loyalty/headers each enumerate the complete header set (Authorization, Content-Type, Accept, Accept-Version, X-ClientId, Merchant-Key, User-Agent, Reward-Redemption-Token) and none is a quota header; across all 168 pages there is not one occurrence of X-RateLimit, RateLimit or Retry-After, and docs.thanx.com/consumer/usage/errors lists response codes with no budget or reset field. A client cannot see its remaining budget or a server-told backoff interval - only the 429. https://docs.thanx.com/partner/overview · retrieved 2026-09-01

extensibility-doordash-preferred differentiator

Fetched 2026-09-01. DoorDash's newsroom names the 2026 Preferred Integration Partner cohort as a closed list of ten: Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast and UrbanPiper. Thanx appears nowhere on the page. This is the program operator publishing the membership roster itself, so the enumeration is exhaustive in the way the evidence bar requires. It is also structurally consistent: DPIP qualification runs on POS order-injection quality across live DoorDash stores, and Thanx injects no orders into any POS - it is a loyalty, CRM and digital-ordering layer riding Toast, Square, Olo, Onosys or Deliverect, and its own Deliverect release note states 'Deliverect Dispatch selects and manages the courier (e.g. Uber or DoorDash). Thanx doesn't choose the courier or process its orders/invoices - that stays between you and Deliverect.' https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-09-01

extensibility-first-party-delivery-integrations differentiator

Delivery exists, but not on the terms the claim states. The Deliverect release note (2026-08-11) describes 'Delivery handled for you, with pricing upfront - Deliverect Dispatch selects the courier (Uber, DoorDash, and others) and guests see a live delivery quote - availability, price, and ETA - right at checkout', and its FAQ answers the ownership question directly: 'Does Thanx process the delivery courier's orders and invoices? No. Deliverect Dispatch selects and manages the courier (e.g. Uber or DoorDash). Thanx doesn't choose the courier or process its orders/invoices - that stays between you and Deliverect.' The Square release note offers 'pickup or delivery (via DoorDash or Uber Direct)' through Square. Two named shortfalls: (1) these are DoorDash Drive and Uber Direct courier-dispatch services reached through a middleware or POS layer, not first-party certified integrations with the DoorDash, Uber Eats and Grubhub ordering marketplaces, and that middleware layer is exactly what the claim excludes; (2) Grubhub is named nowhere - zero occurrences across the 101-entry changelog corpus and the 168-page developer documentation. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

extensibility-middleware-compatibility

Documented and dated. The 2026-08-11 release note announces 'We've expanded our ordering middleware options to include Deliverect', with real mechanism: menus, PLUs and 86'd items sync from Deliverect, orders confirm through the POS via Deliverect, and its FAQ states 'Any POS integrated with Deliverect supports ordering and loyalty via Thanx - and Deliverect is constantly adding new POS providers.' The Square announcement frames the estate: 'adding to existing direct integrations with Toast and middleware partnerships with Deliverect, Onosys, and Olo'. Shortfalls: only one of the five platforms the claim names (Deliverect) is supported - Chowly, Otter, Checkmate and ItsaCheckmate have zero occurrences across the 101-entry changelog corpus and the 168-page developer documentation - and the relationship runs the opposite way from the claim's premise, since Thanx is not a POS receiving injected third-party orders but an ordering and loyalty experience sitting on top of the middleware. Olo and Onosys are ordering middleware rather than delivery aggregators, so counting them toward 'at least two major aggregation middleware platforms' would read the claim more loosely than it is written. https://thanx.launchnotes.io/announcements/deliverect-powered-ordering · retrieved 2026-09-01

extensibility-accounting-connectors

No accounting or GL destination exists on any documented egress path. docs.thanx.com/data/overview states 'we provide the following access mechanisms' and names three - SFTP CSV exports, Snowflake Secure Data Sharing and Thanx Connex. Its Connex destination table has 16 rows, but the site publishes 23 destination pages (the table omits Delta Lake, Iceberg, MongoDB, MotherDuck, Oracle, Redshift Serverless and SFTP), so I scored the larger set: every one of the 23 is a database, object store, file transport or spreadsheet, and none is an accounting, ERP or general-ledger system. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity, so there is no ledger entity to post from either. Verified independently on 2026-09-01 by fetching every page under /data/ as markdown (37 pages) and the whole published documentation corpus in one request from docs.thanx.com/llms-full.txt (725,958 bytes, 200 page bodies, a superset of the 174 pages listed in docs.thanx.com/llms.txt): zero occurrences of 'quickbooks', 'xero', 'chart of accounts', 'journal entry' or 'ledger'. Corroborated off-host on the vendor's partner directory, www.thanx.com/partnerships, re-read on 2026-09-01: its department taxonomy runs Agency, Business Intelligence, CDP, Credit Card, Delivery, Digital Ordering, Dynamic Quote Times, Feedback, Geolocation, Gift Cards, Marketing, Middleware, Non-Discount Rewards, Online Ordering, Operations, Payments, POS, Technology and User Experience - no accounting department and zero accounting partners. Structurally expected: Thanx is a loyalty and CRM layer with no ledger to post to. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false, as is the description of the 16-row table as the 'full' destination list. https://docs.thanx.com/data/overview · retrieved 2026-09-01

extensibility-payroll-export

Absence by a document that asserts its own completeness, not by silence. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity - there is no employee, shift, timeclock or labour-hours object to export. Verified independently on 2026-09-01 by fetching every page under /data/ as markdown (37 pages) and the whole published documentation corpus in one request from docs.thanx.com/llms-full.txt (725,958 bytes, 200 page bodies, a superset of the 174 pages listed in docs.thanx.com/llms.txt): 'payroll', 'timecard', 'timeclock', 'gusto', 'paychex' and 'paylocity' each occur zero times, and 'employee' occurs exactly twice, once as a tag-key casing example ('Employee and employee are treated as the same key') and once in prose about team roles. The Thanx Connex destination set - 23 documented pages, seven more than the overview's 16-row table - contains no payroll provider; every entry is a database, object store, file transport or spreadsheet. The vendor's partner directory at www.thanx.com/partnerships, re-read on 2026-09-01, carries no payroll department and no payroll partner. Thanx employs no one on the restaurant's behalf and records no hours; there are no labour hours to export. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false - the overview's Models section links nine, but a tenth model page is published, and the argument rests on the completeness sentence rather than on any count. https://docs.thanx.com/data/overview · retrieved 2026-09-01

extensibility-bi-data-warehouse differentiator

Directly on point and documented three ways over. 'The Thanx platform supports a variety of data export mechanisms. We are firm believers that data within the Thanx platform belongs to our customers.' (1) SFTP exports are 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', 'available to all Thanx merchant customers', with a multi-file mode that 'eliminates the 10 million record limit', splits into 5GB CSVs with headers, and is 'recommended for programmatic integrations and automated data pipelines'. (2) Snowflake Secure Data Sharing is 'a direct Snowflake-to-Snowflake share - data is never copied', into the customer's own Snowflake account (AWS us-east-1 only). (3) Thanx Connex provides 'fully managed loading of structured Thanx data directly into a variety of data destinations' - Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, Postgres, AWS Postgres, MySQL, AWS MySQL, SQL Server, S3, S3 Compatible, Google Cloud Storage, Azure Blob Storage and Google Sheets - synced on a 24-hour schedule with Thanx managing schema creation and migration. Transaction-level granularity is confirmed by the documented purchases model and its per-purchase pos_id and pos_provider columns. Friction worth recording but not a shortfall against this claim as worded: enablement is by request to the Thanx success manager rather than self-serve, and the sync cadence is daily. https://docs.thanx.com/data/overview · retrieved 2026-09-01

extensibility-app-marketplace

Retrieved 2026-09-01. Thanx publishes a public partner directory, filterable by nineteen departments (Agency, Business Intelligence, CDP, Credit Card, Delivery, Digital Ordering, Dynamic Quote Times, Feedback, Geolocation, Gift Cards, Marketing, Middleware, Non-Discount Rewards, Online Ordering, Operations, Payments, POS, Technology, User Experience), listing named third-party companies - Deliverect, Klaviyo, Square and Toast featured, with 5&5, Adentro, American Express, Attentive, Bikky, Bite Kiosk, Bounteous, BRAME, Braze, CardFree, Cartwheel, CBS Northstar, Curbit, Custom Channels and Customer XI among the alphabetical listing. Shortfall: it is a browse-only directory, not a self-install marketplace. Each entry offers an outbound link or a Thanx-hosted profile page; there is no install or connect action. The developer documentation says why - docs.thanx.com/partner/overview states partner credentials 'grant access to all merchants that have explicitly opted into the specified integration', credentials are issued by Thanx after a 'lightweight but mandatory certification process', and every integration path in docs.thanx.com/overview/integrating opens with a scoping conversation with the partnerships team. Grade D: the source is a first-party marketing page, and the operator-facing enablement screen that would settle self-install lives in the SSO-walled help centre. https://www.thanx.com/partnerships · retrieved 2026-09-01

extensibility-custom-fields-scripting

Half the claim is documented and half is absent. Tags are genuinely operator-defined custom fields: PUT /partner/tags 'allows for bulk upserting of tag values for specified users. If a tag with the specified key does not exist for the user / merchant pair, a new tag record is created' - arbitrary key, up to 50 values, up to 500 users per request, requiring only the tags.write scope. The docs even give naming guidance because the namespace is shared: 'tags are merchant/user-scoped ... we recommend integration partners prefix tag keys with the name of your organization to avoid key usage conflicts between integrations enabled for a given merchant', with 'allergens' offered as a general-purpose profile attribute. The same shape exists on the Consumer API (PUT /tags) and on purchases (/consumer/purchases/update-tags). Shortfalls: the custom-field surface covers only users and purchases - no other object in the 168-page reference accepts arbitrary attributes - and there is no vendor-hosted custom logic at all. No scripting endpoint, rules engine, sandboxed function, formula field or server-side event handler appears anywhere in the dual-manifest-bounded documentation; the only programmable extension point is an outbound webhook running on code the partner hosts, which Thanx must enable ('please reach out to our team ... to have webhooks enabled'). Access itself also runs through a partnership and certification rather than self-serve. https://docs.thanx.com/partner/tags/upsert-tags · retrieved 2026-09-01

extensibility-headless-embedded

Documented headless operation, with a named limit on what is actually being driven. The Loyalty API 'is designed to provide POS, online ordering, and kiosk providers the ability to integrate Thanx Loyalty into their ordering systems - reward redemption and loyalty points accrual', served from loyalty.thanx.com; the POS / Kiosk guide walks a third-party UI through the full lifecycle - Create Access Token, Get Account, then Create or Update Basket in checkout, placed, billed, completed, voided and refunded states, with Qualifying Baskets as a read-only dry run. The Consumer API is equally headless: 'Integrate Thanx into a custom consumer experience', with OAuth SSO, webhooks and a dedicated certification track for custom apps and web experiences, so a brand's own app can front the whole platform. Shortfall: Thanx is not a transaction engine, and the claim is worded about one. Payment, tender and order transmission remain with the POS - the 'billed' state 'indicates that the order has been transmitted to the POS and the user's credit card has been charged' - so the third-party UI drives reward lookup, discount computation and points accrual, not a POS transaction. Drive-thru appears nowhere in the developer documentation and is listed among the unsupported handoff modes on the Square ordering path. https://docs.thanx.com/loyalty/overview · retrieved 2026-09-01

extensibility-api-versioning-deprecation

Real, published, and narrower than the claim. Versioning is mandatory and enforced: 'Accept-Version: v4.0 ... This value must be specified in API calls. This denotes the current API version that is in use. Any other value specified will cause undefined behavior and may risk API access revokation' (Partner and Consumer APIs), with the Loyalty API on application/vnd.thanx-v1+json. A written compatibility policy exists for data exports and is unusually explicit: new attributes are appended to the right of each CSV and 'Consumers must parse CSVs by header name, not by column position, and must ignore unknown columns rather than failing'; 'Attributes are not removed from the schema under normal operations, to prevent breaking existing integrations. If a column must be retired ... the column remains present in the schema but will be empty'; 'Attribute data types will not be adjusted. Changes to any calculation will be announced in the changelog below and applied to all exports on the listed date' - with dated entries for 2026-08-24, 2026-05-11 and 2025-06-01. A separate dated public product changelog runs at thanx.launchnotes.io (101 entries), and certification requires partners to subscribe to it. Shortfalls: this changelog is scoped to data-export schema changes, not to the Consumer, Partner or Loyalty APIs, for which the 168-page reference carries no changelog at all; and no deprecation or advance-notice policy for breaking API changes is published - the only commitment is 'Thanx will notify you when a new API version is available', with no notice period, sunset window or supported-versions table. https://docs.thanx.com/data/changelog · retrieved 2026-09-01

extensibility-data-portability-exit differentiator

Strong on format and completeness, thin on scope and on the exit mechanics. docs.thanx.com/data/overview states 'data within the Thanx platform belongs to our customers' and that SFTP exports 'are a snapshot of the entire data set resident within the Thanx platform in CSV format', 'available to all Thanx merchant customers', with a multi-file mode removing the 10-million-record cap, plus Snowflake Secure Data Sharing and 23 documented Thanx Connex destinations. Machine-readability is documented per model: each published model page carries a field-level attribute table, and /data/changelog publishes an additive schema-stability policy. A termination-time right does exist and is published, contrary to an earlier reading of this cell: the Data Processing Addendum at www.thanx.com/dpa01012025va (effective 2025-01-01, re-read 2026-09-01) commits Thanx to 'upon termination of the Agreement, as instructed by Merchant, delete or return the Personal Data'. Three shortfalls keep this at partial. (1) That right is scoped to Personal Data at the merchant's instruction and attaches no format, delivery window or post-termination retention period; the master services agreement and Order Form, where commercial export terms would sit, are not published. (2) Two of the claim's four named object families are absent from the export model - there is no menu entity at all, since menus live in the upstream POS or middleware, and the purchases model carries authorization_amount, settlement_amount, channel, location, purchased_at and pos_id/pos_provider but no payment-instrument or processor metadata. (3) Enablement is not on demand in the self-serve sense - 'please reach out to your Thanx success manager directly and they can set this up'. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false; the overview's Models section links nine while a tenth model page is published. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reliability-offline-order-entry

Migrated from the 2026-08-01 research pass; no source URL was recorded.

reliability-offline-card-auth differentiator

The vendor states the opposite of a store-and-forward path. Its 2026-08-14 platform-downtime notice tells merchants that during a one-hour maintenance window 'the Thanx platform (dashboard + all guest-facing web and app experiences) will be down', that 'If you're operating during that window, you won't be able to receive orders for ~1 hour', and that 'online ordering and in-store loyalty via POS will be unavailable during this time' - i.e. the ordering and payment path fails closed when the cloud is unreachable, with no local fallback. Corroborated by the developer corpus: the words 'offline', 'store-and-forward' and 'store and forward' appear zero times across all 168 pages of docs.thanx.com (the surface docs.thanx.com/llms.txt and /sitemap.xml enumerate identically), and the POS / Kiosk integration guide requires a live API call to Thanx at every basket state (checkout, placed, billed, completed). Note the scope: Thanx is not the payment terminal - card capture happens on the merchant's POS or ordering provider - so this is a finding about the Thanx-dependent path, not about the third-party POS's own store-and-forward behaviour. https://thanx.launchnotes.io/announcements/reminder-platform-downtime-august-21st-1-2am-pst · retrieved 2026-09-01

reliability-offline-decline-liability differentiator

Read the complete published standard agreement (Merchant Agreement 2026, ~30,000 characters of contract text served in full on the page) plus the Additional Terms (additionalterms010125va), the Master Restaurant Ordering Terms (mrot010125va), the 2024 Terms and Conditions and the API Addendum. Across all five documents the strings 'uptime', 'service level', 'service credit', 'SLA', 'offline' and 'store-and-forward' do not occur; the only relevant security/liability language is the mutual safeguards duty at Section 9.1 ('maintain administrative, physical and technical safeguards to protect against the unauthorized disclosure and the confidentiality, integrity and availability of Program Data, Merchant Data and Confidential Information'). No allocation of loss for a declined stored-and-forwarded transaction and no per-transaction or cumulative offline cap is published anywhere. This is consistent with reliability-offline-card-auth: there is no store-and-forward mode for such terms to govern. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

reliability-lan-degraded-multi-terminal differentiator

Thanx ships no terminal and no terminal software: its own POS / Kiosk integration guide is written for a third-party POS or kiosk vendor building against Thanx ('you will be provided the following credentials: Client ID, Client Secret, Merchant ID, Merchant Key, Partner Token'), and the loyalty flow at the register is a cloud round trip on every basket state change - Create Access Token -> Get Account -> Create or Update Basket, called again 'any time the user updates their basket or reward selection'. The 168-page developer corpus (llms.txt and sitemap.xml enumerate it identically) documents no terminal application, no local server and no LAN component. Check and table state lives in the third-party POS Thanx integrates with (Toast, Square, NCR Aloha, Qu, PAR Brink, Xenial via Genius, or middleware such as Olo, Deliverect and Onosys); Thanx's own basket object exists only server-side in its cloud. There is therefore no Thanx-side LAN-degraded mode: the vendor's August 2026 downtime notice confirms that when its platform is unreachable 'in-store loyalty via POS will be unavailable'. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

reliability-local-transaction-engine differentiator

The published developer surface is enumerable and was enumerated twice by the vendor itself (docs.thanx.com/llms.txt and /sitemap.xml agree exactly at 168 pages). Every ordering-path document in it is a hosted request/response API: the POS / Kiosk guide's flow is Create Access Token -> Get Account -> Create or Update Basket against Thanx's cloud, repeated 'any time the user updates their basket or reward selection'; the Loyalty API, Consumer API, Partner API, webhooks and Connex data-export sections contain no on-premise runtime, no edge server, no local cache and no local database. 'edge server', 'on-premise' and 'on-prem' return zero real hits across the corpus. The vendor's own maintenance notice confirms the architecture operationally: a one-hour cloud maintenance window means 'you won't be able to receive orders for ~1 hour'. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

reliability-offline-kds-printing

Migrated from the 2026-08-01 research pass; no source URL was recorded.

reliability-printer-fallback

Migrated from the 2026-08-01 research pass; no source URL was recorded.

reliability-sync-conflict-handling

Thanx does publish a conflict-resolution rule, and it is last-write-wins: 'Webhook delivery is not exactly-once. The same event can be delivered more than once ... Design your consumer to be idempotent: deduplicate on the payload's stable identifier ... Where a field can be refined over a resource's lifecycle (such as a purchase amount), prefer the latest delivery ... treat the last delivery you receive for an id as the current state.' Writes are protected by an X-Idempotency-Key on partner reward issuance, and the basket state machine locks a reward to the order at the 'placed' state. SHORTFALL: all of that governs the event stream and API writes, not the case the claim names — concurrent edits on two devices during a network partition. Thanx hosts no local multi-device editing surface (checks and baskets live in the POS), and the mandatory POS/kiosk pre-certification checklist requires no offline queueing or conflict handling at all; 'concurren', 'partition' and 'last write' are zero across the 728 KB docs corpus. https://docs.thanx.com/webhooks/overview · retrieved 2026-09-04 adversarially verified

reliability-offline-feature-matrix

The mandatory pre-certification self-check is the vendor's own enumeration of everything an integrating POS or kiosk must handle, and its Error Handling section is complete at four items: 'Handle authentication failures gracefully / Handle reward redemption errors (expired, already used) / Handle basket submission errors / Display meaningful error messages to end users'. There is no offline, queue, store-and-forward or degraded-mode requirement, and no feature is marked unavailable without connectivity. 'offline' occurs zero times in the entire 728 KB / 168-page docs corpus (including the POS-Kiosk integration guide, the one place a degraded-mode contract would be binding), zero in the 124-page www corpus, and in the merchant console it appears only as the ordering error string 'Online ordering offline'. Thanx runs no local mode to enumerate: its own maintenance notice says a window stops 'the dashboard and all consumer-facing experiences (web + app)' outright. https://docs.thanx.com/assets/Pre_Cert_Checklist_POS_Kiosk.md · retrieved 2026-09-04 adversarially verified

reliability-public-status-page

Fetched anonymously (no cookie, no login) on 2026-09-01. The page is per-component, listing Authentication (auth.thanx.services), Signup UI, Merchant UI, Ordering UI, Consumer API, Merchant API and Ordering Service, each with a 90-day uptime bar and a percentage (e.g. Merchant API 99.926%, Merchant UI 100.000%). Historical state is public too: status.thanx.com/history carries dated incident records - 'Platform wide ordering outpage' (Jul 21 2026: Identified 11:36, Update 11:41, Resolved 13:07) and 'Reporting Data Delay' (Aug 21-27 2026) - plus a maintenance record for the Aug 21 window naming the affected services. Vendor-run on hyperping; the merchant changelog also directs operators to it ('subscribe to platform updates here: https://status.thanx.com/'). https://status.thanx.com/ · retrieved 2026-09-01

reliability-contractual-uptime-sla differentiator

Thanx publishes its standard agreement in full (Merchant Agreement 2026, linked from its own sitemap) together with the Additional Terms, Master Restaurant Ordering Terms, 2024 Terms and Conditions, API Addendum and DPA. All six were fetched and read whole on 2026-09-01: the strings 'uptime', 'service level', 'SLA', 'service credit' and 'scheduled maintenance' do not appear in any of them, and the sole use of 'availability' is inside the Section 9.1 data-safeguards clause. The only uptime figure Thanx publishes is on its marketing services page ('Modern API architecture with >99.95% uptime ensures your integrations work consistently'), which is grade-D copy with no measurement window, no exclusions and no credit remedy; the only contractual response commitment found is a support one, not an availability one ('4-hour average response time and 8-hour SLA' on the Customer Success page). The claim requires a stated percentage AND a service credit remedy, published or in the standard agreement; neither is present. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

reliability-incident-postmortems

status.thanx.com/history is Thanx's public incident venue and it publishes status updates, not post-incident reports. Its record of the July 2026 major outage ('Platform wide ordering outpage') reads in its entirety: 'We are currently investigating a platform-wide issue affecting ordering and have identified the root cause. Our team is actively working on resolution.' (Jul 21, 11:36), 'A fix is being deployed right now.' (11:41), 'The incident has been resolved.' (13:07) - the root cause is stated to have been identified and is never disclosed. The August 2026 'Reporting Data Delay' entry closes the same way ('The delay was kept at an acceptable level and has since subsided; the issue is resolved'). No RCA document, no follow-up entry and no linked write-up exists on the status page, in the 101 dated launchnotes announcements (zero hits for 'incident', 'postmortem', 'post-mortem'), or in the 19 public help-center articles. https://status.thanx.com/history · retrieved 2026-09-01

reliability-247-live-support

Thanx states its support model positively and it is neither 24/7 nor phone-based. The Customer Success page: 'Get rapid support when you need it with 4-hour average response time and 8-hour SLA - your CSM responds in hours, not days'. The Services page: '<8 hour Average ticket reply time', '<22 hour Average ticket resolution time', and guest-facing support is explicitly optional and paid - 'Thanx offers fully managed support as an optional service', 'Optional Managed support package'. The vendor's own announcement of its merchant support channel is live chat inside the dashboard, with stated hours: 'Our support team is available to respond to any and all inquires within an average of 3 minutes between 8AM to 6PM PST, Monday through Friday' (www.thanx.com/blog/announcing-live-chat-support-from-thanx). An 8-hour response SLA and an 8AM-6PM PST weekday window are incompatible with 24/7/365 live phone coverage, and no support telephone number or after-hours line is published on any Thanx host. Recorded as no rather than partial because the capability named - 24/7 live phone support in the base subscription - is contradicted by the vendor's own published hours, not merely unevidenced. https://www.thanx.com/customer-success · retrieved 2026-09-01

reliability-onsite-install differentiator

The vendor states the absence directly on its own services surface rather than by inference from a hiring page: www.thanx.com/transitioning-loyalty — 'Zero hardware requirements and no on-site POS configuration—all transition work happens behind the scenes with minimal impact on operations', and on the same page 'zero hardware requirements and minimal operational disruption' (re-read 2026-09-04). The delivery model is then enumerated with no site visit in it. www.thanx.com/implementation names its workstreams — a dedicated implementation manager who 'understands restaurant operations, not just software', full guest-data migration, program redesign, 'Rigorous data testing, staff training, and guest communication', 'Comprehensive Team Training — Hands-on training gets your marketing, operations, and support teams ready to execute campaigns', and validation that 'ensures flawless performance on launch day' — and www.thanx.com/services adds 'Professional design, training, and QA built in' plus 'the managed support other platforms don't'. Across /services, /implementation, /transitioning-loyalty and /customer-success, 'on-site', 'onsite' and 'in-person' occur only in the negating sentence above, and the only 'install' hit is a customer quote that there was 'no new app to install'. There is no dealer network to dispatch — the /partners pages are integration partners, not installing resellers — and the company describes itself as 'Fully remote for focus and efficiency' (www.thanx.com/careers). Go-live support is delivered remotely, and there is no hardware to install. https://www.thanx.com/transitioning-loyalty · retrieved 2026-09-04 adversarially verified

reliability-menu-build-service differentiator

There is no Thanx menu for Thanx to build. The console's Ordering management screen states 'These locations are ingested from your ordering provider' and exposes only a read-only 'Menu status' column, an error list and an enable/disable toggle — the 8 MB bundle (read 2026-09-04) contains no item, category, modifier or price editor of any kind, and no menu-authoring endpoint exists across the 168-page docs corpus. The launch path inherits the operator's existing POS menu instead: brands go live 'using their existing Toast menu structure', and under Square 'pricing, imagery, availability, handoff modes, and store hours all live in Square'. Accordingly www.thanx.com/implementation's six onboarding workstreams cover discovery, integration management, launch planning, training and QA — 'Our team manages integrations with your POS, ordering platforms, and other systems' — but no menu configuration, and 'menu build' is zero across all 124 site pages. The vendor performs integration setup, not a menu build. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

reliability-hardware-replacement-sla

There is no Thanx hardware. The complete standard agreement (Merchant Agreement 2026, read in full) contains zero occurrences of 'hardware', 'equipment' or 'terminal': it licenses services and program data only, with no sale, lease, warranty, RMA or advance-exchange provision of any kind, and the same is true of the Additional Terms, Master Restaurant Ordering Terms, 2024 Terms and Conditions and API Addendum. Thanx ships no terminal and no terminal software: its own POS / Kiosk integration guide is written for a third-party POS or kiosk vendor building against Thanx ('you will be provided the following credentials: Client ID, Client Secret, Merchant ID, Merchant Key, Partner Token'), and the loyalty flow at the register is a cloud round trip on every basket state change - Create Access Token -> Get Account -> Create or Update Basket, called again 'any time the user updates their basket or reward selection'. The 168-page developer corpus (llms.txt and sitemap.xml enumerate it identically) documents no terminal application, no local server and no LAN component. 'hardware' also returns zero hits across all 168 pages of docs.thanx.com and appears once, incidentally, across 101 changelog entries. A replacement SLA presupposes a device the vendor supplies; Thanx supplies none, and its own positioning is 'best-in-class loyalty on the POS you already run'. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

reliability-backup-restore

The retrieval half of the claim is documented in the vendor's primary docs: 'The Thanx platform supports a variety of data export mechanisms. We are firm believers that data within the Thanx platform belongs to our customers.' Three mechanisms are specified - SFTP exports that are 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format' (single-file, capped at 10 million most recent records per report, or multi-file up to 5GB per part with no cap), Snowflake Secure Data Sharing ('a direct Snowflake-to-Snowflake share - data is never copied'), and Thanx Connex, 'fully managed loading of structured Thanx data' into two dozen documented destinations (Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, MotherDuck, Delta Lake, Iceberg, Postgres, MySQL, MongoDB, SQL Server, Oracle, S3, GCS, Azure Blob, SFTP, Google Sheets and others). Shortfalls, both material: (1) this is one-way egress only - nothing in the 168-page corpus documents a restore, rollback or re-import path, so an operator can hold a copy of their data but cannot use Thanx to recover the platform's own state; (2) no RPO or RTO figure is published anywhere on docs.thanx.com, status.thanx.com or in the merchant agreement. It is also not fully self-serve: SFTP export and multi-file mode both require the operator to 'reach out to your Thanx success manager directly'. https://docs.thanx.com/data/overview · retrieved 2026-09-01

reliability-pci-dss-4-attestation

New this pass and absent from every corpus earlier passes had read: Thanx does publish a PCI compliance assertion, on four www.thanx.com pages retrieved 2026-09-02 in a fixpoint crawl of the site. /open-platform-apis carries it as a checklist - 'Industry-leading security standards: SOC 2 Type 2 Compliant / PCI DSS Level 1 Service Provider / Platform uptime >99.95%' - and repeats it as 'SOC 2 Type 2 and PCI DSS Level 1 certified, with continuous monitoring'; the home page and /enterprise-loyalty-program-management-software state 'SOC 2 Type II certified, PCI DSS Level 1 Service Provider'; /growth-brands states 'PCI DSS Level 1 Service Provider'. Shortfalls, all material to the claim as worded: (1) it is a badge and not an attestation - no Attestation of Compliance, ROC summary, QSA name or certificate is published anywhere on the site, in the 168-page docs.thanx.com corpus or in any of the 18 published legal instruments; (2) no DSS version is named, so nothing distinguishes a v3.2.1 assessment from a v4.0/4.0.1 one; (3) no assessment or expiry date is given, so 'current' cannot be established; (4) nothing addresses the post-March-2025 future-dated requirements, and there is no validated P2PE listing - 'P2PE' is zero across all five first-party corpora. The vendor routes the artefact away from publication rather than denying it exists: the published DPA (/dpa01012025va) offers an 'Audit Report ... prepared by third-party security professionals' 'upon request from Merchant', with further audit at merchant cost and 'subject to reasonable confidentiality procedures'. There is no /security, /trust, /compliance or /pci page (557-URL sitemap re-fetched 2026-09-02; www.thanx.com/security returns 404; trust.thanx.com and security.thanx.com redirect to rewards.thanx.com and 403), and help.thanx.com/hc/en-us 302s to /hc/en-us/restricted with its Help Center API returning HTTP 401, so a merchant-gated trust package would be invisible to us. https://www.thanx.com/open-platform-apis · retrieved 2026-09-02

reliability-mfa-role-based-access

The RBAC limb is met and documented in mechanism detail (2026-04-13 release): custom roles are built at Dashboard Access in the profile menu across seven feature areas - 'Marketing, Customers, Dashboard Management, Program Configuration, Loyalty Program, Games & Experiences, and Reporting' - each set to 'No Access, Can View, or Can Manage', with role templates (Location Manager, Customer Service, Accountant), per-location scoping, invite-with-role, and admin-only administration ('Only admins can manage users and roles. Your account must always have at least one admin'). Shortfalls are named by the vendor itself: 'Location-based reports aren't fully scoped yet. Insights Lab and Looker Labs reports don't support location scoping in this release'; 'Guest profiles are visible in full regardless of location assignment'; 'Users who have no locations assigned will have access to all locations'; and overlapping roles resolve as 'the union of all roles - so the most permissive setting for each feature area applies', meaning a restrictive role cannot reduce access. The MFA limb is unmet on the evidence available: no multi-factor or two-factor enforcement setting appears in any of the 168 doc pages, the 101 changelog entries or the public help-center articles, and Thanx's own July 2026 security post describes the one visible new dashboard-access control as a warning when 'someone tries to invite a new dashboard user from an unfamiliar email domain', not MFA. Scope note: this is the back-office dashboard only - there are no POS administrative logins, because Thanx supplies no POS. https://thanx.launchnotes.io/announcements/role-based-permissions-for-every-user-on-your-team · retrieved 2026-09-01

reliability-self-serve-training

The public half exists and is free and un-gated: www.thanx.com/videos-webinars is a filterable 'library of on-demand videos and webinars' (four pages of items, filterable by Type and by Topic - Learn, Trends, News, Product, Loyalty, Engagement, Data, Company), including a 'Thanx Tech Tips' series of product walkthroughs ('New Customer Checkout Flow', 'Perks in the Ordering Experience', 'Returning Customer Experience', 'Straight to Ordering'), alongside www.thanx.com/guides and 19 public how-to articles under www.thanx.com/help-center (including per-POS loyalty integration guides for Toast, Square, Qu and NCR Aloha). Shortfalls, both concrete: (1) it is not a staff-onboarding curriculum - the bulk is case-study, webinar and thought-leadership content, the vendor's actual product knowledge base at help.thanx.com/hc/en-us redirects to a dashboard.thanx.com SSO login (Help Center API returns HTTP 401), and the in-product tutorial videos Thanx announced are reachable only inside the dashboard ('Click the tutorial banner at the top of any Insights Lab report'); (2) there is no practice or training mode on a terminal, because Thanx supplies no terminal - the register is the merchant's third-party POS, and the only sandbox Thanx publishes is a developer sandbox for API integrators (docs.thanx.com/overview/sandbox-faq), not a staff training mode. https://www.thanx.com/videos-webinars · retrieved 2026-09-01

reliability-failover-terminal-role differentiator

Thanx ships no terminal and no terminal software: its own POS / Kiosk integration guide is written for a third-party POS or kiosk vendor building against Thanx ('you will be provided the following credentials: Client ID, Client Secret, Merchant ID, Merchant Key, Partner Token'), and the loyalty flow at the register is a cloud round trip on every basket state change - Create Access Token -> Get Account -> Create or Update Basket, called again 'any time the user updates their basket or reward selection'. The 168-page developer corpus (llms.txt and sitemap.xml enumerate it identically) documents no terminal application, no local server and no LAN component. With no first-party terminal application and no on-premise server, there is no primary/secondary role for a peer to assume: each POS or kiosk holds its own issued credentials and calls Thanx's hosted endpoints independently, and when those endpoints are unreachable the vendor states that 'in-store loyalty via POS will be unavailable' rather than describing any local election or takeover. 'failover' returns zero hits across the 168-page corpus and the 101 changelog entries. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

reliability-cellular-backup

Thanx ships no terminal and no terminal software: its own POS / Kiosk integration guide is written for a third-party POS or kiosk vendor building against Thanx ('you will be provided the following credentials: Client ID, Client Secret, Merchant ID, Merchant Key, Partner Token'), and the loyalty flow at the register is a cloud round trip on every basket state change - Create Access Token -> Get Account -> Create or Update Basket, called again 'any time the user updates their basket or reward selection'. The 168-page developer corpus (llms.txt and sitemap.xml enumerate it identically) documents no terminal application, no local server and no LAN component. The claim asks about terminals supporting automatic cellular/LTE failover, first-party or documented; Thanx has no first-party terminal to equip, 'cellular' returns zero hits across all 168 pages of docs.thanx.com and all 101 dated changelog entries, and no connectivity-failover guidance of any kind is given to POS or kiosk integrators. Connectivity at the register belongs to the merchant's own POS vendor; when the Thanx cloud is unreachable the vendor's stated position is that in-store loyalty via POS is simply unavailable. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

commercial-month-to-month-contract differentiator

Merchant Agreement (effective 2.20.26), Sec. 10.1: 'The term of the Services will commence on the Project Kick-Off date set forth in the Order Form and ... shall continue for the Initial Subscription Term identified therein. This Agreement shall automatically renew for additional terms of equal length to the Initial Subscription Term ... unless either Party notifies the other in writing of its intent not to renew at least sixty (60) days prior to the end of the Initial, or any Renewal, Subscription Term.' Sec. 7.1: 'All Fees are non-refundable and non-cancellable.' Sec. 5.2: 'Fees are fixed for the stated number of Locations set forth in the Order Form and Fees will not be downward adjusted or suspended by Merchant for any Locations for any reason during the Term.' Termination (Sec. 10.2) exists only for uncured material breach - there is no termination for convenience. www.thanx.com/pricing publishes no figures and no term options ('To discuss pricing tailored to your brand, schedule a demo'). The finding is about the public offer: no month-to-month subscription is publicly offered. The LENGTH of the Initial Subscription Term is itself not published - it lives in the unpublished Order Form - so this is not a finding that the minimum is multi-year. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-no-early-termination-fee differentiator

Merchant Agreement (effective 2.20.26), Sec. 7.1: 'All Fees are non-refundable and non-cancellable.' Sec. 10.2 grants termination only where 'the other Party materially breaches this Agreement and fails to cure such breach within thirty (30) days following written notice' - no termination for convenience is offered. Sec. 10.3: 'Upon any expiration or termination of this Agreement, Merchant will pay all amounts due to Thanx within thirty (30) days from the last day of the month in which the termination is effective.' Sec. 5.2 adds that fees 'will not be downward adjusted or suspended by Merchant for any Locations for any reason during the Term'. The published terms therefore do not state that no early-termination fee or liquidated damages apply; they make the committed fees payable regardless. No separate liquidated-damages figure is published - the remedy is simply that the term's fees remain owed. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-autorenew-terms-published

Merchant Agreement, headed 'Effective 2.20.26', served publicly (HTTP 200, server-rendered HTML, no login) at www.thanx.com/merchant-agreement-2026. Sec. 10.1: 'This Agreement shall automatically renew for additional terms of equal length to the Initial Subscription Term (each a "Renewal Term"), unless either Party notifies the other in writing of its intent not to renew at least sixty (60) days prior to the end of the Initial, or any Renewal, Subscription Term.' Both the renewal mechanism (automatic, equal-length) and the required notice window (60 days) are published. The length of the Initial Subscription Term itself, and all fee amounts, remain in the private Order Form. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-processing-not-bundled differentiator

Read in full, the 2026 Merchant Agreement contains no payment-processing, acquiring or merchant-account obligation of any kind; Sec. 7.5 'Third-Party Services Fees' names only SMS pass-through fees for in-store enrollment and third-party delivery fees. The developer documentation agrees: in the POS/Kiosk flow the POS itself charges the card ('the order has been transmitted to the POS and the user's credit card has been charged'), and the pay-at-table guide warns that card-linked accrual fails for 'Payments made through Stripe or other payment service providers (aggregators) ... processed under the provider's merchant ID rather than the merchant's own' - the merchant's own acquiring relationship is assumed throughout. Shortfall: Thanx is a loyalty/CRM and ordering layer over someone else's POS, so processor freedom is bounded by whatever that POS or ordering middleware supports - the 2026-08-11 Deliverect release sells exactly that as the benefit, Deliverect 'connects to more POS systems and payment processors than other ordering middleware' - and Thanx publishes no list of processors supported by its own ordering checkout. There is no in-house Thanx processing to be locked into. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-interchange-plus-published differentiator

Merchant Agreement Sec. 7 read in full: 7.1 fees are invoiced 'pursuant to the terms of the Order Form' and are 'non-refundable and non-cancellable'; 7.2 taxes; 7.3 a 1.5%-per-month late-payment charge; 7.4 suspension for 30-day arrears; 7.5 'Third-Party Services Fees' limited to SMS pass-through for in-store enrollment and third-party delivery fees. No interchange, discount rate, bps markup or per-transaction card fee appears anywhere in the agreement, and www.thanx.com/pricing publishes no figures at all. The developer docs put card processing on the operator's POS or PSP under the merchant's own merchant ID, not through Thanx. This is a no because there is no processing product to price, not because a rate card is being withheld. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-rate-increase-clause differentiator

The 2026 Merchant Agreement contains no rate-protection clause. Sec. 7.1 fixes fees only by reference to the Order Form ('Thanx will invoice Merchant, and Merchant shall pay, for all Fees pursuant to the terms of the Order Form. All Fees are non-refundable and non-cancellable.'), and Sec. 10.1's automatic renewal 'for additional terms of equal length' carries no pricing term and no notice-of-increase mechanism; the only exit is written non-renewal at least 60 days before term end, which is not conditioned on any fee change. Sections 7.1-7.5 and 10.1-10.4 were read in full and contain no cap, no prohibition on unilateral increases and no increase-triggered termination right. Thanx also has no processing agreement - it provides no card processing - so the interchange pass-through half of the claim has no surface. Renewal-term pricing is left to the unpublished Order Form. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-pricing-published

Pricing page explicitly declines to list tiers, citing restaurant count, AUV and capability mix; demo request only. https://www.thanx.com/pricing · retrieved 2026-08-01

commercial-module-unbundling differentiator

Merchant Agreement Sec. 2.1 grants a licence to 'the Services selected in the Order Form during the Term', and the vendor's product surface is modular (Loyalty, Digital Ordering & Apps, Marketing Automation, Offer Management, CRM & Segmentation, Guest Recovery, Reporting & Analytics, Thanx Data Platform, ThanxAI), with the pricing page saying fees follow 'restaurant count, average unit volume, and the platform capabilities you need' - so capabilities are selected and priced individually at order time. Shortfall: no published term allows a module to be cancelled independently. Sec. 7.1, 'All Fees are non-refundable and non-cancellable'; Sec. 5.2, fees 'will not be downward adjusted or suspended by Merchant for any Locations for any reason during the Term'; Sec. 10.2 offers termination only for uncured material breach of the entire agreement, and Sec. 10.1 renews the whole agreement automatically. The claim's 'base POS subscription' has no analogue here - Thanx sells no POS - so this scores the loyalty/ordering platform subscription. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-hardware-purchase-outright

No mandatory hardware lease is possible because Thanx sells no hardware - operators run it over terminals they already own for their separate POS - but no Thanx hardware price list exists either, so the claim's published-price limb has nothing to satisfy it.

commercial-hardware-not-locked differentiator

The POS / Kiosk Integration Guide documents the entire in-store surface as three REST calls (Create Access Token, Get Account, Create or Update Basket) made by the operator's own POS or kiosk software, with a downloadable Postman collection and a mandatory certification checklist - no Thanx-supplied terminal, printer, scanner or cash drawer appears anywhere, and the guest identifies by QR code, phone number or email on whatever device the POS vendor supplies. The certified partners named across the changelog are all third-party POS platforms (Toast, Square, PAR/Brink, NCR Aloha, Qu, Xenial via Genius, Deliverect, Olo). Merchant Agreement Sec. 5.3 puts the consumer half on commodity devices: Thanx 'will publish a white label version of the Thanx mobile application ... for Merchant on both iOS and Android platforms', and the 2026-04-30 release records the React Native app live on the App Store and Google Play. There is no vendor-only device requirement of any kind. The corollary is that Thanx publishes no hardware compatibility list, because it certifies software integrations rather than devices. https://docs.thanx.com/overview/guides/pos-kiosk · retrieved 2026-09-01

commercial-implementation-fee-published

www.thanx.com/pricing publishes no figures of any kind and routes to sales ('To discuss pricing tailored to your brand, schedule a demo with our team'), saying only that fees follow 'restaurant count, average unit volume, and the platform capabilities you need'. www.thanx.com/implementation, the dedicated services page, sells a guided implementation ('Go live in 90 days with expert guidance'; 'Our average implementation takes 90 days, and many customers launch much faster') with a dedicated implementation manager, discovery, technical setup, training and testing - and states no cost and no inclusion in the subscription. www.thanx.com/faqs offers only 'Thanx pricing is designed to scale with your business and deliver strong ROI from day one'. Merchant Agreement Sec. 5.1 makes implementation and onboarding a contractual deliverable scheduled by the Order Form and Sec. 7.1 puts all Fees in that Order Form. One-time implementation fees therefore exist as a contractual object, and no amount is published anywhere nor stated to be zero. https://www.thanx.com/pricing · retrieved 2026-09-01

commercial-data-export-self-serve

docs.thanx.com/data/overview documents three raw-data mechanisms - SFTP CSV exports 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform'; Snowflake Secure Data Sharing; and Thanx Connex managed loading into twenty named destinations (Snowflake, BigQuery, Redshift, Databricks, Athena, ClickHouse, Postgres/MySQL/SQL Server/Oracle/MongoDB, S3, GCS, Azure Blob, SFTP, Google Sheets) - with per-table schemas at /data/models/* and an additive-schema-change policy at /data/changelog. Two named shortfalls. (1) Not self-serve: for SFTP, 'If you are an existing customer and would like to get access to this data, please reach out to your Thanx success manager directly and they can set this up'; multi-file exports and Connex carry the same instruction and Snowflake sharing is 'a manual, one-time configuration'. (2) The transactional grain is thin: the documented purchases model exposes purchase/order/location ids, authorization_amount, settlement_amount, channel, purchased_at and pos_id/pos_provider only - no line items, no modifiers, no tender breakdown - and no labor data exists anywhere in the platform (Thanx employs no one on the operator's behalf). The Consumer and Partner REST APIs document GET /purchases, but as per-user reads rather than a full-history export. https://docs.thanx.com/data/overview · retrieved 2026-09-01

commercial-export-customer-and-loyalty differentiator

Guest records and loyalty balances export cleanly; gift-card liability does not. docs.thanx.com/data/overview states the SFTP export is 'updated once every 24 hours and are a snapshot of the entire data set resident within the Thanx platform in CSV format', and it is that self-completeness sentence, not the page's bullet list, that bounds the platform: the page's Models section links nine models but a tenth model page is published at /data/models/loyalty-reward-progress-legacy (filed under Archive, listed in llms.txt, documenting loyalty_reward_progress_legacy.csv with three columns), so that list is a floor and not a census. The tenth is another loyalty table; all ten models are loyalty, guest, campaign or purchase entities and none is an employee, timecard, shift, tip, inventory, recipe, supplier, invoice or ledger entity. Ten model pages are published - the nine linked from the overview (campaigns, communication-preferences, memberships, nps-feedback, points-accounts, points-transactions, programs, purchases, rewards) plus /data/models/loyalty-reward-progress-legacy under Archive - each delivered as CSV over SFTP and as a named Thanx Connex table. Guest records: memberships carries user_id/user_uid, first_name, last_name, email, birthday, zip_code, phone, tier_status, user_joined_at, user_entered_crm_at and alternate_pos_id. Loyalty balances: points_accounts carries balance, points_program_currency and points_program_conversion_rate per account; points_transactions is the debit/credit ledger; rewards carries issuance, discount, estimated_cost, expiration_at and retired_at; and the tenth model exports loyalty_reward_progress for non-points programs. Shortfall: there is no gift-card model on any export path - I fetched all 37 pages under /data/ as markdown on 2026-09-01 and 'gift' occurs zero times in them - and Thanx's gift cards are third-party-provider balances (a direct Valutec integration plus the gift-card providers Olo supports) surfaced through per-user consumer endpoints, so gift-card liability is not exportable in machine-readable form by the operator. Withdrawn from this note: the earlier assertion that the overview enumerates the data set as exactly nine tables, which is false. https://docs.thanx.com/data/overview · retrieved 2026-09-01

commercial-post-termination-export-window differentiator

Merchant Agreement Sec. 10.3 (Effect of Termination): 'Upon any expiration or termination of this Agreement, Thanx will continue to make available to Merchant all Merchant Data for export for a period of thirty (30) days following the effective date of termination, provided Merchant has paid in full all amounts due to Thanx pursuant to this Agreement.' Sec. 10.4 lists 10.3 among the surviving sections. The window is a defined number of days rather than an immediate cutoff, and it is published rather than quote-only. Two conditions attach: payment in full of amounts due (themselves payable within 30 days of the last day of the month in which termination is effective), and Sec. 6.2.4's perpetual post-term licence, which covers Program Data only 'in connection with any loyalty program operated by Merchant or on Merchant's behalf'. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-data-ownership-clause differentiator

Ownership half satisfied: Merchant Agreement Sec. 6.1.1, 'As between Merchant and Thanx, Merchant owns all right, title and interest in and to the Merchant Data,' with Thanx's licence limited to 'process the Merchant Data for the purpose of performing the Services'; transfers to Integrations require the merchant's express consent, revocable by email to support@thanx.com. Use/resale constraint satisfied for personal data: the published DPA states Thanx 'will not (a) "sell" or "share" (as defined in Data Protection Law) the Personal Data; (b) retain, use, combine, or disclose the Personal Data for any purpose other than as permitted under this DPA ... or (c) retain, use, or disclose the Personal Data other than in the context of the direct relationship with Merchant.' Shortfall: Sec. 1.8 defines Program Data to include 'transaction data attributes provided to Thanx by third party credit card networks (such as settlement amount, date, time, and location)' plus derived aggregated insights, and Sec. 4 (Reservation of Rights) provides that 'Thanx and its licensors own all right, title and interest in and to the Services, Program Data'. The merchant holds only a licence to that transaction data - during the Term for administering its loyalty programme (Sec. 6.2.1), perpetually after termination for loyalty purposes (Sec. 6.2.4) - and the anti-resale covenant at Sec. 6.2.3 binds the MERCHANT, not Thanx. So merchant ownership does not reach all transaction data, and Thanx's own use of Program Data is not confined to aggregated or de-identified use. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-source-available-selfhost

Merchant Agreement Sec. 4 (Reservation of Rights): 'Thanx and its licensors own all right, title and interest in and to the Services, Program Data, and all intellectual property rights therein ... Merchant shall not (a) modify, adapt, alter or translate the Services, (b) sublicense, lease, sell, resell, rent, loan, distribute, transfer the Services ... (d) reverse engineer, decompile, disassemble, or otherwise derive or determine or attempt to derive or determine the source code (or the underlying ideas, algorithms, structure or organization) of the Services ... or (e) create derivative works based on the Services.' Sec. 2.1 grants only 'a non-exclusive, non-sublicensable, non-transferable ... license during the Term to access and use the Services'. Consistent with a hosted-only product, every documented environment is Thanx-operated (api.thanxsandbox.com, api.thanx.com), sandbox credentials are issued by Thanx Developer Support and production API keys are released only after a mandatory certification review. No licence, repository or self-hosting page exists on the 168-page developer-doc surface (enumerated twice by the vendor) or in the 557-URL marketing sitemap; the only 'self-hosted' references in the docs concern the CUSTOMER's own data warehouse or authentication provider. https://www.thanx.com/merchant-agreement-2026 · retrieved 2026-09-01

commercial-pci-p2pe-tokenization

The tokenization half is documented and the vendor names its vault partners: 'Thanx utilizes a third party payment processor and a payment orchestration platform, to validate, tokenize and vault credit cards (and other payment types) ... Each are PCI-DSS compliant and only store tokenized card data. Please see Stripe's Privacy Policy and Basis Theory's Privacy Policy ... Thanx does not store credit card numbers.' SHORTFALL: no SAQ is ever named — 'SAQ' and 'P2PE' occur zero times across the closed 168-page docs corpus, the 124-page www corpus and the 18 published contracts — and the P2PE limb is structurally unavailable, because Thanx supplies no card-entry hardware ('Zero hardware requirements') and does not acquire: the Toast Ordering Integration Addendum routes acceptance to Stripe, and the July 2026 release to Square Payments. The only first-party compliance statement is an unversioned 'PCI DSS Level 1 Service Provider' badge, which is a service-provider assertion, not a merchant scope-reduction statement. CITATION NOTE (verified 2026-09-04): dashboard.thanx.com/privacy is a client-rendered route — a plain HTTP fetch returns the 1,880-byte SPA shell containing neither 'Basis Theory' nor 'tokenize'. The quoted passage was read from the console's application bundle, dashboard.thanx.com/static/js/main.568d2c06.js (7,999,311 chars), where the privacy text ships as strings, exactly as for the other bundle-backed cells in this record. https://dashboard.thanx.com/privacy · retrieved 2026-09-04 adversarially verified

commercial-pci-dss-4-controls

The claim's headline control can now be measured directly rather than inferred, and it is absent: the back-office console enforces no MFA. Its login is 'Log in to Thanx' with 'Email', 'Password' and 'Forgot your password?' and the error 'Invalid username/password combination', and across the full 7,999,311-char application bundle (fetched 2026-09-04) 'MFA', 'multi-factor', 'two-factor', '2FA', 'authenticator', 'one-time code' and 'verification code' all occur zero times (the only 'security code' strings are Stripe card-entry copy). Script-integrity monitoring is equally undocumented: '6.4.3', '11.6.1' and 'script integrity' are zero across the console, the closed 168-page docs corpus and the 124-page www corpus, and no /security, /trust, /compliance or /pci page exists (www.thanx.com/security returns 404, re-probed 2026-09-04). The vendor's only PCI statement is an undated 'PCI DSS Level 1 Service Provider' badge citing no requirement, and the 2026-07-08 'levelling up security' post enumerates credential scanning and invite warnings with no MFA requirement. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified

commercial-soc2-attestation

Data Processing Addendum (effective 1-1-2025), Audit section: 'Thanx will make available to Merchant at Merchant's request reasonable information which is necessary to demonstrate compliance with this DPA ... To the extent Thanx makes available to Merchant confidential summary reports ("Audit Report") prepared by third-party security professionals, upon request from Merchant, Thanx may provide such Audit Report in satisfaction of any audit rights accorded to Merchant pursuant to Data Protection Law' - with a further right to a bespoke audit at the merchant's cost on not less than 30 days' notice, under confidentiality. Shortfalls, all measured: the report is described only as 'confidential summary reports ... prepared by third-party security professionals', so no framework is named and 'to the extent Thanx makes available' is permissive rather than a warranty that one exists; the strings 'SOC 2', 'SOC2' and 'ISO 27001' appear zero times across the 168-page developer docs, the 101 dated changelog entries, the Merchant Agreement and the DPA; and there is no trust centre or security page - www.thanx.com/security, /trust and /legal all return 404 and none appears in the vendor's own 557-URL sitemap. The 2026-07-08 security announcement describes hardening work and names no attestation. A current attestation may well exist and be shared under NDA during procurement; what is published is the mechanism, not the attestation. https://www.thanx.com/dpa01012025va · retrieved 2026-09-01

commercial-privacy-dsar-tooling

Published-DPA half satisfied: www.thanx.com/dpa01012025va (effective 1-1-2025), incorporated by Merchant Agreement Sec. 9.2, provides that Thanx will 'assist Merchant, taking into account the nature of the Processing and the information available to Thanx, in complying with Merchant's obligations to respond to requests concerning Personal Data from individuals under applicable Data Protection Law', will 'delete or return the Personal Data' on termination as instructed, will not sell or share it, and binds subprocessors to substantially similar terms. Deletion tooling exists: docs.thanx.com/consumer/users/delete-user submits an account-closure request, and the 2026-05-08 release 'Marketing suppression list for users with deleted accounts' adds an automatic merchant-specific email suppression list on account deletion - 'automatically enabled for all merchants; no setup is required' - visible in the dashboard for the last 30 days, with a weekly notification to 'your designated CCPA opt-out email contact' configured on the dashboard's Terms and Policies settings page. Shortfalls: the documented deletion endpoint is a request, not an action - 'The Thanx support team will review the request and interface directly with that user to complete account closure' - so it is not self-serve; no in-app tooling to LOCATE or EXPORT an individual guest's records is documented anywhere (bulk export is table-level SFTP/Connex); and Merchant Agreement Sec. 9.2 places the duty on the operator: 'Merchant is responsible for responding to all requests and demands directly from data subjects ... including ... requests for data access, correction, deletion, portability, and the opt-out of the sale or sharing of Personal Information.' The merchant help centre that would document any dashboard DSAR screen is behind SSO (help.thanx.com 302s to dashboard.thanx.com; Help Center API HTTP 401). https://www.thanx.com/dpa01012025va · retrieved 2026-09-01

commercial-wcag-kiosk-accessibility differentiator

Census of the vendor's own sitemap.xml (557 URLs, fetched 2026-09-01 under 'Allow: /'), which lists the full legal-document set (merchant agreement, DPA, API addendum, BAA, additional terms, delivery services, referral terms, cookie policy) and contains no accessibility, VPAT, ACR, conformance or trust page. Direct probes confirm it: www.thanx.com/accessibility, /vpat, /trust and /security each return HTTP 404. 'WCAG', 'VPAT' and 'ACR' appear zero times in the complete 168-page docs.thanx.com corpus (enumerated identically by llms.txt and sitemap.xml) and zero times in the 101 dated changelog entries; the only accessibility material in the docs is a design best-practice line telling integrators to 'check font size and color contrast against accessibility standards', linking a third-party contrast tool - guidance to partners, not a conformance claim. The kiosk half has no surface at all: Thanx publishes no kiosk product, only an API its POS/kiosk partners call, so no tactile or audio non-visual access mode could be documented by Thanx. Nor is a conformance report published for the consumer web-ordering surface. A VPAT furnished privately during procurement would not satisfy a claim about publication. https://www.thanx.com/sitemap.xml · retrieved 2026-09-01

commercial-dual-pricing-compliant differentiator

The merchant console is the complete configuration surface for the Thanx checkout, and it contains no fee engine: 'surcharge', 'dual pricing' and 'cash discount' occur zero times in main.568d2c06.js (7,999,311 chars, fetched 2026-09-04), there is no fee, BIN, debit-exclusion or card-type object anywhere in it, and the same three terms are zero across the closed 168-page docs corpus, which likewise has no fee object in any endpoint. The only related artefact is a free-text disclosure box shipped April 2026 — 'Add a note explaining service charges or surcharges so customers aren't surprised at the end of checkout' — a message field, not a pricing rule, and it addresses none of automatic computation, debit and prepaid exclusion, or receipt and menu-board disclosure. Thanx does not acquire: fee assessment sits with Stripe under the Toast addendum, Square Payments, or Deliverect's processors, which are also the only parties holding the BIN data a compliant program needs. https://dashboard.thanx.com/login · retrieved 2026-09-04 adversarially verified