A rocky start with the Oregon Metrc API

Towards the end of August, I received a "Proficiency Evaluation", which is the final step in getting production keys for the Oregon Metrc API. Because this is essentially a test, I'm not going to share any of the questions (or answers). However, this was my first chance to play with the API, so I will share my impressions.

It took me over a month to complete the evaluation. And it wasn't because I didn't invest the time! The initial set of docs I got were . . . well, wrong. A number of the argument names weren't correct (though a few were easily guessable). A few of the endpoints just flat-out didn't exist. Of course, none of these issues are immediately obvious, so each of them wasted a lot of time.

Feeling defeated, I contacted Metrc to explain the problems I was having in completing the test. I can not over emphasize how helpful and responsive Metrc has been (Michelle is my hero and I could not have gotten to this point without her help!). I was pointed to some updated online docs. Much better!!!

However, it still wasn't smooth sailing from there.

To complete the evaluation, I was granted access to a sandbox. I was sent a list of plant and package tags, for a number of different licensees, and the sandbox has some initial data. It eventually occurred to me, not all (or maybe not any) of the data was created by the good folks at Metrc. The sandbox, the credentials, the list of tags . . . everything was shared with everyone else who was trying to complete the evaluation. This makes for some nasty surprises and confusing moments!

The shared tags made it impossible to know which tags had been used and which could be attached to plants or packages. To find usable tags, I ended up looking them up until I got a non-200 response. As time went on, finding unused tags became harder and harder. I'm pretty sure I ended up using the last plant tag for one of the producer accounts.

It would be nice to believe you can create something, like a plantbatch, and walk it through it's lifecycle. But in a shared environment, especially one in which users have no means of communicating with each other, your data can get stomped at any time. I had data change out from under me. Initially I felt a tinge of guilt when I used other peoples objects. But by the end, I was flagrantly harvesting other peoples plants and selling out of other peoples packages.

Overall, the API makes a lot of sense. As long as you understand the Metrc system, figuring out which endpoints to call is pretty intuitive. I like the RESTful approach, and I think this is a pretty good implementation.

There are some rough edges though. There's some inconsistency in some of the endpoints. For example, in one case you "changegrowthphase" and in the other case you "changegrowthphases". You can "destroy" a plantbatch, but individual plants require "destroyplants". And while you tag new plants using a "StartingTag", you find plants with a "Label" (these are the same thing). The part I like least is the difference between shapes of requests and responses. For example, when you create a plantbatch, you give it the "Strain". But getting a plantbatch returns the "StrainId" and "StrainName".

I found there's very limited access to historical data. So, if you change the growth phase on a plantbatch, and later see the strain is different, or it's been harvested (or both in my case), there's really no way (that I could tell) to figure out what happened to the plants. Of course, if you're in an environment with a single licensee, none of this should happen . . . but if you wanted to show the lifecycle of a plant, you're going to have to jump through some hoops.

I was less than thrilled to find successful POST requests always return empty responses. Non-200 responses include pretty good information, but after making a successful call, you just get a 200. This pretty much doubles the number of calls I ended making . . . create something, then go look it up.

Though there were some frustrating moments, all in all this was a pretty fun challenge. By the end of completing the evaluation, I felt pretty comfortable with the API and look forward to actually building some software that leverages Metrc. I'm secretly hoping some details of the API are still a work in progress, but even if it's fully baked, I can envision building a lot of cool integrations.

Current software products specifically for the Cannabis industry

With the rapidly expanding list of players in the Cannabis industry, any attempt to compile an exhaustive list of cannabis software is futile. Even if such a list could be created, it would soon be outdated. 

Still, keeping a catalog of software I encounter may prove interesting. Instead of doing a Web search and relisting the results, I'm only including companies and products I've encountered through conversations or first hand experience. So while this may be of limited value to others, these are the Cannabis related software products that have found me:

Metrc

While it's not the first product I learned about, it seems to hold the most promise as an entry into Marijuana businesses. This is the system the Oregon Liquor Control Commission (OLCC) has selected as Oregon's cannabis tracking system (CTS). It's also what the state of Colorado uses.

Because this is the "official" tracking system in Oregon, I've already started investing in learning to leverage this software. I'm currently a certified third party vendor (TPV) and have begun exploring their API.

MjFreeway

This is the first Marijuana-centric company I encountered. A good friend in Colorado with contacts in the Cannabis industry there, introduced me to this company. At the time, had their product been written in something other that PP, I might have contacted them to see if there were any remote opportunities.

Because MjFreeway is a tracking system, integrating it with other tracking systems seems an obvious opportunity. I have yet to investigate whether it has an API.

Leafly

This same friend that introduced me to MjFreeway also introduced me to Leafly.com. I'm particularly interested in solving business problems, so my interest here would be limited to updating a dispensaries menu from a tracking system or pulling in stats to include in a larger report.

Biotrack

Biotrack was presented to me as the only tracking system used by growers. This is despite having been introduced to MjFreeway prior to this. So, while my source was less knowledgable than he purported to be, Biotrack is clearly widely used. I've heard mixed messages about whether Biotrack already has integrations with Metrc, and have yet to do any of my own research.

Flohub

I was introduced to Flohub recently by a local grower. This seems to be a tracking system targeting both growers and dispensaries. Interestingly, the grower mentioned he has a friend who is working on integrating Flohub and Metrc (despite the Flohub site claiming they have integration built-in).

IndicaOnline

I learned about IndicaOnline from an exasperated hostess at a dispensary. She was trying to enter in new visitors on a particularly busy day. Since I happened to be at the tail end of the rush, I asked her whether her frustration was directed towards the workload or at the software. She indicated it was more at the workload, but wished there was a way to simply scan id cards, instead of having to type the information. I was then able to ask her a bit more about the software, which was IndicaOnline.

I'm in! Sort of . . .

I finally have credentials to get into the Metrc sandbox! Unfortunately, I don't have any documentation other than the this work in progress: http://media.wix.com/ugd/73c73e_e930c713c46f4c08b07e7c2e2d29a2b5.pdf

I've been able to retrieve rooms, plants, items, etc., but that's it. While I can report waste, without any other documentation, I'm left to guess at the endpoints and payload required for other calls.

I'm waiting to see if I can get my hands on better docs. Until then, I can't do much more.

First Test Passed . . . Literally!

In order to gain access to the Metrc API, there are a series of steps one must get through. One of those is to "Attend a Metrc training class and complete the test". Check that step off the list! I am a certified "Third Party Vendor". The next step is to get access to the Metrc API sandbox and start experimenting.

Since I'm not looking to leave my current full time job, I'm doubtful existing software companies hold appropriate opportunities for me. However, I found it very interesting to find the OLCC approved four companies to provide retail sales tracking. I might investigate whether these systems have APIs worth exploring as well.

Converting failure into motivation

There's goes another failed side project! 

This one went from really promising to utter disaster over the course of a few days. There were so many warning signs and red flags I should have seen. Lack of clear vision (no business or marketing plan), disorganized priorities (going public prior to having any revenue), and complete lack of experience of software products or development were all there . . . and I choose to ignore or rationalize them away. While it sucks to spend hours and hours working on software that will never see an audience, in hindsight, I'm glad it fell apart before money got involved.

Even though we parted bitterly, I hope "the company" goes on to become profitable. Therefore, all I'll say about the application is it targeted the cannabis industry. It was pretty data heavy and had some interesting challenges to solve. Fortunately, I've learned a lesson from previous side projects that applied here:

Projects that are fun to program will never end up being a total waste of time

But that thing about targeting the cannabis industry . . . that's the silver lining! It's an industry in it's infancy which promises to be enormous. For nearly 70 years, prohibition attempted to suppress demand, without much success. While there's still a stigma around marijuana, I believe billions of dollars in sales will soon change that perception.

Since I don't want to be prejudged as "a stoner", I've been reluctant to open up about my desire to work in the cannabis industry. I feared being associated with pot might cost me an employment opportunity in the future. But this project made me realize:

I don't want to work for a company who views marijuana negatively

I don't expect my employer to allow lighting up at work (despite having refrigerators full of beer). But if being associated with a marijuana related business is a reason not to hire me, then it's probably best I don't work there. In fact, a job where I can get fired because a pee test says I've consumed THC in the past month is a job I don't want. Consider what would happen if employers fired every employee who had consumed alcohol in the past month . . . that would make for a pretty empty office!

So instead of hiding the fact I'd like to be involved in this newly formed industry, I'm going to dive in (at least with my spare time). My first goal is to gain access to the Metrc API. I'm not sure exactly what I'll do after that, but I'll cross that bridge later. My employment status won't change, nor will any of my activities affect my day to day work. But I'm hopeful ability to write custom solutions that leverage the API will provide entry and exposure to cannabis businesses.

One reason the project failed was "the company" had a complete lack of understanding or experience in software. They thought knowledge of the cannabis industry was enough to develop a successful software product. And while I tried to provide guidance, an inability/unwillingness to accept principals like agile and iterative development made creating an MVP like chasing butterflies. I like working with people who have nothing but a good idea, but now I've learned:

You must know how the software will be profitable before you start coding

Notice I said "be profitable" instead of "make money" or "generate income". Maybe your goal isn't to make money. If the goal is to reduce the time spent repackaging production batches in Metrc, figure out how much time you expect will be saved. If you're starting or joining an open source project, determine what you expect to get out of it. If you want the project to feed you, you'd better figure out how it's going to spin off cash before you start planning features for your MVP.

Finally, while it's important to agree what will happen if the project succeeds, it's just as important to decide what will happen if it fails. Waiting until things are crumbling around you is too late! I learned a valuable lesson, and while I wish I had never made the mistake, I'll try to keep it in mind in any future work:

Agree upfront what will happen to the code if it's determined it will not become profitable

When the project melted down, I reacted impulsively. We didn't have any agreements in place, much less one that covered what would happen to the code if a disagreement surfaced. The hardest part of the whole ordeal was being accused of being dishonest and disingenuous. In an attempt to prove I had nothing but good intentions, I zipped up the entire code base and sent it to "the company". I told them to use it for whatever they wanted. I said I didn't expect or want any payment. To be honest, at that point I just wanted to get the fuck away from a toxic situation.

By not getting an agreement what would happen if things went south, I ended up losing a lot of interesting code. I don't care about giving away almost 100 hours of coding for no money, but I kick myself for making it unusable or unsharable. One day I may ask if I can publish it under an open source license (though I'm not sure it's worth it). I may need to settle for being paid in lessons learned, fears overcome, and motivation gained.