I've been asked repeatedly whether the Metrc API can be used to do various things. It seems reasonable that a "seed to sale" system would provide the ability to track inventory and provide information useful for a number of reporting functions. Unfortunately, I invariably end up being the bearer of bad news.
The Metrc API is a mechanism to report some compliance data to the State. That's it! If you want to use it for anything else, that's your prerogative, but don't be surprised if your project fails. Would you use a screwdriver to drive nails? Cook your Thanksgiving turkey with a bunsen burner? Commute to work on a Big Wheel? You get the idea.
At first glance, you might think the API is poorly designed. Posting data returns a 200, but absolutely nothing else. Fetching data returns only records which have changed in the past 24 hours. The documentation shows a single sample request payload, with no additional information. Terms such as Tag and Label are synonymous, but not interchangeable. Rooms represent an arbitrary area rather than a space which is separated from the rest of the building. And while you can "delete" Items and Strains, you "post" to destroy Plants and Packages.
But if you remember what the API is designed to do, you realize these features are actually benefits. While most API's return at least the identifier of the object created with a "post", this forces your system to hold the response in memory, and then parse it. So, by not returning a payload on success, Metrc is keeping your system light and nimble.
Since you'll need that identifier later, as soon as your "post" completes, you'll need to do a "get" in order to find the new record you've just created. Metrc makes this easier by returning records sorted by "last modified" date, so your record is probably one of the first. Not only does Metrc make it easy to find your new record, by getting the record you can rest assured other threads will now be able to retrieve the record as well. And by limiting the "get" response to only records that have changed in the past 24 hours, your system doesn't have to deal with an abundance of records.
Again, if you decide to use the API for things it was not designed for, you'll end up causing yourself pain. If you want to see all of the Plants or Package a licensee has, you'll need to page through all of the records, again sorted by "last modified" date. Since you only get a 24 hour period for each "get", you'll need to make 30 calls to see anything that's changed in the past month. If the licensee has anything in inventory that hasn't been modified in longer than a month, you'll need to go back farther. If you're trying to get the inventory of a licensee who's been in business for a year, you'll need to make 365 calls, or risk not getting all the relevant data.
The documentation indicates you get records back based on the last modified date. However, there's no information about defaults or what happens if you provide incorrect values. But that's why vendors must be certified! Anyone authorized to use the API must go through training, so the documentation can be more of a "refresher" rather than a "how to" helper. The training also makes things like inconsistent naming, nonintuitive concepts and oddly assembled endpoints a non-issue.
As long as you use the Metrc API for what it's intended to provide, and only what it's intended to provide, you'll be a happy camper. You can think of the Metrc API as a one way door where data goes in. However, once it's in there, don't expect or try to get it back out. You've been warned.
No comments:
Post a Comment