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

• Use International System of Units for weight and volume values.
• Use ISO-8601 for date and time values.

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 docs

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

./make.sh docs-openapi

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.

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)

• 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

./make.sh 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 make.sh script for the latest information.

• https://openapis.org/
• https://asciidoctor.org/
• https://redoc.ly/redoc/
• https://jsonschema.net/#/
• https://www.jsonschemavalidator.net/
• https://github.com/epoberezkin/ajv
• https://github.com/zircote/swagger-php
• https://github.com/jensoleg/swagger-ui
• https://github.com/E96/swagger2slate
• How to Design the APIs of Tomorrow
• Ask HN: What is your go-to example for a good REST API?
• Ask HN: What are good reads for designing APIs?
• Microsoft REST API Guidelines