Deliverect

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

menu-pricing-nested-modifiers

Nested modifiers are documented on the live POS integration guide How to configure Modifier Groups (updatedAt 2026-09-04): 'A product configuration can include a sub-group of options to be selected. These options themselves can also contain their own sub-groups, this is reffered to as "Nested Modifiers"' [sic], with a mermaid figure and a worked payload running Chicken Sate P-SATE -> modifier group MG-RICE (min 1, max 1) -> product RICE-01 -> modifier group MG-SAUCES (min 0, max 1) -> SAUCE-01/SAUCE-02. Per-level selection control is fully evidenced: the Ordering Group Rules table defines min, max, multiMax, multiply, maxUniqueOptions and minUniqueOptions on each group, and states the forced-selection flag verbatim - min '`0` would be equivalent to "optional" and `1` or more would be "required"'. SHORTFALL: depth. The claim asks for at least three levels of nesting; the documentation demonstrates TWO modifier-group levels and asserts further recursion only through the general sentence that options 'can also contain their own sub-groups', with no three-level example, no stated maximum, and no statement that depth is unbounded. Deliverect is middleware, so what a channel or POS renders from a nested menu is not Deliverect's capability either way. Order-side interpretation is documented separately: modifiers arrive nested under subItems and 'Total modifiers ordered = quantity of modifiers x quantity of products' (.../docs/how-to-interpret-order-quantity.md, updatedAt 2026-08-26). https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-modifier-groups.md · retrieved 2026-09-15 adversarially verified

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

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

Half the claim is documented and half is not. Overloads (live guide, updatedAt 2026-08-16) let 'Specific item attributes ... be overridden depending on the item or grouping it is offered within': an `overloads` array of objects, each a `scopes` list of one or more PLUs plus override properties, with the worked example pricing Avocado (base 100) at 0 when scoped to modifier group FREE-TOP and at 100 when scoped to product POKE - the prose above that payload says 50, a vendor self-inconsistency. A second example overrides `bundlePrice` to 0 in bundle group FREE-DESS and `price` to 450 inside combo product BRGR_COMBO. So a single modifier item, defined once, carries different prices per PARENT ITEM or per GROUP without being duplicated. SHORTFALL: the per-SIZE half. Sizes are variant options inside one variant group (MG-VAR-1 -> VAR-1/VAR-2/VAR-3), and nothing scopes a price to a chosen sibling option: the overload table defines `price` as 'Standard price override for any item within a Modifier Group `productType:3`)' and the Insert/Update OpenAPI describes `scopes` as 'surcharges applied to the specific modifier group or bundle'. Scoping to the variant group itself cannot discriminate 3 from 6 from 9 pieces. Per-size topping prices would require attaching a separate modifier group to each size option and one overload row per group - a composition no page demonstrates or mentions. https://developers.deliverect.com/v1.1-restaurants/docs/overloads.md · retrieved 2026-09-15 adversarially verified

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

menu-pricing-fractional-placement

Held to the highest bar per the brief. Independent keyword sweep of the full 145-page doc index returned zero hits for 'fractional', 'half' or 'pizza' as page subjects. Combined with the documented flatten-nested-modifiers guidance, the absence is affirmative enough to sustain 'no'. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

menu-pricing-half-and-half-rule

Searched Deliverect's words: half, fraction, portion, topping, pizza, variant, bundle, overload, modifier. The Product Structure page enumerates every product-configuration guide (modifier groups, auto-apply, upsell, variant, meal deal, bundles, overloads, ingredient groups) and no fractional/half placement exists; the help product-types page lists the same six types. The corpus's only 'half pizza' is NCR Voyix's own Advanced Pizza feature. No half pricing rule is stated. Absence bounded to the four llms.txt manifests plus the Intercom and vendor sitemaps. SOURCE QUOTE: "Outside of basic product structure, these guides show the required format to apply product configurations typical to ordering platforms;" https://developers.deliverect.com/v1.1-restaurants/docs/structure · retrieved 2026-09-06 adversarially verified

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

menu-pricing-topping-quantity-tiers

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/glossary-pos-orders.md returns 200 and still carries the per-item quantity field. The old note's remark that the field note "links to the deleted article" is now WRONG in its premise: the modifier-quantity guide was MOVED, not deleted, and is live at https://developers.deliverect.com/v1.1-restaurants/docs/how-to-interpret-order-quantity.md (indexed as "How to handle Item 'Quantity'" in the v1.1-restaurants manifest), alongside https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-modifier-groups.md which documents min / max / multiMax / defaultQuantity. A FUTURE PASS SHOULD RE-READ THAT PAGE AND DECIDE WHETHER THE MULTIPLICATION RULE THE 2026-08-09 NOTE WITHDREW (total = modifier qty x product qty) IS RECOVERABLE; it was withdrawn on the false belief that the page was gone, not on a reading of the page. The verdict itself is not disturbed here: light/regular/extra multiplier TIERS remain undocumented anywhere in the 377-document corpus, which is what 'partial' rests on. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/glossary-pos-orders.md · retrieved 2026-09-15

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

menu-pricing-size-style-matrix

One axis, not a grid. The live variant products guide (updatedAt 2026-08-16) defines a variant as letting customers 'choose between different versions of the same product, such as size, flavor, or quantity', built from a variant product (`isVariant: true`), a single variant group (`isVariantGroup: true`) and options that each follow 'a standard product setup with its own `plu`, `price`, and tax fields'. The worked payload is Chicken Tenders (price 0) -> MG-VAR-1 'How many pieces?' (min 1, max 1) -> 3 Pieces 800 / 6 Pieces 1100 / 9 Pieces 1350, with the parent advertising the lowest option price ('Deliverect will send ordering platforms the lowest priced option as the variant product'). SHORTFALL: that is a single single-select modifier group along ONE axis, with a flat price per option. Nothing documents a second variant axis or a per-cell price override across a pair of axes. A size x crust menu can only be modelled as two independent single-select groups whose pricing is additive - the retired product-configuration page described exactly that shape ('for Pizza, the "Size" and "Crust" or other single-select groups') - so a 5x4 grid still needs its 20 prices expressed as sums, not as 20 overridable cells. The one combination-scoped construct in the docs, an overload scoped to a product-and-group pair ('BYOP-00-->>BYOP-TOP'), is documented only for `defaultQuantity`, not for price, and keys on a group rather than on a chosen option. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-variant-products.md · retrieved 2026-09-15 adversarially verified

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

menu-pricing-included-allowance

Audit re-based the evidence: the earlier rationale ('does not provide the menu-entry surface') was wrong — Deliverect does ship a menu builder with modifier groups. But the product-configuration reference enumerates the entire modifier-quantity model — min, max, multiMax, defaultQuantity, and isIngredientGroup ('It is only possible to define items with zero price within modifier groups with the flag isIngredientGroup: true') — and no included-allowance / charge-only-for-overage mechanism is among the documented options. Value no stands on that enumeration. RE-BOUND 2026-09-15: /page/product-configuration.md now 404s (393,670 b, byte-comparable to a fabricated /page/ control at 393,680 b; a known-good /page/ control returns 200 at 34,324 b). It was moved, not deleted, but it moved in pieces; the ingredient-group and modifier-quantity enumeration this cell rests on is now at .../v1.1-restaurants/docs/how-to-add-ingredient-groups-modifier-deltas.md (200, 4,198 b, updatedAt 2026-08-16), which carries the quoted sentence verbatim along with min/max/multiMax and scoped defaultQuantity, and still shows no allowance/overage mechanism. Value and grade unchanged. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-ingredient-groups-modifier-deltas.md · retrieved 2026-09-15 adversarially verified

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

menu-pricing-combos

Meal deals are 'a combination of products with a fixed price', built from meal deal sections that each carry 'Minimum selection', 'Maximum selection' and 'Allow customers to select an item more than once'. Component swap-with-delta is explicit: 'If you want some products to cost extra, activate the Surcharge option and set a price', repeated in the Simphony combo article as 'To change the price of a product inside a meal deal section, select the Surcharge option and enter the additional charge'. Named shortfall: nothing in the 984-article English help centre describes the system detecting eligible a-la-carte items already in a cart and converting them to the combo price - a meal deal is a Deal-type product the guest selects, and modifier groups cannot be added inside meal deal sections. https://help.deliverect.com/en/articles/7979030-create-a-meal-deal · retrieved 2026-08-09

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

menu-pricing-upsell-prompts

Kiosk upselling plus a Deliverect AI 'Autonomous Menu Agent' that deploys upsells and tracks performance in Mission Control. Per-channel config and attach-rate reporting are claim-level. https://www.deliverect.com/en-us/deliverect-ai · retrieved 2026-08-01

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

menu-pricing-86-propagation

Snoozing an item propagates from the menu hub to connected marketplaces, Kiosk and first-party channels. No numeric propagation latency published. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

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

menu-pricing-countdown-auto-86

Retail-side Post Inventory Update and Inventory JSONL endpoints drive availability from stock levels; automatic 86-at-zero with scheduled restore for restaurants is not documented. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01

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

menu-pricing-dayparting

Scheduling is at menu and category level, not per item. 'Add menu availability: Create a schedule for the entire menu. Add category availability: Create a schedule for specific categories. This is not supported by all channels' -- e.g. 'select a Breakfast category and specify that it should only be available from 7 am to 12 pm', chosen per location. Menus/Schedules lets you 'Schedule one or multiple menus to be published at different times of the week', which is how prices are dayparted (a different menu carries different prices). The API models the same thing: availabilities[] with dayOfWeek 1-7, startTime and endTime 'expressed in the local time of the location', on the menu and on categories.availabilities. Shortfall: no per-item day/time schedule -- an individual product is controlled by Snoozing, a manual pause 'for one hour, multiple hours, indefinitely, or until a chosen date', not a recurring calendar. https://help.deliverect.com/en/articles/7978991-add-or-edit-menu-availability · retrieved 2026-08-09

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

menu-pricing-channel-price-books

RE-CITED 2026-08-09: the cited /docs/price-level-configuration.md is deleted (404). Measured 2026-08-09 with a known-good control (/docs/staging-and-production-environment.md, 200/2445b) and a fabricated control (404 at the ~237KB ReadMe shell), on a prober that retries 429 rather than scoring it. The mechanism survives, and on a better surface -- the schema page the record already cites elsewhere. "Optionally, additional prices can be defined using `"priceLevels"` in order to support different pricing for specific ordering channels and menu fulfilment type", with a worked example on one product record: `"priceLevels": { "TA": 350, "DL": 400, "1PO": 300 }` against named levels Takeaway, Delivery and First Party. THE OLD NOTE'S WORKED EXAMPLE (a Hawaiian pizza at EUR8 / 8.25 / 9) IS NOT RECOVERABLE -- it lived only on the deleted page and appears nowhere in the 64-document /page/ corpus or the 983-article help centre -- so it is withdrawn and replaced rather than restated. The researcher's caveat is UNCHANGED and still correct: prices originate in the POS payload and Deliverect selects the applicable level, it does not compute a markup. CORRECTION 2026-09-15: the PORTAL CONTEXT below is wrong, and so was the 2026-08-09 re-cite that rested on it. The /docs/ how-to tier was NOT deleted — it MOVED under the /v1.1-restaurants/ prefix and is indexed at https://developers.deliverect.com/v1.1-restaurants/llms.txt. The /page/ tier is the one that died: /page/product-configuration.md now 404s (393,670 b, byte-comparable to a fabricated /page/ control at 393,680 b, against a known-good /page/ control at 200/34,324 b). priceLevels now has its own live page, .../v1.1-restaurants/docs/how-to-configure-price-levels.md (200, 3,703 b, updatedAt 2026-08-17), which carries the quoted sentence and the TA 350 / DL 400 / 1PO 300 example verbatim against named levels Takeaway / Delivery / First Party, plus the channel-link mapping steps and a hierarchy rule (overloads beat price levels on the same item). Value and grade unchanged; url re-pointed. STALE PORTAL CONTEXT: developers.deliverect.com deleted its /docs/ how-to tier in a restructure. The surviving pages still LINK to the deleted articles, the site nav links to five slugs that 404, and llms.txt publishes 64 custom-page URLs without their /page/ route prefix so that every one of them 404s as published. The content on /page/ is alive; the vendor index is malformed. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-price-levels.md · retrieved 2026-09-15 adversarially verified

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

menu-pricing-dual-pricing

The POS Product Configuration doc enumerates the platform's complete pricing axes: a base 'price', optional 'priceLevels' keyed to ordering channel and fulfilment type (delivery/pickup/eat-in), and scope-keyed 'overloads'. Tender type (cash vs card) is not a pricing axis anywhere in the model. Zero matches for 'surcharge', 'cash discount' or 'dual pricing' across the 144-page developer index; help-centre 'surcharge' hits are meal-deal price bumps and delivery-cost pass-through to the POS, not tender-based pricing. Deliverect also ships no card-present POS or first-party receipt surface (payments-emv-nfc: no), and Direct/kiosk checkout is Deliverect Pay (Adyen) card/wallet — there is no cash tender on its own channels to discount against. RE-BOUND 2026-09-15: /page/product-configuration.md now 404s (393,670 b, byte-comparable to a fabricated /page/ control at 393,680 b; a known-good /page/ control returns 200 at 34,324 b). It moved, not deleted, but in pieces under the /v1.1-restaurants/ prefix. NOTE THE SCOPE CHANGE: the pricing axes are no longer enumerated on one page — base price and tax are on .../docs/product-configurations.md, priceLevels on .../docs/how-to-configure-price-levels.md (cited here; 200, 3,703 b, updatedAt 2026-08-17) and scope-keyed overloads on .../docs/overloads.md. The cited page states the priceLevels axis verbatim ('different pricing for specific ordering channels and menu fulfilment type') and the hierarchy rule against overloads; tender type appears on none of the three. Value and grade unchanged. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-price-levels.md · retrieved 2026-09-15

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

menu-pricing-versioning-effective-dates

Menus do carry a draft/published split with a diff: 'You can compare a menu to the existing published version or a different menu', with a 'Compare to online menu' action, an option to 'view the current online menu or the draft (unpublished) version', new/unavailable item highlighting and a 'Show changes only' filter. Preview before publish is documented separately - 'We recommend previewing a menu before publishing it to your channels' - filtered by 'locations, channels, languages, and dates', with an Inspect mode that reveals a field's original value. Named shortfalls: staging is not effective-dated (Schedules is a recurring weekly grid of menus per day published to stores, not a go-live date attached to a version), and there is no rollback to a prior published version - the only revert is 'Reset menu products', which returns overrides to defaults and states 'It is not possible to undo this action.' https://help.deliverect.com/en/articles/9204130-compare-menus · retrieved 2026-08-09

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

menu-pricing-franchise-hierarchy

THE QUARANTINE IS LIFTED, NOT RENEWED, AND THIS IS THE MOST CONSEQUENTIAL CORRECTION OF THE PASS. The 2026-08-09 quarantine recorded status dead-404 with "NO REPLACEMENT WAS LOCATED", and its search was bounded to "/docs/ and root .md routes, the /v1.1/ version prefix, all 64 live /page/ documents, the 7 live /reference/ pages, and the 983-article English help centre." That bound was WRONG in one specific way: the version prefix is /v1.1-restaurants/, not /v1.1/, and the /docs/ how-to tier had MOVED there rather than being deleted. Probing the right prefix finds the successor immediately. Per the evidence rules, quarantine is for evidence we may no longer re-open; this evidence is open, so 'dead_url' returns to 'url', 'status', 'measured', 'quarantined' and 'do_not_refetch' are dropped, and the grade is restored from the demoted C to its 'grade_before_quarantine' of B. THE SENTENCE THE CELL RESTED ON IS ALIVE, VERBATIM, and the prior note's claim that it "returns zero hits corpus-wide, as does the phrase 'main location' itself" is refuted: 'main location' now reads 10 hits, all on https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-product-locations.md (200), which says "Use a main location to sync one shared product inventory across multiple locations, such as a brand or chain" and then, word for word, "Deliverect does not push products from other locations when those locations use products from the main location. Orders reference either the products from the main location or products specific to the ordering location." The configuration steps are there too - "During Deliverect onboarding, Deliverect and the customer determine whether the customer requires this setting. The chosen location will show a MAIN tag in their Deliverect account", then "Activate the Use main location toggle for each location that uses products from the main location", with the escape hatch "Some locations may not reference products from the main location. For those locations, sync products from the location's POS and include them in menus." THE VERDICT IS UNCHANGED AND THE SHORTFALL IS SHARPER. The claim asks for "a central corporate menu template pushed to locations with FIELD-LEVEL GOVERNANCE controlling which attributes a location may override." Deliverect ships a whole-catalogue reference toggle, not field-level governance: the choice is binary per location (use the main location's products, or don't), it is set during vendor-run onboarding rather than self-serve, and the only per-scope variation mechanism anywhere in the model - 'channelOverrides' and item 'overloads' - is keyed to CHANNEL and fulfilment type, not to a location's permission to override a corporate attribute. No locked-field, approval or attribute-allowlist concept exists in the 377-document corpus or in the ~150-permission census. Value unchanged; grade restored from C to B; url restored from dead_url. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-product-locations.md · retrieved 2026-09-15

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

menu-pricing-allergen-nutrition

Allergens are a first-class enum on the product: 34 values (CELERY 100 through SOURCES_OF_GLUTEN 134) plus exclusions NO_ALLERGENS/GLUTEN_FREE/SUGAR_FREE/LAC_FREE, carried in productTags and pushed to channels in the menu payload; help.deliverect.com publishes the same list for CSV import. Nutrition is a per-product nutritionalInfo block (netQuantity, servingSize, fat, saturatedFat, trans/mono/poly fat, carbohydrates, sugar, addedSugar, fiber, starch, polyols, protein, cholesterol, sodium, salt, minerals, vitaminC) alongside supplementalInfo (additives, ingredients, legalName, FBO) and calories/caloriesRangeHigh. Shortfall: every one of those values is entered or imported on the product record -- Deliverect documents no recipe or bill-of-materials engine, so nothing derives nutrition from components. Docs also warn channels may not display the info unless 'prepackaged' is true. https://developers.deliverect.com/page/custom-tags-and-allergens.md · retrieved 2026-08-09

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

menu-pricing-recipe-linkage

Verified the prior finding. Searched recipe, bill of materials, ingredient group, food cost, theoretical, inventory. isIngredientGroup is order-flow semantics: it marks defaults so payloads carry only NO/ADD modifier deltas; no cost, yield or depletion field appears. Deliverect's Inventory pages carry stock quantities, not component recipes; 'food cost' occurs only in the Campaign Manager ROI input and in blog/customer prose. Absence bounded to the four llms.txt manifests plus the Intercom and vendor sitemaps. SOURCE QUOTE: "To simplify the order flow for products with default ingredients e.g. Pizzas with modifier groups of standard toppings, a new attribute is now available to set an" https://developers.deliverect.com/changelog/ingredient-groups-modifier-actions · retrieved 2026-09-06 adversarially verified

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

menu-pricing-3p-menu-push

CITATION RE-POINTED. The cited https://developers.deliverect.com/page/menu-push-protection-against-missing-products-at-location.md is genuinely dead (HTTP 404; the body is the ~393KB ReadMe soft-404 shell, which opens '<!DOCTYPE html><html lang="en" style="" data-color-mode="system" class=" useReactApp "' - the discriminators are the STATUS and that markup, never the byte length, which varies with the requested path). NO REPLACEMENT WAS LOCATED FOR THE PHRASE "missing-product protection": 'protection' returns 0 and 'missing products' returns 0 across all 377 live developer documents and all 984 English help articles, so that clause of the old note is WITHDRAWN AS A QUOTATION and must not be restated from memory. The rest of the note is re-sourced and stands. Menu push itself: "Publish new or existing menus to your stores. ... Step 2. Select the stores and then the Publish button. You can search for stores or select the Filter button to find specific locations, location groups, channels, menus, or schedules. ... Step 3. Confirm by selecting the Publish button. You can check the status by going to the Operation reports page" (https://help.deliverect.com/en/articles/7978992-publish-a-menu, gated on the "Publish menus" and "View menus" permissions). Per-item sync error surfacing survives on the Operation reports enumeration, where the "Menu import" type provides "Any warnings (e.g. products that couldn't be automatically linked)" and "Product sync" provides "Any products inserted, updated, or deleted" (https://help.deliverect.com/en/articles/7979010-view-operation-reports). PLU handling is documented at grade A on the Insert Products endpoint (https://developers.deliverect.com/v1.1-restaurants/reference/insert-update-products-and-categories.md; 'PLU' reads 756 across the corpus). Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://help.deliverect.com/en/articles/7978992-publish-a-menu · retrieved 2026-09-15

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

menu-pricing-dynamic-pricing

Deliverect Plus (paid add-on) offers price increases at peak hours and weekends with before/after revenue comparison. Floor/ceiling guardrails not documented. https://www.deliverect.com/en-us/deliverect-plus · retrieved 2026-08-01

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

payments-processor-choice

Deliverect Pay is explicitly powered by Adyen. That is a single named processor with no documented alternative and no BYO path for Direct/Kiosk/QR checkout. 'Unknown' overstated the merchant's freedom here. https://www.deliverect.com/en-us/online-ordering · retrieved 2026-08-01 adversarially verified

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

payments-published-rates

Pricing page publishes no card-processing rate of any kind - no flat rate, no interchange-plus markup, no per-transaction figure. Its only cost statement is 'Deliverect offers flexible pricing based on your business's specific needs' with a 'Get a personalized quote' / 'Book a 1-on-1 with our team to discuss pricing' call to action. Raw-HTML extraction of the page returns zero currency amounts. Same result on the en-us and en-ca locale variants. https://www.deliverect.com/en/pricing · retrieved 2026-08-08

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

payments-dual-pricing

Pricing axes documented: base price, priceLevels by channel/fulfillment, and scope-keyed overloads. Tender type (cash vs card) is not a pricing axis. RE-BOUND 2026-09-15: /page/product-configuration.md now 404s (393,670 b, byte-comparable to a fabricated /page/ control at 393,680 b; a known-good /page/ control returns 200 at 34,324 b). It moved rather than being deleted, but in pieces under the /v1.1-restaurants/ prefix, so the three axes are now on three pages: product-configurations.md (base price, tax), how-to-configure-price-levels.md (cited here; 200, 3,703 b, updatedAt 2026-08-17) and overloads.md. Tender type appears on none of them. Value and grade unchanged. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-price-levels.md · retrieved 2026-09-15

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

payments-surcharge-guardrails

CLAIM: a surcharging engine that automatically excludes debit and prepaid cards via BIN or product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. ABSENT: all three conjuncts. Deliverect's published pricing axes are base price and tax (v1.1-restaurants/docs/product-configurations.md), priceLevels keyed to ordering channel and fulfilment type ('"priceLevels": { "TA": 350, "DL": 400, "1PO": 300 }', how-to-configure-price-levels.md, 200 at 3,695 bytes), and scope-keyed overloads; tender type is an axis on none of them. The Role Permissions article, which declares of itself 'In this article, you can find every permission you can activate for a user role' (18,560 bytes, ~150 permissions in 26 groups), contains no surcharge, dual-pricing or fee-toggle permission, so there is no per-location enable/disable to find. 'surcharging' reads 0 in all three corpora and 'interchange' reads 0. WHAT ARGUES THE OTHER WAY, DISCLOSED: the Pay API does expose the inputs a compliant engine needs - v3.0-ordering-experience/reference/pay-api-get-customer-tokens.md returns a vaulted card as '{"brand":"visa","last4":"1111","expirationMonth":3,"expirationYear":2030,"bin":"41111111","funding":"credit"}', a BIN plus a credit/debit funding discriminator, vaulted at basis_theory - but 'bin' and 'funding' occur on that one schema page only, nothing consumes them, and no rule, cap, exclusion list or disclosure string exists. VERIFIER'S CORRECTION TO THE PRIOR NOTE: this cell is NOT settled by a closed enumeration of the money model, and it should not be argued as one. The Payment API glossary's 'charges' member is a GENERIC container - charges.id, charges.product, charges.percentage, charges.amount - i.e. an open fee array that already carries a percentage, which is exactly the shape a surcharge line would take; what is absent is any documented rule, tender test or toggle that would populate it with a card fee, not a schema slot that forbids one. PUBLISHER-SCOPE RULING: Deliverect IS the right publisher and the 'no' is bounded to it. A surcharging engine with a per-location toggle is a merchant-facing configuration of the checkout Deliverect itself operates (Direct, Kiosk, Deliverect Pay), and Deliverect publishes both its complete permission model and its complete pricing model; had it one, that is where it would be. What is explicitly NOT ruled on, and what a reader must not take from this cell, is Adyen, Stripe, Mollie, Paymob or Airwallex: Deliverect Pay brokers those acquirers, an acquirer-side surcharging product may well exist, and that is a claim about the acquirer's product, not this one. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://developers.deliverect.com/page/glossary-payment-api.md · retrieved 2026-09-15 adversarially verified

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

payments-emv-nfc

Sustained on affirmative evidence, not just inference: the Kiosk page states compatibility with external payment devices, i.e. Deliverect explicitly does not provide the EMV/NFC hardware itself. https://www.deliverect.com/en-us/deliverect-kiosk · retrieved 2026-08-01 adversarially verified

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

payments-softpos-tap-to-pay

CLAIM: accepts contactless payments directly on a phone (Tap to Pay on iPhone or Android tap-to-pay) with no separate card reader. ABSENT: any phone-as-terminal surface at all. Deliverect's only card-present product is the Kiosk, and its acceptance hardware is a dedicated CABLED terminal, which is the opposite of the claim: 'PAX Q25: Resolve Issues - USB terminal displays a "card silent" message ... Verify that all banking contracts associated with your Q25 terminal are correctly initialized with your payment provider' (help article 10419740, 4,914 bytes, 200), and 'Ensure that the POS USB cable is securely connected to the control station' plus 'Ensure that the USB cable connecting the terminal to the screen is securely plugged in on both ends' (10419589, PAX D200, 5,423 bytes). The vendor's EU Data Act appendix describes the same device from the data side, logging 'terminal event logs (e.g., touch screen input, payment terminal connection status)' for the 'Kiosk Terminal (e.g., FOX/Oslo/Rio models)'. Consistent with the record's settled payments-emv-nfc: no, which rests on the Kiosk page stating compatibility with EXTERNAL payment devices. CONTROLS: 'tap to pay', 'Tap to Pay on iPhone', 'SoftPOS', 'contactless', 'NFC', 'EMV', 'card reader', 'card machine', 'tap on phone', 'phone as terminal' and 'mobile payment' all read 0 in all three corpora, in both boundary and stem mode. WHAT ARGUES THE OTHER WAY, DISCLOSED BY THE VERIFIER AND MISSED BY THE PROPOSING PASS: the Pay API's request-payment reference ships a closed OpenAPI enum for the payment mode - 'mode.type' is one of 'offline', 'redirect', 'terminal', 'token' - and a 'pending - terminal' example response. So Deliverect Pay does have a card-terminal mode, undocumented in prose; it is the slot a SoftPOS would be plumbed into. Nothing anywhere says that terminal can be a phone, and the only terminals Deliverect documents are the two cabled PAX units, so the cell stays 'no' - but this enum is the cheapest way to falsify it and is named here for that reason. PUBLISHER-SCOPE RULING: Deliverect IS the right publisher. The claim is about what the vendor's own product accepts, and Deliverect documents its card-present hardware, its kiosk troubleshooting and its payment-mode enum; a phone acceptance surface it shipped would be in one of those. Explicitly not ruled on: whether Adyen can enable Tap to Pay for a merchant OUTSIDE Deliverect - that is Adyen's product. Also out of bound: the six non-English help centres were not dumped. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://help.deliverect.com/en/articles/10419740-pax-q25-resolve-issues · retrieved 2026-09-15 adversarially verified

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

payments-pay-at-table

No vendor handheld exists. Table payment is guest-phone QR instead of a server-carried EMV device. https://www.deliverect.com/en-us/order-and-pay · retrieved 2026-08-01

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

payments-qr-guest-pay

QR at-table lets the guest pay from their phone with Apple Pay, Google Pay or card. Whether payment auto-closes an existing POS check is not documented. https://www.deliverect.com/en-us/order-and-pay · retrieved 2026-08-01

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

payments-tip-adjust

Deliverect's own checkout collects a guest-entered tip: the Online Ordering settings screen exposes 'Enable restaurant tips: Activate this to allow customers to provide tips when ordering', and POS integration settings carry 'Send Tip: If activated, tips will be sent to the POS'. Tips are modelled downstream too - Analytics' Revenue Breakdown reports tips as a line, and Dispatch's My Couriers stats show 'earned tips' per courier. Named shortfall: only a pre-payment, guest-entered tip on a card-not-present order is documented. No pre-auth-then-tip-adjust flow, no batch or adjust window, and no manager screen for unadjusted tips appears anywhere in the 984-article English help centre; 'PAR Brink: Configure Tips' pushes the mechanism the other way - 'Tips need to be configured in PAR Brink POS in order for Deliverect to be able to send tips' - so adjustment sits on the POS. https://help.deliverect.com/en/articles/7979314-deliverect-online-ordering-edit-your-settings · retrieved 2026-08-09

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

Searched tip, tip pool, tip out, gratuity, payroll, hours worked, clock in, rota, timesheet. Tips exist only as pass-through integers (tip = intended for the restaurant, driverTip = intended for the courier, restaurantTip in the Pay API amount_split); Deliverect forwards the amount to the POS or the courier job and holds no employee, shift or allocation object. Zero hits for time clock or hours worked in dev and help. Absence bounded to the four llms.txt manifests and the Intercom sitemap. SOURCE QUOTE: "Our channel partners may charge a delivery cost or service charge and give customers the option to add a tip to their orders." https://developers.deliverect.com/v1.1-restaurants/docs/how-to-process-additional-charges · retrieved 2026-09-06 adversarially verified

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

payments-offline-store-and-forward

Deliverect's word 'offline' in payments means a gateway where payment happens outside the commerce integration (cash, pay at counter), not stored card capture: this page says a DPay integration accepts only paymentType 'online', redirects the user to the provider, and the payment stays pending until a webhook returns 'authorized'. Searched store-and-forward, offline limit, offline mode. No queued-capture path or offline transaction limit exists. Absence bounded to the four llms.txt manifests and the Intercom sitemap. SOURCE QUOTE: "Merchants can create online and offline payment gateways in Deliverect." https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-request-a-payment · retrieved 2026-09-06 adversarially verified

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

payments-offline-decline-liability

Publication-observable claim held to the published-rate-limits standard: zero pages in the 144-page developer index match 'offline', and no store-and-forward payment capability is documented on any surface (settled reliability-offline-order-entry: no — pure cloud, webhook/HTTP order delivery). No offline-decline liability statement and no post-reconnect failed-payment report exist to be published; help-centre search likewise surfaces no offline-payments documentation. https://developers.deliverect.com/llms.txt · retrieved 2026-08-04

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

payments-gift-cards

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-checkout-glossary.md returns 200 and still carries the enum the note quotes - 'gift_card' reads 6 hits on that page and 'third_party' 2, with the payment-type enumeration 'dpay' | 'gift_card' | 'third_party' and externalId documented as the transaction ID for gift_card. The live corpus adds a whole Gift Card API tier the old note could not see because it was looking at a dead index: https://developers.deliverect.com/v3.0-ordering-experience/docs/gift-card-api-overview.md, how-to-apply-a-gift-card-to-an-order.md, how-to-connect-a-gift-card-provider-to-deliverect-direct.md, and the reference endpoints giftcards_get_balance, giftcards_redeem, giftcards_reverse, giftcards_validategiftcard and giftcards_registerprofile. That tier is a PROVIDER-CONNECTION API - it registers an external provider profile and proxies balance/redeem/reverse to it - which CONFIRMS the named shortfall rather than removing it: no first-party issuance, no Deliverect-held balance, no cross-location card. A future pass should read that tier in full before disturbing the verdict. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-checkout-glossary.md · retrieved 2026-09-15

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

payments-house-accounts

Catering supports 'customer whitelisting for offline invoicing'. Credit limits, running balances and statement generation are not documented. https://www.deliverect.com/en-us/catering · retrieved 2026-08-01

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

payments-split-tender

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-checkout-glossary.md returns 200 and still carries the schema the note quotes: a 'payments' array of "one or more payment entries" whose amounts must sum to the basket total, each entry carrying a type from 'dpay' | 'gift_card' | 'third_party', an externalId, an amount and a collected flag. The v3.0 reference confirms it at the endpoint level (https://developers.deliverect.com/v3.0-ordering-experience/reference/update-basket-payments.md and .../commerce-checkout.md, where 'gift_card' reads 13 and 'dpay' 14). The named shortfall is unchanged: digital checkout only, no split by seat, item or even shares, and no POS-terminal split flow. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-checkout-glossary.md · retrieved 2026-09-15 adversarially verified

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

payments-refund-void-controls

Overturned on audit: refunds on Deliverect's own payment surfaces ARE role-gated. The help centre documents granular role permissions including 'Refund payments' ('To perform a refund, you are required to have the Refund payments permission' — Deliverect Pay: View and Refund Payments, article 7979060), plus 'View Refund Reasons', 'Manage Cancelled Orders' and report-export permissions. Named shortfall: covers Deliverect Pay/Direct refunds only — no manager-PIN approval flow, no documented immutable audit log identifying the approver, and POS-terminal voids, discounts and no-sales remain outside Deliverect's surface. https://help.deliverect.com/en/articles/7979053-role-permissions · retrieved 2026-08-05 adversarially verified

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

payments-chargeback-tooling

Reclaim disputes marketplace refund deductions (not card chargebacks) with a claimed 80-85% win rate — but it is a managed service billed on success, not a self-serve dispute dashboard. https://www.deliverect.com/en-us/reclaim-by-deliverect · retrieved 2026-08-01

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

payments-card-on-file

Direct offers accounts with saved payment methods, and a payment token flow is documented. Reuse of the same token in-store is not documented. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

payments-payout-timing

CLAIM: the vendor PUBLISHES its deposit schedule and offers a next-day or same-day/instant funding option. The operative verb is 'publishes', so this is a bounded publication question and the publication surface was censused, not sampled. ABSENT: any frequency, cut-off, T+n or accelerated-funding statement. Deliverect Pay's entire published funds documentation is five help-centre articles (7979060 View and Refund Payments, 7979062 Details Needed to Add a Payment Profile, 7979307 Configure a Payment Gateway, 11515027 View and Export Payouts, 12441416 Specify Which Roles Can Perform Refunds). The payouts article is 3,100 bytes and is quotable in substance in full: 'You can view and export payouts if you have an online payment gateway configured on your account. This page is not yet available to all accounts. ... Select the Filter button to only view payouts from a chosen date range, business, or account. ... Export payouts - Select the Export link for the payout. A CSV file will download to your device.' That is a payouts LEDGER with no schedule attached. The only timing sentence in the gateway article is about onboarding, not money ('Verification of your details can take a couple of days'), and the one financial add-on that could have carried a schedule disclaims itself as unfinished: Deliverect Financial Reconciliation ships under terms reading 'The version of DFR that you are using is a beta, pilot, limited release, developer preview, non-production solution' and 'DFR is provided for evaluation purposes only and not for production use'. CONTROLS: in the 377-document developer corpus, which contains the whole v3.0 Pay API and Payment Platform reference, 'payout' reads 0 in both boundary and stem mode, as do 'settlement', 'deposit schedule', 'instant funding', 'T+1', 'remittance' and 'disbursement'; on www, including /pricing, 'payout' reads 0. In the 984 help articles 'payout' reads 2 tokenised and 17 as a stem, and every one is either the Payouts article itself, the single Role Permissions row 'View payouts - Allows access to the payouts page', or the KYC line 'A bank statement or voided cheque for the payout account verification'. PUBLISHER-SCOPE RULING: Deliverect is the right publisher BY THE WORDING OF THE CLAIM - a claim that the vendor publishes a schedule can only be settled against that vendor's publications, and this is the strongest-bounded of the payments cells for that reason. Deliverect is also in the funds flow on the merits: it runs full KYC and holds 'IBAN (or bank code and account code): Bank account to be used for payments', so it could disclose a schedule and has not. Falsified by any Deliverect Pay contract, pricing or help page naming a payout frequency or cut-off. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://help.deliverect.com/en/articles/11515027-deliverect-pay-view-and-export-payouts · retrieved 2026-09-15 adversarially verified

A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator

payments-multi-entity-routing

'Deliverect Online Ordering: Configure Multiple Bank Accounts' walks the whole flow: Locations > More > Payment profiles > + Payment profile > Add Gateway, then 'To use a new bank account, leave the Account field as Create new', 'Enter the bank account settings. The required fields vary per country', then 'Select the Store dropdown and choose the store to use for this bank account or leave it as Create new to configure one', ending 'Repeat these steps to add additional bank accounts.' Deliverect Pay's gateway article says the same from the other side - 'For online payments, repeat these steps if your locations use different bank accounts', 'You can only upload one bank statement per location' - and adds a Link step mapping 'one or multiple gateway profiles' to selected stores, filterable by location and channel. Each profile is a separately verified legal entity (legal business name, company registration number, stakeholders, IBAN). Reporting stays unified: the Payouts page filters 'payouts from a chosen date range, business, or account' in one view and exports CSV. https://help.deliverect.com/en/articles/8000397-deliverect-online-ordering-configure-multiple-bank-accounts · retrieved 2026-08-09

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

payments-p2pe-pci4

Same measurement, from the merchant's side of the question. Deliverect publishes no P2PE listing and no PCI DSS 4.x Attestation of Compliance, and offers neither to merchants on request in any document - the security page's only offer is 'please reach out to our Security Team via email at security@deliverect.com' for 'more information regarding the cybersecurity controls that we have in place', which is a conversation, not an attestation. The card-present path runs on PAX D200/Q25 terminals with Adyen as Payment Processor, so a validated P2PE solution may well exist at Adyen; that would be a fact about Adyen, and Deliverect's own record is silent. `P2PE` and `point-to-point` return zero substring hits across the 984-article English help centre, the security page and the marketing site. https://www.deliverect.com/en-us/security · retrieved 2026-09-10

Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).

delivery-driver-roster

Courier App manages an in-house fleet with driver assignment and real-time arrival times. Driver clock-in/out and per-driver run history reporting are not documented. https://www.deliverect.com/en-us/dispatch · retrieved 2026-08-01

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

delivery-dispatch-board

Real-time delivery overview across owned and third-party fleets. Multi-order run batching is not documented ('Multiple Couriers for Split Orders' covers order splitting, not batching). https://www.deliverect.com/en-us/dispatch · retrieved 2026-08-01

Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator

delivery-route-map

Dispatch Introduction's order-stacking FAQ is explicit: drivers can be assigned multiple orders, 'you can assign orders to available drivers using the Live Map view', and under 'Optimized Routing' - 'As soon as the driver goes en route, we use the Google Maps API to automatically optimize the drop-off sequence. The route is calculated based on their transport type (bike, car, etc.) and ensures the quickest return to the restaurant for the next delivery' - with 'Drivers can override the suggested route at any time by simply selecting the next drop-off they prefer.' The map itself is documented in 'Dispatch: Using the Live View Page': a map view of orders and courier positions with per-job delivery address, expected delivery time and assigned courier, plus full-screen mode, gated by a 'View dispatch live map view' role permission. Scope caveat recorded rather than a downgrade: the map view requires the Courier App, i.e. the operator's own couriers. https://help.deliverect.com/en/articles/7979513-dispatch-introduction · retrieved 2026-08-09

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

delivery-driver-tracking

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/courier-status-update-model.md returns 200 and still carries 'coordinates' (4 hits on that page), 'courierId', "The name of the dispatch partner company" and the split-delivery flag. The 2026-08-09 correction that the Courier App is named in first-party technical documentation, not only marketing, stands, and the moved how-to tier adds https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-recieve-courier-status-updates.md, .../how-to-enable-courier-nearby-release.md and https://developers.deliverect.com/v1.1-restaurants/docs/courier-updates.md. The shortfall is unchanged: the coordinate feed is relayed from dispatch partners and the model does not demonstrate first-party GPS capture. The old note's withdrawn quotation ("Updated courier coordinates from the dispatch partner") should NOT be reinstated from memory - it was withdrawn correctly, only for the wrong stated reason. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/courier-status-update-model.md · retrieved 2026-09-15 adversarially verified

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

delivery-zones-polygon

Direct Suite locations expose 'Delivery areas' with an 'Add delivery areas' button offering a choice of 'Polygon area: Create a shape over a map to specify where orders can be delivered' or 'Radius area: Provide the maximum delivery radius from your location'. The polygon is directly manipulable - 'Manipulate the polygon by dragging the corners. Addresses inside the polygon are eligible for delivery' - and each area carries Area name, Min. basket value, Delivery fee and Delivery fee tax rate, so multiple named polygons with independent economics can be drawn per location. No drive-time isochrone option is offered, but the claim is satisfied by arbitrary map polygons. The older Deliverect Online Ordering channel settings screen (7979314) offers only 'By PostalCode and By Radius'; Direct Suite is the successor surface ('We are currently moving customers to Direct Suite'). https://help.deliverect.com/en/articles/8031423-direct-suite-manage-your-locations · retrieved 2026-08-09

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

delivery-zone-pricing

Each delivery area carries its own money settings in the current product. Direct Suite locations expose 'Add delivery areas' offering a 'Polygon area' or a 'Radius area', and both variants carry the same per-area fields: 'Area name', 'Min. basket value: Enter the minimum basket value of an order to qualify for delivery', 'Delivery fee: Provide the delivery fee to add to orders within this radius' and 'Delivery fee tax rate (%)'. Areas are added, edited and deleted individually, and the applicable area follows from the guest's address ('Addresses inside the polygon are eligible for delivery'). The legacy Deliverect Online Ordering settings screen shows the same shape - per-radius and per-postcode 'Delivery Fee', 'Min Order Amount' and 'Free Delivery From' (https://help.deliverect.com/en/articles/7979314-deliverect-online-ordering-edit-your-settings). Named shortfall: there is no per-zone quoted promise time in either product. The Direct Suite per-area field list contains no time field, and order timing is set once for the whole site - 'Timeslots Minute Skip', 'Enable Delivery Asap', 'Pre Order (Days)', 'Order Time Window Settings' - while preparation time is a per-location lever (Busy mode 'increase the preparation time of orders'), so a farther area cannot be quoted a longer promise. https://help.deliverect.com/en/articles/8031423-direct-suite-manage-your-locations · retrieved 2026-08-09

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

delivery-address-validation

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-checkout-glossary.md returns 200 and still documents the pre-commit validation call. The dispatch-availability half is now much better sourced than the note records, because the how-to tier it was declared dead is live: https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-validate-dispatch-availability.md, https://developers.deliverect.com/page/dispatch-sequence-diagram.md and https://developers.deliverect.com/page/glossary-dispatch-availability.md, with the endpoint at https://developers.deliverect.com/v3.0-ordering-experience/reference/dispatch_validate_job.md. The named shortfall is unchanged and should be re-tested against those pages by a later pass: geocoding validation and out-of-zone rejection at guest order entry remain undocumented. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-checkout-glossary.md · retrieved 2026-09-15

Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator

delivery-driver-comp

Dispatch > My Couriers carries a Stats section: 'Find out the total deliveries, distance, and earned tips of each courier. Use the filters at the top of the page to change the location and time frame.' Two of the three compensation inputs the claim names - distance driven per period and driver-retained tips - are therefore tracked per driver, first-party. Named shortfall: no per-delivery flat reimbursement or per-distance rate is configurable anywhere; the page's Settings are enumerated and are cash payments, partner fallback, manager-only job assignment, enforced location sharing, geofencing and breaks - none monetary. And there is no payroll export: the only export in the Dispatch product is the Live View delivery-jobs CSV, with no separation of reimbursement from wage lines and no payroll destination documented. https://help.deliverect.com/en/articles/9399812-dispatch-my-couriers · retrieved 2026-08-09

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

delivery-cash-reconcile

A driver cash bank is documented on both ends. Settings: 'Enable cash payments: Activate to track the amount of cash your couriers are holding. You can also set how much cash they can hold until they are required to cash out.' Operation: on Dispatch > Live View's map view 'you can also view the status of the couriers and manage their cash', and on the Couriers tab 'The current cash of your couriers is displayed if you have activated the Enable cash payments setting on the My Couriers page. Select the current cash amount of the courier to log cash returned.' Named shortfall: this is a running held-cash balance with a manual cash-returned entry and a ceiling, not a settle-up. Nothing reconciles cash collected against the orders assigned and the tips owed for a shift, and no per-driver over/short figure or end-of-shift report is documented in the 984-article English help centre. https://help.deliverect.com/en/articles/9398761-dispatch-using-the-live-view-page · retrieved 2026-08-09

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

delivery-daas-dispatch

Capability upheld — multi-DaaS brokering is documented and the eight named partners match exactly. But the '40+' figure does NOT appear on the cited Dispatch page; I could not find it there at all. Strike the number or downgrade it to claim-level pending a source. The eight named partners are what the page actually supports. https://www.deliverect.com/en-us/dispatch · retrieved 2026-08-01 adversarially verified

Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator

delivery-daas-fallback

My Couriers > Settings documents the toggle 'Assign orders to a delivery partner when none of my couriers are available': 'If nobody can deliver the order, a delivery partner is sent the job instead (requires at least one delivery partner to be configured for the location).' Native hybrid overflow, own fleet to DaaS. Shortfall: availability is the only documented trigger — no out-of-zone or wait-threshold overflow rule from the in-house fleet; Auto-selection's Maximum pickup time, Delivery ranges and Cheapest/Fastest tie-breaker rank third-party partners against each other, not own fleet vs DaaS. Requires the Deliverect for Couriers module. https://help.deliverect.com/en/articles/9399812-dispatch-my-couriers · retrieved 2026-08-02 adversarially verified

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

delivery-3p-direct-integration

THE QUARANTINE IS LIFTED, NOT RENEWED, AND THIS IS THE MOST CONSEQUENTIAL CORRECTION OF THE PASS. The 2026-08-09 quarantine recorded status dead-404 with "NO REPLACEMENT WAS LOCATED", and its search was bounded to "/docs/ and root .md routes, the /v1.1/ version prefix, all 64 live /page/ documents, the 7 live /reference/ pages, and the 983-article English help centre." That bound was WRONG in one specific way: the version prefix is /v1.1-restaurants/, not /v1.1/, and the /docs/ how-to tier had MOVED there rather than being deleted. Probing the right prefix finds the successor immediately. Per the evidence rules, quarantine is for evidence we may no longer re-open; this evidence is open, so 'dead_url' returns to 'url', 'status', 'measured', 'quarantined' and 'do_not_refetch' are dropped, and the grade is restored from the demoted C to its 'grade_before_quarantine' of B. A GRADE-A SUCCESSOR EXISTS AND THE 2026-08-09 SEARCH MISSED IT BECAUSE IT PROBED THE WRONG VERSION PREFIX. https://developers.deliverect.com/v1.1-restaurants/reference/channel-integrators.md (200) is the Store API's Channel Integrators endpoint - "Retrieve a list of all integrated channels in the Deliverect system to identify the ordering platform from which an order originated by it's unique 'channelId'" - and its sample response enumerates, as first-class integrator identities inside Deliverect's own API, 'DELIVEROO', 'UBER_EATS', 'DOORDASH', 'JUST_EAT', 'GRUBHUB', 'WOLT', 'MENULOG', 'HUNGER_STATION', 'PEDIDOSYA_DH' and 'MEITUAN'. That is the claim - Deliverect holds these connections itself rather than reselling another aggregator's - carried by an API reference page that ships its own OpenAPI definition, which the evidence rules grade A. The page states honestly that the sample is partial ("The sample response below includes only a limited set of channels. To retrieve the full and most up-to-date list, call this endpoint directly"), so the endpoint is the census mechanism and the sample is a floor, not a census; the breadth half of the claim is corroborated at grade C by the 626 distinct /integrations/<partner> slugs in www.deliverect.com's sitemap. ONE SENTENCE OF THE OLD NOTE IS DROPPED RATHER THAN RESTATED: "is a named DoorDash 2026 Preferred Integration Partner" was a marketing assertion carried over from the dead page and is not re-sourceable from the live corpus, so the verdict is re-based entirely on the API enumeration. Value unchanged; grade restored from the demoted C and raised to A on the new source; url restored from dead_url. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/reference/channel-integrators.md · retrieved 2026-09-15

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

delivery-3p-injection

Core product. Vendor-claimed 99.95% order injection rate into the POS with no tablet re-keying. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

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

delivery-menu-push

CITATION RE-POINTED AND FALSE PREMISE REMOVED. The cited /page/menu-glossary.md is 404, but it was RENAMED, not deleted: the root manifest lists it as "Channel Menus - Glossary" at https://developers.deliverect.com/page/channel-menu-model.md (200). The successor carries the same field set the note rests on - the menu structure with categories, products, modifiers, snooze state, deposits, 'nutritionalInfo' and 'priceLevels' for per-channel prices - and the publish event is still enumerated on the flow diagram as "POST menuUpdate webhook (menu published)" (https://developers.deliverect.com/page/commerce-api-flow-diagram.md, verified live this pass; 'menuUpdate', 'checkoutUpdate', 'paymentUpdate', 'busyMode', 'orderStatusUpdate' and 'courierStatusUpdate' each read 1, all on that page). The operator-side half is now also sourceable at grade B on https://help.deliverect.com/en/articles/7978992-publish-a-menu. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/channel-menu-model.md · retrieved 2026-09-15

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

delivery-86-sync

CITATION RE-POINTED. /page/lce-set-visible-status-per-menu.md is 404, and its successor is in the MOVED how-to tier: https://developers.deliverect.com/v1.1-restaurants/docs/how-to-apply-visible-status-per-channel.md (200), which carries the mechanism verbatim - "A product, modifier, modifier group or bundle can be set to '"visible": false' which by default would disable it on all channels. By applying 'channelOverrides' variations on this disabled status can apply per channel", with the worked payload '"channelOverrides": { "7": { "visible": false }, "12": { "visible": true } }'. The snooze/restore half is separately live at grade A on https://developers.deliverect.com/v1.1-restaurants/reference/snooze-by-plu.md and .../mark-products-out-of-stock-by-tag.md and .../get_channeldisabledproducts.md ('snooze' reads 32 across the corpus). Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-apply-visible-status-per-channel.md · retrieved 2026-09-15

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

delivery-store-pause

Verified verbatim: 'Sentinel detects downtime, send you email alerts, and reopens stores automatically or with one click', with stores integrated to Deliverect Restaurants reopening automatically. Burger King UK case data (97% to >99% uptime; ~4,000 auto-reopens/month) is on the page as a customer-attributed claim. https://www.deliverect.com/en-us/sentinel · retrieved 2026-08-01 adversarially verified

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

delivery-3p-reconciliation

Reclaim reconciles marketplace refund deductions and disputes them as a managed success-fee service; the dashboard compares revenue by channel. Full payout-to-POS-sales matching itemizing commission and marketing fees is not documented. https://www.deliverect.com/en-us/reclaim-by-deliverect · retrieved 2026-08-01

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

delivery-injection-error-visibility

Sentinel surfaces store downtime and out-of-stock leakage with email alerts and a live map; Deliverect AI's support agent monitors failed injections, mismatched PLUs and sync issues; a public per-component status page exists. https://www.deliverect.com/en-us/sentinel · retrieved 2026-08-01

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

delivery-tracking-page

Dispatch provides real-time delivery tracking and ETAs. A branded status page on the restaurant's own domain is not explicitly documented. https://www.deliverect.com/en-us/dispatch · retrieved 2026-08-01

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

delivery-promise-time

CITATION RE-POINTED AND FALSE PREMISE REMOVED. /page/stores-glossary.md is 404 but was RENAMED to "Store - Model", https://developers.deliverect.com/page/store-model.md (200), which carries both quoted fragments verbatim: 'status' is documented as "'open' - active; 'busy' - open with delay ('preparationTimeDelay' in minutes); 'paused' - temporarily closed within normal hours, not accepting orders; 'closed' - closed or outside opening hours", and 'preparationTimeDelay' as "Additional delay (in minutes) added to preparation time before an order is ready". The named shortfall is unchanged and still correct: this is an operator-set additive delay, not a promise time computed from kitchen load, driver availability or zone drive time. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/store-model.md · retrieved 2026-09-15

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

delivery-offline-behavior

Searched internet, connection, connectivity, outage, offline in Deliverect's vocabulary across Dispatch, Courier App and DMA pages. The Dispatch pages document courier cash tracking, cash-out limits and automated driver assignment, but never their behaviour during an outage; the only documented connectivity-loss behaviour is failure (this page) plus the six-attempt POS order failover retry. No offline continuation for cash orders, assignment or settlement is documented. Absence bounded to the four llms.txt manifests and the Intercom sitemap. SOURCE QUOTE: "Cancellations may occur if your point-of-sale (POS) system is not properly connected to the internet. If the POS is unreachable, orders fail and are subsequently cancelled." https://help.deliverect.com/en/articles/7979017-manage-cancelled-orders · retrieved 2026-09-06 adversarially verified

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

digital-first-party-web

Corroborated and strengthened: branded storefront with the operator's 'logo, colors, and menus', geolocation landing pages routing to the nearest location, configurable tip amounts, order tracking, Deliverect Pay checkout. The dossier's caveat that commission-free could not be confirmed is correct — no commission-free claim exists on either page. https://www.deliverect.com/en-us/online-ordering · retrieved 2026-08-01 adversarially verified

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

digital-menu-single-source

One menu hub drives first-party and third-party channels: 'Update all menus across all your channels at the same time'. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

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

digital-native-app

'Branded website & app' appears only as a navigation-menu label. The dedicated Online Ordering page describes a responsive web storefront working 'across mobile and desktop' and mentions no mobile app and no app store at all. A responsive web app being labelled 'app' in nav copy is the weakest possible basis for a 'yes' on native app. https://www.deliverect.com/en-us/online-ordering · retrieved 2026-08-01 adversarially verified

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

digital-account-saved-payment

Guest accounts are real and first-party: 'Customers can create their own login on your Online Ordering site. By doing so, they are able to store their personal information to save time for future orders', with the resulting records listed under Online Ordering > Customers. Direct Suite reinforces it - its loyalty program has a 'Sign up bonus ... to incentivize customers to create an account', and Direct Suite > Customers shows each guest's contact details, transactions, last purchase and order count. Named shortfall: the two other halves of the claim are undocumented. No article describes storing a tokenized card on a guest account - Deliverect Pay is documented only as gateway onboarding, payment listing and refunds - and no one-tap reorder of a previous order is described anywhere; 'reorder' in the 984-article English dump refers only to dragging menu items into a different order. https://help.deliverect.com/en/articles/7979317-deliverect-online-ordering-view-and-export-customers · retrieved 2026-08-09

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

digital-upsell-engine

Kiosk upselling plus Deliverect AI's Autonomous Menu Agent, which deploys upsells from sales performance and reports in Mission Control. Attach-rate reporting specifically is not evidenced. https://www.deliverect.com/en-us/deliverect-ai · retrieved 2026-08-01

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

digital-scheduled-pacing

Scheduled ordering plus per-menu cut-off times for catering and Buffer Orders. Per-daypart slot capacity limits that auto-close saturated slots are not documented. https://www.deliverect.com/en-us/catering · retrieved 2026-08-01

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

digital-fulfillment-modes

Delivery, pickup and table ordering are corroborated. Curbside is not mentioned on either the Direct page or the Online Ordering page. Drop curbside from the note. https://www.deliverect.com/en-us/online-ordering · retrieved 2026-08-01 adversarially verified

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

digital-qr-table

QR scan-to-order and scan-to-pay with Apple Pay/Google Pay/cards, tied to a table number. Attaching to an existing open POS check, splitting and tipping are not documented. https://www.deliverect.com/en-us/order-and-pay · retrieved 2026-08-01

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

digital-kiosk

First-party Kiosk on the shared menu hub with external EMV terminal support and optional printer. No accessibility compliance claim published. https://www.deliverect.com/en-us/deliverect-kiosk · retrieved 2026-08-01

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

US homepage, Catering section: 'Offer group ordering, set menus, and à la carte options with menu-specific cut-off times', alongside 'support for offline invoicing, deposits, and split payments.' Marketing claim only, and scoped to the enterprise Catering product. Named shortfalls: none of the claim's mechanics (shareable link, participants adding their own items, per-person or total spend caps) are documented anywhere — the Catering product page describes single-orderer 'specify party size' ordering, the Commerce basket API models exactly one customer (update surface: customer, items, discounts, fulfillment, tips), and standard Direct/Online Ordering shows no group-order concept in its help collection or settings article. https://www.deliverect.com/en-us · retrieved 2026-08-04

Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator

digital-catering-portal

Distinct branded catering portal with separate packages/a-la-carte menus, per-menu cut-off times, pre-injection order review, and offline invoicing via customer whitelisting. Quotes, deposits and proposals are not documented. https://www.deliverect.com/en-us/catering · retrieved 2026-08-01

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

digital-voice-ai-phone

The claim allows a named certified partner, and Deliverect has two. ConverseNow (announced 16 April 2026) integrates its Voice AI so that 'phone and drive-thru voice orders' flow into Deliverect alongside marketplace and first-party digital orders. SoundHound AI (announced 23 July 2026, NEW YORK dateline) has its voice agents 'access real-time menu and location data' from Deliverect and 'route them straight to kitchen fulfillment through Deliverect's certified POS integrations', across 'drive-thru, phone, kiosk, and in-car channels'. Named shortfall: nothing native - Deliverect's own AI catalogue (12981597) is three menu/ops agents with no telephony - and neither partner has an Integration Overview article in the 983-article English help centre, so there is no first-party documentation of setup, certification status or availability; both sources are vendor press releases with no stated rollout date. https://www.prnewswire.com/news-releases/conversenow-and-deliverect-announce-partnership-to-bring-voice-ai-ordering-into-unified-restaurant-order--menu-management-302743431.html · retrieved 2026-08-09

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

digital-drivethru-ai

Deliverect's SoundHound AI partnership (NEW YORK, 23 July 2026) covers 'drive-thru, phone, kiosk, and in-car channels' in more than 100 languages, with SoundHound's agents accessing 'real-time menu and location data' from Deliverect and routing orders 'straight to kitchen fulfillment through Deliverect's certified POS integrations' - which is the menu/modifier integration the claim asks for. The ConverseNow partnership (16 April 2026) likewise brings 'phone and drive-thru voice orders' into Deliverect. Named shortfall: the lane agent belongs to the partner, not to Deliverect; no escalation-to-human handoff is described in either announcement; and neither partnership has any help-centre or developer documentation, so configuration, certification and availability are unevidenced. Deliverect's own AI catalogue (12981597) contains no lane-side agent. https://www.prnewswire.com/news-releases/deliverect-and-soundhound-ai-partner-to-turn-voice-into-a-fully-automated-ordering-channel-for-restaurants-302833315.html · retrieved 2026-08-09

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

digital-sms-ordering

Direct markets ordering via WhatsApp, Facebook, Instagram and Google. Conversational text-to-order mechanics are not documented. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

digital-google-order

What the page actually says about Google is 'Add delivery and pickup options to your profile' — that is Google Business Profile enrichment, which is not the same as the Order with Google end-to-end transaction program. No 'Preferred by Business' provisioning, no order-injection-from-Google statement. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01 adversarially verified

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

digital-apple-business-connect

CLAIM: supports Apple Business Connect ordering placement - an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow. ABSENT, on a census rather than a sample: 626 distinct /integrations/<partner> slugs appear in www.deliverect.com's sitemap.xml (1,901 distinct slugs in total, verified by the verifier from the slug file, not inherited), and not one is Apple, Apple Maps, Apple Business Connect, Google, Google Maps, Yelp or TripAdvisor. The only place-card-adjacent entries in the entire directory are /integrations/facebook and /integrations/instagram. Deliverect's first-party ordering product points the same way: Direct Suite's Site Links configuration enumerates 'Social media links - Facebook, X (Twitter), Instagram, TikTok, YouTube, LinkedIn', 'Legal links', and 'Review links - Add links to your Google Business profile' (help article 8039953, 3,168 bytes). A Google Business REVIEW link is the closest thing Deliverect ships to a map-place-card integration, and it is an outbound link, not an order placement. CONTROLS: 'Apple Business Connect', 'Apple Maps', 'Business Connect', 'place card', 'Order with Google', 'Siri', 'Yelp' and 'TripAdvisor' all read 0 in all three corpora in both boundary and stem mode. PUBLISHER-SCOPE RULING, and it is the closest call of the nine: an Apple Business Connect place card is registered by the MERCHANT in Apple's own console and can be pointed at any ordering URL, including a Deliverect Direct one, without Deliverect's involvement - so this cell would be unanswerable if the claim asked whether an operator CAN do it. It does not; it asks whether the vendor supports the placement. Deliverect publishes one how-to per supported placement (Facebook Start Order, Facebook Shop Buy Now, Instagram Order Food, TikTok link, WhatsApp menu, website widget, QR codes, mobile-app deep link) plus a 626-entry partner directory, so it is the publisher who would document an Apple placement if it supported one. Ruled: bound to Deliverect, value no. GRADE: C, because the strongest instrument is a vendor directory written to sell rather than a technical enumeration; the claim is 'niche' weight and this is a 'no', so the grade floor that binds a differentiator 'yes' does not apply. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://www.deliverect.com/en-us/integrations · retrieved 2026-09-15 adversarially verified

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

digital-loyalty-attach

Direct and Catering both cite loyalty program integration, and the integrations hub has a Loyalty & CRM category — indicating partner loyalty rather than a native engine sharing in-store identity. https://www.deliverect.com/en-us/integrations · retrieved 2026-08-01

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

digital-subscriptions

No guest subscription or membership programme exists on any Deliverect-published surface. The decisive corpus is the guest ORDERING STOREFRONT itself, deliverectdirect.com (the VITE_WEBORDERING_DOMAIN named in social-frontend's shipped __ENV__): tenants resolve as <business>.deliverectdirect.com and serve one shared Nuxt build, and its complete 55-chunk asset set (2.17 MB, all chunks referenced by the served HTML, retrieved 2026-09-15) is tokenised recurring 0, plan 0, club 0, perk 0, allowance 0, budget 0, monthly 0, creditLimit 0. Its guest customer model enumerates loyalty as points only -- 'loyalty:{lifetimePoints, tier, nextTier, wallet:{cash:{balance,expiringAmounts}, points:{balance,expiringPoints}}}' with a LoyaltyProgression component computing 'tier.maxPoints - lifetimePoints' to the next tier -- so tiers are EARNED by spend, never sold. Deliverect's own Direct Suite loyalty article gives the whole configuration set and it is store credit: Details (Title, Description), Rules > Earning ('Set how much credit customers receive with each order (e.g., 10% of an order totaling EUR15 gives the customer EUR1.50 credit)'), Spending (Redeemable %, Maximum redeemable value), Sign up bonus, Scope -- no price, no term, no renewal, no fee waiver (https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program). The Role Permissions article, exhaustive of PERMISSIONS ('every permission you can activate for a user role', 29 groups), carries no membership or guest-subscription permission; its only subscription entries are Billing > 'Edit subscriptions... This includes changing your plan' -- the operator's own Deliverect SKU. CONTROLS/POISON: 'subscription' is unusable unqualified on every corpus here. In the 15.6 MB portal bundle the tokenised count is 191 (plus 173 'subscriptions', 63 'subscribe') and the sampled contexts are all the operator's plan -- selectASubscriptionPlan, cancelSubscription, coreSubscription vs addonSubscriptions, 'Your account has no subscription yet', 'Trial subscription', alongside recurringPayments/oneTimeSetupFees/'Billed now' in an invoices UI -- so its 'recurring' vocabulary bills the RESTAURANT, not the guest. In the guest storefront every 'subscription'/'subscribe'/'member' hit is Pusher websocket plumbing (pusher_internal:subscription_succeeded, member_added on presence channels); in order-tracker they are Framer Motion's SubscriptionManager; in the Direct merchant dashboard they are the GraphQL operation enum (QUERY|MUTATION|SUBSCRIPTION) and Apollo/Pinia observables, its 3 'club' hits are cc-diners-club.svg and its 5 'vip' hits are an unused vip.svg icon name. The storefront's single 'membership' hit is B2B, not a meal plan: 'business-profiles/{businessId}/membership' alongside getBusinessProfile/requestBusinessProfile with an invoiceEmail -- corporate accounts paying by invoice, which Deliverect does not even bill ('Deliverect does not create or send invoices to your customers. You'll need to handle invoicing yourself', https://help.deliverect.com/en/articles/16161317-direct-suite-configure-invoice-as-a-payment-method), and which carries no allowance, budget or spend limit anywhere. CAVEATS: loyalty TIERS do exist (contra a naive loyaltyTier grep of the portal) -- the loyalty platform integration publishes 'GET Loyalty Tiers' returning 'name, description, point requirements' (Gold/Silver/Bronze) -- but they are points-earned and are served by an external Loyalty Partner webhook receiver the merchant selects, so they are neither purchased nor Deliverect's own programme. Deliverect is middleware: a connected POS, a loyalty partner or a delivery marketplace may run its own paid membership (a marketplace delivery-fee pass), which is outside this record. Six non-English help locales were not dumped. https://frontend.deliverect.com/assets/index-P6NKz4NQ.js · retrieved 2026-09-15 adversarially verified

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

digital-promo-parity

Discounts are modelled centrally (discount types, discount provider type, BOGO in menu) and pushed per channel. Parity with an in-store POS discount engine is not guaranteed and channel eligibility controls are not documented. https://developers.deliverect.com/page/list-of-discount-types.md · retrieved 2026-08-01

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

digital-guest-data-ownership

Direct markets 'guest data ownership' and first-hand guest profiles, but no documented bulk self-serve export without fee or approval. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

digital-checkout-pci-sca

A Deliverect Pay payment-token flow and a Commerce API payment request/checkout flow are documented, implying hosted card capture. No PCI DSS 4.0 attestation, no script-integrity statement, no 3DS documentation found. https://developers.deliverect.com/page/deliverect-pay-payment-token-flow.md · retrieved 2026-08-01

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

digital-surcharge-transparency

CITATION RE-POINTED, ONTO A STRONGER SOURCE. /page/payment-types.md is 404; the successor in the root manifest is "Payment API - Glossary", https://developers.deliverect.com/page/glossary-payment-api.md (200), and it enumerates the fee model more completely than the dead page did: 'amount', 'amount_without_charges', a 'charges' array with 'charges.id' / 'charges.product' / 'charges.percentage' / 'charges.amount', and 'amount_split' broken out as 'basketValue', 'tax', 'deliveryFee', 'driverTip', 'restaurantTip', plus 'amount_after_refund'. The per-channel order-fee model the note describes is live alongside it - 'bagFee' (14 hits), 'smallOrderFee' (7), 'serviceCharge' (21) and bottle deposits (https://developers.deliverect.com/v1.1-restaurants/docs/how-to-handle-bag-fees.md, .../how-to-handle-deposits.md, .../how-to-process-additional-charges.md). The shortfall is unchanged and now rests on an enumeration rather than an absence: no card surcharge, no dual pricing and no jurisdictional disclosure field appears in the charge model. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/glossary-payment-api.md · retrieved 2026-09-15

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

guest-loyalty-unified-profile

Direct builds 'detail-rich guest profiles' across its own channels. Automatic merge with in-store POS transactions and documented dedup behaviour are absent. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

guest-loyalty-thirdparty-identity-attach

Marketplace orders are not anonymous tickets: the channel order model carries a customer object, and Deliverect Pay's payments list shows a 'Customer: The customer's name' column beside 'Channel: The delivery platform'. Named shortfall: there is no attach to a native profile. The guest database is documented as first-party only - 'You can view a list of customers who placed an order on a Direct Suite channel', with contact details, transactions, last purchase and order count - and the Online Ordering customer list is built from guests who 'create their own login on your Online Ordering site'. No article in the 984-article English help centre describes a DoorDash, Uber Eats or Grubhub order creating or matching one of those records, so marketplace identity stays on the order and never becomes a usable guest profile for loyalty or marketing. https://help.deliverect.com/en/articles/8045310-direct-suite-view-your-customers · retrieved 2026-08-09

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

guest-loyalty-accrual-models

The Direct Suite loyalty admin guide documents one earning model: 'Earning: a % of each order returned as credit'. Named shortfall: only percentage-of-order accrual is documented; per-item, per-quantity, tiered-by-spend, and operator-choice models are not documented. https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-04

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

guest-loyalty-tiers

The loyalty admin guide enumerates the entire program configuration: Details (title, description), Rules (Earning, Spending), Sign up bonus, and Scope (locations). No tier levels (bronze, silver, gold, etc.) or tier-based rules are documented. https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-04

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

guest-loyalty-offline-behavior

Loyalty in Deliverect is a live partner webhook used by Direct and Kiosk: the channel retrieves a customer's available programs from the loyalty platform at order time, and the documented flow runs get customer, get wallet, retrieve programs, validate, apply discount, redeem, with no offline or queue branch. Searched offline, internet, connectivity, queue and reconcile across every loyalty page. Nothing states what lookup, accrual or redemption do during an outage. Absence bounded to the four llms.txt manifests and the Intercom sitemap. SOURCE QUOTE: "webhook to ensure channels integrated with Loyalty are able to retrieve a list of loyalty programs available to a specific customer" https://developers.deliverect.com/v3.0-ordering-experience/docs/loyalty · retrieved 2026-09-06 adversarially verified

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

guest-loyalty-offer-stacking-rules

The Online Ordering discount form states 'The following options are available for discounts' and then lists the complete field set: Discount code, Applicable on, Deactivate, Expired; Type (Lump, Percentage or Product) with its value fields; Availability (Valid from, Valid until, Day of the week); Extra configuration (Min order amount, Max order amount, Discount usage type limited by budget or by orders, with remaining-budget and remaining-order counters). The Direct Suite coupon form is equally fully enumerated - Code, Description, Amount, Limits, Valid from, Valid to, and Scope of locations, fulfillment types and channels. Neither exposes an exclusive-versus-combinable flag, a priority or precedence value, or an order-of-application setting. The only precedence Deliverect publishes is fixed behaviour inside loyalty spending - 'Define maximum limits when redeeming credits. The lowest value is always applied at checkout' - which is not configuration. https://help.deliverect.com/en/articles/7979308-deliverect-online-ordering-create-and-manage-discounts · retrieved 2026-08-09

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

guest-loyalty-targeted-offers

Direct markets 'time-sensitive promotions' and 'bespoke, tailor-made offers'. No documented audience rule builder over recency/frequency/spend/items. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

guest-loyalty-rfm-segmentation

Deliverect computes the RFM inputs without the operator building a query: the Direct Suite Customers table lists each guest's contact details, transactions, last purchase date and order count, and opening a guest shows 'Total purchase amount', 'Average order value', 'Total orders' and the full order history. One lifecycle dimension is also automated end to end - an email campaign is triggered by 'Days after last order: Choose how long after a customer's previous order they will receive the email. The minimum is 7 days.' Named shortfall: recency is the only actionable dimension. There are no computed lifecycle segments (no new, regular, at-risk, lapsed or VIP labels), no segment builder, and no way to target a campaign on frequency or monetary value - those two remain display-only columns. https://help.deliverect.com/en/articles/8045310-direct-suite-view-your-customers · retrieved 2026-08-09

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

guest-loyalty-lifecycle-automation

'Marketing automation through personalized email campaigns' is claimed; named always-on birthday/win-back/first-visit triggers are not documented. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

guest-loyalty-native-email-sms

Native email campaigns are claimed for Direct. Native SMS sending is not mentioned. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

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

guest-loyalty-consent-management

Consent is captured per guest at signup and surfaced to the operator: 'Customers can choose if they are willing to receive marketing communication (offers, personalized benefits, and money-saving promotions). This is indicated in the Subscribed to marketing column', and that column travels with the self-serve customer CSV export. Named shortfall: it is a single boolean covering the one channel Deliverect sends on (email). No timestamp of consent and no source-of-consent field is recorded or displayed, there is no per-channel consent breakdown, and no article describes how a revocation received by any other means is honoured. The only adjacent control is a support-activated GDPR anonymisation setting rather than a consent ledger. https://help.deliverect.com/en/articles/7979317-deliverect-online-ordering-view-and-export-customers · retrieved 2026-08-09

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

guest-loyalty-10dlc-registration

Deliverect's outbound guest marketing is email and only email. The Direct Suite campaign builder's creation step is 'Select the Create campaign button and choose Email campaign', its configurable fields are campaign name, days after last order, reminder sending time and an optional attached discount code, its customisation is cover image, email subject, message headline, message content, offer headline and button text, and its test action is 'Enter an email address and select the Send button'. The operator-facing Alerts feature enumerates its delivery methods the same way - 'Notify me by: Email'. Across the 984-article English help centre, 'A2P', '10DLC', brand registration and campaign registration return zero hits, and the only SMS strings in the corpus are UI translations belonging to a third-party French loyalty integration rather than to Deliverect. With no SMS sending through the platform there is no A2P 10DLC registration for Deliverect to handle, and it documents none. https://help.deliverect.com/en/articles/10713992-deliverect-direct-create-and-manage-email-campaigns · retrieved 2026-08-09

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

guest-loyalty-campaign-attribution

Redemption of a specific offer is counted first-party: a discount can be capped by 'Total budget' or 'Total discount orders' and the form reports 'Remaining budget' and 'Remaining discount orders' as it is consumed, while Analytics' Revenue Breakdown reports total discounts alongside revenue, orders and average order value with CSV export. Order-level linkage is published too, but outward: Direct Suite's Google Tag Manager integration fires a 'place_order' event carrying id, revenue, tax, shipping, tips, discount, loyalty, serviceCharges, coupon, fulfillment, channel and products together, plus an 'initiate_checkout' event carrying coupon and total. Named shortfall: the attribution has to be assembled in the operator's own analytics stack. Deliverect publishes no in-product report tying a named campaign or offer's redemptions to the check totals they rode on, and no incremental-sales or lift measurement of any kind. https://help.deliverect.com/en/articles/7979308-deliverect-online-ordering-create-and-manage-discounts · retrieved 2026-08-09

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

guest-loyalty-data-export-portability

Guest list: 'To create a CSV file of your customers, select the Export customers button. Go to your Operation reports page to download the file.' The exported record is the one shown on the Customers page - the personal information the guest stored on their login, plus the 'Subscribed to marketing' flag - and access is gated only by the 'View Online Ordering customers' / 'Edit Online Ordering customers' role permissions, with no support step. Transaction history exports the same way and equally self-serve: 'Export orders' and 'Export analytics' are role permissions in their own right, the Analytics page states 'For each option, an export can be created to be used by an external application. Click on the Export button', and there is a dedicated 'Export Order Reports' article; every CSV lands on the same Operation reports page, whose 'Export' operation type simply 'Provides the download link'. Recorded caveat rather than a downgrade: the guest list and the order history are two exports, not one combined file. https://help.deliverect.com/en/articles/7979317-deliverect-online-ordering-view-and-export-customers · retrieved 2026-08-09

Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator

guest-loyalty-cdp-event-api

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-api-flow-diagram.md returns 200 and still enumerates the outbound contract - 'orderStatusUpdate', 'courierStatusUpdate', 'menuUpdate', 'busyMode', 'paymentUpdate' and 'checkoutUpdate' each read exactly 1 hit and all six are on that page. THE CAVEAT IN THE OLD NOTE MUST BE RE-QUOTED FROM THE LIVE FAQ, WHOSE WORDING CHANGED: it now reads "Deliverect does not have a TRADITIONAL Reporting API, but you can collect order data using the Reporting Endpoint feature - structured order payloads pushed after each fulfilment" (https://developers.deliverect.com/page/web-faq.md, the renamed successor to the 404ing /page/faq.md), and its link no longer dangles - it resolves to the live https://developers.deliverect.com/v1.1-restaurants/reference/order-events. The old note's statement that the FAQ "links to the now-deleted guide" is withdrawn. A queryable event API is still explicitly disclaimed by the vendor; transaction-level events are pushed. Value and grade unchanged. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-api-flow-diagram.md · retrieved 2026-09-15

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

guest-loyalty-review-capture-routing

Confirmed: 'AI-powered sentiment analysis' that 'transforms delivery reviews into actionable insights' across locations. Correctly scored partial — it is inbound analysis of marketplace reviews only, with no feedback solicitation and no score-based routing. https://www.deliverect.com/en-us/sentinel · retrieved 2026-08-01 adversarially verified

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

guest-loyalty-referral-program

The Direct Suite loyalty admin guide enumerates the entire program configuration: Details (title, description), Rules (Earning: a % of each order returned as credit; Spending: redeemable % and maximum redeemable value), Sign up bonus ('incentivize customers to create an account' with bonus credits), and Scope (locations). The sign-up bonus is the only acquisition incentive — no referral codes or links, no referred-first-order attribution, no two-sided reward. The Marketing collection's full surface is coupons, loyalty, visitor tracking and email campaigns, and help-centre plus 144-page dev-index searches for 'referral' return nothing. https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-04

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

guest-loyalty-wallet-pass

The loyalty program form is the entire configurable surface of Direct Suite loyalty and it is enumerated in full: Details (Title, Description); Rules > Earning ('Set how much credit customers receive with each order'); Spending ('Redeemable (%)' and 'Maximum redeemable value', with 'The lowest value is always applied at checkout'); Sign up bonus ('Bonus credits'); Scope (locations). The mechanic is store credit attached to a Direct Suite web account and redeemed at that channel's checkout, so there is no card, membership number or pass artifact in the model to push to a wallet - and no branded app download for the claim's alternative to substitute for, since Direct ordering runs in the browser. 'Apple Wallet', 'Google Wallet' and pass issuance return zero hits across the 984-article English help centre. https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-09

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

guest-loyalty-privacy-rights-tooling

Some admin tooling exists, but only for minimisation: at least ten POS integration settings pages carry an 'Anonymize customer data (GDPR)' toggle - 'Activate to hide order customer info and delivery address details ... Updates the customer's name to Anonymized when the order is finalized ... The customer information is available until the order receives the Finalized order status.' That is operator-configurable, in-app, per integration. Named shortfall: anything beyond it is a ticket. Account-level anonymisation is explicitly not self-serve - 'Your customers' data can be anonymized in Deliverect. To request this, please reach out to your account manager or our support team and ask them to activate the GDPR setting for your locations.' There is no in-app subject-access or deletion request queue, no per-guest delete or export action on the Customers page, and no documented propagation of a deletion to loyalty credit balances or email-campaign audiences. https://help.deliverect.com/en/articles/9595607-anonymize-customer-data · retrieved 2026-08-09

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

guest-loyalty-redemption-fraud-controls

Two enumerations close this. The loyalty program form is the whole configurable surface and contains only Earning (credit as a percentage of order value), Spending ('Redeemable (%)' and 'Maximum redeemable value'), a sign-up bonus and location scope - a per-order value cap, not a redemption velocity limit. And 'Role Permissions' opens 'In this article, you can find every permission you can activate for a user role' and then lists every permission across all 25 sections; loyalty appears exactly once, as 'Manage loyalty integrations', with no manual credit or point adjustment permission, no approval permission and no audit-log permission to gate. Consistently, nothing in the 984-article English help centre documents manual credit adjustment, manager approval of one, employee self-redemption flagging, or a loyalty audit log; 'velocity' returns zero hits. https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-09

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

guest-loyalty-ai-offer-recommendation

The page uses present-tense verbs but makes no general-availability statement, gives no launch date, names no customer using it, and publishes no pricing. Present-tense marketing copy is not evidence of a shipped feature, and this is a paid-add-on-adjacent AI surface — exactly the category where vendors pre-announce. Partial with an explicit availability-unverified flag. https://www.deliverect.com/en-us/deliverect-ai · retrieved 2026-08-01 adversarially verified

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

guest-loyalty-stored-value-gift

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-checkout-glossary.md returns 200 and still carries 'gift_card' as one of three documented payment types with its externalId documented as the external transaction ID. Kept deliberately identical to payments-gift-cards so one fact does not yield two answers. The live v3.0 Gift Card API tier (overview, apply-to-order, connect-a-provider, plus giftcards_get_balance / redeem / reverse / validategiftcard / registerprofile) is a provider-proxy surface and reinforces the shortfall: no first-party issuance, balance or cross-location card. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-checkout-glossary.md · retrieved 2026-09-15

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

labor-clock-in-at-pos

Deliverect sells no workforce product. Product nav covers ordering, marketplace, dispatch and revenue protection only; the Quest App is grocery order-picking, not labor. https://www.deliverect.com/en-us/quest-app · retrieved 2026-08-01

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

labor-photo-punch-verification

The EU DPA's Description of Data Processing is a closed Article 28(3) annex, not an illustrative list: it names the personal data Deliverect processes for a merchant as name, email, phone, address, order details and geo-location. A punch photo would be an image, and a facial template would be Article 9 special-category data a processor must declare; neither appears, and staff are not a listed data-subject category. clock, punch, photo and biometric are zero in dev and help. Absence bounded to the four llms.txt manifests and the Intercom and English www sitemaps. SOURCE QUOTE: "Types / Categories of Personal Data: Name, email address, phone number, address, order details, and geo-location." https://www.deliverect.com/en/dpaeu · retrieved 2026-09-06 adversarially verified

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

labor-geofenced-mobile-punch

Geofencing does exist at Deliverect, so the question is what it is for. The vendor's own Dispatch article gives its only purpose: checking that a courier is at the delivery address when marking an order Delivered. There is no timecard to geofence — clock in, clock out, timeclock, timesheet, timecard and punch return zero documents across help and dev, and the only www hit is one blog post. Absence bounded to the Intercom English sitemap and the four developer llms.txt manifests. SOURCE QUOTE: "Enable geofencing for more accurate results : Use the courier's location when marking a delivery as “Delivered” to check if they are within the area of the delivery address." https://help.deliverect.com/en/articles/9399812-dispatch-my-couriers · retrieved 2026-09-06 adversarially verified

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

labor-offline-time-punch

The vendor glossary is Deliverect's own term census: the only people it defines are Consumer, Courier, Customer and Merchant, with no employee, shift, punch or timecard term, so there is no punch to buffer offline. Searched punch, clock, timesheet and attendance across help and dev: zero article titles. Absence bounded to the Intercom English sitemap and the four developer llms.txt manifests. SOURCE QUOTE: "Consumer The person who places an order on a 3rd party application. Courier The person who delivers an order to the consumer." https://help.deliverect.com/en/articles/7978930-restaurants-glossary · retrieved 2026-09-06 adversarially verified

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

labor-granular-rbac

Deliverect documents a real per-permission model rather than fixed tiers: the Role Permissions article covers 'every permission that can be activated for a user role', roles can be created and edited on the Roles page beyond the Finance, Manager, Store staff and Technical support defaults, a user 'cannot activate permissions that you do not have yourself', and location scoping exists via Restrict Menu Edits Based on Location. Shortfall: the permissions govern the Deliverect portal — menus, products, orders, analytics and billing — and not the discrete POS-terminal actions this claim enumerates (void, comp, discount, refund, drawer open, price change), which Deliverect has no terminal to perform. Granular and per-location, over a different action surface. https://help.deliverect.com/en/articles/7979053-role-permissions · retrieved 2026-08-03

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

labor-manager-override-audit

Deliverect does keep a queryable action log with individual attribution. 'View Operation Reports' is gated by a 'View operation reports' permission and filterable after the fact by 'Date and time', 'Operation type', 'Location', 'Delivery channel' and 'Status', and its enumerated operation types name the actor: 'Close store - User who initiated the closure'; 'Busy mode - User who made the change, Channel, Preparation time, Busy Mode status'; 'Product sync - User who initiated the sync'; 'CSV product update - User who initiated the update'; 'Update holidays - User who initiated the update'; 'Health check - User who initiated the check'. The store-closure troubleshooting article confirms the intended use: 'Examining Deliverect's activity logs can help identify who initiated the closure'. Named shortfalls: there is no manager-override or approval workflow to attribute - Deliverect runs no terminal, and the nearest control is role-scoped rather than approval-based ('Deliverect Pay: Specify Which Roles Can Perform Refunds'); several enumerated operation types record no user at all, including Menu publish, Open store, Channel activation/deactivation and Update store opening hours; and neither immutability nor retention is stated anywhere. https://help.deliverect.com/en/articles/7979010-view-operation-reports · retrieved 2026-08-09

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

labor-native-scheduling

In Deliverect's vocabulary "schedule" means menu scheduling and "hours" means a location's opening hours. The account permission catalogue runs to 25 modules — Accounts, Alerts, Analytics, Operations, Settings, Miscellaneous, Discounts, Dispatch, Gift Cards, Integrations, Billing, KDS, Locations, Media, Menus, Online Ordering, Orders, Payment Refund Settings, Payments, Payouts, Products, Promotions, Reporting Endpoints, Stores, Tunnels, Users — and none is staff scheduling; the only time objects are opening hours and holidays. Rotas are a partner function (Kobas, Prefectos). Absence bounded to the Intercom English sitemap. SOURCE QUOTE: "Manage holidays Allows managing holidays for locations. Manage opening hours Allows managing opening hours for locations." https://help.deliverect.com/en/articles/12645177-default-roles · retrieved 2026-09-06 adversarially verified

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

labor-demand-labor-forecast

The Analytics article is a closed enumeration of the dashboard: revenue, orders, average order value, revenue breakdown, plus sections for menu items, locations and channels. No staffing level, labour hour or forecast appears, and Deliverect holds no hours data to forecast against. Searched forecast, staffing and labour in the vendor's wording. Absence bounded to the Intercom English sitemap. SOURCE QUOTE: "At the top of the page, a graph shows the evolution of revenue, orders, average order value, and revenue breakdown. Just below, you can find individual sections for menu items, locations, and channels." https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

labor-realtime-labor-percent

The revenue breakdown Deliverect displays is total revenue, delivery costs, discounts, tips, service charges and taxes; labour cost is not a line, and no manager view (Analytics, Insights, DMA dashboard, Manager by Deliverect) reports a labour percentage. "Labor cost" occurs in the corpus only as marketing copy about savings, never as a reported metric. Absence bounded to the Intercom and English www sitemaps. SOURCE QUOTE: "Revenue Breakdown See your total revenue, delivery costs, discounts, tips, service charges, and taxes." https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

labor-overtime-prevention

An overtime warning presupposes hours-worked data about an employee. The EU DPA annex closes the categories of data subject to end users, merchant clients and couriers; restaurant employees are not among them and no hours or wage category is processed. "Overtime" appears in no developer page and no help article title. Absence bounded to the publisher manifests, not evidence about the merchant's own POS. SOURCE QUOTE: "Categories of Data Subjects: Deliverect will process data from end users and clients of Customer and/or Franchisees, and/or from couriers of Customer and Franchisees that may be assigned to provide delivery services" https://www.deliverect.com/en/dpaeu · retrieved 2026-09-06 adversarially verified

Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator

labor-break-compliance-by-state

The only time rules a Deliverect account holds are a location's opening hours and holidays; the permission catalogue has no break, attestation or jurisdiction module. Searched break, rest, meal, attestation and premium pay in the vendor's wording across help and dev: no article or endpoint addresses staff breaks. Absence bounded to the Intercom English sitemap and the four developer llms.txt manifests. SOURCE QUOTE: "Manage holidays Allows managing holidays for locations. Manage opening hours Allows managing opening hours for locations." https://help.deliverect.com/en/articles/12645177-default-roles · retrieved 2026-09-06 adversarially verified

Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.

labor-fair-workweek-support

The Users module is Deliverect's whole people model: invite, edit, deactivate, remove and assign roles to account logins. With no published schedule object there is no advance-notice deadline or predictability pay to compute. Searched predictive scheduling, advance notice and predictability pay, plus the vendor's own "schedule" (which means menus). Absence bounded to the Intercom English sitemap. SOURCE QUOTE: "Deactivate users Allows deactivating users. Remove users Allows removing users. Edit users Allows modfiying users in your account. Invite users Allows inviting new users to your account." https://help.deliverect.com/en/articles/12645177-default-roles · retrieved 2026-09-06 adversarially verified

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

labor-minor-labor-rules

Minor-labour enforcement needs an employee age or date of birth. The DPA annex closes the personal data Deliverect processes to name, email, phone, address, order details and geo-location, with no age or employment record, and its data subjects are end users and couriers rather than staff. Searched minor, age, school day and prohibited hours in help and dev: nothing. Absence bounded to the vendor sitemap and publisher manifests. SOURCE QUOTE: "Types / Categories of Personal Data: Name, email address, phone number, address, order details, and geo-location." https://www.deliverect.com/en/dpaeu · retrieved 2026-09-06 adversarially verified

Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.

labor-tip-pooling-rules

Deliverect's tip model is two order-level integer fields, "tip" for the restaurant and "driverTip" for the driver, forwarded to the POS. There is no employee, shift, role or points dimension to allocate against, and no help article covers tip pooling or tip-outs. Absence bounded to the four developer llms.txt manifests and the Intercom English sitemap; the merchant's own POS may still pool tips. SOURCE QUOTE: "there are two possible parameters allowing a channel to distinguish between the intended recipient of tips" https://developers.deliverect.com/v3.0-ordering-experience/docs/payments · retrieved 2026-09-06 adversarially verified

Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.

labor-tip-distribution-audit-trail

Tips exist in Deliverect only as an order-level amount and a revenue-breakdown line, the two recipients named in the payments guide being the restaurant and the driver. No per-shift or per-employee record of tips received, contributed or distributed exists to export, because there is no employee record. Absence bounded to the Intercom English sitemap and the developer llms.txt manifests. SOURCE QUOTE: "Revenue Breakdown See your total revenue, delivery costs, discounts, tips, service charges, and taxes." https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

labor-qualified-tips-w2-reporting

The tip fields Deliverect carries are "tip" and "driverTip", passed through to the POS partner and toggleable off; there is no cash-versus-charged split, no tipped-occupation code and no payroll export. Searched W-2, Box 12, Box 14 and qualified tips across the whole corpus: zero. The subject of W-2 reporting is the merchant's payroll provider, not Deliverect. Bounded to the publisher manifests. SOURCE QUOTE: "Please be aware that not all POS partners will handle this addition to an order, in which case we have a toggle setting to not include these." https://developers.deliverect.com/v3.0-ordering-experience/docs/payments · retrieved 2026-09-06 adversarially verified

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

labor-native-payroll

Deliverect processes personal data for end users, merchant clients and couriers only, not employees, and its product list (Sentinel, DMA, Direct, Dispatch, Courier App, Kiosk, Table Ordering, Quest, Retail) contains no payroll product. "Payroll" occurs in the corpus only on partner integration pages such as Kobas and Prefectos and in blog copy. Absence bounded to the English www sitemap and the Intercom manifest. SOURCE QUOTE: "Categories of Data Subjects: Deliverect will process data from end users and clients of Customer and/or Franchisees, and/or from couriers of Customer and Franchisees that may be assigned to provide delivery services" https://www.deliverect.com/en/dpaeu · retrieved 2026-09-06 adversarially verified

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

labor-payroll-export-formats

Extracting the Category field from all 616 integration pages in the corpus gives thirteen distinct values: POS systems, 3rd-party marketplace, Online ordering, On-site ordering, 3rd-party dispatch, Loyalty & CRM, Kiosk, Retail, Payment and Gift Cards, AI voice ordering, AI integrations, Social media, and "KDS, inventory & reporting". None is payroll or workforce, and Gusto, ADP, Paychex and QuickBooks have no integration page. Rotas and payroll belong to partner systems such as Kobas. Bounded to the English slice of the vendor sitemap. SOURCE QUOTE: "Streamline workforce management: Manage all team-related processes from the very beginning of their employment with recruitment and tracking, through to HR management, rotas & payroll, holidays and more." https://www.deliverect.com/en/integrations/kobas · retrieved 2026-09-06 adversarially verified

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

labor-shift-swap-workflow

The Quest App is the staff-facing app in the corpus; its complete profile settings are Location, Language, Notification sound and Printing settings, with no availability, shift or swap, and its eleven help articles cover picking, scanning, cancelling and opening stores only. Couriers and Quest pickers "go online" to accept individual requests, which is request acceptance, not a manager-approved shift swap. Bounded to the Intercom English sitemap. SOURCE QUOTE: "You can change the following settings for your Quest profile: Location Language Notification sound Printing settings" https://help.deliverect.com/en/articles/10485010-quest-app-edit-your-profile · retrieved 2026-09-06 adversarially verified

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

labor-digital-onboarding-i9

Onboarding in Deliverect means account creation: the Store creates a Quest user from name, surname and email, and merchant users are invited into an account with a role. No W-4, I-9, E-Verify, tax form or right-to-work document appears anywhere in the corpus in any wording. Absence bounded to the English www sitemap, the Intercom English sitemap and the four developer llms.txt manifests. SOURCE QUOTE: "User profile information. Your name, surname, and email address; You initially share your personal data with the Store, which manages your account creation process." https://www.deliverect.com/en/quest-app-privacy-notice · retrieved 2026-09-06 adversarially verified

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

labor-server-performance-metrics

Deliverect's per-location metrics are total orders, total revenue, average order value and best selling product; no dimension is an employee. cashier, waiter and employee return zero across all 450 developer pages, and "server" appears there only in the compute sense (MCP server, production environment, HMAC header), never as a person, because orders arrive from channels. The one per-staff metric that exists is Quest App picking efficiency, retail picking speed rather than sales by server. Bounded to the Intercom sitemap and the four llms.txt manifests. SOURCE QUOTE: "After clicking on a location, you will be shown the following metrics: Total orders Total revenue Average order value Best selling product" https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

inventory-recipe-bom-costing

Searched Deliverect's own words: 'ingredient', 'recipe', 'sub-recipe', 'prep item', 'bill of materials', 'BOM', 'plate cost', 'costing'. The only 'ingredient' object the vendor publishes is a MODIFIER GROUP flag used to pass order-payload deltas, not a costed component list; 'sub-recipe' and 'bill of materials' return zero across dev and help. Absence bounded to the four developers.deliverect.com llms.txt manifests and the help.deliverect.com English sitemap. SOURCE QUOTE: "An attribute can be set on a modifier group to identify it as an **'Ingredient Group'**" https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-ingredient-groups-modifier-deltas · retrieved 2026-09-06 adversarially verified

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

inventory-unit-conversion-yields

The admin guide enumerates inventory management in full: import a CSV, 'Update status: Choose to activate or deactivate the items', 'Update stock status: Mark the item as in or out of stock', and Sync, which sends 'current stock status' to channels (companion article 10226230). There is no on-hand quantity beyond binary stock status, no purchase/recipe/count units, no conversion factors, and no yield or waste percentage; zero 'yield' or 'recipe' pages exist in the 144-page developer index. Deliverect's inventory concept is channel availability, not back-of-house stock accounting. https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-08-04

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

inventory-theoretical-vs-actual

Searched 'theoretical' (zero hits corpus-wide), 'variance' (only report-discrepancy and discount senses), 'usage', 'count'. Deliverect's Inventory page, in the vendor's own description, offers only activate/deactivate and in/out-of-stock status; no count period and no recipe, so no theoretical usage to compare. Absence bounded to the vendor's Intercom English sitemap and the four llms.txt manifests. SOURCE QUOTE: "Update status : Choose to activate or deactivate the items Update stock status : Mark the item as in or out of stock." https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-09-06 adversarially verified

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

inventory-realtime-depletion

Retail-side inventory endpoints (Post Inventory Update, Inventory JSONL flow) sync stock levels into channel availability. Deliverect consumes stock from the merchant's system; it does not compute ingredient depletion from modifier selections. https://developers.deliverect.com/page/post-inventory-update.md · retrieved 2026-08-01

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

inventory-86-auto-sync

CITATION RE-POINTED. /page/retail-orders-item-unavailable-actions.md is 404 and its successor is in the moved how-to tier, indexed in the retail manifest: https://developers.deliverect.com/v2.0-retail/docs/how-to-handle-item-availability-actions.md (200). It carries the model the note rests on, as a closed enumeration: 'itemUnavailableActions' with 'ITEM_AMENDMENT' ("Change the quantity of the item or remove it"), 'ITEM_REMOVE', 'ITEM_SUBSTITUTION' ("Allow the item to be replaced with any other item"), 'CANCEL_ORDER', 'ITEM_SUBSTITUTION_CUSTOMER' ("Replace the item by another preselected item by the customer") and 'ITEM_SUBSTITUTION_CATALOG', with a 'substituteCandidate' array. The named shortfall is unchanged: this is retail item availability, and ingredient-threshold-driven menu-item 86 for restaurants is documented nowhere in the 377-document corpus. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v2.0-retail/docs/how-to-handle-item-availability-actions.md · retrieved 2026-09-15

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

inventory-count-modes

Searched 'stock take', 'stocktake', 'cycle count', 'spot count', 'physical count', 'inventory count' — only one marketing blog. The vendor's own Inventory page describes exactly two operations, CSV import and manual status change; the retail Inventory Update feed overwrites stock per location rather than recording count sessions. Absence bounded to the help.deliverect.com English sitemap and the developers llms.txt manifests. SOURCE QUOTE: "You can manage your inventory by importing a CSV file or making manual changes." https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-09-06 adversarially verified

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

inventory-mobile-count-offline

The Quest App scans and flags out-of-stock items during grocery picking on Zebra scanners, but it is a picking app, not an inventory counting app, and no offline mode is documented. https://www.deliverect.com/en-us/quest-app · retrieved 2026-08-01

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

inventory-vendor-catalogs-edi

Searched 'purchase order' (two blog posts only), 'supplier', 'distributor', 'broadline', 'EDI', 'Sysco', 'US Foods', 'Performance Food Group' — no vendor or supplier object anywhere in dev or help. Deliverect's own statement of Retail scope is catalog sync, Quest picking and order injection into the merchant's POS/ERP. Absence bounded to the vendor sitemaps and llms.txt manifests, not to the product. SOURCE QUOTE: "Catalog management : Sync price and inventory in real-time." https://help.deliverect.com/en/articles/10199753-retail-get-started · retrieved 2026-09-06 adversarially verified

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

inventory-invoice-ocr

Searched 'invoice line', 'line-item detail', 'scan an invoice', 'OCR', 'supplier', 'goods received', 'delivery note'. 'invoice' in the corpus means only the merchant's Deliverect subscription invoice; supplier invoices are absent. Deliverect's inventory operations are status toggles and a CSV feed, with no ledger to post invoice lines into. Absence bounded to the help English sitemap plus the four developers llms.txt manifests. SOURCE QUOTE: "Update status : Choose to activate or deactivate the items Update stock status : Mark the item as in or out of stock." https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-09-06 adversarially verified

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

inventory-price-change-alerts

Searched 'price alert', 'price increase alert', 'contracted price' (all zero), plus 'supplier', 'purchase price', 'invoice'. Price in Deliverect is a SELLING price set per location, location group or channel on the inventory feed, not a purchase price with history. No purchasing side exists to alert on. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap. SOURCE QUOTE: "Two formats of importing inventory are available; by **Location** of by **Location Group** which allow item pricing and availability to be set." https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

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

inventory-par-auto-suggest

Searched 'par level' (one partner page, one blog), 'replenish', 'suggested order', 'minimum/maximum'. The nearest Deliverect feature is a Stock threshold, and the cited page names its subject: the levels come from the merchant's POS and the action is a snooze, not a suggested purchase quantity. No par-per-item-per-location store exists. Absence bounded to the help English sitemap. SOURCE QUOTE: "Stock threshold Set a threshold on when to automatically snooze an item based on POS stock levels." https://help.deliverect.com/en/articles/9756259-lightspeed-restaurant-o-series-settings · retrieved 2026-09-06 adversarially verified

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

inventory-waste-logging

'waste' and 'spoil' return ZERO across all 450 developers.deliverect.com pages, and in help appear twice only as marketing prose ('minimize order errors and food waste'). 'reason code' is zero corpus-wide. The vendor's own Inventory page offers no debit transaction of any kind. Absence bounded to the four llms.txt manifests and the Intercom English sitemap. SOURCE QUOTE: "Update status : Choose to activate or deactivate the items Update stock status : Mark the item as in or out of stock." https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-09-06 adversarially verified

Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.

inventory-transfers

Searched 'stock transfer', 'inter-store', 'between locations', 'in-transit' (only courier and delivery senses). Deliverect's location-level inventory model is a one-way feed setting price, ranging and stock per location; there is no two-sided movement document and no approval state. Subject note: the stock values originate from the merchant's POS/ERP. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap. SOURCE QUOTE: "Two formats of importing inventory are available; by **Location** of by **Location Group** which allow item pricing and availability to be set." https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.

inventory-commissary

Searched 'commissary', 'central kitchen' (two marketing pages only), 'hub', 'production planning', 'prep item'. Deliverect groups locations for pricing and ranging, not for production and issue at a computed transfer cost; no prep-item or recipe object exists to produce. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap; it bounds the documentation, not the product. SOURCE QUOTE: "Two formats of importing inventory are available; by **Location** of by **Location Group** which allow item pricing and availability to be set." https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.

inventory-lot-traceability

Searched 'lot number', 'batch', 'traceab', 'recall' — no hit in dev or help; 'traceability' appears only in a customer story about the merchant's own sourcing. The retail Inventory feed's grain is the PLU with a single integer stock quantity, so there is no lot dimension to capture at receiving. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap. SOURCE QUOTE: "Current stock quantity of an item" https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.

inventory-shelf-life-expiry

Searched 'expir', 'use-by', 'shelf life', 'best before'. Every developer-docs hit for 'expire' concerns OAuth tokens and signed URLs, not goods. The retail Item Upload and Inventory Update column sets carry no date field on stock, only quantity and IN_STOCK/OUT_OF_STOCK. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap. SOURCE QUOTE: "Current stock quantity of an item" https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

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

inventory-bar-partial-bottle

Searched 'scale', 'weight', 'weighted item', 'price unit', 'conversion rate', 'bottle'. Weight appears only as retail SELLING logic (Conversion Rate for items priced by weight) and bottle only as a deposit; the sole stock field is an integer quantity per PLU, admitting no fraction or measured weight. Absence bounded to the v2.0-retail llms.txt manifest and the help English sitemap. SOURCE QUOTE: "Current stock quantity of an item" https://developers.deliverect.com/v2.0-retail/reference/inventory-update · retrieved 2026-09-06 adversarially verified

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

inventory-cogs-gl-export

Searched 'COGS', 'cost of goods', 'gross margin', 'food cost', 'general ledger', 'GL account', 'accounts payable', 'QuickBooks', 'NetSuite', 'Sage', 'Xero' — none appear in help or developer docs in an accounting-export sense. Inventory in Deliverect carries no cost, so there is no COGS to post. Absence bounded to the Intercom English sitemap and the four llms.txt manifests. SOURCE QUOTE: "Update status : Choose to activate or deactivate the items Update stock status : Mark the item as in or out of stock." https://help.deliverect.com/en/articles/10682905-manage-your-inventory · retrieved 2026-09-06 adversarially verified

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

inventory-native-not-partner

Deliverect's own integration directory places inventory and recipe costing in a partner category ('KDS, inventory & reporting') filled by separately-licensed products — Apicbase, Gstock, Koust, Inpulse — each page stating the operator must subscribe to both. Marketing/integration page, so grade C. Corroborated by help.deliverect.com, where the native Inventory page offers only activate/deactivate and in/out-of-stock status. Bounded to the English slice of the vendor sitemap. SOURCE QUOTE: "This integration requires a subscription to Apicbase and Deliverect." https://www.deliverect.com/en/integrations/apicbase · retrieved 2026-09-06 adversarially verified

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

inventory-menu-margin-linkage

Deliverect AI's menu agent ranks items by sales performance, not contribution margin — there is no ingredient cost to join against. https://www.deliverect.com/en-us/deliverect-ai · retrieved 2026-08-01

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

reporting-realtime-dashboard

Analytics dashboard consolidating sales across locations and channels, plus a live store-status map in Sentinel. A dedicated off-premise mobile reporting app is not documented (the DMA is an operations app). https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

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

reporting-eod-closeout

Analytics (article 7978952) has a date filter and a 'Revenue Breakdown' showing 'your total revenue, delivery costs, discounts, tips, service charges, and taxes', with gross sales and AOV per location; orders export to CSV (7979015). Shortfall: no single daily close-out document, no tender-type breakdown and no expected cash deposit -- Deliverect never holds the drawer. Article 9104394 'Reporting Differences Between Your POS, Channel, and Deliverect' states 'Revenue displayed in Deliverect does not include the following: Delivery fees, Discounts, Tips' and tells operators to export one day and match order IDs against POS and channel reports, i.e. Deliverect is one of three divergent sources rather than the reconciler. https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-08-09

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

reporting-pmix-modifier-level

The Menu Items analytics page reports items sold with quantity ('Items sold as item') and revenue (base vs extended, upsell and variation revenue), with a type selector spanning products, meal deals AND modifiers, per-modifier related-item tables ('Products that contained the modifier'), and CSV export carrying SuccessfulQuantity/SuccessfulRevenue per item. Named shortfalls: filters are location, custom tag, channel and date only — no daypart filter and no revenue-center dimension (channel is the closest analogue); revenue is defined net of delivery fees, tips, service charges and discounts with taxes included (Analytics page article 7978952), with no per-item gross-vs-net split. https://help.deliverect.com/en/articles/7978954-view-menu-items-sold-on-your-channels · retrieved 2026-08-04

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

reporting-comps-voids-audit

Searched Deliverect's own audit vocabulary ('operation reports', 'order update', 'refund reasons', 'discount', 'price override') plus comp/void/reason-code. The Operations page is the vendor's only audit log; its enumerated operation types cover busy mode, menu publish, product sync, snooze, export and order updates, and the order-update entry records only an Order ID - no employee, approver, reason code or comp/void event. 'comps' and 'reason code' return zero vendor hits. Absence bounded to the Intercom sitemap, the four llms.txt files and the vendor www sitemap. SOURCE QUOTE: "Order update When an update has been made to an order. Information provided: Order ID" https://help.deliverect.com/en/articles/7979010-view-operation-reports · retrieved 2026-09-06 adversarially verified

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

reporting-cash-over-short

Deliverect's reporting dimensions are enumerated on its own Analytics page: location, custom tag, channel and date. There is no drawer, shift, employee, counted-cash or expected-cash dimension, and no shift-close surface exists in help or dev. The corpus's only cash-drawer instruction ("Disable Cash Drawer Opening") is written for PAR PixelPoint, so its subject is the merchant's own POS, where cash handling stays. Absence bounded to the Intercom sitemap, the four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "At the top of the page, you can filter the data displayed. The options are: On locations On custom tags On channels On date" https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

reporting-labor-productivity

Searched 'labor/labour cost', 'time clock', 'clock-in', 'sales per labor hour', 'staff', 'department'. The Analytics article enumerates the per-location metric set - orders, revenue, average order value, best selling product - with no labour hour, wage or department dimension; 'time clock' returns zero vendor hits and clocked hours live in the merchant's POS. Absence bounded to the Intercom sitemap, four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "After clicking on a location, you will be shown the following metrics: Total orders Total revenue Average order value Best selling product" https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

reporting-server-scorecards

Searched Deliverect's dimension vocabulary - 'location', 'custom tag', 'channel', 'brand', 'user' - and 'server', 'employee', 'attachment rate'. Analytics filters and breakdowns expose location, custom tag, channel and date only; there is no employee or server dimension anywhere in the enumerated dashboard, and 'per-server' and 'server scorecard' return zero. Absence bounded to the Intercom sitemap, the four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "At the top of the page, you can filter the data displayed. The options are: On locations On custom tags On channels On date" https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

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

reporting-channel-profitability

Revenue comparison by channel and location is a headline dashboard feature, and Reclaim quantifies refund deductions. Margin net of each marketplace's commission is not documented as a report. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator

reporting-multiloc-drilldown

'Comparing revenue across locations and channels' is claimed; drill-down from group total to individual transaction is not documented. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator

reporting-custom-report-builder

'Introduction to Your Dashboard' enumerates the reporting surface exhaustively -- 'The dashboard is split into multiple tabs. The articles listed below explain the functionality of each: Main page, Menu items, Orders, Custom tags, Reviews, Insights, Order issues'. Every tab is a canned view whose filters are fixed (locations, custom tags, channels, date). The nearest thing to authoring is the CSV export dialog, which lets you pick fields and group 'by day, week, or all' (7978954) or choose Fields/Format/Split items (7979015) -- but the selection is not saved and produces a file, not a saved report. No dimension/measure builder or query interface appears in the 984-article English help centre. https://help.deliverect.com/en/articles/7978951-introduction-to-your-dashboard · retrieved 2026-08-09

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

reporting-scheduled-delivery

No scheduled or recurring report delivery exists. The only surface combining email delivery with a recipient list is Notifications, whose create-notification screen enumerates its entire option set -- Notification type, Trigger requirement, Delivery method, Locations, Subscribers, Add external users -- and offers no cadence and attaches no report: 'Default: A notification is sent immediately when the event first occurs. Afterward, events are grouped every 10 minutes' / 'Custom: Send a notification if the alert topic occurs a specific number of times within a defined timeframe' (help 7979009, updated 2026-08). Order reporting is manual pull only: 'Select the Request export button', then 'Select the Get download link button and then the Download button' (help 7979015 'Export Order Reports'). The developer-side Reporting Endpoint is per-event push, not a schedule -- it 'route[s] all incoming order data to a specified endpoint', with a closed three-row Order Data Types table (New Order 'Full order containing all information available at the point of webhook delivery'; Status Update 'Each order preparation status change can trigger a webhook'; Courier Update), and the how-to page states the trigger per event ('This event triggers once for each order'). Deliverect's own developer FAQ is explicit that no report-oriented API exists: 'Deliverect does not have a traditional Reporting API, but you can collect order data using the Reporting Endpoint feature - structured order payloads pushed after each fulfilment' (live at https://developers.deliverect.com/page/web-faq.md, the slug published in llms.txt). The portal shell's inline single-spa route table carries no reporting or scheduling route and returns schedul 0. NEAREST MISS, named rather than suppressed: developer doc inventory-jsonl-webhook-flow.md does diagram a 'Daily Cron/Trigger' that compiles a per-location 'product_feed_[date].csv/jsonl' to Google Cloud Storage and POSTs a 24-hour signed URL to a partner webhook. That is a genuine daily cadence to a shared destination, but it is an internal Deliverect-to-partner product/inventory feed -- not a report, not operator-configurable, with no recipient list and no email -- so it does not satisfy the claim, though it means 'nothing in the product runs on a cadence' would be too strong. SCOPE: Deliverect is middleware; a connected POS or delivery marketplace may schedule its own reports, which is not Deliverect's. CONTROLS: over the 92-file v1.1-restaurants branch corpus, cadence/cron/daily/weekly/recurring/sftp all 0 (schedul 2, both 'pre-orders'/'failover' prose). POISON: 'schedul' is unusable unqualified -- store-model.md's 13 hits are all openingHours.scheduling order-ahead fields, order-status.md's 1 is the 'Scheduled' buffered-order status, and the 2 hits on each cited reporting page are ReadMe's own 'planSchedule'/'stripeScheduleId' billing metadata in the embedded page JSON, not product content. https://help.deliverect.com/en/articles/7979009-set-up-and-manage-notifications · retrieved 2026-09-15 adversarially verified

Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator

reporting-raw-warehouse-export

CITATION RE-POINTED AND THE QUOTATION UPDATED - THE VENDOR'S WORDING CHANGED AND THE OLD SENTENCE MUST NOT BE RESTATED. /page/faq.md is 404 but was RENAMED to https://developers.deliverect.com/page/web-faq.md (200, updatedAt 2026-08-21). The old note quoted "Deliverect does not have a Reporting API, however you will be able to collect order data using our Reporting Endpoint feature." The live text is softer and is what must be quoted now: "Does Deliverect have a Reporting API? - Deliverect does not have a traditional Reporting API, but you can collect order data using the Reporting Endpoint feature - structured order payloads pushed after each fulfilment." The word "traditional" was added and the link no longer dangles: it now resolves to https://developers.deliverect.com/v1.1-restaurants/reference/order-events, which is live, so the old note's remark that "its link to that feature's guide is itself a 404" is WITHDRAWN. The verdict is unchanged and still rests on a first-party denial rather than an absence: push of transaction-level order payloads to a customer endpoint, with no scheduled bulk drop to S3/SFTP/Snowflake/BigQuery documented anywhere ('archive' 0, 'payout' 0, no bulk-export destination named in 377 documents). The Reporting Endpoint how-to is live at https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-reporting-endpoints.md. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/web-faq.md · retrieved 2026-09-15

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

reporting-public-api

CITATION RE-POINTED. /docs/certification-process and /docs/certification-process.md are BOTH genuinely 404 - re-probed slowly on 2026-09-15 with >=3.5s spacing after the fast census left the .md form at 429, and both returned the ReadMe soft-404 shell (394,133 b and 394,169 b respectively; size is an order-of-magnitude sanity check only, never an equality test). But the CONTENT moved rather than being deleted: it is now on https://developers.deliverect.com/docs/become-an-integration-partner.md (200, 2,050 b, updatedAt 2026-08-12), which is listed in the root llms.txt and carries the gating the note rests on, verbatim: "Before you can begin an integration project, you need to be onboarded as a partner. 1. Complete the partner application form. 2. A member of our Partnership team will reach out to you directly. 3. Once you're signed up, you'll receive a Welcome email containing: Access to a staging account, API Credentials, A certification document"; "All initial development and testing will be carried out in our staging environment. You won't get production access until our certification process is complete"; "Certification is validated through a series of certification calls with the Deliverect team. On average, it takes two calls to complete certification." The same facts are restated on https://developers.deliverect.com/page/web-faq.md. The comprehensive-public-REST half of the note is if anything stronger than recorded: the four manifests index 407 .md URLs covering POS, KDS, Store, Commerce, Channel, Dispatch, Loyalty, Gift Card, Coupon, CRM, Pay and Payment Platform APIs, and 377/377 fetched at 200. Labour data remains absent. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/docs/become-an-integration-partner.md · retrieved 2026-09-15

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

reporting-webhooks

Order lifecycle, courier status and reporting webhooks, HMAC-signed, with a documented POS order webhook failover flow and IP/domain whitelisting. https://developers.deliverect.com/reference/hmac-authentication.md · retrieved 2026-08-01

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

reporting-api-not-upcharged

API access is self-serve and two raw-order-data routes carry no documented charge, but one documented route -- the real-time reporting webhook -- requires a separate subscription and a signed charging agreement, which is the shortfall. INCLUDED (1): the Deliverect portal exports transaction-level order data to CSV with no fee, subscription, tier or add-on named anywhere in the article -- 'In this article, learn how to export the data of your orders from your Deliverect account into a CSV file', via Orders > more > 'Export orders', with selectable Pickup time, Location, Channels, Order Status, Custom tags, Fields, Format and 'Split items into separate rows', then 'Request export' and 'Get download link' (https://help.deliverect.com/en/articles/7979015-export-order-reports; the 7979015-operation-reports slug 301s here). INCLUDED (2): the Store API publishes GET /my-orders, whose OpenAPI 3.1 example returns the full order document (_id, account, location, channelOrderId, channelOrderDisplayId, status, statusHistory with per-status timestamps and source, plus item price, serviceCharge, deliveryCost, bagFee, tip, driverTip), refinable by ?where= on account, location or _id and paginated (https://developers.deliverect.com/v1.1-restaurants/reference/orders, updatedAt 2026-08-27); it is secured by ordinary oauth2 client-credentials partner keys and carries no pricing callout of any kind. SHORTFALL: the push reporting webhook is gated twice -- 'Any account with a subscription to use the reporting webhook services can ad [sic] Reporting Endpoint URLs in the Deliverect portal to collect order and order status data from an account', under a 'Reporting Service Pricing' callout reading 'Please note that this service has an associated cost, before this can be implemented, an agreement to accept the specific charges for receiving order data needs signed' -- and provisioning is manual: 'Once an agreement is signed, you can provide a webhook URL to our API support team along with the details of the intended order data and accounts where these should be installed (contact via integrations-support@deliverect.com)'. That identical callout appears on three pages, not two: docs/reporting-endpoint-overview (updatedAt 2026-08-11), docs/how-to-add-reporting-endpoints (2026-08-17) and reference/order-events (2026-09-14). No figure, rate or per-location price is published -- only the charge's existence. CONTROLS/POISON: tokenised over reference/orders.md (44,666 bytes) subscription 0, agreement 0, pricing 0, 'reporting endpoint' 0, while its cost 4 / charge 2 / fee 2 / price 6 hits are ALL order-payload fields (deliveryCost, fixedCost, serviceCharge, bagFee, item price) and none is a commercial term. Over the 1.19 MB export-order-reports page, every fee/cost/charge/subscription/pricing/Plus hit lies in navigation chrome or another article's title ('Foodics: Default Delivery Fee', 'PAR Brink: Configure Your Delivery Cost Surcharge', 'Cancel a Subscription', 'Heartland: Create Pricing Rules', 'Deliverect Plus') and not one is in the article body -- a raw word count there would have manufactured a false gate. CAVEATS: the Store API orders route is a query surface, not a feed -- 'Please note that frequent polling of orders is not allowed. To receive orders in real time as a POS, use the Order Notification webhook' -- and the developer FAQ says 'No, polling is not supported. You must configure an Orders Webhook URL'. So the priced reporting webhook remains the only real-time push of raw order data, which is exactly why this is partial and not yes. Deliverect's own pricing is quote-only (deliverect.com/en-us/pricing) and the US Terms contain no API-access fee clause, so 'included in the standard subscription' cannot be affirmatively confirmed for any route; what is established is that two documented routes carry no charge and one carries one. Middleware scope: this is Deliverect's own data, not a connected POS's. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-reporting-endpoints · retrieved 2026-09-15 adversarially verified

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

reporting-tier-paywall

The Deliverect Plus article's 'What's included?' list is Sales comparisons ('Use in-depth stats to compare the performance of your channels and locations over set periods'), Menu optimization, Notifications and Refund reasons, reached by 'Try for free' then a paid subscription. The Sales Comparison article (7978950) states flatly 'This feature is included in Deliverect Plus.' Four of the seven documented alert topics -- Item snoozed, Store closed by channel, Store closed by user, Order delayed -- are also marked '(requires Deliverect Plus)', as is refund-reason analysis (7978960). So cross-location/period comparison and refund analytics sit behind an add-on SKU rather than the entry-level plan; base Analytics is limited to revenue/orders/AOV, item mix, per-location and per-channel lists. https://help.deliverect.com/en/articles/7978935-deliverect-plus · retrieved 2026-08-09

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

reporting-history-retention

CLAIM: documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. The operative verb is 'documents', so this is a publication question. ABSENT: any figure of 24 months or more, anywhere. Deliverect publishes exactly two window statements across all three corpora and both are shorter or emptier than the claim. First, and this is the on-subject one, a published 30-day cap on a transaction-level export: 'Dispatch: Using the Deliveries Page' (help article 12276265, 4,247 bytes) says the Deliveries page 'allows you to view and export delivery information for orders fulfilled using Deliverect Dispatch' and that the export icon exports 'up to 30 days of data. A CSV file will download to your device.' Second, the only retention policy the vendor publishes anywhere, in the EU Data Act pre-contractual transparency appendix for the Kiosk (effective 1 December 2025, carried verbatim on www.deliverect.com/en/kiosk-pre-contractual-transparency-information, on /en/kiosk-terms-conditions and inside /en-us/terms-of-service): 'Storage locations and retention - On-device: For 30 days limited, transient, encrypted operational logs may be stored temporarily on-device ... Deliverect/Tabesto servers: Product Data (as defined under the Act) is stored for 30 days; Related Services Data (as defined under the Act) is stored indefinitely or for any period of time later communicated by Deliverect/Tabesto. Retention: The retention period of the collected data depends on the type of data and the purpose of the use case. Data is anonymised and kept indefinitely.' The same appendix defines Related Services Data as transaction-level detail ('Specific order details (e.g., items selected, modifiers, transaction values, payment status ... cancellation, receipt request)'), so the only published window over order-level data is a unilateral, unbounded, revisable discretion - a refusal to commit, not a 24-month guarantee - and it is scoped to the Kiosk/Tabesto line rather than to Restaurants reporting. The reporting surfaces themselves say nothing: Analytics (7978952), Menu Items (7978954) and the order export (7979015) each expose an unqualified date filter with no stated earliest date and no truncation warning. CONTROLS: 'months of data', 'data retention' and any '<n> months/years' history phrase read 0 across all three corpora; the only bounded-window phrases in the entire help centre are 'up to 30 days' (the Dispatch export above), 'up to 18 days' and 'up to 15 days'. PUBLISHER-SCOPE RULING: Deliverect is the right publisher, by the claim's own verb - only Deliverect can document Deliverect's retention - and there is no third party to whom this could be re-bounded. The 'no' rests on the absence of any published window of 24 months or more, plus one published 30-day export cap and one published refusal to bound the period; it is NOT a finding that history is truncated at 30 days platform-wide. Falsified by any help, pricing or contract clause naming a months or years figure for order history. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://help.deliverect.com/en/articles/12276265-dispatch-using-the-deliveries-page · retrieved 2026-09-15 adversarially verified

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

reporting-anomaly-alerts

Email alerting on downtime plus a live map with real-time out-of-stock monitoring confirmed on the page. Note it remains a marketing page rather than product documentation, and Sentinel's pricing relationship to the base product is not stated anywhere — so this may be a paid add-on capability, which the dossier should flag alongside Plus/Reclaim. https://www.deliverect.com/en-us/sentinel · retrieved 2026-08-01 adversarially verified

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

reporting-nl-query

Deliverect ships a Model Context Protocol server (https://developers.deliverect.com/mcp) that lets an AI assistant query the tenant's own account: the docs describe 'Direct API access to Deliverect functionality', 'Documentation search capabilities' and 'Real-time data from your Deliverect account', with setup instructions for 'AI-powered code editors like Cursor and Windsurf, plus general-purpose tools like Claude Desktop' and authentication headers passed by the client. Named shortfall: there is no in-product ask-a-question surface - the Deliverect AI catalogue (12981597) is three menu and order-repair agents, and Analytics is seven fixed tabs (7978951) - so the operator must run a third-party MCP client with API credentials; the server returns API data and text, not a figure or chart; and Deliverect holds no labor data for the claim's second data domain. https://developers.deliverect.com/docs/mcp.md · retrieved 2026-08-09

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

reporting-guest-cohorts

'Direct Suite: View Your Customers' shows 'a list of customers who placed an order on a Direct Suite channel', with 'names ... contact details, transactions, last purchase data, and order count', and per customer 'Total purchase amount', 'Average order value', 'Total orders' plus the order history table. Identifiable guest records therefore exist with lifetime spend and frequency inputs. Shortfalls: no cohorting -- no new-vs-returning counts, no visit-frequency bands, no lifetime-spend brackets, and no analytics tab for guests (the dashboard's seven tabs are Main, Menu items, Orders, Custom tags, Reviews, Insights, Order issues, per 7978951); and coverage is limited to Direct Suite channels, since marketplace orders arrive without identifiable guests and customer data can be anonymised account-wide via the GDPR setting (9615604). https://help.deliverect.com/en/articles/8045310-direct-suite-view-your-customers · retrieved 2026-08-09

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

reporting-sales-forecast

The dashboard enumeration (Main page, Menu items, Orders, Custom tags, Reviews, Insights, Order issues) is entirely historical: 'On the main Analytics page, explore historical data about your locations' (7978952). Comparison, where it exists, is backwards-looking -- the Plus-gated Sales Comparison compares a chosen period 'to a period of' N prior weeks (7978950). The three AI agents (12981597) optimise menus and fix failed orders; none forecasts. A grep of all 983 dumped English articles returns zero hits for 'forecast' and only one for 'predict' (a marketing line about the Courier App). No forward projection at daypart or hourly granularity is exposed in the reporting UI, and Deliverect holds no scheduling or ordering workflow to consume one. https://help.deliverect.com/en/articles/7978951-introduction-to-your-dashboard · retrieved 2026-08-09

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

reporting-tip-tax-compliance

Searched 'tip', 'tip pool', 'declared tip', 'payroll', 'tax liability', 'jurisdiction'. Tips appear only as one aggregate component of the location/channel revenue breakdown; 'tip pool', 'tip-out' and 'declared tip' return zero vendor hits and payroll appears only in blog prose. No employee dimension exists to attribute tips to. Absence bounded to the Intercom sitemap, the four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "Revenue Breakdown See your total revenue, delivery costs, discounts, tips, service charges, and taxes." https://help.deliverect.com/en/articles/7978952-track-performance-using-the-analytics-page · retrieved 2026-09-06 adversarially verified

Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.

multi-location-org-hierarchy

THE QUARANTINE IS LIFTED, NOT RENEWED, AND THIS IS THE MOST CONSEQUENTIAL CORRECTION OF THE PASS. The 2026-08-09 quarantine recorded status dead-404 with "NO REPLACEMENT WAS LOCATED", and its search was bounded to "/docs/ and root .md routes, the /v1.1/ version prefix, all 64 live /page/ documents, the 7 live /reference/ pages, and the 983-article English help centre." That bound was WRONG in one specific way: the version prefix is /v1.1-restaurants/, not /v1.1/, and the /docs/ how-to tier had MOVED there rather than being deleted. Probing the right prefix finds the successor immediately. Per the evidence rules, quarantine is for evidence we may no longer re-open; this evidence is open, so 'dead_url' returns to 'url', 'status', 'measured', 'quarantined' and 'do_not_refetch' are dropped, and the grade is restored from the demoted C to its 'grade_before_quarantine' of B. The quoted sentence is live verbatim on https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-product-locations.md - "Deliverect does not push products from other locations when those locations use products from the main location" - and 'main location' reads 10 hits there, against the 0 the quarantine recorded. THE VERDICT IS UNCHANGED AND THE SHORTFALL IS NOW MEASURED RATHER THAN ASSERTED. The claim asks for "a named organizational hierarchy of at least three levels ... as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations." Deliverect does have named objects above the location - account, business, brand, location, store, and the 'brandId' field is first-class in the order payload and in the Store API (https://developers.deliverect.com/v1.1-restaurants/reference/get-accounts-brands-2.md; 'brandId' reads 21 across the corpus) - and the Payouts page filters "from a chosen date range, business, or account." But the grouping layer that reporting and permissions would scope to is a BETA TAG, not a hierarchy level: "Location groups allow you to perform actions simultaneously for multiple locations and see their combined stats. THIS FEATURE IS CURRENTLY IN BETA AND NOT AVAILABLE ON ALL ACCOUNTS. Reach out to your Deliverect account manager for more information", created by typing into a multi-valued "Location group tag(s)" field on a location (https://help.deliverect.com/en/articles/7978966-create-and-assign-location-groups). And permissions scope to individual locations, not to groups: the published permission census offers "Manage locations - Allows modifying the allowed locations of other users in your account" and "Manage location groups", with no group-scoped role (https://help.deliverect.com/en/articles/7979053-role-permissions). Value unchanged; grade restored from C to B; url restored from dead_url. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-product-locations.md · retrieved 2026-09-15

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

multi-location-central-menu-publish

THE QUARANTINE IS LIFTED, NOT RENEWED, AND THIS IS THE MOST CONSEQUENTIAL CORRECTION OF THE PASS. The 2026-08-09 quarantine recorded status dead-404 with "NO REPLACEMENT WAS LOCATED", and its search was bounded to "/docs/ and root .md routes, the /v1.1/ version prefix, all 64 live /page/ documents, the 7 live /reference/ pages, and the 983-article English help centre." That bound was WRONG in one specific way: the version prefix is /v1.1-restaurants/, not /v1.1/, and the /docs/ how-to tier had MOVED there rather than being deleted. Probing the right prefix finds the successor immediately. Per the evidence rules, quarantine is for evidence we may no longer re-open; this evidence is open, so 'dead_url' returns to 'url', 'status', 'measured', 'quarantined' and 'do_not_refetch' are dropped, and the grade is restored from the demoted C to its 'grade_before_quarantine' of B. THE OLD NOTE IS SUBSTANTIALLY WRONG ON ITS FACTS AND IS REWRITTEN, THOUGH THE VALUE SURVIVES - FLAGGING THIS LOUDLY BECAUSE A FUTURE PASS MAY REASONABLY RE-ARGUE IT. The old note asserted "There is no authored-once-then-published pipeline, no described publish event, and no field-level override or governance model." The first two clauses are CONTRADICTED by live first-party documentation and are withdrawn. There is a publish pipeline and it is documented step by step: "Publish new or existing menus to your stores. This process has to be completed every time you make a change to a menu. ... Step 1. Select the menu and choose Publish. Step 2. Select the stores and then the Publish button. You can search for stores or select the Filter button to find specific locations, location groups, channels, menus, or schedules. Step 3. Confirm by selecting the Publish button", with a Republish path for subsequent changes, gated on the "Publish menus" permission (https://help.deliverect.com/en/articles/7978992-publish-a-menu). The publish EVENT is described on both sides - "POST menuUpdate webhook (menu published)" on https://developers.deliverect.com/page/commerce-api-flow-diagram.md, and as its own operation-report type in the app. WHY PARTIAL NEVERTHELESS, on a positive enumeration rather than an absence: the claim requires "a publish/version history showing what was pushed, when, and BY WHOM". The Operation reports page enumerates, type by type, exactly what each report records, and it names the initiating user for six types - Bulk onboarding ("Deliverect employee who initiated the process"), Busy mode ("User who made the change"), Close store, CSV product update, Health check, Product sync and Product sync preview ("User who initiated ...") - while the Menu publish type provides only "Channel" and "Menu name", with the caveat "A menu push may stay in a queued status for up to 30 minutes" (https://help.deliverect.com/en/articles/7979010-view-operation-reports). So what and when are recorded and by whom is not, on the vendor's own itemised list. The "View menu publish payload" permission ("Allows viewing the menu payload that is sent to the channel") covers what was pushed; nothing covers attribution. Value unchanged; grade restored from C to B; url re-pointed from the dead /docs/use-master-location.md to the live publish article. The shared-catalogue mechanism the old note described is separately live at https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-product-locations.md. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://help.deliverect.com/en/articles/7978992-publish-a-menu · retrieved 2026-09-15 adversarially verified

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

multi-location-local-override-policy

'Edit Product Information for a Single Location' (7979040): 'Any edits you make on this page will only be made for that location', with a per-field Revert button, and an explicit central lock -- 'Some information can only be edited for all locations (product specifications, packaging). Change to All Locations ... to edit that information.' The customisation feature names the overridable set: 'The customizable fields include prices, taxes, visibility status, names, descriptions, categories, and images', scoped to Locations, Location groups, Channels, Custom tag or Order type (7978996). Shortfalls: the locked set is hard-coded by Deliverect (specifications and packaging only), so corporate cannot lock name, image or price while leaving others open; governance is instead coarse -- 'Menu edit restrictions' picks which locations may edit a menu at all and a per-user 'Restrict to locations' toggle enforces it (7979005). There is no per-field override policy object. https://help.deliverect.com/en/articles/7979040-edit-product-information-for-a-single-location · retrieved 2026-08-09

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

multi-location-price-zones

RE-CITED 2026-08-09 off the deleted /docs/price-level-configuration.md. Measured 2026-08-09 with a known-good control (/docs/staging-and-production-environment.md, 200/2445b) and a fabricated control (404 at the ~237KB ReadMe shell), on a prober that retries 429 rather than scoring it. Value unchanged and the shortfall is now sharper, because the surviving schema page states the axis explicitly: priceLevels support "different pricing for specific ordering channels and menu fulfilment type" -- channel and fulfilment type, NOT geography. The example levels are Takeaway, Delivery and First Party. So per-channel and per-order-type pricing is documented from one product record, while a per-location-group price tier and per-daypart variance are not. CORRECTION 2026-09-15: the PORTAL CONTEXT below is wrong. The /docs/ how-to tier was NOT deleted — it MOVED under the /v1.1-restaurants/ prefix and is indexed at https://developers.deliverect.com/v1.1-restaurants/llms.txt; the /page/ tier is the one that died, and /page/product-configuration.md now 404s (393,670 b, byte-comparable to a fabricated /page/ control at 393,680 b, against a known-good /page/ control at 200/34,324 b). The url is re-pointed to the live successor, .../v1.1-restaurants/docs/how-to-configure-price-levels.md (200, 3,703 b, updatedAt 2026-08-17), which restates the channel/fulfilment axis verbatim, names the levels Takeaway / Delivery / First Party, and confirms the shortfall: the only mapping surface it documents is per-channel-link, with the instruction to keep the same posId values across locations in an account. Still nothing geographic. Value and grade unchanged. STALE PORTAL CONTEXT: developers.deliverect.com deleted its /docs/ how-to tier in a restructure. The surviving pages still LINK to the deleted articles, the site nav links to five slugs that 404, and llms.txt publishes 64 custom-page URLs without their /page/ route prefix so that every one of them 404s as published. The content on /page/ is alive; the vendor index is malformed. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-price-levels.md · retrieved 2026-09-15

Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator

multi-location-scheduled-publish

Menus can be scheduled by time, day and location. Per-location timezone interpretation and post-activation rollback are not documented. https://www.deliverect.com/en-us/deliverect-kiosk · retrieved 2026-08-01

A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator

multi-location-new-store-template

Reusable pieces exist: menus can be duplicated ('create or duplicate an existing menu, and then assign a single location', 7979005); a new menu's catalogue source is chosen with 'Use products from ... choose which location to use to build your menu if you have synced products from multiple locations' (9129049); tablet settings are cloned by device profiles linked to a location (7979054); and location groups batch locations (7978966). Shortfalls: there is no clone-a-location action -- 'Add a Location' (7978962) is a request form, 'You may be asked to provide your information so that a Deliverect representative can contact you', and adding a brand states 'A representative from Deliverect will be in touch with you typically within three days' (7978963). Taxes, user roles, printers and tenders are configured per object with no template, and no expected time-to-open is published anywhere on help.deliverect.com or deliverect.com; the only activation figure documented is per-channel (e.g. Deliveroo 'can take 48 hours', 7979326). https://help.deliverect.com/en/articles/7978962-add-a-location · retrieved 2026-08-09

The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator

multi-location-corp-vs-franchisee-roles

CLAIM: the permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking and labor data. ABSENT from a self-declaring closed enumeration: the Role Permissions article opens 'In this article, you can find every permission you can activate for a user role' (18,560 bytes, 200) and lists roughly 150 permissions across 26 groups - Accounts, Alerts, Analytics, Applications, Operations, Settings, Miscellaneous, Discounts, Dispatch, Gift Cards, Integration Settings, Integrations, Billing, KDS, Locations, Media, Menus, Online Ordering, Orders, Payment Refund Settings, Payments, Payouts, Products, Promotions, Quest, Reporting Endpoints, Stores, Tunnels, Users. Not one names a franchisor, a franchisee, a corporate tenant or a royalty. The nearest two levers are flat and symmetric, and naming them is the honest part of this verdict: 'Access linked accounts - Allows accessing accounts linked to your accounts' and, under Users, 'Manage locations - Allows modifying the allowed locations of other users in your account'. That is account-to-account linking plus per-user location scoping, with no corporate/franchisee asymmetry, no cross-tenant config enforcement and no group-scoped role. THE VENDOR'S OWN CONTRACT PRESCRIBES THE WORKAROUND, which is the affirmative shape this verdict needs. The SLA does distinguish the two location types - 'Customer shall provide L1 Support for Corporate Locations and to Franchisee Locations (if applicable)' - and the mechanism it specifies is not a tenancy model but full admin on somebody else's tenant: 'Customer's personnel involved in the delivery of L1 Support are expected to: (a) be registered as users on the Customer's and/or Franchisee's Deliverect account, and; (b) be configured with administrator-level access rights to ensure the full scope of L1 Support can be performed' (www.deliverect.com/en/sla-v2, section 4.5). A single flat admin role across the franchisee's account is precisely what the claim's why_it_matters names as the legal and adoption blocker. The fourth conjunct is moot rather than met: Deliverect holds no employee, scheduling or labour data at all, so a franchisee cannot fail to own it. THE OPEN GAP, CARRIED FORWARD FROM THE PRIOR UNKNOWN AND NOT SILENTLY DROPPED: 'Log in to Deliverect' (7978937) states 'One email address cannot be linked to multiple accounts except in the case of Group or Partner accounts. Contact our support team if you require this', and a second article adds that this 'cannot be done by individual users'. A support-provisioned Group or Partner account structure therefore exists and is undocumented - 'group account' reads 0 across all three corpora - and enterprise.deliverect.com is likewise undescribed. This 'no' is a statement about the published permission model, which is the object the claim names; it is falsified by any Deliverect document describing a Group or Partner account that scopes a franchisor differently from a franchisee. CONTROLS: 'franchisor' reads 0 in all three corpora; 'franchisee' reads 0 in the developer corpus and 0 in 984 help articles, with all 7 www hits in one document, the SLA, as a contract party; 'tenant' reads 0 everywhere. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://help.deliverect.com/en/articles/7979053-role-permissions · retrieved 2026-09-15 adversarially verified

Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator

multi-location-royalty-calculation

Held to the highest bar. Zero pages in the 145-page index match 'royalty' or 'franchise'. No franchise-fee surface in any product page. Sustained. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01 adversarially verified

Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.

multi-location-royalty-collection

Searched the vendor's franchise vocabulary - 'Franchisee', 'Customer Affiliates', 'FSA', 'fees', 'invoice', 'direct debit' - plus 'royalty' and 'ACH'. Deliverect models franchisees only as authorised users under the Customer's agreement; every money flow in the Terms runs Deliverect-to-Customer for its own fees. 'royalty' occurs twice in the corpus, both irrelevant; 'ACH' zero. No franchisee-visible statement of charges. Absence bounded to the vendor sitemap legal set, the Intercom sitemap and the four llms.txt manifests. SOURCE QUOTE: "Services are exclusively for the use of Customer, and if approved in writing by Deliverect, for the use of customer affiliates or franchisees" https://www.deliverect.com/en/terms-of-service · retrieved 2026-09-06 adversarially verified

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

Analytics dashboard aggregates and compares revenue across locations and channels; Sentinel gives a portfolio-wide uptime map. Labor/void/comp aggregation is out of scope. https://www.deliverect.com/en-us/deliverect-restaurants · retrieved 2026-08-01

Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator

multi-location-normalized-item-rollup

'View Menu Items Sold on Your Channels' filters 'On locations', 'On custom tags', 'On channels', 'On date' -- 'It is possible to utilize all filters at once and with multiple locations' -- and returns one row per item with Items sold, Revenue base, Successful revenue extended, Revenue from upsells and variations; the Times Snoozed column is explicitly cross-location ('an item snoozed once on 5 locations would show 5'), confirming rows aggregate locations rather than splitting by them. Local renames and prices are customisations on the same product ('The customizable fields include prices, taxes, ... names', 7978996; 7979040), so a locally renamed or repriced item still reports under the one product. Shortfalls: no document states the rollup key is a shared corporate item ID, and product identity comes from the POS PLU -- where a chain has no master location the docs tell operators to export and import catalogues 'so that item PLUs don't have to be written manually on every location' (23512 / National Soft), meaning locations that carry different PLUs for the same dish are not documented to consolidate. https://help.deliverect.com/en/articles/7978954-view-menu-items-sold-on-your-channels · retrieved 2026-08-09

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

The prior rationale ('no gift-card product') is wrong: a Gift Card API exists. But it is a connector to the merchant's own gift-card provider, scoped by the vendor to retrieval, redemption and reversal of balances; the balance ledger, cross-location redeemability and any liability report belong to that provider, and Deliverect publishes no outstanding-liability or inter-store settlement report. Searched 'gift card', 'stored value', 'liability', 'settlement'. Bounded to the four llms.txt manifests, the Intercom sitemap and the English vendor sitemap. SOURCE QUOTE: "The Gift Card API allows you to connect your Gift Card solution to any digital channel integrated with Deliverect" https://developers.deliverect.com/v3.0-ordering-experience/docs/gift-card-api-overview · retrieved 2026-09-06 adversarially verified

A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.

multi-location-cross-location-loyalty

'Direct Suite: Activate and Manage a Loyalty Program' defines one programme with Earning ('10% of an order totaling EUR15 gives the customer EUR1.50 credit to use on future orders'), Spending caps (Redeemable %, Maximum redeemable value), a sign-up bonus, and a Scope section: 'Select the Add location button to choose which locations have access to this loyalty program.' One programme therefore spans many locations. Shortfalls: the article never states that a customer's credit balance and history are shared across those locations, only that the locations share the programme definition; and the whole feature is confined to Direct Suite, Deliverect's own ordering channel -- customer records are 'customers who placed an order on a Direct Suite channel' (8045310), so marketplace orders (Uber Eats, DoorDash, Deliveroo) and any in-store POS sales earn and redeem nothing. Third-party loyalty is a separate integration category ('Manage loyalty integrations' permission, 7979053). https://help.deliverect.com/en/articles/8041162-direct-suite-activate-and-manage-a-loyalty-program · retrieved 2026-08-09

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

multi-location-multi-brand

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/glossary-pos-orders.md returns 200 and still documents 'brandId' as "Appears where customer operates multiple brands from one location". The account-brands guide the old note called deleted is alive at https://developers.deliverect.com/v1.1-restaurants/docs/how-to-handle-account-brands.md, with the endpoint at https://developers.deliverect.com/v1.1-restaurants/reference/get-accounts-brands-2.md; 'brandId' reads 21 across the corpus, including the KDS and Store APIs, so brands are first-class throughout, not only in the order payload. The operator-side article is https://help.deliverect.com/en/articles/7978963-add-brands-to-your-account. Value and grade unchanged. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/glossary-pos-orders.md · retrieved 2026-09-15

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

CITATION RE-POINTED. /page/pos-payments-taxes-discount-other-charges.md is 404 and the tax content moved into the versioned how-to tier: https://developers.deliverect.com/v1.1-restaurants/docs/how-to-handle-taxes.md (200), with the calculation webhook at grade A on https://developers.deliverect.com/v1.1-restaurants/reference/pos-tax-calculation-webhook.md. The 2026-08-09 correction to this note - that multiple named taxes per order and a per-item tax class ARE documented - is re-confirmed on the live pages: 'taxClassId' reads 11 across the corpus (glossary-pos-orders, glossary-channel-orders, how-to-handle-taxes, the tax-calculation webhook and the v3.0 how-to-process-taxes guide) and 'deliveryTax' / 'takeawayTax' / 'eatInTax' read 133, so rates varying by fulfilment type in the published menu are live too. The shortfall is unchanged: no rate table keyed to a state, county or municipality, and no rule engine that picks a rate from a location's address. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-handle-taxes.md · retrieved 2026-09-15 adversarially verified

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

multi-location-multi-currency-locale

Published currency list and translation language codes with translatable menu elements; operates in 65+ countries. Consolidated conversion to a single reporting currency is not documented. https://developers.deliverect.com/page/list-of-currencies.md · retrieved 2026-08-01

Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator

multi-location-config-audit-log

'View Operation Reports' gives 'the complete list of filters ... Date and time, Operation type, Location, Delivery channel, Status' and then enumerates every operation type with the fields each records. Many carry actor attribution: Close store ('User who initiated the closure'), Busy mode ('User who made the change'), CSV product update and Pending CSV product update ('User who initiated the update'), Product sync and Product sync preview ('User who initiated the sync'), Update holidays ('User who initiated the update'), Health check, plus Billing, Bulk onboarding, Bulk user import, Channel activation/deactivation, Courier update, Export, Insert order, Menu API import, Menu import, Menu publish, Open store, Order update, Snooze report, Update store opening hours. Exporting it is a distinct permission ('Export operation reports', 7979053), so corporate can pull it. Shortfalls: the enumerated types contain no configuration-change record for prices, taxes, discounts, promotions or user permissions -- the audit stops at menu/product/store operations -- and no article asserts the log is immutable or states a retention period. The only other reference to change forensics is indirect: 'Examining Deliverect's activity logs can help identify who initiated the closure' (article on unexpected store closures). https://help.deliverect.com/en/articles/7979010-view-operation-reports · retrieved 2026-08-09

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

multi-location-enterprise-sso

'Log in to Deliverect' states: 'To verify your identity, you can use: An email address and password / A Google account', and the troubleshooting article adds 'Use the same login method that you used to sign up (email and password or Google)' and describes Google Workspace account-linking behaviour (7978940). So an operator whose IdP is Google Workspace does get federated sign-in. Shortfalls: no SAML or bring-your-own-OIDC configuration exists in the 983-article English help centre (zero hits for SAML, OIDC, SSO or 'single sign-on'), so any other IdP falls back to passwords; and there is no SCIM or automated deprovisioning -- users are removed by hand ('Deactivate users', 'Remove users', articles 7979094 and 9423492). The separate enterprise.deliverect.com portal is named in 7978937 but its authentication is undocumented, so an enterprise-only SSO path cannot be excluded. https://help.deliverect.com/en/articles/7978937-log-in-to-deliverect · retrieved 2026-08-09

Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator

multi-location-enterprise-api

Partner accounts hold one credential pair that accesses customer accounts across locations; order, menu and reporting APIs are location-scoped by parameter, not by separate per-location credentials. https://developers.deliverect.com/docs/staging-and-production-environment.md · retrieved 2026-08-01

Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.

multi-location-central-labor-policy

Searched Deliverect's grouping vocabulary - 'location group', 'brand', 'account', 'custom tag' - and 'overtime', 'break', 'predictive scheduling', 'time clock'. Location groups scope orders, dashboard stats, menu publishing and scheduling, opening hours and special hours; no labour rule is configurable per location or group, and Deliverect operates no terminal at which one could be enforced. Absence bounded to the Intercom sitemap, the four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "Location groups allow you to perform actions simultaneously for multiple locations and see their combined stats." https://help.deliverect.com/en/articles/7978966-create-and-assign-location-groups · retrieved 2026-09-06 adversarially verified

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

extensibility-public-api-docs

developers.deliverect.com is fully readable with no NDA, login or sales call — 145 pages indexed in llms.txt across six API surfaces, plus a public forum and changelog. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01

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

extensibility-api-access-cost

Partial: the ordinary API surfaces are exercised inside the standard account with no fee documented at any step, but one documented API surface is affirmatively charged for. MET, on positive evidence rather than silence: API credentials are an ordinary role permission in the normal portal, not a plan upgrade or a side contract -- the self-declared exhaustive Role Permissions article ('In this article, you can find every permission you can activate for a user role', 29 groups) carries an Applications group ('Create application: Allows creating new application keys', plus Edit, View, Revoke, Unrevoke) and an Accounts group ('Create account credentials' / 'View account credentials') (https://help.deliverect.com/en/articles/7979053-role-permissions, grade B, re-read 2026-09-15). On the partner path credentials are issued as part of onboarding at no charge: 'Once you're signed up, you'll receive a Welcome email containing: Access to a staging account, API Credentials, A certification document' and 'As soon as you pass certification, you'll receive your production credentials' (https://developers.deliverect.com/docs/become-an-integration-partner, updatedAt 2026-08-12; the whole page returns zero hits for fee, cost, price, pricing, charge and revenue share), and certified partners then manage their own keys at 'Settings > Partner Integration > Application ... re-generate the secret by clicking on Replace Secret' (https://developers.deliverect.com/docs/managing-your-integration, updatedAt 2026-08-18; also zero fee/cost/charge/revenue hits). That self-management is post-certification, and issuance itself is gated on a partner application form and certification calls rather than being self-serve at acquisition; for a merchant it presupposes an existing Deliverect account, which is what this claim's 'included in the base subscription' asks about. SHORTFALL: the order-data reporting webhook is not included and is billed separately -- 'Any account with a subscription to use the reporting webhook services can ad [sic] Reporting Endpoint URLs in the Deliverect portal', under a 'Reporting Service Pricing' callout reading 'Please note that this service has an associated cost, before this can be implemented, an agreement to accept the specific charges for receiving order data needs signed' (https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-reporting-endpoints, updatedAt 2026-08-17, re-fetched at 200 on 2026-09-15; the identical callout is on .../reporting-endpoint-overview, updatedAt 2026-08-11). Both sentences were checked against the RAW bytes, not a tag-stripped rendering: each is contiguous in the source and appears three times per page, so neither is a welded-cell artefact. SHARED EVIDENCE, DECLARED: that same callout is the entire basis of this vendor's reporting-api-not-upcharged 'no', where it properly belongs -- here it supplies only the shortfall half, and the met half rests on three independent surfaces that do not mention it. No amount is published: deliverect.com/en-us/pricing is quote-only and the General Terms contain no API-access fee clause, so this records a gate, not its size. POISON: 'subscription' is unusable as a bare token on this vendor -- the 15.6 MB portal bundle returns 1,263 hits and every sampled one is the operator's own Deliverect plan (upgradeSubscription, cancelSubscription, 'days left on your trial'); the word in the quote above carries that same operator-plan sense, i.e. a paid Deliverect SKU. Middleware scope: this is Deliverect's own API, not a connected POS's. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-reporting-endpoints · retrieved 2026-09-15 adversarially verified

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

extensibility-partner-revshare

This claim asks whether the terms are PUBLISHED, not whether a revenue share exists. The help centre's own partner article is 501 bytes and entirely non-commercial: 'Do you want to integrate your solution with Deliverect? If so, visit this page to sign up ... You should receive a response from our team within 14 business days', with benefits listed as 'Reliable and scalable tech', 'Access to our API support team', 'Easily expand to new regions/countries'. The partner landing pages (deliverect.com/en/partner, /en-us/become-a-partner) describe referral and reseller tracks in the same qualitative register -- referrers 'get rewarded', partners gain 'access to discounts' -- with no percentage, referral fee or per-location figure. developers.deliverect.com's certification-process doc states only 'You will receive the certification document when we provide the API keys'. Every commercial term is therefore behind a sign-up form and a sales conversation. https://help.deliverect.com/en/articles/8347495-become-a-partner · retrieved 2026-08-09

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

extensibility-free-sandbox

CITATION RE-POINTED, AND ONE SENTENCE OF THE OLD NOTE IS CORRECTED. /docs/certification-process is 404 (re-probed slowly; so is the .md form). The successor is https://developers.deliverect.com/docs/become-an-integration-partner.md (200, updatedAt 2026-08-12). THE OLD NOTE SAID the certification doc "does not even document a request path" - that is NO LONGER TRUE and is withdrawn: the live page documents the path explicitly ("Complete the partner application form. A member of our Partnership team will reach out to you directly"), and the FAQ repeats it ("Complete the partner application form on the Deliverect website. A member of our Partnerships team will reach out to guide you through the next steps", https://developers.deliverect.com/page/web-faq.md). The verdict is unchanged because the gate itself is unchanged and explicit: staging access and API credentials arrive only in a Welcome email after partner onboarding, and "You won't get production access until our certification process is complete." A sandbox exists and is free, but it is not self-serve - there is no sign-up-and-get-a-key route. The staging environment page is live at https://developers.deliverect.com/docs/staging-and-production-environment.md. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/docs/become-an-integration-partner.md · retrieved 2026-09-15 adversarially verified

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

extensibility-oauth-partner-apps

OAuth 2.0 machine-to-machine: client_id/client_secret exchanged at /oauth/token for a short-lived access token with an audience. Scoped, operator-granted, individually revocable permissions are not documented — this reads as partner-level credentials, not per-merchant consent grants. https://developers.deliverect.com/reference/access-token.md · retrieved 2026-08-01

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

extensibility-webhooks-push

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-api-flow-diagram.md returns 200 and still enumerates the push contract across order, courier, menu, payment, store-state and checkout events. THE OLD NOTE'S CLOSING CONCESSION IS NOW FALSE AND IS WITHDRAWN: it said "The registration mechanics themselves are no longer published on this host, so the yes now rests on the event contract rather than on the setup guide." Registration is fully published again, at grade A, in the moved tier - https://developers.deliverect.com/v1.1-restaurants/reference/pos_register.md (Register POS), https://developers.deliverect.com/v1.1-restaurants/reference/pos_webhooks.md (Webhooks), https://developers.deliverect.com/v1.1-restaurants/reference/kds_register_kds.md, https://developers.deliverect.com/v3.0-ordering-experience/reference/channel_register.md and https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-pos-registration-url.md - together with HMAC signing on every webhook page. The 'yes' now rests on both the event contract AND the setup mechanics. Value and grade unchanged; grade A is available if a later pass wants it. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-api-flow-diagram.md · retrieved 2026-09-15

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

extensibility-webhook-reliability

CITATION RE-POINTED AND THE SHORTFALL MATERIALLY NARROWED - READ THIS ONE, IT CHANGES WHAT THE CELL ASSERTS EVEN THOUGH IT DOES NOT CHANGE THE VALUE. /page/pos-order-webhook-failover-flow.md is 404 but was RENAMED to https://developers.deliverect.com/page/pos-orders-failover-flow.md (200), and the substantive guide moved into the versioned tier at https://developers.deliverect.com/v1.1-restaurants/docs/how-pos-order-failover-works.md (200, updatedAt 2026-08-16). THE OLD NOTE'S SHORTFALL SENTENCE - "Specific retry/backoff numbers and a replayable missed-delivery event log were not found" - IS HALF REFUTED BY THE LIVE SUCCESSOR AND IS WITHDRAWN AS TO RETRY. The live page publishes the numbers in full: "we have a retry policy that uses an exponential backoff with a maximum of 5 retries. This means we may try the connection request up to six times (one initial attempt plus five retries) before marking the order as failed"; "Retries are attempted only under the following failure conditions; Inability to establish a network connection within 3 seconds. Receipt of an HTTP '502', '503', or '504' server-error response"; "Retries will use an exponential backoff factor of 2 ... beginning with a 10 second delay", tabulated as 10s / 20s / 40s / 80s / 160s with "The total potential backoff wait time would then be 310 seconds" and 328 seconds if each attempt consumes its full 3-second connect budget. The signing half was already sound and is re-confirmed live ('HMAC' reads 48 across the corpus, on https://developers.deliverect.com/reference/hmac-authentication.md and on every webhook reference page for POS, KDS, Store and Retail). WHAT IS STILL SHORT, and it is now the only shortfall: the REPLAYABLE EVENT LOG. There is no developer-facing replay or missed-delivery event-log endpoint; the nearest thing is operator-facing and in-app - the "Retry orders" and "View traces tab" permissions in the published permission census (https://help.deliverect.com/en/articles/7979053-role-permissions) and the Operation reports page, whose "Insert order" type is logged only "if Log Operations is activated for the location" (https://help.deliverect.com/en/articles/7979010-view-operation-reports). Partial therefore stands on one named conjunct instead of two. Value and grade unchanged; a future pass should re-verify whether the traces tab constitutes replay. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/docs/how-pos-order-failover-works.md · retrieved 2026-09-15

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

extensibility-order-injection-api

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/page/commerce-api-flow-diagram.md returns 200 and still carries the injection step and the terminal success signal ("POST checkoutUpdate webhook (status=completed / failed)"). The eat-in detail the old note said "lived on the deleted page" is alive in the moved tier at https://developers.deliverect.com/v1.1-restaurants/docs/how-to-handle-eat-in-orders.md and https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-create-an-eat-in-order.md, and the write endpoint is at grade A on https://developers.deliverect.com/v3.0-ordering-experience/reference/create-channel-order.md. Value and grade unchanged. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/commerce-api-flow-diagram.md · retrieved 2026-09-15

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

extensibility-menu-write-api

CITATION RE-POINTED AND FALSE PREMISE REMOVED. /page/menu-glossary.md is 404 but was renamed to "Channel Menus - Glossary", https://developers.deliverect.com/page/channel-menu-model.md (200), which still carries the write surface as a full field glossary including 'nutritionalInfo' and 'priceLevels'. THE OLD NOTE'S CLOSING SENTENCE IS NOW WRONG AND IS WITHDRAWN: it said "this page links to at least two deleted guides (product sorting, nutritional supplemental info), so the field list survives while its worked examples do not." Both guides are live under the version prefix - https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-nutritionalsupplemental-data.md and https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-sort-categories-items.md - and the authoritative write endpoint is at grade A on https://developers.deliverect.com/v1.1-restaurants/reference/insert-update-products-and-categories.md, which ships the OpenAPI definition. Value and grade unchanged; a grade-A re-point to the Insert Products reference is available and defensible if a later pass wants it. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/channel-menu-model.md · retrieved 2026-09-15

Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator

extensibility-data-symmetry

Orders, menu, products, availability, stores, opening hours, inventory and dispatch jobs are all read/write. Customers are thin, and employees/labor do not exist as objects at all. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01

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

extensibility-published-rate-limits

Legitimate 'no' because the cell scores whether limits are PUBLISHED, which is directly observable. I searched the full 145-page index at llms.txt: zero pages match 'rate limit'. Confirmed. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

extensibility-doordash-preferred

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

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

extensibility-first-party-delivery-integrations

THE QUARANTINE IS LIFTED, NOT RENEWED, AND THIS IS THE MOST CONSEQUENTIAL CORRECTION OF THE PASS. The 2026-08-09 quarantine recorded status dead-404 with "NO REPLACEMENT WAS LOCATED", and its search was bounded to "/docs/ and root .md routes, the /v1.1/ version prefix, all 64 live /page/ documents, the 7 live /reference/ pages, and the 983-article English help centre." That bound was WRONG in one specific way: the version prefix is /v1.1-restaurants/, not /v1.1/, and the /docs/ how-to tier had MOVED there rather than being deleted. Probing the right prefix finds the successor immediately. Per the evidence rules, quarantine is for evidence we may no longer re-open; this evidence is open, so 'dead_url' returns to 'url', 'status', 'measured', 'quarantined' and 'do_not_refetch' are dropped, and the grade is restored from the demoted C to its 'grade_before_quarantine' of B. Same evidence as delivery-3p-direct-integration, deliberately kept identical so that one fact does not yield two answers. https://developers.deliverect.com/v1.1-restaurants/reference/channel-integrators.md (200) enumerates 'DELIVEROO', 'UBER_EATS', 'DOORDASH', 'JUST_EAT', 'GRUBHUB', 'WOLT', 'MENULOG', 'HUNGER_STATION', 'PEDIDOSYA_DH' and 'MEITUAN' as channel integrator identities inside Deliverect's own Store API, with an OpenAPI definition on the page. Deliverect IS the certified middleware and holds the direct connections; the 2026-08-09 quarantine's "NO REPLACEMENT WAS LOCATED" was an artefact of searching /v1.1/ instead of /v1.1-restaurants/. The old note's unverifiable "DoorDash 2026 Preferred Integration Partner" clause is dropped rather than restated. Value unchanged; grade A on the new source; url restored from dead_url. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/v1.1-restaurants/reference/channel-integrators.md · retrieved 2026-09-15

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

extensibility-middleware-compatibility

CITATION RE-POINTED - A 403 IS NOT A DELETION, AND THIS ONE WAS A CLOUDFLARE INTERSTITIAL. The cited HTML page https://helpdesk.tryotter.com/hc/en-us/articles/15046529749395-Otter-Revel-Integration-Guide returns HTTP 403 with a 6,003-byte body whose title is "Just a moment..." and whose head carries '<meta name="robots" content="noindex,nofollow">' - the Cloudflare challenge page, not a missing article. The Zendesk Help Center API on the same host serves the article anonymously at HTTP 200: https://helpdesk.tryotter.com/api/v2/help_center/en-us/articles/15046529749395.json returns 47,503 bytes, 'article.title' = "Otter + Revel Integration Guide", 'article.locale' = "en-us", 'article.draft' = false, 'article.updated_at' = "2025-06-23T19:42:45Z", 'article.html_url' = the 403ing page. The body still says what the note rests on: "A POS integration is when you connect your online channels and delivery platforms with your Revel POS, via Otter", "Step 1: Menu Sync", "Step 2: Order Injection" - Otter integrating DIRECTLY with a POS, not through another aggregator. NO QUARANTINE IS WARRANTED: the evidence is retrievable today by a route we are permitted to use, so the url is simply moved to the API form and the grade stays B. The note's substance is unchanged; note only that its "617-page integrations directory" figure was not re-derived here - a fresh sitemap census this pass counts 626 distinct /integrations/<partner> slugs on www.deliverect.com, and that figure (and its derivation) is recorded on the digital-apple-business-connect proposal rather than silently overwritten here. Value and grade unchanged. https://helpdesk.tryotter.com/api/v2/help_center/en-us/articles/15046529749395.json · retrieved 2026-09-15

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

extensibility-accounting-connectors

Bounded against Deliverect's own published partner census rather than against the help centre, which is what the prior pass had. www.deliverect.com/sitemap.xml lists 617 English /en/integrations/ pages - the directory the site itself advertises as '1000+ Integration partners' - and NOT ONE is a general ledger or accounting system: QuickBooks, Xero, Sage, NetSuite, MYOB and DATEV are each absent from all 617 slugs. The categories that come closest are a different thing in each case: payments (adyen, stripe, mollie, airwallex, freedompay, dojo), food-cost and inventory tools (apicbase, inpulse, koust, gstock), and hotel PMS (shiji-group, guestline, valk-solutions). So there is no vendor-maintained connector to map journal entries into, let alone two. Consistent with what Deliverect is: it reconciles marketplace payouts and pushes orders to a POS, and the accounting step belongs to whatever system sits downstream of that POS. https://www.deliverect.com/en/integrations · retrieved 2026-09-10

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

extensibility-payroll-export

Searched payroll, Gusto, ADP, Paychex, Paylocity, rota, timesheet, hours worked, clock in. Gusto/Paychex/Paylocity/ADP appear on one unrelated customer page; payroll appears only inside third-party POS partners' own descriptions (Kobas, Prefectos, RockSpoon), never as a Deliverect integration category, and the hub's categories are POS, 3P marketplace, online ordering, on-site ordering, 3P dispatch, loyalty and CRM. Deliverect holds no labour-hours object to export. Absence bounded to the vendor sitemap and the four llms.txt manifests. SOURCE QUOTE: "We have partnered with the world’s best food ordering companies to offer the highest-quality, most reliable API integrations across delivery apps, POS systems, inventory software, last-mile delivery solutions, and more." https://www.deliverect.com/en/integrations · retrieved 2026-09-06 adversarially verified

Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator

extensibility-bi-data-warehouse

CITATION RE-POINTED, deliberately onto the same evidence as reporting-raw-warehouse-export so that one fact does not yield two answers. /page/faq.md is 404, renamed to https://developers.deliverect.com/page/web-faq.md (200, updatedAt 2026-08-21). QUOTE THE LIVE WORDING, not the old one: "Deliverect does not have a traditional Reporting API, but you can collect order data using the Reporting Endpoint feature - structured order payloads pushed after each fulfilment." Reporting webhooks push transaction-level data to a customer endpoint (https://developers.deliverect.com/v1.1-restaurants/docs/how-to-add-reporting-endpoints.md, plus the New Order Event / Order Status Event / Courier Update Event pages); no scheduled bulk export to a warehouse is documented. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/page/web-faq.md · retrieved 2026-09-15

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

extensibility-app-marketplace

The 1000+ headline and the categories are confirmed (POS, 3P Marketplace, Online ordering, On-Site Ordering, 3P Dispatch, Loyalty & CRM). But this is a partner DIRECTORY, not an app marketplace: no self-install flow, no operator-side enable/disable, and the page's own call to action is 'Request a New Integration'. An app marketplace the operator cannot install from is a partial at best. Note also the dossier lists a 'Retail' category that did not appear in my fetch. https://www.deliverect.com/en-us/integrations · retrieved 2026-08-01 adversarially verified

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

extensibility-custom-fields-scripting

A product 'metaData' attribute and custom tags allow operator-defined data on POS objects. No vendor-hosted custom logic or scripting. https://developers.deliverect.com/changelog/product-metadata-attribute.md · retrieved 2026-08-01

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

extensibility-headless-embedded

I could not resolve the cited page or any Commerce API page at three URL variants — all 404. The only verification available is that llms.txt indexes the titles 'Commerce API - Flow Diagram', 'Commerce Checkout - Glossary', 'How to Request a Payment' and 'How to Checkout a Basket'. Index titles establish that a basket/payment/checkout API exists; they do not establish that a third party can drive the full transaction engine, nor whether access is partner-gated. Downgrade until a page body is actually read. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

extensibility-api-versioning-deprecation

Verbatim confirmed: 'Deprecated API elements are maintained for at least three months after the announcement on the Deliverect Developer Hub', with expected retirement dates and migration paths. Two caveats the dossier omitted and should carry: beta features are explicitly exempt and may change at any time, and Deliverect reserves the right to break backward compatibility for security reasons or when the policy 'impedes the development of an API'. The three-month floor is therefore softer than presented. https://developers.deliverect.com/docs/deprecation-policy · retrieved 2026-08-01 adversarially verified

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

extensibility-data-portability-exit

On-demand exports are real and documented while the subscription is live: orders to CSV with a field picker and format choice (7979015), menu-item sales with grouping by day/week/all (7978954), analytics (7978952), products and menus (7979008), Direct Suite customers (15223), locations (30494), devices (7979054) and Deliverect Pay payouts (30523), each requested then downloaded from the Operation reports page; APIs and reporting endpoints cover the same ground programmatically. Shortfall: nothing survives termination. The US Terms of Service says the customer 'will lose access to the data, information, and content associated with such subscription' and that the 'right to access and use the Deliverect Services shall immediately cease', with no export period, no retrieval window and no documented post-termination format. No article on help.deliverect.com describes an exit export, and the cancellation article (7978942) covers notice periods and billing only. https://www.deliverect.com/en-us/terms-of-service · retrieved 2026-08-09

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

reliability-offline-order-entry

Held to the highest bar. Zero pages in the doc index match 'offline'. No offline capability is documented for any surface, and the architecture (webhook/HTTP order delivery) makes it structurally absent. Sustained across the whole offline block. https://developers.deliverect.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

reliability-offline-card-auth

CLAIM: card payments can be accepted while offline via store-and-forward, not just cash-only fallback. ABSENT, and settled on the vendor DEFINING its own use of the word rather than on a zero: 'Types of payment gateways - Merchants can create online and offline payment gateways in Deliverect. Online payment gateways allow end users to complete checkout through an online payment service, such as Adyen or Stripe. Offline payment gateways allow checkout to continue when the payment happens outside the scope of a commerce integration.' Deliverect's 'offline' is a TENDER CLASSIFICATION - cash, invoice, pay at counter - which is exactly the cash-only fallback the claim excludes, not a connectivity mode. The same page adds that for a Deliverect Pay integration 'only gateways with "paymentType": "online" are compatible, as they'll support the required re-direct or tokenization flow', and the checkout keeps the payment pending until a webhook returns an authorised status. A CLOSED ENUMERATION SEALS IT, and the verifier adds it: the Pay API's request-payment OpenAPI reference declares 'mode.type' as an enum of exactly four values - 'offline', 'redirect', 'terminal', 'token' - and none of the four is a queued or stored capture. There is no offline floor limit, no replay, and no post-reconnect decline report. Kept deliberately consistent with the record's already-settled payments-offline-store-and-forward: no, payments-offline-decline-liability: no, reliability-offline-decline-liability: no, reliability-offline-order-entry: no and payments-emv-nfc: no, so that one architectural fact does not yield two answers. CONTROLS: 'store and forward' and 'store-and-forward' read 0 in all three corpora in both modes; 'floor limit' reads 0. PUBLISHER-SCOPE RULING: Deliverect IS the right publisher, because the claim is about this product's own architecture and Deliverect publishes that architecture - a pure-cloud order pipe whose payment modes are an enumerated four and whose order entry is already scored 'no' for offline operation. What is explicitly NOT ruled on: whether a kiosk operator's PAX D200 or Q25 performs acquirer-side offline authorisation is a property of that terminal and of Adyen, is documented by them if at all, and is out of scope for a record about Deliverect. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-request-a-payment · retrieved 2026-09-15 adversarially verified

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

reliability-offline-decline-liability

This claim is about what the vendor publishes. The Kiosk T&C carries Deliverect's payment loss-allocation clause: it puts chargebacks and refunds on the Customer and states no offline cap, floor limit or store-and-forward decline provision, and neither do the Terms of Service, the SLA or the Deliverect Pay articles. 'store and forward' returns zero corpus-wide. Absence bounded to the full legal set in the English vendor sitemap plus the Intercom sitemap and four llms.txt manifests. SOURCE QUOTE: "Customer shall immediately reimburse Deliverect any Chargebacks and/or Refunds that are collected from Deliverect by the Payment Processor" https://www.deliverect.com/en/kiosk-terms-conditions · retrieved 2026-09-06 adversarially verified

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

Searched 'LAN', 'local network', 'same network', 'master', 'station'. Each Delivery Manager App tablet is an independent cloud client that receives orders from Deliverect and, when offline, simply waits for reconnection; 'local network' returns zero and 'LAN' appears only as a printer connection type in the DMA hardware list. No shared check or table state is held on site. Absence bounded to the Intercom sitemap and the four llms.txt manifests. SOURCE QUOTE: "When your tablet is online and connected to the app, new orders are sent instantly." https://help.deliverect.com/en/articles/8592174-dma-faqs · retrieved 2026-09-06 adversarially verified

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

Searched 'on-premise', 'edge server', 'local server', 'appliance', 'buffer'. The vendor's own SLA identifies the Services' runtime as Google Cloud, MongoDB, Cloudflare and Auth0 with no on-site component; 'edge server' and 'local network' return zero. Buffer Orders holds orders in Deliverect and releases them to the POS a set number of minutes before readiness, which is cloud-side scheduling, not a local engine. Absence bounded to the vendor sitemap, the Intercom sitemap and four llms.txt manifests. SOURCE QUOTE: "Outages caused by third-party services (including but not limited to Google Cloud, MongoDB, Cloudflare, Auth0," https://www.deliverect.com/en/sla · retrieved 2026-09-06 adversarially verified

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

reliability-offline-kds-printing

Deliverect does ship a KDS (help-centre collection of 14 articles: a browser/iPad web app requiring a cloud account, with a LAN receipt printer configured by IP per screen profile — articles 9527403 and 7979527), but no offline mode is documented for it or any other surface: zero pages match 'offline' in the 144-page developer index, the KDS articles document no offline behaviour, and orders reach the kitchen screen only via the cloud platform. The settled reliability-offline-order-entry: no (pure cloud middleware) makes continue-while-offline routing structurally absent — with connectivity down, no orders can arrive to display or print. https://developers.deliverect.com/llms.txt · retrieved 2026-08-04

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

reliability-printer-fallback

Printing in Deliverect is the Delivery Manager App's. Setting up a printer is discover-add-configure, and the configure step's whole option set is 'print bag or kitchen tickets by enabling them via the toggles ... adjust the number of tickets to be printed and the font size ... Print test tickets ... an option to disconnect the printer' (7979068). Workstation creation likewise enumerates Station name, Station type (Items or Brands), Print kitchen tickets, Print bag tickets, 'Assign printers: Choose the printer to use' -- singular, with no alternate or fallback (7979091). The tablet-profile Printing section (7979054) lists automatic printing, print trigger, ticket counts, fonts, logos and QR codes, again with no failover. Nor is there an alarm: the create-alert screen's topic list is Order cancelled, Order injection failed, Menu publish failed, Item snoozed, Store closed by channel, Store closed by user, Order delayed (7979009) -- no printer or device offline topic. Failover in Deliverect exists only for order delivery to the POS endpoint (developers.deliverect.com POS Order Webhook Failover Flow), and where the POS owns printing Deliverect defers to it entirely ('The management of receipts and printing must be done on Epos Now', 7979145). https://help.deliverect.com/en/articles/7979068-dma-set-up-a-printer · retrieved 2026-08-09

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

Publication-observable claim — the cell scores whether conflict-resolution behaviour is DOCUMENTED. Zero pages match 'conflict' in the 144-page developer index, and the help centre documents no partition or concurrent-edit semantics (closest is 'Reporting Differences Between Your POS, Channel, and Deliverect', article 9104394, a reconciliation explainer, not a concurrency policy). With no offline editing on any surface (settled offline block: no), the vendor documents no partition-edit scenario and no resolution behaviour. https://developers.deliverect.com/llms.txt · retrieved 2026-08-04

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

reliability-offline-feature-matrix

Searched 'offline' in the vendor's own sense - which usually means a store hidden on a delivery channel, not a device without connectivity - plus 'degraded', 'unavailable offline', 'limitations'. The single device-offline passage Deliverect publishes describes waiting for reconnection and catching up missed orders; no per-feature list of what does or does not work offline exists. Absence bounded to the Intercom sitemap, the four llms.txt manifests and the English vendor sitemap. SOURCE QUOTE: "If your tablet goes offline (for example, due to Wi-Fi issues or the device being turned off), the app doesn’t keep retrying every few minutes." https://help.deliverect.com/en/articles/8592174-dma-faqs · retrieved 2026-09-06 adversarially verified

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

reliability-public-status-page

Verified exactly: all 13 named components present, 90-day uptime shown for 12 of them at 100.0% (DoorDash Orders shows no percentage). Worth adding one skeptical note the dossier missed — the incident history shows 'No incidents reported' for every date in the visible window while 12 components sit at a flat 100.0%, which is unusually clean and suggests conservative incident declaration rather than perfect uptime. https://status.deliverect.com/ · retrieved 2026-08-01 adversarially verified

A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator

reliability-contractual-uptime-sla

CORRECTED 2026-09-06. The prior note asserted 'the SLA document itself is not published' -- that is FALSE and is withdrawn. Deliverect publishes its Service Level Agreements at /en/sla (and a revision at /en/sla-v2), both in the www sitemap, governing DfRS, Dispatch and Deliverect Direct. The percentage conjunct is therefore MET: a stated Uptime Threshold of 99.5% yearly, excluding planned maintenance and named third-party dependencies (Google Cloud, MongoDB, Cloudflare, Auth0). The credit conjunct is NOT met: the strings credit, refund, remedy, penalty and compensation return ZERO across both revisions (7,141 and 9,564 chars, read whole). The document offers escalation tiers and response/resolution targets instead of a financial remedy. One conjunct of two, so partial, not no. SOURCE QUOTE: "Deliverect will make commercially reasonable efforts to ensure the Services are available 99.5% of the time, on a yearly basis" https://www.deliverect.com/en/sla · retrieved 2026-09-06 adversarially verified

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

reliability-incident-postmortems

OVERTURNS THE PREMISE THAT HELD THIS CELL. The prior rationale read status.deliverect.com's front page, which says 'All Systems Operational' and 'Uptime over the past 90 days', and concluded there was nothing to post-mortem. The 90-day window is the front page's, not the vendor's history: status.deliverect.com/history.atom enumerates 25 incidents from 2022-05 to 2026-04, and one of them carries a labelled Postmortem section with cause, impact and remediation - 'Some of our customers experienced temporary delays in order processing due to an issue with a new feature. This feature, designed to improve how we handle old data, unintentionally created extra work for our system during a busy period... To prevent this from happening again, we've made several improvements, including better monitoring, stricter testing for new features, and adjustments to how our system handles errors.' So Deliverect does publish written post-incident reports. `partial` rather than `yes` because it is 1 of 25, and not for the biggest ones: the two largest outages in the feed - 'Global Cloudflare Outage' (Dec 2025) and 'Outage Due to Cloud Provider Issue' (Jun 2025) - and the 'Menu Pushes Failing' major of Apr 2026 all end at the standard Investigating / Identified / Monitoring / Resolved ladder with no report. NOTE ON ACCESS: status.deliverect.com/robots.txt disallows /api/ and /embed/, so the Statuspage JSON API is barred and was not used as evidence; the Atom feed and the /incidents/ HTML pages are permitted and are what this cites. https://status.deliverect.com/incidents/nbvxp776h6gk · retrieved 2026-09-10

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

reliability-247-live-support

'Contact Us' (7978926): 'our support team is here to help ... We are available 24/7.' The primary route is in-product chat -- 'Our technical support team typically responds to live chats within a few minutes' and 'our agents can initiate voice calling or screen sharing' -- reachable from the web portal and from the Delivery Manager App, plus four regional WhatsApp numbers (Asia/Oceania +61 481 606 504, EMEA/North Africa +44 7401 275062, North America +1 646 933 0428, LATAM +52 55 9225 2033), gated on the number being listed on the account. Shortfalls: no inbound support telephone number is published anywhere -- voice is agent-initiated out of a chat, and WhatsApp is messaging; and inclusion in the base subscription is not established, because Deliverect sells a separate 'Support as a Service' subscription with non-refundable Support Fees applied at account level (deliverect.com/en/support-as-service-terms-and-conditions), while the Terms of Service reserve the right to 'suspend the provision of technical and operational support, or to change the scope of support services'. No response-time SLA is published. https://help.deliverect.com/en/articles/7978926-contact-us · retrieved 2026-08-09

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

CLAIM: the vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. PARTIAL. THE POSITIVE HALF, from the Kiosk Terms and Conditions section 5 (Delivery and Installation), carried verbatim in /en-us/terms-of-service as well: 'Deliverect shall deliver the Hardware to the location(s) designated by Customer following confirmation of payment or execution of these Terms, depending on the selected financing option. Unless otherwise agreed in writing, delivery shall be FOB (Incoterms 2020). If installation services are included, Deliverect shall perform installation of the Hardware through qualified personnel or a third party appointed by Deliverect. Customer shall ensure that the installation site meets all infrastructure requirements, including but not limited to power, connectivity, and physical access.' That is a binding, physically-present, first-party-or-appointed installation obligation, so the claim's in-person and first-party conjuncts are MET for one product line and this cell is not a shortfall on every conjunct. NAMED SHORTFALL, four parts. (a) SCOPE: it exists only for Kiosk HARDWARE; the core middleware's entire documented onboarding is remote and self-serve, and the SLA pushes first-line support back onto the operator ('Customer shall provide L1 Support for Corporate Locations and to Franchisee Locations (if applicable)', /en/sla-v2 section 4). (b) CONDITIONALITY AND PRICE: the clause is governed by 'If installation services are included' - a quote line, not an entitlement - and the financing section confirms it is charged separately: 'Customer acknowledges that shipping, setup, VAT and other taxes linked to shipping the Hardware and installation costs are excluded from the financing and invoiced separately.' (c) NO DEALER NETWORK, AND ONE PRODUCT GOES THE OTHER WAY: no certified installer network is published anywhere, and for the Resolve add-on Deliverect explicitly refuses the work - 'Resolve requires the installation of hardware at the Resolve Locations. Deliverect will provide Customer with the contact details of its preferred hardware vendors, enabling Customer to liaise directly with a selected vendor and enter into a separate purchase and installation agreement ("P&I Contract")', with 'Deliverect is not liable or responsible for the acts or omissions of the selected hardware provider'. The 27 'reseller' hits in the help centre point the same way: every one is the OPERATOR'S OWN POS reseller (Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool) being asked to do the physical or licence work, never a Deliverect-certified installer. (d) GO-LIVE, STATED PRECISELY: the vendor does publish a go-live section, but it is remote and partner-facing, not a cutover visit - the developer FAQ's 'Post-Certification & Go-Live' says 'Our team will guide you through the onboarding of your first customer. Make sure you test your production environment thoroughly after receiving production credentials before the go-live', and the only other four 'go-live' hits in 984 help articles are 'contact our support team so we can check your go-live status' for Menulog and Takeaway.com channel activation. No on-site go-live or cutover-night commitment is published for any product. Premium support is sold as a remote subscription with its scope unpublished ('The scope of the Premium Services that are hired by Customer will be made available on www.deliverect.com, Deliverect's frontend, or any other channel chosen by Deliverect'). CONTROLS: 'onsite' reads 0 in all three corpora; 'certified installer', 'field service' and 'dealer' read 0 in all three; 'on-site' reads 41 across the 25 live www pages and every hit is the navigation item 'On-Site Ordering'. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://www.deliverect.com/en/kiosk-terms-conditions · retrieved 2026-09-15 adversarially verified

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

reliability-menu-build-service

Deliverect AI's Smart Assistant Agent performs bulk menu content work (harmonising images, standardising descriptions, applying allergen tags at scale) — closest available, but not a documented onboarding menu-build service. https://www.deliverect.com/en-us/deliverect-ai · retrieved 2026-08-01

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

reliability-hardware-replacement-sla

The prior rationale ('no first-party hardware') is wrong: Deliverect sells, leases and finances Kiosk hardware and ships PAX D200/Q25 payment terminals, and help articles describe a replacement process with return instructions and a shipped replacement unit. Partial, not yes: the included 12-month warranty gives repair or replacement at Deliverect's discretion with shipping at the Customer's cost, and no turnaround time or advance-exchange window is stated anywhere in the legal set or the help manifest. DMA tablets remain the operator's own. SOURCE QUOTE: "Deliverect warrants that the Hardware shall be free from defects in materials and workmanship under normal use for a period of 12 months from the date of delivery." https://www.deliverect.com/en/kiosk-terms-conditions · retrieved 2026-09-06 adversarially verified

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

reliability-backup-restore

Deliverect documents an operator-triggered backup and restore of the product catalogue in those exact terms: the Bulk Edit Products workflow has the operator request a CSV export (Products > Export > Request export, then Get download link / Download CSV from Operation reports) and states 'We highly recommend creating an un-edited backup, which will allow you to restore the original values of your products if necessary', with steps 10-13 documenting the Import CSV path that writes the values back. Object-level reversion also exists ('Revert all product changes', 7978989). Named shortfall: it covers products only and depends on the operator storing the file themselves - there is no platform-side snapshot or point-in-time recovery (Role Permissions, which states 'you can find every permission you can activate for a user role', has no backup, restore or snapshot permission), deleted menus cannot be restored at all (7978997), force sync is 'irreversible', and no RPO or RTO figure is published: deliverect.com/en-us/security names 'High availability and disaster recovery capabilities' without any recovery point or recovery time objective. https://help.deliverect.com/en/articles/7979048-bulk-edit-products · retrieved 2026-08-09

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

reliability-pci-dss-4-attestation

A publication claim, and nothing is published. Deliverect's security page enumerates its compliance posture in six numbered sections and names GDPR and NIST SP 800-218 only; PCI DSS, an Attestation of Compliance and a validated P2PE listing are all absent from it, from the 984-article English help centre and from the 1,213-page English marketing site. No trust center exists to host such a document - trust.deliverect.com does not resolve and /en-us/trust is a 404 - and the page's own escalation path for security questions is an email address rather than a document. The claim is specifically about the post-March-2025 future-dated requirements, and Deliverect publishes no attestation of any PCI version, current or superseded. https://www.deliverect.com/en-us/security · retrieved 2026-09-10

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

reliability-mfa-role-based-access

RBAC is fully met: 'In this article, you can find every permission you can activate for a user role' introduces ~150 discrete permissions across 27 groups, roles are user-authored (9420014 Create or Edit User Roles; 31211 Default Roles), permission grants are bounded by the granter ('You can not activate permissions that you do not have yourself'), access can be scoped per location ('Manage locations: Allows modifying the allowed locations of other users' plus the per-user 'Restrict to locations' toggle, 7979005), and sensitive actions are separable -- Deliverect Pay refunds can be limited to named roles (31165). Shortfall: MFA. 'Log in to Deliverect' (7978937) enumerates identity verification as 'An email address and password' or 'A Google account'; the password article documents only reset and lockout after repeated failures (7978939). The strings MFA, 2FA, two-factor, multi-factor and authenticator appear nowhere in the 983-article English help centre, no MFA-enforcement setting appears in the permission list or account settings articles, and deliverect.com/en-us/security names 'authentication and authorization' without any second-factor claim. So a second factor is only available to operators who sign in through Google, and cannot be enforced by Deliverect for password accounts. https://help.deliverect.com/en/articles/7979053-role-permissions · retrieved 2026-08-09

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

reliability-self-serve-training

CITATION UNCHANGED AND VERIFIED LIVE THIS PASS. https://developers.deliverect.com/docs/staging-and-production-environment.md returns 200 (it is the known-good control the prior passes used, and it is listed in the root llms.txt as "How to access a test customer account"). The practice surface is broader than the note records now that the how-to tier is readable: https://developers.deliverect.com/v1.1-restaurants/docs/how-to-create-test-orders.md and .../how-to-recieve-orders.md, https://developers.deliverect.com/v3.0-ordering-experience/docs/how-to-test-orders.md, .../how-to-test-busy-mode.md and .../how-to-test-courier-assignment-via-dma.md, plus the 'testOrder' flag (14 hits) and the DMA install guide. The "Dummy POS" withdrawn by the 2026-08-09 note is still absent (0 hits) and stays withdrawn. The named shortfall is unchanged and is the reason the value does not move: this is INTEGRATOR tooling, not a staff-facing video/LMS library or a terminal training mode. Value and grade unchanged. THE NOTE'S FALSE PREMISE IS THE ONLY DEFECT AND IT IS CORRECTED HERE. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/docs/staging-and-production-environment.md · retrieved 2026-09-15

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

reliability-failover-terminal-role

Searched the vendor's own word 'failover', plus 'master', 'primary', 'local server', 'station'. Deliverect uses 'failover' for one thing only: cloud-side retry of the order webhook into the merchant's POS, six attempts over about five minutes. No terminal topology, primary role or role election appears in the manifest; DMA tablets are peer cloud clients. Absence bounded to the four llms.txt manifests and the Intercom sitemap. SOURCE QUOTE: "To deal with potential order injection failures, we have a retry policy that uses an exponential backoff with a maximum of 5 retries." https://developers.deliverect.com/v1.1-restaurants/docs/how-pos-order-failover-works · retrieved 2026-09-06 adversarially verified

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

reliability-cellular-backup

Searched 'cellular', 'LTE', '5G', 'SIM card', 'mobile data' and 'failover' against the vendor's connectivity vocabulary, which is Wi-Fi, Ethernet/LAN and Bluetooth. All return zero in dev and help. DMA runs on the operator's own iPads, iPhones and Android devices and Deliverect states it supplies no hardware; the Kiosk hardware it does supply is documented as mains-powered and network-attached, with no connectivity failover. Absence bounded to the Intercom sitemap and four llms.txt manifests. SOURCE QUOTE: "The following hardware is currently supported for use with DMA. Deliverect does not provide any hardware." https://help.deliverect.com/en/articles/7979065-dma-app-requirements-and-installation · retrieved 2026-09-06 adversarially verified

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

commercial-month-to-month-contract

General Terms cl.13: 'Deliverect offers subscription periods of 30 days, 90 days, 6 months, or 12 months ("Subscription Period"). Longer Subscription Periods may apply for Deliverect Kiosks.' A 30-day period is therefore publicly offered, and the longest period in the published set is 12 months - the terms contain no multi-year minimum and the words 'liquidated damages' and 'early termination' do not appear in the document. Caveats: the kiosk carve-out is the one place a longer term is contemplated, and which period a given customer gets is set in the quote (pricing remains quote-only), so this establishes that month-to-month is on offer, not that it is the default. https://www.deliverect.com/en-us/terms-of-service · retrieved 2026-08-09

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

commercial-no-early-termination-fee

The whole General Terms document was fetched and searched: 'liquidated damages' and 'early termination' return zero hits, and cl.40 bounds the exit cost - on termination 'Customer shall immediately pay all outstanding and undisputed fees due up to the effective date of termination', with no acceleration of the remaining Subscription Period. Named shortfall: cl.40 gives the CUSTOMER a termination right only for cause (material breach, insolvency, fraudulent or unlawful activity) while reserving termination 'for convenience' to Deliverect alone; the customer's ordinary exit is the cl.13 notice route (15/30/90 days before the end of the Subscription Period), and cl.8 states fees are non-refundable. So there is no penalty for leaving at the term boundary and no ETF anywhere in the contract, but no published right to cancel early either. https://www.deliverect.com/en-us/terms-of-service · retrieved 2026-08-09

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

commercial-autorenew-terms-published

General Terms cl.13: 'The Subscription Period shall automatically renew for an additional Subscription Periods of the same length, unless Customer provides notice to Deliverect ... as follows: (i) 15 days notice if the Subscription Period is 30 or 90 days; (ii) 30 days notice if the Subscription Period is 6 months, and; (iii) 90 days notice if the Subscription Period is 12 months.' The same windows are restated in the public help centre (help.deliverect.com/en/articles/7978942-cancel-a-subscription: 'Notice periods are: 15 days for subscriptions with a renewal period of 1 month. 30 days ... 6 months. 90 days ... 12 months'), so both the renewal term and the cancellation notice window are published rather than confined to a signed quote. https://www.deliverect.com/en-us/terms-of-service · retrieved 2026-08-09

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

commercial-processing-not-bundled

'Deliverect Pay: Configure a Payment Gateway' has the operator add a gateway and link stores to it; separate articles walk through supplying the operator's OWN credentials for Mollie ('Copy the Live API key' from the Mollie dashboard, art. 7979305), Stripe ('Copy the Secret key' from the Stripe dashboard, art. 7979306), Adyen (art. 14321835), Paymob and Airwallex, plus offline gateways (cash, card, invoice) needing no verification. The General Terms, Direct supplemental cl.2, confirm the boundary: payments are 'provided by third party payment processors integrated with Deliverect', and 'Deliverect may offer a functionality - subject to additional fees - that allows the Customer to use its current payment processor'. Deliverect is not the acquirer and there is no in-house processing lock; the practical limit is that a processor outside the integrated set is a paid-for option rather than a standard connector. https://help.deliverect.com/en/articles/7979307-deliverect-pay-configure-a-payment-gateway · retrieved 2026-08-09

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

commercial-interchange-plus-published

No processing rate of any structure is published - neither blended/flat card-present rates nor an interchange-plus option with a stated bps + per-transaction markup. The page's entire cost content is 'Deliverect offers flexible pricing based on your business's specific needs' plus 'CUSTOMIZED PRICING FOR ENTERPRISES / Get a personalized quote'. Zero currency or bps figures in the page source. https://www.deliverect.com/en/pricing · retrieved 2026-08-08

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

commercial-rate-increase-clause

General Terms cl.14 'Changes to the Fees': 'Deliverect reserves the right to increase the fees and/or change the fee structure by providing thirty (30) days' notice to Customer. Continued use ... will be interpreted and construed as Customer's express acceptance of the updated fees. Customer's sole recourse if Customer does not agree with the updated fees is to terminate these Terms and cease using the Deliverect Services.' So an exit right on any increase is granted and 30 days' notice is guaranteed. Named shortfalls: there is no cap, no index and no carve-out limiting increases to pass-through costs ('indexation' returns zero hits); the exit is not stated to be penalty-free - fees are non-refundable and cl.14 does not waive the cl.13 15/30/90-day notice windows or the current Subscription Period. Separately, card processing rates are set by the third-party Payment Processor under the customer's own contract with it (Direct supplemental cl.2-3), not by this document, so no processing rate-escalation term is published at all. https://www.deliverect.com/en-us/terms-of-service · retrieved 2026-08-09

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

commercial-pricing-published

Explicitly quote-only. Verbatim from the FAQ block 'How much does Deliverect cost?': 'Deliverect offers flexible pricing based on your business's specific needs. Factors like your location, the scale of your digital operations, number of locations, and the Deliverect solution you choose (Restaurants, Retail, Direct, or Dispatch) all influence the cost.' followed by 'Book a 1-on-1 with our team to discuss pricing'. No per-location or per-terminal software figure is published. https://www.deliverect.com/en/pricing · retrieved 2026-08-08

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

commercial-module-unbundling

Products are distinct SKUs (Restaurants, Direct, Catering, Kiosk, Dispatch, Sentinel, Reclaim, Quest) and Deliverect Plus is stated to be 'An Add-on'. Whether each can be cancelled independently without repricing the base is not published. https://www.deliverect.com/en-us/deliverect-plus · retrieved 2026-08-01

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

commercial-hardware-purchase-outright

'DMA: App Requirements and Installation' says verbatim 'Deliverect does not provide any hardware', then lists what the operator must supply: iPads (5th gen or higher, iPad Pro, iPad Air 2nd gen+, iPad Mini 4th gen+) or iPhones on iOS 15+, or Android 9+ devices, plus named Star (TSP100III/TSP143III family) and Epson (TM-m30II/III, TM-m50, TM-P20/P20II/P60II/P80) printers. 'Deliverect KDS: Supported Hardware' (art. 7979532) likewise says the KDS screen is 'any device that has a web browser' and lists supported Epson and Star models. All of it is third-party retail hardware the operator buys outright; there is no Deliverect terminal SKU, hardware bundle, lease or rental in the software product. The one lease that exists in the General Terms is a French-market Financial Lease Agreement for the Deliverect KIOSK terminal only - explicitly optional, 'exclusively available for Customer that are located in France', and with a purchase option at expiry - and kiosks are outside the required hardware for order/menu management. https://help.deliverect.com/en/articles/7979065-dma-app-requirements-and-installation · retrieved 2026-08-09

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

commercial-hardware-not-locked

Runs on commodity tablets and 'any mobile device, including Zebra scanners, with no special hardware needed'; the Kiosk works with external payment devices and optional standard printers. https://www.deliverect.com/en-us/quest-app · retrieved 2026-08-01

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

commercial-implementation-fee-published

No implementation, onboarding, menu-build or training fee is published as an amount, and there is no statement that any of them is $0. The pricing FAQ addresses setup only qualitatively - 'Once you sign up, our expert team will be ready to guide you through setup. We offer personalized onboarding' - with no figure attached and no 'included' or 'free' wording, while cost overall is directed to a personalized quote. https://www.deliverect.com/en/pricing · retrieved 2026-08-08

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

commercial-data-export-self-serve

CITATION RE-POINTED. /docs/certification-process.md is 404 (re-probed slowly on 2026-09-15); the content moved to https://developers.deliverect.com/docs/become-an-integration-partner.md (200), which carries the credential gate the note rests on: the Welcome email delivers "Access to a staging account, API Credentials, A certification document", and "You won't get production access until our certification process is complete." So machine-readable transaction access exists (Reporting Endpoints plus the order and menu APIs) but obtaining API credentials requires vendor contact. The operator-facing self-serve half is unchanged and is stronger than the note records: Export products, Export locations, Export orders, Export analytics and Export operation reports are all first-class permissions in the published permission census (https://help.deliverect.com/en/articles/7979053-role-permissions), and the CSV route is documented end to end. Value and grade unchanged. PORTAL-CONTEXT CORRECTION (2026-09-15): the note previously asserted that "developers.deliverect.com deleted its /docs/ how-to tier in a restructure". THAT IS FALSE AND IS WITHDRAWN. A 301 is not a deletion and neither is a re-prefix. The /docs/ how-to tier MOVED under version prefixes and is indexed, live, in the vendor's own manifests: https://developers.deliverect.com/llms.txt (7 guides, 4 reference pages, 55 /page/ documents, 10 changelog entries), https://developers.deliverect.com/v1.1-restaurants/llms.txt (the restaurant POS how-to tier, ~130 entries), https://developers.deliverect.com/v2.0-retail/llms.txt (~25) and https://developers.deliverect.com/v3.0-ordering-experience/llms.txt (204). Re-derived this pass: 407 distinct .md URLs across the four manifests, of which 377 were fetched after de-duplicating the versioned changelog copies; 377/377 returned HTTP 200, zero 404 shells, one page (v3.0 /reference/webhooks) served the ReadMe HTML shell at 200 rather than markdown. The tier that actually lost documents is /page/, where ten slugs 404 and several were RENAMED rather than removed (menu-glossary -> channel-menu-model, stores-glossary -> store-model, faq -> web-faq, pos-order-webhook-failover-flow -> pos-orders-failover-flow, payment-types -> glossary-payment-api). The root llms.txt now also states the retrieval route in its own words: "Append .md to any documentation page URL to get its markdown version." RETRIEVAL CAVEAT: developers.deliverect.com rate-limits hard. A fast census of the 117 cited URLs returned 23 x HTTP 429, and 17 of those 23 were plain 200s on a slow re-probe. A 429 written to disk manufactures a false death. Every fetch behind this pass slept >=3.5s and retried 429 with exponential backoff; the 377-document corpus contains no 429 and no 404. https://developers.deliverect.com/docs/become-an-integration-partner.md · retrieved 2026-09-15

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

commercial-export-customer-and-loyalty

Guest records: documented. 'To create a CSV file of your customers, select the Export customers button. Go to your Operation reports page to download the file' - the table carries contact details, transactions, last-purchase data and order count, plus the marketing-consent flag. Named shortfall: the loyalty half is not covered. Direct Suite loyalty is a stored-credit scheme ('Set how much credit customers receive with each order ... Redeemable (%) ... Maximum redeemable value', art. 8041162) and neither that article nor 'Direct Suite: View Your Customers' (art. 8045310) documents any export of per-customer credit or point balances; gift cards appear in the help centre only as user-permission rows ('Create/Remove/Link/Unlink/View gift card profiles'), with no gift-card article and no liability-balance report. Deliverect Pay payouts have their own export (art. 11515027 'Deliverect Pay: View and Export Payouts'), which is settlement, not liability. https://help.deliverect.com/en/articles/7979317-deliverect-online-ordering-view-and-export-customers · retrieved 2026-08-09

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

commercial-post-termination-export-window

'Cancel a Subscription', section 'What happens after cancellation': 'Once your cancellation request is processed, the related services will remain accessible until the end of the billing period. All integrated channels are disconnected after your cancellation request is processed. Download any necessary reports or data from Deliverect before the end of your subscription, as data will be permanently removed.' The General Terms agree twice - cl.13 'If the subscription is terminated, Customer will lose access to the data, information, and content associated with such subscription', and cl.40 'Deliverect shall terminate Customer's access to Customer's Deliverect account, and the data residing therein, and Customer will lose access to all of the data'. So the documented window runs to the end of the paid billing period and there is no post-termination retrieval period; the vendor addresses the question directly and instructs operators to export first. (Narrow exception outside the software subscription: the EU Data Act appendix for Kiosk/Tabesto promises readily-available data on request in a machine-readable format, but it is kiosk product data and states no post-termination window either.) https://help.deliverect.com/en/articles/7978942-cancel-a-subscription · retrieved 2026-08-09

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

commercial-data-ownership-clause

Direct's marketing asserts operator guest-data ownership and first-hand data. No published contract clause constraining Deliverect's own use or resale of transaction data was found. https://www.deliverect.com/en-us/deliverect-direct · retrieved 2026-08-01

The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).

commercial-source-available-selfhost

Proprietary cloud SaaS. No source availability, no self-hosting option; the only open artefact is the API documentation. https://developers.deliverect.com/ · retrieved 2026-08-01

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

commercial-pci-p2pe-tokenization

A Deliverect Pay payment-token flow is documented, implying tokenized hosted capture for digital channels. No P2PE validation, no named SAQ type, no card-present scope statement. https://developers.deliverect.com/page/deliverect-pay-payment-token-flow.md · retrieved 2026-08-01

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

commercial-pci-dss-4-controls

Also a documentation claim, and the two named controls are documented nowhere. The security page's section 1 lists the measures Deliverect will describe in public - 'Data encryption. Privacy by design and by default. GDPR and privacy compliance. Robust authentication and authorization mechanisms; High availability and disaster recovery capabilities; Vulnerability detection, monitoring, and remediation controls; Robust information security policies and security training are available to all employees.' - and then stops, directing anyone who wants detail to email the Security Team. MFA for cardholder-data-environment access is not among those bullets; neither is payment-page script-integrity monitoring under Req 6.4.3 / 11.6.1, which would matter for Deliverect's hosted Direct ordering pages. The 984-article English help centre carries no substring of PCI at all. Recorded as `no` on the documentation test the claim sets, not as a statement about what Deliverect operates internally. https://www.deliverect.com/en-us/security · retrieved 2026-09-10

Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.

commercial-soc2-attestation

The claim asks whether the vendor STATES it holds the attestation, and Deliverect's security page is the document that would state it. That page is a closed six-section enumeration - Security at the Core, Security in the SDLC, Hosting, Governance Risk and Compliance, Responsible Security Disclosure, Personal Information - and the only frameworks it names are GDPR and one SDLC standard: 'aligning with NIST Special Publication 800-218: Secure Software Development Framework (SSDF)'. Neither SOC 2 nor ISO 27001 appears on it, or anywhere in the 984-article English help centre. There is no trust center to hold the report either: trust.deliverect.com does not resolve at all, and www.deliverect.com/en-us/trust answers 404. What the page offers instead is a mailbox, and it frames the controls as unpublished rather than attested: 'For more information regarding the cybersecurity controls that we have in place, please reach out to our Security Team via email at security@deliverect.com' A vendor that held the attestation would name it here; it names two other frameworks and not this one. https://www.deliverect.com/en-us/security · retrieved 2026-09-10

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

commercial-privacy-dsar-tooling

DPA half: satisfied. Deliverect publishes Data Processing Terms at www.deliverect.com/en/dpaeu, incorporated by reference in the Direct supplemental terms ('Customer Personal Data will be processed under the Data Processing Terms available at www.deliverect.com/en/dpaeu'), so the operator does not have to negotiate one; it names Deliverect as processor, carries a sub-processor regime, and includes 'Processes to Comply with Rights of Data Subject Rights ... Deliverect shall assist Customer and/or Franchisees by implementing appropriate technical and organizational measures for the fulfillment of Customer's obligations to respond to requests to exercise Data Subject rights'. Tooling half - named shortfall: the in-app surface is locate and export only (Direct Suite / Online Ordering customer list with search, plus the Export customers CSV, art. 7979317). Deletion is not self-serve: 'Anonymize Customer Data' (art. 9595607) reads in its entirety 'Your customers' data can be anonymized in Deliverect. To request this, please reach out to your account manager or our support team and ask them to activate the GDPR setting for your locations.' There is no documented per-guest DSAR workflow and no CCPA/CPRA-specific mechanism; the EU Data Act appendix likewise routes access and erasure requests through the support chat. https://www.deliverect.com/en/dpaeu · retrieved 2026-08-09

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

commercial-wcag-kiosk-accessibility

The Kiosk product page makes no accessibility, ADA or WCAG claim, and no VPAT/ACR is published for the kiosk or the consumer ordering surfaces. https://www.deliverect.com/en-us/deliverect-kiosk · retrieved 2026-08-01

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

commercial-dual-pricing-compliant

CLAIM: supports card-network-compliant dual pricing / cash discount or surcharging, with automatic exclusion of debit and prepaid cards from any surcharge and required receipt and menu-board disclosure of the fee. This is the compliance-wrapped form of a capability the record has already settled as absent in its base form, and one fact must not yield two answers: menu-pricing-dual-pricing is 'no' at B, payments-dual-pricing is 'no' at B, payments-surcharge-guardrails is 'no' at B, payments-emv-nfc is 'no' at B. If there is no tender-based pricing axis and no first-party card-present tender, there is nothing to make compliant. ABSENT: the documented pricing axes are enumerated across three live developer pages and tender is not among them - 'Optionally, additional prices can be defined using "priceLevels" in order to support different pricing for specific ordering channels and menu fulfilment type', worked as '"priceLevels": { "TA": 350, "DL": 400, "1PO": 300 }' against Takeaway, Delivery and First Party (how-to-configure-price-levels.md, 200 at 3,695 bytes, updatedAt 2026-08-17), with base price and tax on product-configurations.md and scope-keyed overloads on overloads.md, which also states that overloads beat price levels on the same item. There is no receipt or menu-board disclosure surface to carry a fee notice either: Deliverect ships no first-party card-present receipt, the Kiosk page states compatibility with EXTERNAL payment devices, and the kiosk's card acceptance is a cabled PAX D200/Q25. 'dual pricing' reads 0 in all three corpora in both modes; 'surcharging' reads 0; 'interchange' reads 0. PUBLISHER-SCOPE RULING: Deliverect IS the right publisher for the pricing half of this claim, because Deliverect defines and publishes the complete set of axes on which a price may vary, and tender is not one of them; a merchant running dual pricing on a connected POS would compute it in that POS and Deliverect would receive the resulting prices. Explicitly not ruled on: whether Adyen, Stripe, Mollie, Paymob or Airwallex offer a compliant surcharging product of their own - that is a claim about the acquirer. VERIFIER'S CAUTION ON THE OTHER HALF: the debit/prepaid exclusion conjunct is genuinely processor machinery, so this cell is not 'no' because Deliverect fails a compliance test - it is 'no' because the thing to be made compliant does not exist in the product. CONTROL DISCIPLINE. Every figure below was run twice by the verifier, once with both word boundaries and once as a left-boundary stem that catches the plural and the -ing, never as a substring, with a positive control and a nonsense control on the same run. THE FIGURE IS A READER ARTEFACT AND ONLY THE INVARIANCE IS THE CONTROL: the positive control 'Deliverect' reads 2,751 developer hits for this verifier where the proposing pass published 2,771, and 8,056 help-centre hits where it published 8,057; both instruments agree that the term saturates all three corpora, and the nonsense control 'zzqqxxnotaword' reads 0 in all three. POISON, published so it is not re-stepped-on. (1) 'debit' IS NOT ZERO and the proposing pass published it as zero in two control tables: tokenised it reads 5 hits in the help centre and 2 on www, and as a left-boundary stem it reads 12, because 'DebittechPOS' is the name of a Canadian/US POS partner with its own integration article - the real debit hits are a partner-POS tender note ('Support for credit and cash tender types (but not debit)'), Deliverect's own subscription billing by GoCardless direct debit, a tablet field 'Debit card, luncheon voucher card', and the marketing line 'Apple Pay, Google Pay, debit and credit cards'. (2) 'prepaid' IS NOT ZERO either: the single www hit is 'Save staff's time with prepaid orders', i.e. pre-paying for an order, not a prepaid CARD. (3) 'Apple Pay' and 'Google Pay' were published as 0/0/0 and each reads 2 on www - online WALLET methods in the Deliverect Pay hosted checkout, not card-present acceptance. (4) 'cash discount' reads 12 in the developer corpus and every one is a '"type": "wallet_cash"' LOYALTY-WALLET validation error ('More than one wallet cash discount in the order'), not tender-based pricing. (5) 'surcharge' tokenised reads 4 in the developer corpus but 12 as a stem, and all twelve are order fees - bagFee, smallOrderFee, a 'Take-away' surcharge line in updateBill, and combo overload pricing - none card-keyed. (6) 'offline' in Deliverect's vocabulary is a TENDER CLASS, not connectivity: an 'offline payment gateway' is one where 'the payment happens outside the scope of a commerce integration', and the remaining hits are the POS health-check status enum. (7) 'on-site' reads 61 across 35 www files and 41 across the 25 live ones, and every hit is the navigation item 'On-Site Ordering'; the three help-centre hits are 'Check your on-site internet connection'. (8) 'reseller' reads 27 in the help centre and every one is the OPERATOR'S OWN POS reseller - Revel, PixelPoint, unTill, Zone Soft, IGT Agora, MyChefTool - never a Deliverect dealer. (9) 'retention' on www is 15 hits, of which the marketing ones are CUSTOMER retention ('2x MORE RETENTION') and the developer ones are the phrase 'customer acquisition and retention'. (10) 'next day' reads 1 in the help centre and it is a Glovo menu-publish rate limit. (11) 'archive' reads 17 (30 as a stem) and every hit is menu archiving. (12) 'phone' reads 80 tokenised and 211 as a stem in the developer corpus and every hit is a contact field (phoneNumber, phoneAccessCode, deliveryLocations.phone). (13) 'franchise' reads 1 in the developer corpus and it is an example location-group TAG STRING ('CITY', 'FRANCHISE') in the retail inventory spec. (14) 'settlement' reads 1 in 984 help articles and it is 'the initial settlement sum' in a TRUST definition in a KYC article. BOUND MANIFESTS, all three re-derived this pass and re-measured by the verifier rather than inherited: the developer site's four llms.txt tier manifests (/, /v1.1-restaurants, /v2.0-retail, /v3.0-ordering-experience), 377 documents and 3,707,737 characters on disk, with no 429 and no 404 body in the set; the English help centre's own sitemap, 984 articles and 3,442,391 characters; and www.deliverect.com's sitemap.xml, 1,901 distinct slugs of which 626 are /integrations/ pages, with 35 pages fetched as prose. CORPUS HOLE MEASURED AND DISCLOSED: 10 of those 35 www files are one byte-identical 4,169-byte 404 shell fetched at locale-less slugs (sla-v2, kiosk-terms-conditions, kiosk-pre-contractual-transparency-information, support-as-service-terms-and-conditions, reporting, agentic-commerce, sla, tabesto-by-deliverect, tabesto-terms-conditions, terms-and-conditions/deliverect-financial-reconciliation), so the real www bound is 25 distinct live pages and 328,555 characters; every one of those ten pages IS in the corpus under its live /en/ or /en-us/ form, so nothing is missing, but any www figure quoted over 35 files is inflated by that shell's navigation. https://developers.deliverect.com/v1.1-restaurants/docs/how-to-configure-price-levels.md · retrieved 2026-09-15 adversarially verified