If you are building or buying a cannabis POS, METRC is the compliance layer you cannot avoid in most U.S. markets. We have integrated with METRC in California, Colorado, Nevada, Michigan, Illinois, New York, and a handful of emerging states. The API looks straightforward on paper, but the real complexity lives in the state-by-state variants, permission models, and operational edge cases that break integrations at 2 a.m. when a manifest fails to close.
What METRC actually is (and is not)
METRC is a traceability system operated by Franwell. It tracks cannabis plants and products from seed to sale using unique identifiers: package tags, plant tags, and lab result certificates. Each state contracts with Franwell to run its own METRC instance, which means the API base URL, data fields, and business rules differ by jurisdiction. METRC is not a POS. It is not an inventory management system. It is a compliance reporting pipe, and treating it like anything else is where most integrations fail.
Per-state METRC variants that matter
California (DCC oversight)
California METRC requires daily sales reporting and manifest completion before a delivery can leave the premises. The DCC expects explicit transfer types — wholesale, retail, or return — and the API enforces recipient license validation on every transfer. If your integration skips recipient validation, the transfer will reject with a generic 400 that takes hours to trace.
Colorado (MED oversight)
Colorado METRC uses a different audit-log format than California. The MED requires timestamped logs for every inventory adjustment, including the reason code. If your POS does not store reason codes locally before pushing to METRC, you will have to reconstruct them during an audit.
Michigan and Illinois
Both states run METRC but enforce purchase limits tied to the Cannabis Regulation and Taxation Act (CRTA) in Illinois and equivalent rules in Michigan. The API does not enforce these limits — your POS must. That means tracking rolling 30-day grams across all transactions for every customer.
Common integration pitfalls
Rate limits
METRC API rate limits are not documented consistently per state. In California, we have observed effective limits around 100 requests per minute for sales endpoints. If you are syncing inventory in real time during a busy Saturday, you will hit the wall. We implement token-bucket backoff with jitter and queue non-critical syncs for off-peak windows.
License type permissions
A dispensary license cannot create packages. A cultivator license cannot record retail sales. A microbusiness license has hybrid permissions that vary by state. Your integration must validate the license type before calling an endpoint, or METRC will return a 403 with a message like "License does not have permission to perform this action."
Native integration versus middleware
Native integration means your POS calls METRC APIs directly from its backend. You own the credentials, the retry logic, the error handling, and the mapping. The advantage is control and latency. The disadvantage is engineering cost. Middleware integration means a third-party service sits between your POS and METRC. The advantage is faster time to market. The disadvantage is an additional dependency, latency, and a support ticket dance when something breaks.
We chose native integration for DubLedger because our operators need sub-second checkout and because we want direct observability into every METRC call. If you are evaluating a POS, ask the vendor which architecture they use and whether they expose METRC call logs to you. If the answer is no, you are flying blind during an audit.