dev-master 2023-01-30 21:05 UTC

This package is auto-updated.

Last update: 2023-01-30 21:06:05 UTC


Provides a common reference and API end-point specification for implementing Cannabis Data Systems.

The world of cannabis regulatory compliance is complex and large. There are hundreds of vendors, each with a common goal but without an API, partial API, or have implemented a unique flavor. The goal of this interface is to provide a basis for data interoperability.

It's our hope that others in the cannabis industry could adopt, in whole or in part, some of the concepts and designs published here. Open Issues, submit PRs, etc and we can build the future we all want to see.

A Common Data Model

An important first step for bringing the industry together is to start talking in with common terms, a second is a common interface.

The OpenTHC API Specification aims to define core parts of this data model and suggested interfaces. The API and data-models are defined in the openapi directory. There are definitions of base-data (ie: lab-metric, product-type in etc. Both are defined with YAML.

Some scripts for processing that YAML into other flavours (JSON, CSV, SQL) are in bin. But, YAML is so easy, one can quickly process with their preferred tools.

A Common Interface

The OpenTHC API Module provides a method for reading/writing to a compatible system. A set of standard base data models for objects in the cannabis industry.

This API was heavily influenced by the Open API Initiative and the Data Transfer Project

We provide some base data examples and JSON schema.


The documentation has been created using a combination of Asciidoc and OpenAPI.

Asciidoc is in doc and the OpenAPI sources are in openapi

./ docs

JSON Schema

A JSON Schema is published for all the objects in this system, they are located in ./webroot/pub/json-schema These files are constructed from the YAML documentation in ./swagger Sample objects are provided in ./json-example

./ docs-openapi

Data Models

There is a bunch of "base" data for this industry, Company, Company_Type, License, License_Type, Product_Type, Variety and Laboratory Metrics. Included in the ./etc directory are pre-populated yaml files describing these common objects. Usage of common, unique identifiers for data-fields we all care about will improve interoperablity.

License Configuration Data

These objects are defined and specific to each Company or License in the system. Includes: Product, Variety, Section, Vehicle (although, Section and Vehicle only exist for backwards compatibility)

License Operational Data

  • Crop / Plant
  • Inventory Lot
  • Lab Sample / Lab Result
  • B2B Transaction and B2B Transaction Items
  • B2C Transaction and B2C Transaction Items


Run the unit tests in ./test

./ test

You could also use Prism for running a mock interface.


This thing depends on Asciidoc/Asciidoctor (Python, Ruby) and some build scripts (JS, PHP, Ruby). Just review the script for the latest information.

See Also