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.
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.
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
./make.sh docsA 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
./make.sh docs-openapiThere 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.
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)
Run the unit tests in ./test
./make.sh testYou 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 make.sh script for the latest information.