Metrc API Documentation: A Map of the Endpoints

Where the documentation lives

• Interactive API docs: every endpoint with its parameters, request bodies, response schemas, and examples.
• OpenAPI spec: /v2/spec/openapi.json returns the full OpenAPI 3.0.2 specification, ready for code generators and API clients.
• llms.txt: a quickstart written for LLMs and AI agents.
• T3 wiki: task-focused guides such as creating transfers, receiving transfers, and managing plant batches.

Patterns that repeat across the API

Once you recognize a handful of patterns, most of the reference reads the same way:

• Collections such as GET /v2/packages/active return paginated data with page, pageSize, and total, and accept filter, sort, and collectionMask.
• Object endpoints such as /v2/packages/active/{id} fetch one record by its numeric ID.
• Supercollections add /super to a path, attaching related records through include and derived values under metadata.
• Reports add /report or /super/report and return a whole dataset as JSON, CSV, Excel, or a Google Sheet.
• Write endpoints are POST actions such as /v2/packages/create. Many pair with a /inputs endpoint that returns the reference data needed to build the request body, and with /source-* lookups for eligible packages, plants, items, and tags.
• licenseNumber is required on nearly every data endpoint. Only reports accept more than one license per request.

Endpoint map by domain

Packages

Active, on hold, inactive, in transit, and transferred packages, each in collection, super, and report form, plus per-package history, lab results, and source harvests. Write endpoints create packages from existing packages, create testing packages, adjust quantities, add notes, and unfinish packages.

Plants

Vegetative, flowering, mother (active, on hold, and inactive), on hold, and inactive plants, with history, waste, and additives. Write endpoints cover plantings, growth phase changes, location and strain changes, tag assignment and replacement, merges, splits, destruction, waste recording, and creating packages or plant batch packages from plants.

Plant batches

Active, on hold, and inactive plant batches with history. Create batches from packages or other batches, then split, promote, package, move, rename, adjust, re-tag, change strains, destroy, or record waste.

Harvests

Active, on hold, and inactive harvests with their plants, packages, lab results, waste, and history. Create harvests and manicures, create packages from harvests, record or discontinue waste, finish, unfinish, rename, change locations, and manage harvest schedules.

Transfers

Incoming and outgoing transfers (active and inactive), rejected transfers, and hub transfers, with deliveries, transporters, packages, history, and manifest PDFs. Create transfers with POST /v2/transfers/create, using helper endpoints that list destinations, transporters, and eligible packages, then update or void them and manage templates and notes. Receiving has its own receive, approve, reject, and rejected-receive endpoints, and hub transfers support accept, depart, check-in, check-out, arrive, and update.

Tags and tag lists

Available, used, and voided tags, plus current and historical tag orders. Tag lists are T3 lists of tag handles: create them, add entries, bulk-mark entries as scanned (after an RFID sweep, for example), and resolve a list into matching packages, plants, transfers, plant batches, harvests, items, or strains with /v2/tag-lists/{id}/resolve.

Items and strains

The product catalog, with item notes, history, ingredients, images, and photos, plus endpoints to create and discontinue items. Strains can be listed, created, and discontinued.

Locations

Active locations, the rooms and storage areas where inventory lives, available as a collection, a supercollection, and a report.

Sales

Active and inactive sales receipts, the transactions on each receipt, and actions to void or unfinalize a receipt.

Processing jobs

Active and inactive processing jobs. The super form can include the packages a job created, its source packages, and its history.

Lab results

Package lab results, lab result batches, required lab test batches, COA PDFs, and harvest lab results, plus include=labResults on package supercollections. The lab results guide covers these in depth.

Labels

Label template layouts and label content layouts that you can create, read, update, and delete, the built-in values templates can use (such as state warning text), and POST /v2/labels/generate to render print-ready label PDFs from Metrc data.

Reports

/report and /super/report endpoints across nearly every domain above, transfer manifest reports that join packages and transporters, and saved report definitions under /v2/saved-reports. The export guide explains formats, columns, and delivery options.

Account and utilities

Authentication (credentials, secret keys, whoami, and sandbox sessions), licenses, states, permissions, cross-endpoint search, data import CSV templates, and support tickets. The authentication guide explains how to get started.

Reading the docs efficiently

• Start from the Free section. Endpoints that work without T3+, such as authentication, licenses, permissions, and search, are grouped together.
• Check permissions when a write fails. The actions available to you depend on your Metrc admin’s grants, your license class, and your state, and the permissions endpoints report what is allowed.
• Build writes from inputs. When an action has an /inputs endpoint, call it first so the IDs in your request body come from real reference data.
• Read the error body. Errors follow RFC 7807, and each includes a code and a link into the error reference.
• Prune the spec for tools. Filter the spec by path, tag, schema, or parameter to give a code generator or AI agent only what it needs.

# Everything tagged Packages, plus the schemas those paths reference
GET https://api.trackandtrace.tools/v2/spec/openapi.json?tag=Packages

# A single endpoint and its dependencies
GET https://api.trackandtrace.tools/v2/spec/openapi.json?path=/v2/transfers/create

If you are deciding whether to build on this API at all, the overview of why teams build on the T3 API covers state coverage, Super Reports, and common use cases.