POS API comparison 2026: what Dutchie, Treez, Flowhub, Cova and BLAZE actually expose.

Summary. We read the developer documentation for the five point-of-sale systems most US dispensaries run, plus the partner terms behind them, and built adapters against each. This is what they actually expose — read surfaces, write surfaces, webhooks, rate limits and the contract language — with the gaps named rather than glossed. If you are buying an operations tool, the interesting question is not "does it integrate with my POS" but "integrate how, and what happens to the half the API cannot do."

Read in September 2026. APIs move; the terms move less.

The short version

	Dutchie POS	Treez	Flowhub	Cova	BLAZE
Auth	API key per location, HTTP Basic	client_id + per-location key → 2-hour token	clientId + key headers	OAuth2 via iQmetrix + IntegratorId	Partner key + per-shop key
Webhooks	No	Yes	Not documented	None documented	Partner webhooks
Rate limit	~120 req/min per key	10 TPS per location, fixed	Not documented	Not documented	Not documented
Order write	No create-order API	Create ticket	Not in public API	Create order (TIP/TEP)	Yes
Price write	No	Products CRUD	Via MCP connector	Via catalogue	Confirming
Sandbox	Not documented	Yes, after MNDA	Not documented	Not documented	Partner

The pattern: every one of them reads well and writes narrowly. Any vendor promising to "automate your pricing across any POS" is either doing it through a human step or is not telling you which POS.

Dutchie POS

The biggest footprint — 6,500+ dispensaries claimed, about a third of US stores with a known POS — and the most restrictive write surface of the five.

Reads are genuinely broad: products, inventory with package IDs and lab results, register transactions with line-level package IDs, taxes and returns, customers with types, tags and journal, discounts (v1 and v2), employees, deliveries and drivers, purchase orders. Enough to build a package-level ledger, which is the thing that matters.

Writes are thin. You can POST brands, strains, customers, customer tags and journal entries, drivers, delivery route details and purchase orders. There is no product or price write and no inventory-adjust endpoint in the published path list. So a repricing tool on Dutchie cannot reprice. What it can do is produce the change and ask a person to make it — which is the honest shape, and which we implement as a task: change it in Dutchie, then confirm, with the confirmation coming from the next sync rather than from someone ticking a box.

No webhooks, so "live" means polling. At roughly 120 requests per minute per key that lands around fifteen minutes of latency for a multi-location operator — which is fine, as long as every screen says when it last synced instead of implying now.

Getting a key: a store administrator requests it at Dutchie's API-key page, about three business days, under the Certified Partner Program. Keys are per location and do not expire.

Worth knowing: Dutchie Plus, the headless GraphQL e-commerce API, is being sunset at the end of 2026, replaced by an "E-Commerce Pro" extensions model for certified partners. If a vendor's menu integration is built on Plus, ask what happens in January.

Treez

The most capable API of the five, and the most restrictive terms.

Auth is a partner client_id plus a per-location key exchanged for a two-hour access token; calling for tokens too eagerly can block certification, so token caching is not an optimisation here, it is a requirement.

Reads: customers by a useful set of keys (id, email, phone, driver's licence, name, signup range, last-updated), products and catalogue, stock by location with a group_by_package option and lab results, tickets, invoices, discounts, collections and tags. Writes are the broadest on this list: create and merge customers, create a ticket with a preview step, update status, products CRUD with image upload, inventory adjustments and moves, invoices.

Webhooks exist for customer, ticket, status, product and inventory. The rate limit is 10 transactions per second per location and cannot be raised. There is a sandbox, after an MNDA. Overage is billed at $25 per 100,000 calls above 100,000 per month.

Then the terms, which are the most restrictive we found: no resale, no "enhancing the data files of third parties", no use in a product that competes with Treez, no storing customer data or PII except as expressly permitted, and delete everything on termination.

That last set is worth reading twice if you are evaluating Treez's own AI product, Winston, which launched in June 2026 and — notably — integrates other point-of-sale systems including Dutchie and Cova. A competitor-facing clause in the API terms of the vendor whose competing product you are comparing against is a fact to weigh, not an accusation; but weigh it.

Flowhub

1,000+ dispensaries, $4B+ a year. Auth is a clientId and key pair in headers, issued by Flowhub after the retailer files an API Integration Request naming the partner — retailer-initiated, which is slower to start and cleaner on consent.

The public REST surface is narrower than the others, or at least more narrowly documented: orders by location and the locations list are clear; inventory, customers and employees are not documented publicly. One concrete gap worth knowing before you promise a compliance feature: the Flowhub API omits driver's-licence expiry and medical-card expiry. If your product wants to warn on an expiring patient card, on Flowhub it cannot.

The interesting development is the official MCP connector, launched 1 July 2026: OAuth, inheriting Flowhub's own roles, read and write — prices, deals, room transfers, catalogue, fees — with destructive changes requiring approval and an audit log, and it works with Claude, ChatGPT, Gemini and others. It is the first first-party agent surface from a cannabis POS, and it is more capable than the public REST API it sits beside.

Metrc reporting is automatic, in real time where the state requires it, with re-push of failed sales.

Cova

2,200+ dispensaries across the US and Canada, on iQmetrix infrastructure. Auth is proper OAuth2 against accounts.iqmetrix.net, plus CompanyId, LocationId and an IntegratorId that tags the order source — a small thing that makes attribution honest by construction.

Reads are strong: a DataPlatform catalogue with full or incremental sync including cannabis package details, stock, pricing and taxes; completed orders and refund invoices; customers searchable by modified date; loyalty; promotions; GL; and a Reporting API where the output shape depends on the report you run.

Writes are real: create orders, mark paid, complete orders, customers CRUD, loyalty adjustments, roles and users.

No webhooks documented, so polling again. Rate limits are not published, which is its own kind of answer — build a backoff and find out.

BLAZE

1,500+ businesses across the supply chain, and the owner of Greenline (Canadian POS) and Tymber (e-commerce). Partner key plus a per-shop key. Reads cover products, inventory, transactions and customers; there are partner webhooks; and the write surface reaches orders, products, prices and discounts — though we list the price write as confirming rather than verified, because we have not yet exercised it end to end and will not claim what we have not run.

What this means if you are buying

Four questions that separate a real integration from a logo on a slide:

1. "Which writes are real on my POS?" If the answer is "we support Dutchie" and your workflow is repricing, the honest answer is that a human applies it. Fine — but it should be in the product, not discovered in month two.
2. "How stale can a number be?" Only Treez and BLAZE offer webhooks among these five. Everything else is polling at a documented, sometimes fixed, rate. A product that shows a freshness time on every screen has thought about this. One that shows a number has not.
3. "What do your POS's terms say about my data?" Treez's are explicit about third-party enhancement and competing products. Dutchie's published developer terms we could not find at all — approval checks that partners use data "safely, securely and responsibly", which is a posture rather than a clause.
4. "What happens when the API cannot do it?" This is the real question. Every one of these APIs has holes. A tool that degrades into a clear task for a person is usable. A tool that silently does nothing is worse than no tool.

We publish the per-POS detail, including the limits, on each integration page — because a capability matrix that only lists capabilities is marketing.

---

Sources: published developer documentation for Dutchie POS (api.pos.dutchie.com, Swagger 2.0), Treez (code.treez.io, OpenAPI), Flowhub (Stoplight partner API), Cova (api.covasoft.net) and BLAZE, together with each vendor's partner-programme and developer-terms pages, read September 2026. Store counts are vendor claims; market-share figures are from Cannabiz's 2024 analysis. Where we could not verify a behaviour it is named as unverified above rather than omitted.

Vendor names are trademarks of their owners. BudAlly is an independent product and is not endorsed by or affiliated with any of them.