Supercollection Includes¶
The include parameter controls which additional data is fetched and attached to each object in the response. Without it, a supercollection request behaves like a regular collection request.
Each include value does two things:
- Attaches raw Metrc data as a new array on each object (e.g.
labResults,sourceHarvests). - Populates fields on the
metadataobject with extracted, cleaned-up values derived from that raw data.
You can combine multiple include values by repeating the parameter: include=labResults&include=sourceHarvests.
A comma-joined list is not supported, include=labResults,sourceHarvests is one value, not two.
An include value the endpoint does not accept returns 400 Invalid Include, and the response lists the values it does accept:
GET /v2/packages/active/super?licenseNumber=EX-00001&include=labresults
400 Invalid Include
Unrecognized include `labresults`. This endpoint accepts: history, sourceHarvests,
labResultBatches, labResults.
Include values are case-sensitive, so labresults above is rejected while labResults is accepted. The valid values for each endpoint are also published as an enum in the OpenAPI spec, so an API client can read them programmatically rather than copying them from this page.
The same include values work on super reports, which return the whole enriched dataset in one request instead of paging through it, useful for spreadsheet exports. See Super Reports.
A few metadata fields are populated unconditionally (no include required), when the underlying data is available:
- Superpackages:
netWeightOrVolume,netWeightOrVolumeUnitOfMeasure - Superitems:
approvalNumber,itemImages
Superpackage includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
labResults | labResults[] | extractedLabResults, testSamplePackageLabels, labResultPdfs, indexedLabResults, hasTerpeneResults |
labResultBatches | labResultBatches[] | extractedLabResults, testSamplePackageLabels, labResultPdfs, indexedLabResults, hasTerpeneResults |
sourceHarvests | sourceHarvests[] | harvestDates |
history | history[] | initialQuantity, initialQuantityUnitOfMeasure, manifestNumber², destinationFacilityLicenseNumber², destinationFacilityName², transferType² |
² Only present for in-transit packages.
indexedLabResults is a simplified dictionary intended for templating (e.g. on a label). Example access:
{{ package.metadata.indexedLabResults.totalThc.name }} → "Total THC"
{{ package.metadata.indexedLabResults.totalThc.value }} → 12.5
{{ package.metadata.indexedLabResults.totalThc.unit }} → "%"
{{ package.metadata.indexedLabResults.totalThc.full }} → "Total THC: 12.5 %"
Also indexed: totalCbd, topTerpene1, topTerpene2, etc.
topTerpene1 and its siblings rank the package's individual terpenes by descending value. Rollup results a lab reports alongside them -- Total Terpenes, Other Terpenes -- are excluded, since they summarize the individual terpenes rather than being one. Those rollups are still indexed under their own names.
Because the topTerpeneN keys only exist when the package actually has terpene results, metadata.hasTerpeneResults tells you whether any are there. Use it to toggle a whole terpene section rather than probing for topTerpene1:
{% if package.metadata.hasTerpeneResults %}
Terpenes
{{ package.metadata.indexedLabResults.topTerpene1.full }} → "Limonene: 1.2 %"
{{ package.metadata.indexedLabResults.topTerpene2.full }} → "Myrcene: 0.8 %"
{% endif %}
hasTerpeneResults is always present, and is true exactly when topTerpene1 is. A package whose terpenes were all measured at zero still reports true -- those results were reported and are indexed, so the section has rows to show.
Superitem includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
notes | notes[] | (none) |
history | history[] | (none) |
ingredients | ingredients[] | (none) |
images | images[] | itemImages |
approvalNumber and itemImages are populated on every superitem when the data is available, you don't need include=images to get image metadata, only the raw base64/image records themselves.
Supertransfer includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
packages | packages[] | (none) |
transporters | transporters[] | (none) |
Hub supertransfer includes¶
Hub transfers (the ones your license transports) take a different include set:
include | Raw data attached | metadata fields populated |
|---|---|---|
packages | packages[] | (none) |
history | history[] | (none) |
There is deliberately no transporterDetails include. Metrc embeds the driver legs directly in the hub response as shipmentTransporterDetails, so they are present on every record without spending a request:
import requests
response = requests.get(
"https://api.trackandtrace.tools/v2/transfers/hub/super",
headers={"Authorization": f"Bearer {access_token}"},
params={
"licenseNumber": "DIS000038",
"pageSize": 20,
"include": ["packages", "history"],
},
)
for transfer in response.json()["data"]:
# Already present -- no include was needed for this
for leg in transfer["shipmentTransporterDetails"]:
print(transfer["manifestNumber"], leg["lineNumber"], leg["driverName"])
# These two required the includes above
print(f" {len(transfer['packages'])} packages, {len(transfer['history'])} history entries")
Note that transporterFacilityName, driverName, vehicleMake and friends are also flattened onto the transfer itself. When multiVehicle or isLayover is true those top-level fields describe only the first leg, read shipmentTransporterDetails for the rest.
Superharvest includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
history | history[] | (none) |
plants | plants[] | (none) |
packages | packages[] | (none) |
Superplant includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
history | history[] | (none) |
Supersales includes¶
include | Raw data attached | metadata fields populated |
|---|---|---|
transactions | transactions[] | (none) |
Superprocessingjob includes¶
Processing jobs are currently exposed by Metrc in Oregon only.
include | Raw data attached | metadata fields populated |
|---|---|---|
createdPackages | createdPackages[] | (none) |
sourcePackages | sourcePackages[] | (none) |
history | history[] | (none) |
createdPackages are the packages the job produced; sourcePackages are the packages it consumed. Both return the same shape.
A job record also arrives with a packages array already populated. That is Metrc's own partial projection of the source packages, and every entry in it carries "processingJobId": 0 instead of the real job id, so it cannot be joined back to the job it came from. Use include=sourcePackages when you need those packages:
GET https://api.trackandtrace.tools/v2/processingjobs/active/super
?licenseNumber=LIC000001
&include=sourcePackages
{
"number": "0001465709",
"jobTypeName": "Cannabis Extract Job",
"totalQuantity": 237.36,
"isFinished": false,
"sourcePackages": [
{
"processingJobId": 1465709,
"label": "1A4010300002A31000018335",
"quantity": 18.35,
"unitOfMeasureAbbreviation": "lb",
"itemName": "PERMANENT LEE HI FLOWER"
}
],
"metadata": {
"summary": "0001465709 · In progress · Cannabis Extract Job",
"description": "Processing job 0001465709. Type: Cannabis Extract Job. Consumed: 12 packages."
}
}
Next Steps¶
- Back to the endpoint list: Supercollections.
- Use includes in a report instead: Super Reports.