We are Metrc API certified

My first week at Simplifya was spent uncovering the nuances of the Metrc API. The goal was for us as a company to become a validated integrator and in order to do that we had to complete the Metrc API Proficiency Evaluation, a series of 33 tasks designed to show competence with the API. We submitted our evaluation on February 14 and received notice that we had been validated on March 1! Here’s a high-level explanation of what it took to make it work.

By the way, Metrc is an acronym for Marijuana Enforcement, Tracking, and Compliance. For some strange reason, the makers of Metrc decided not to show it as METRC, which would make more sense. They show it as Metrc, so we reluctantly show it as Metrc too.

Why become a Validated Integrator?

In a word, credibility. We are now listed on the Metrc website as a Validated Integrator. When prospective clients ask if we’re certified or validated, we get a boost in legitimacy when we can refer them to the short list of validated integrators (click the download link at the bottom of the page). I should point out that Metrc has two types of integrators:

1. Registered Integrators. Vendors on this list have received Franwell training, instructions, and signed a Marijuana Enforcement Division (MED) Confidentiality and User Agreement. Registered Integrators have been provided with access to the Metrc API to upload sales data. Some examples include Compliant Cannabis, Leaflink, and Tradiv.
2. Validated Integrators. Vendors on this list have met requirements to be considered “Registered” and have taken the additional step of demonstrating their ability to perform the functions specified in the proficiency evaluation. Validated Integrators have full access to the Metrc API, meaning they can send and receive data for the areas in which they are validated. We are validated in all areas except lab testing. At the time of this writing, there were only 15 validated integrators for Colorado. Some examples include Adilas, Flowhub, and Green Marimba.

Most importantly, we have access to client seed-to-sale data. This has the potential to strengthen our service offering by providing an even clearer picture of MJB compliance.

How the METRC API works

Note: For a primer on APIs, skip to the last section of this post.

In order to complete the proficiency evaluation, we were given a test API key. When matched with a test API key from Frosted Leaf, our partner in the validation process, this gave us access to test data. The types of data include:

• Harvests
• Items
• Packages
• Plant batches
• Plants
• Rooms
• Sales
• Strains
• Transfers

This list includes all of the data types available in the METRC API except for lab testing, a category that is reserved for labs that provide cannabinoid profiles and residual solvent reports, perform terpene analysis and microbial testing, etc.

Authorization: Using our API key

Every time we call to the API, we have to prove who we are. For that we need two API keys: one that is unique to the marijuana business and one that is unique to us.

To start the validation process, Rick obtained a test API key from Frosted Leaf. Having a client key opens us up to information they’ve recorded in Metrc. It doesn’t allow us to see any data from other companies. If we wanted info on another client, we’d need to approach that business and get their API key.

Before we could get even a single record, I needed to pass data to Metrc exactly as their developers requested it. That’s to say, if I wanted to add or get information, I had to make sure I wasn’t forgetting any fields or including some that didn’t belong. It was a lot of trial and error, because even things as small as a missed comma would result in an error.

Adding in license data

Metrc has a total of 89 open endpoints and all but 22 of them require us to pass a license number through (in addition to the API keys). Why? Because when we are pulling information, we’re only looking at data pertaining to one license at a time. So it’s a way of filtering down the data.

As an example, let’s say we wanted all sales receipts for fake retail store 402R-9998. If we called the API and received 111 different results, those results would be unique to that specific license. So when we change the license to retail store 402R-9999, we’d have no receipts that could be found in both calls.

IDs and Labels

With few exceptions, data entered into Metrc has two unique identifiers. The first is an ID. Each ID is assigned when a new object is created, and adds one to the ID of the last created object. What’s an object? It’s a broad way of referring to a piece of data. When I say object, I’m referring to a piece of data we can manipulate that has it’s own characteristics (like an ID or a name).

The second is a Label. Labels are a semi-random series of numbers and letters assigned by the user when inputting information. So when I was adding basic information for a new package (item, name, quantity, date, etc.), I would also give it a 24-digit label, such as 1A4000500266EEEA00000132. There was some pattern to labels though, as different types of data shared a similar order of letters and numbers (so only the five or six digits to the far right would be changing).

Retrieving (and understanding) the data

If you read the API primer, I mentioned the API sends us JSON (JavaScript Object Notation) data back whenever we successfully complete a request. Since JSON is hard for the human eye to read (see image below), I had to parse it.

To successfully complete everything the test asked (close to 50 requests in all), I needed a lightweight way to change endpoints and enter data – two things necessary for EVERY request. I created a mini-software program to spit the API data (or error messages) onto my command line. The command line is a programmer-friendly way of interacting with a computer.

Without that mini-program, it would have been like having to enter your credit card information 50 times successfully while needing to have a unique credit card number for each interaction. On top of that, you start with limited knowledge of how all the fields fit together (many of which are dependent upon one another).

Metrc API calls: An extended list

For reference, here’s a larger (but far from extensive) rundown of things we were asked to do with the Metrc API – each of which required a different endpoint:

• Create a new room
• Create a new strain
• Edit an existing strain
• Create a plant batch
• Retrieve items
• Finish an existing package
• Remove waste from a harvest
• Change the growth phase of a batch of plants
• Manicure plants
• Create a single harvest from two plants
• Log sales transactions on a given date

Next Steps: Getting the real data

Now that we’re a validated integrator with access to live data, we just need to get the production API key from Frosted Leaf (or any other client). With some adjustments to the code I’ve already written, I’ll be able to port all of this data to CSV. The idea is to see all of the data points available to us, and from there we can analyze it as we see fit.

---

An API primer

An API (Application Programming Interface) allows two pieces of computer software to talk to each other. In this case, the Metrc API allows them to share the data in their database. But APIs do more than just allow you to retrieve data. They also allow you to create new pieces of data (like a new plant batch, product, or drying room), as well as edit and delete existing data.

How APIs work

When an API provider chooses which data to share, they make it available through an API endpoint. An endpoint is similar to a URL you would see in your search bar. For example, to see all facilities belonging to Frosted Leaf, I send a request to:

https://testing-api-co.metrc.com/facilities/v1

But there are two main differences.

1. APIs require an API key so they can verify the person sending the request.
2. Whereas website display data as HTML on a web page, APIs send data in a universal format like JSON so anyone receiving the data receives it in the same format.