One brand · two licenses · one audit trail

METRC workflow for manufacturing + distribution

A black-box-to-glass-box map for moving cannabis product legally from manufacturing into distribution, through testing, QA, transfer manifests, and retailer delivery — while keeping the software aligned with METRC as the legal source of truth.

Manufacturing Distribution Track & Trace Audit Logs
01

Two licenses, two legal worlds

The app should treat manufacturing and distribution as separate legal contexts even when the same brand owns both.

Manufacturing license

Makes product
  • Accepts incoming source material or bulk cannabis products.
  • Creates manufacturing batches, production records, yields, waste, and new packages.
  • Handles extraction, infusion, blending, packaging, labeling, rework, and internal quality checks.
  • Transfers finished goods to the distribution license with proper package UIDs and manifests.

Distribution license

Moves product
  • Receives finished goods from manufacturing or other licensed businesses.
  • Coordinates lab testing, COAs, QA review, inventory release, holds, and rejections.
  • Creates wholesale transfers and transport manifests to retailers or other licensees.
  • Controls sellable inventory, retailer delivery, returns, destruction, and reconciliation.
02

Product flow

Click the filters to isolate manufacturing, distribution, QA, or legal gate steps.

1. Incoming material

Manufacturer receives source material or bulk product from a licensed source.

MFG + METRC

2. Accept transfer

Incoming transfer is accepted in METRC under the manufacturing facility/license.

UID control

3. Production batch

Extraction, infusion, blending, packaging, labeling, yield, and waste are recorded.

Batch record

6. Distro receives

Distributor accepts the packages, checks counts, labels, and package status.

Receive

7. Lab sample / COA

Testing workflow links batch, lab sample, COA, release status, and documents.

Testing

8. QA review

Distributor verifies COA, packaging, label data, weight/count, and event history.

Release gate

9. Sellable inventory

Inventory becomes available only when local records and METRC package state agree.

Reconciled
03

Data flow

Your software should be the workflow brain, not a shadow version of METRC.

Correct architecture

Local app UI: dashboards, workflows, approvals, alerts.
Local compliance DB: snapshots, audit logs, sync runs, exceptions.
METRC API: legal source of truth for packages, transfers, tests, and events.

Reconciliation mindset

  • Show local count, METRC count, sync timestamp, and status.
  • Block transfers when package status, testing status, hold status, or quantity does not match.
  • Use overlap windows when syncing LastModified data to avoid clock drift misses.
  • Keep every risky action in draft → review → approved → submitted → accepted state.
04

METRC API surface

Core endpoint groups your custom app would likely touch. Search by keyword like packages, transfers, items, lab, or transporters.

Setup / identity

GET /facilities/v2/ GET /employees/v2/ GET /employees/v2/permissions

Items / products

GET /items/v2/active GET /items/v2/inactive GET /items/v2/categories GET /items/v2/brands POST /items/v2/ PUT /items/v2/

Locations

GET /locations/v2/active POST /locations/v2/ PUT /locations/v2/ DELETE /locations/v2/{id}

Tags

GET /tags/v2/package/available GET /tags/v2/plant/available GET /tags/v2/staged

Packages / inventory

GET /packages/v2/active GET /packages/v2/inactive GET /packages/v2/onhold GET /packages/v2/intransit GET /packages/v2/{label} POST /packages/v2/ POST /packages/v2/testing POST /packages/v2/adjust PUT /packages/v2/location PUT /packages/v2/finish

Lab tests / COAs

GET /labtests/v2/states GET /labtests/v2/batches GET /labtests/v2/types GET /labtests/v2/results GET /labtests/v2/labtestdocument/{id} POST /labtests/v2/record PUT /labtests/v2/results/release

Transfers / manifests

GET /transfers/v2/incoming GET /transfers/v2/outgoing GET /transfers/v2/rejected GET /transfers/v2/{id}/deliveries GET /transfers/v2/deliveries/{id}/packages GET /transfers/v2/manifest/{id}/pdf POST /transfers/v2/templates/outgoing PUT /transfers/v2/templates/outgoing

Transporters

GET /transporters/v2/drivers POST /transporters/v2/drivers PUT /transporters/v2/drivers DELETE /transporters/v2/drivers/{id} GET /transporters/v2/vehicles POST /transporters/v2/vehicles PUT /transporters/v2/vehicles
06

Integrator / LLC protections

Build like a software vendor, not like the licensee’s compliance department.

Do not become the legal operator.

Your app can assist, validate, queue, and submit. The licensee should remain responsible for compliance decisions, METRC users, approvals, and regulated operations.

Business setup
LLC, EIN, business bank account, professional domain email, signed MSA/SOW, NDA, privacy policy, terms, and cannabis attorney review.
Insurance
Cyber liability, technology E&O / professional liability, and general liability. Consider higher limits if handling production credentials or compliance records.
API access
Use your integrator/vendor access where required. Customer provides user API keys. Never ask for shared passwords. Never hardcode production credentials.
Contract disclaimers
State that the customer remains responsible for legal compliance, regulatory submissions, user permissions, review/approval, and maintaining accurate records.
Security
Encrypt keys at rest, restrict admin access, use MFA, separate dev/staging/prod, avoid logging sensitive data, and keep incident/backup/restore procedures.
07

Suggested database map

Tables that help the app explain what happened, who did it, why it happened, and what METRC returned.

companies licenses facilities users roles metrc_credentials_encrypted items locations package_snapshots package_lineage manufacturing_batches batch_production_records ingredients waste_events lab_samples lab_results coa_documents qa_reviews transfers transfer_packages drivers vehicles sync_runs metrc_api_requests metrc_api_response_hashes compliance_events reconciliation_reports exceptions

Build the UI friendly. Build the backend paranoid.

Every regulated action should have a human-readable reason, a user, a license context, a METRC endpoint, a response, and an audit event that cannot be quietly rewritten.