Sessions x Dutchie - Issue Log for the Dutchie team

Latest: September 28, 2026 - Dutchie's threshold explanation, tested live

What Dutchie said (Kylie, Sep 28): API response times are healthy; the add-to-cart rejections on the last remaining unit come from the minimum inventory threshold on each menu (a threshold of 1 reserves the last unit, so the online quantity is 0), and because thresholds vary by store the behaviour varies by store. Engineering shipped structured error codes (extensions.code = PRODUCT_UNAVAILABLE / INSUFFICIENT_QUANTITY). POS-to-menu sync lag and real-time inventory locking are a separate, still-open initiative. Dutchie is compiling the per-location threshold list and has passed the "net purchasable quantity in the menu API" request to its API product team.
What we verified the same day, against the Plus API: the structured codes are live (over-ask returns INSUFFICIENT_QUANTITY / "Total exceeds available quantity"; an unknown product returns PRODUCT_UNAVAILABLE / "Product not found"). And at Aurora (Bayview), Orillia, Timmins, Cambridge (Hespeler) and North York we added the last unit of 15 different SKUs (menu quantity 1) to test carts, 16 adds in two rounds: 16 of 16 succeeded (two further last-unit attempts at Cambridge were stopped only by the legal 30 g cart limit, not by quantity). So at these five stores the last unit is purchasable today and the threshold is effectively 0, which matches Dutchie's own note that Aurora is set to 0 everywhere.
Why that matters: three of those stores (Orillia Sep 17, North York Sep 22, Cambridge Sep 24) rejected qty-1 adds with "Total exceeds available quantity" while Dutchie's own menu, read by our server seconds earlier, showed the item in stock. With the threshold at 0 that cannot be the threshold; it is the menu lagging the POS. That is the open sync initiative, not a settings problem on our side.
Since the fix shipped (Sep 13-28): 20 "Validation errors" rejections across 9 carts at 6 stores, 14 "Not Found" across 13 carts at 8 stores, 58 menu-vs-checkout price disagreements across 41 carts at 20 stores. The error shape improved; the rejection rate did not change.
Threshold advice, applied carefully: sessions.ca already hides any item with a single unit left at every store except Welland and Port Colborne, whose inventory is mostly singles and who sell them online on purpose. Setting a Dutchie threshold of 1 at those two stores would stop those sales at checkout; at the other stores it changes nothing customers can see.
Asks: the per-location threshold list (promised); the per-SKU threshold, or the net purchasable quantity, in the menu API response (Darryl's ask, so we can show exactly what checkout will accept); and a date for the POS-to-menu sync work.
Separate and still unanswered - request 701112: at six locations 30 to 47 percent of in-stock Cova products never appear on the Dutchie menu at all (re-measured Sep 28: 1,315 of 3,274; control store 3.4 percent). Dutchie's Sep 28 reply on that thread covered the threshold behaviour above, which does not apply to products that are absent from the menu. Evidence, per-product CSV and the example to trace: helps.sessions.ca/dutchie/menu-gap/.

September 10, 2026 checkout outage - Dutchie side

What happened: the Dutchie Plus API (plus.dutchie.com) returned HTTP 503 to every checkout create and add-to-cart call from 19:58 to 20:34 UTC (3:58 pm to 4:34 pm ET). It self-recovered; no status-page post was seen.
Why it is on Dutchie's side: the 503 was returned on all three independent network paths we use (direct, our allowlisted egress 77.42.66.58, and a third fallback route). Sessions made no change to its checkout path between September 4 and September 10, and the same stores checked out normally before 19:58 and after 20:34.
Customer impact: 40 failed checkout creates at 8 stores (12 customer sessions), plus 4 add-to-cart rejections at 3 more stores. Our automatic fallback engaged 221 times during the window.
Ask: an incident summary (cause, scope, fix), and a status page or incident channel we can subscribe to for Plus API availability.

Where things stand today

Customer-visible impact measured on sessions.ca from our order-error ledger and Google Analytics. "Dutchie-side" means the rejection came from the Dutchie API for an item Dutchie's own menu showed as in stock at the same moment. Purchase-limit blocks (legal 30 g cap) and anything caused by Sessions are excluded.

99.94%

August 1-31: checkouts that reached Dutchie cleanly. 173,805 sessions; 97 Dutchie-side blocked add-to-carts across 60 carts at 28 stores (0.056%); 2 blocks caused by Sessions.

99.76%

July 16 - August 15: 130,753 sessions; 188 Dutchie-side blocks at 28 stores; 124 Sessions-side (70 of them from one 14-minute outage on July 28 that was ours, and is listed on our own ledger, not here).

3-4 / day

August 16-31 run-rate of Dutchie-side blocked add-to-carts (54 across 21 stores), plus 91 rejections that cleared on retry and 30 menu-vs-checkout price disagreements.

3 open

Engineering items still with Dutchie: the POS-to-menu sync lag behind the add-to-cart / price family (686841 / 687019; the Sep 13 error-code release did not change the rejection rate), the Sep 10 outage RCA, and the Cova-to-menu product gap at six locations (701112, evidence page).

Raw API rejections, month by month

Straight from our server ledger (every Dutchie response we log, including retries, so these are higher than the customer-visible numbers above). Ledger starts July 17, 2026; September is split at the Sep 13 structured-error-code release.

Month	"Validation errors" on in-stock item	"Not Found" on item the menu served	Menu vs checkout price mismatch	Checkout create failed (API down)
July (from Jul 17)	103 rejections, 16 stores	181 rejections, 29 stores	273 events / 115 carts, 30 stores	0 Dutchie-side (the 70 on Jul 28 were ours)
August	178 rejections, 34 stores	71 rejections, 26 stores	54 events / 44 carts, 23 stores	0
September 1-12	73 rejections, 17 stores	33 rejections, 12 stores	27 events / 23 carts, 16 stores	40 (Sep 10, 8 stores) + 4 add-to-cart 503s
September 13-28 (after the error-code release)	20 rejections / 9 carts, 6 stores	14 rejections / 13 carts, 8 stores	58 events / 41 carts, 20 stores	0

"Validation errors" carries the Dutchie error detail "Total exceeds available quantity" (verified Sep 13, 2026): the item is on the menu with stock, but at the moment of checkout Dutchie's available count for it is below what the customer asked for - sold in store since the menu snapshot, held by another open online order, or under the store's online threshold. Dutchie described the single-unit case on Aug 18 and attributed it to the threshold setting on Sep 28; our Sep 28 live test (16 of 16 last-unit adds accepted at five stores) shows the threshold is 0 at the stores that rejected, so the remaining cause is the menu lagging the POS. "Not Found" carries the detail "Variant not found" or "Product not found": the product or option the menu served minutes earlier no longer resolves at checkout. Price mismatch means the checkout line price differed from the menu price for the same product at the same moment; retrying does not clear it and it persists for minutes up to about an hour.

What we are asking Dutchie for right now

687019 / 686841 - what shipped and what is left. Shipped by Sep 13: structured extensions.code on addItem rejections (INSUFFICIENT_QUANTITY, PRODUCT_UNAVAILABLE), verified live Sep 28. Still open: the POS-to-menu sync lag behind the rejections themselves (Dutchie: "separate, dedicated engineering initiative, actively open"). Ask: a date, and the per-location threshold list Dutchie is compiling.
Correlation header. Since Aug 13 we have asked which request or response header we should log so Dutchie can trace a failure server-side. Name it and we will log it on every failure from that day.
Sep 10 outage. Root cause, scope (was it all Plus tenants?), and the fix. Plus a status page or incident channel for the Plus API.
Availability at checkout. Expose the checkout-side available count in the menu API: either the per-SKU threshold next to the quantity (inventory_quantity, inventory_threshold, inventory_available, as Darryl asked on Sep 28) or the net purchasable quantity, or a change feed, so we can cap or hide an item before the customer hits "Total exceeds available quantity". Dutchie has passed this to its API product team (Sep 28).
Menu-to-checkout consistency. Why the checkout price and menu price disagree for the same product at the same moment, and why a delisted product keeps being served on the menu for minutes to hours.
701112 - in-stock Cova products missing from six menus. Amherstburg, Brantford West Brant, Cambridge Fiddlesticks, London Kellogg, Sault Ste Marie Hillside and Thunder Bay Red River: 30 to 47 percent of in-stock Cova products are not on the Dutchie menu (Sep 25, unchanged Sep 28). Ask: check the Cova integration for these six retailers, tell us why products are not created or published, whether a re-sync or import is needed on Dutchie's side, and how long. Per-product list and a traceable example: /dutchie/menu-gap/.

Dutchie-side issue log, newest first

Every item here was either confirmed by Dutchie, reproduced against the Dutchie API with Sessions' side held constant, or answered by Dutchie as a platform limitation. Ticket numbers are Dutchie support request IDs.

Date	Ref	What happened	Evidence and impact	Status / ask
Sep 28	686841 / 687019	Dutchie's position: API latency is healthy; last-unit add-to-cart rejections come from the per-menu minimum inventory threshold (1 reserves the last unit); thresholds vary by store; engineering shipped structured error codes; sync lag is a separate open initiative. Recommends standardising thresholds and is compiling the per-location list.	Tested live the same day: INSUFFICIENT_QUANTITY and PRODUCT_UNAVAILABLE codes confirmed. Last-unit adds (menu quantity 1) accepted 16 of 16 at Aurora, Orillia, Timmins, Cambridge (Hespeler) and North York, so the threshold is 0 at the stores that produced the Sep 17-24 rejections; those rejections happened while the menu, read seconds earlier, showed stock. Since Sep 13: 20 validation rejections (9 carts, 6 stores), 14 Not Found (13 carts, 8 stores), 58 price mismatches (41 carts, 20 stores).	Open Ask: threshold list, per-SKU threshold or net quantity in the menu API, a date for the sync work.
Sep 28	701112	Dutchie's reply on the 701112 thread restated the minimum-threshold behaviour from 685427 / 686841 and did not address the missing products. Sessions re-measured the six locations against a fresh Cova snapshot the same day.	Unchanged: 1,315 of 3,274 in-stock Cova products missing across the six locations (Amherstburg 284 of 701, West Brant 168 of 356, Fiddlesticks 203 of 447, Kellogg 124 of 267, Hillside 303 of 726, Red River 233 of 777). Control store Cambridge (Hespeler): 26 of 760 (3.4 percent). Four of the five Kolab Project SKUs from the Sep 25 example are still absent at Amherstburg. Evidence and per-product CSV: /dutchie/menu-gap/.	Open Ask: an answer on the missing products specifically, not the threshold.
Sep 25	701112	Sessions opened request 701112: at six locations a large share of in-stock Cova products never appear on the Dutchie menu (Plus API and consumer menu). Spreadsheet with every missing product, Cova SKU and ProductId attached.	Amherstburg 282 of 704 (40 percent), West Brant 177 of 382 (46), Fiddlesticks 207 of 465 (45), Kellogg 121 of 271 (45), Hillside 292 of 739 (40), Red River 251 of 722 (35). Other locations 2 to 5 percent. Ruled out: archived products, the quantity threshold, Sessions' own cache. Same Cova ProductIds are live on menus at other locations.	Open Ask: Cova integration check for the six retailers; re-sync or import; ETA.
Sep 22-24	686841 family	North York (Back Forty Galactic Jack, Sep 22) and Cambridge (Back Forty Chemzilla, Sep 24): qty-1 add-to-cart rejected with "Validation errors" / "Total exceeds available quantity" after our server had just read the item as in stock on Dutchie's menu; the paced retry 1.2 s later failed identically.	Both stores accepted last-unit adds on Sep 28, so no threshold was in play. Fresh examples of the menu-lags-POS case for the sync initiative.	Open Rolled into 687019.
Sep 10	outage	Plus API returned HTTP 503 to checkout create and add-to-cart calls for 36 minutes (19:58-20:34 UTC).	40 checkout create failures at 8 stores (12 customer sessions); 4 add-to-cart 503s at 3 stores; 221 automatic fallback engagements, all 503. Same result on every network path. No Sessions deploy on the checkout path since Sep 4.	Open Ask: incident summary and a status channel.
Sep 10	686841 family	Timmins (Park Road): one SKU rejected at checkout 8 times across 7 different customer sessions on the same day while the menu showed it in stock.	All 8 were "Validation errors" (Dutchie detail: total exceeds available quantity) on a SKU the menu showed in stock - the family documented on 686841. Logged as a fresh example for the engineering fix.	Open Rolled into 687019.
Sep 1	687019	Dutchie update on the escalation of 686841: "this issue is in the works, our engineering team is actively building a fix."	First confirmation that the add-to-cart / price family is an engineering item on Dutchie's side. No scope, ticket or ETA given.	Pending Dutchie Ask: scope, cases covered, ETA.
Sep 1	internal #11391	Store report: items with on-hand quantity above the ecommerce threshold missing from the online menu (four SKUs at one store: 8, 16, 12 and 6 units on hand).	Products present in POS with stock above threshold but not returned by the consumer menu. Being verified before it is raised as a ticket.	Logged Will raise with examples if it repeats.
Aug 24	CSM call	30-minute review with our Dutchie CSM covering 686841, 685427 and the API gaps below.	Agreed: Sessions keeps a running evidence record; Dutchie to come back with root cause per case.	Pending Dutchie
Aug 18-19	686841	Dutchie (Max, Product Support) confirmed a known limitation: "Dutchie Plus will block a checkout when a product has only 1 unit left in stock." Asked for more examples per case; Sessions replied the same night with counts and timestamps.	Since Jul 25: 83 last-unit blocks, 37 "Not Found" rejections across 13 days, 60 price mismatches. Examples with retailer IDs and UTC timestamps supplied for Port Perry, Orillia, Kenora, Welland, Timmins, Elliot Lake, Brantford, Waterloo, Stoney Creek, Cambridge, North York.	Pending Dutchie No reply on root cause for Not Found or price mismatch since Aug 18.
Aug 14	685427	Dutchie's networking team confirmed the allowlisting of our egress IP 77.42.66.58; Sessions confirmed it working on Aug 19.	Direct authenticated calls from that IP succeed consistently since Aug 19. IPv6 requests still receive 403, so we pin IPv4.	Resolved Ask: allow IPv6 or document that it is unsupported.
Aug 14	687078	"No inventory available" shown in COVA at the register when ringing up an online order (Etobicoke Albion; same family seen chain-wide).	Website side: Albion alone had 6 rejected add-to-carts and 6 price inconsistencies since Jul 23; 37 stores show the same family. Asked Dutchie to link this with 686841 as one inventory-sync race.	Open Ask: link to 686841 / 687019.
Aug 14	686982, 686984, 686985	Three further requests opened by Sessions the same morning; confirmations received.	Being matched to their original requests; will be merged into this log once Dutchie replies.	Pending Dutchie
Aug 13	686841	Opened: recurring add-to-cart failures ("Validation errors" and "Not Found") on in-stock items, plus checkout prices disagreeing with menu prices.	Jul 23 - Aug 13: 286 rejected add-to-carts across 37 stores; 139 price inconsistencies. Stoney Creek example: identical request rejected twice at 17:28 UTC and accepted at 23:00 UTC the same day (same input, opposite outcomes). Full request/response pairs sent the same evening.	Open Escalated as 687019.
Aug 10	685480	Post-checkout return URL updated to sessions.ca/order-completed for all locations.	Completed by Dutchie the same day. Thank you.	Closed
Aug 10	685427	Connectivity: authenticated API calls from our server intermittently refused (403). Dutchie escalated to its networking engineering team.	Sessions could only reach the API reliably through a fallback route until the allowlist landed. See Aug 14 entry for the resolution.	Resolved Aug 19
Jul 18-20	678128	One store's menu briefly showed wrong or missing products.	The consumer menu API returned an incomplete product set for that dispensary during the window; self-resolved. Dutchie found no change on its side; Sessions confirmed resolved Jul 20 with timestamps.	Resolved Cause never identified.
Jul 16-17	internal #11052, #11062	Timmins: delivery orders showed a "please pick up" message with delivery enabled (store back-end configuration). River Bend: phone orders not appearing store-side.	Both traced to Dutchie-side configuration or behaviour; River Bend fixed chain-wide, Timmins reconfirmed.	Closed
Jul 8	674639	Can an order placed through the website be cancelled or modified after submission?	Dutchie: not possible today, no cancel/modify feature exists.	Limitation Ask: roadmap for cancel/modify.
Jun 4 - Aug 14	663272	Request to allowlist Sessions' server so it can reach the Dutchie API directly.	Dutchie implemented it in July but did not communicate back; Sessions learned on Aug 14 and retested the same day.	Resolved Ask: confirm when a request is completed.

Platform limitations Sessions works around

Not tickets, but behaviours of the Dutchie Plus and consumer menu APIs that shape what customers see. Each one costs us engineering time or sales; each would be a welcome roadmap item.

Area	Behaviour	Effect on Sessions	Ask
Availability at checkout	The menu shows an item with stock; addItem rejects it with "Total exceeds available quantity" because Dutchie's checkout-side count has moved (in-store sale, hold from another open order, online threshold). Single-unit case confirmed Aug 18; on Sep 28 Dutchie attributed it to the threshold setting, and the same-day live test showed the rejecting stores have the threshold at 0.	Customer sees an in-stock item, then a checkout error. 73 rejections at 17 stores in the first 12 days of September; 31 of 45 affected carts still completed without the item.	Expose the checkout-side count in the menu API or a change feed so we can stop the customer before the wall.
Hosted checkout TLS	connect.dutchiemenus.com, which every store checkout hostname under sessions.ca points at, still accepts TLS 1.0 and 1.1 (verified Sep 13, 2026).	49 security findings raised against our domain in one scan; weaker transport for customers on the checkout page than on the rest of sessions.ca, which is TLS 1.2 minimum.	Enforce TLS 1.2 minimum on connect.dutchiemenus.com.
Menu vs checkout	Menu keeps serving delisted products; checkout price can differ from menu price for the same product at the same moment.	"Not Found" at checkout; price disagreements that retry does not clear.	Single source of truth or a change feed we can subscribe to.
Search	Text search on the consumer menu returns at most 20 hits.	We index the full menu ourselves to give customers complete search.	Paginated search.
Variant options	Variant option carries total weight, not pack format (a 3 x 0.5 g pre-roll and a 1.5 g pre-roll look identical).	We derive pack format from names to build pre-roll and edible filters.	Expose pack count and unit size.
Price summary	priceSummary.subtotal is pre-discount.	Extra reconciliation logic so the cart total we show matches what the customer pays.	Post-discount subtotal field.
Checkout URL	Some stores' checkout redirect URLs are issued as http:// (Timmins).	We upgrade to https:// ourselves.	Issue https:// everywhere.
Provisioning	Some locations are not provisioned for Plus checkout (Fiddlesticks, Cambridge as of Aug 2026).	Customers are sent to the store's Dutchie menu instead of a native checkout.	Provision all locations.
Brand data	Brand profile on some products is a different company (example: Nugz shown as Amaze NUGZ).	We override brand text by hand.	Fix at source.
IPv6	Requests over IPv6 receive 403 even from allowlisted networks.	We pin IPv4.	Support IPv6 or document it.
Orders	No cancel/modify after submission; no order-status API; no Plus API status page or incident channel.	Stores handle cancellations by phone; we cannot show order progress; outages are discovered by our own monitoring.	Order status API, cancel/modify, status page.
Online payment	Online payment option reviewed Aug 2026: delivery-only, and no second-factor step in the flow.	Not enabled for Sessions customers.	Pickup support and a stronger auth step.

How Sessions measures this

Every call from sessions.ca to the Dutchie API is logged server-side with the Dutchie response body, product, retailer ID and UTC timestamp. Since Sep 13, 2026 the ledger also stores Dutchie's error detail (extensions.errors[0].detail) for every rejection, so each row says whether it was an availability race or an id/option mismatch. This is the ledger the counts above come from. Raw request/response pairs for any row are available on request.
A rejection is counted as Dutchie-side only when Dutchie's own consumer menu showed the item in stock at the same moment and Sessions' side was unchanged. Purchase-limit blocks (the legal 30 g cap) are excluded because they are working as designed.
Anything caused by Sessions - deploys, cache staleness, our own transport changes - is tracked on a separate internal ledger and is deliberately not counted here.
Success rate = checkouts that reached Dutchie without a Dutchie-side rejection, over customer sessions that attempted checkout, from Google Analytics.

Contacts

Sessions: Ravi (ravi@sessions.ca) for anything technical; Sophie (sophie@sessions.ca) for account and store operations.
Dutchie: CSM Kylie Austin; Product Support tickets via support@dutchie.com and apisupport@dutchie.com.
This page is updated whenever a ticket moves. Evidence page for request 701112: Cova to Dutchie menu gap at six locations. Companion pages for Sessions' internal use: Dutchie Ticket Register and Cart Breakages Ledger.