5 ms·
For many years (since 2014) the API for Metrc (the cannabis reporting engine in Colorado and other states) would NEVER return any useful data at all, simply an
by openthc 3y ago
For many years (since 2014) the API for Metrc (the cannabis reporting engine in Colorado and other states) would NEVER return any useful data at all, simply an empty JSON array. So after each operation, one would have to query the search endpoint for plants or inventory to discover the new items -- and hope you could positively identify which one was the new one you were looking for.
That and not supporting B2B transactions via their API. They would alternately claim it's for security or that the States were not asking for it. States would tell other software vendors that Metrc coludn't do it. Neither party could move the ball.
Only now, in 2023, have they started responding with the ID of the newly created items (why not a fully inflated record of what was just created) and working to support B2B.
These state run APIs, from a for-profit corporation, are not good for the public (they hide, or cannot handle important laboratory testing data) and they are not good for the licensees, especially the small businesses. And there is no accountability -- agency points to vendor & vendor points to agency.
Sadly, getting these State agencies to understand the beauty of distributed/federated systems -- and the difficutly for small businesses to respond to RFPs -- keep us from having nice things.
End of rant.
- mfrisbie 3y agoMy favorite Metrc API wart was submitting harvests when their API servers were bogged down. Sometimes, your "create harvest" request would get stuck in a transaction pool that wouldn't timeout for 10 minutes. You'd have to wait the full 10 minutes to see if it succeeded or not because setting a shorter timeout would risk double-submitting the harvest, thereby completely screwing up that cannabis business's compliance data.
- eyelidlessness 3y agoOh, if only it were that simple across the board! One of my favorites was getting any number of errors (timeouts, various internal errors) only to discover later that the reporting did sometimes, eventually, unpredictably succeed despite whatever error had been returned and regardless of how fatal the error message might have seemed to be. And often this occurred during waves of intermittent outages, where determining any given success might take hours. And in any case, correlating success for some resources was partly guesswork, matching data to the timestamps we reported, which of course lost fidelity in their system because… SQL Server stores it that way, I guess.
- quickthrower2 3y agoWhat’s that API smoking?
- dvdkon 3y agoThat reminds me of a certain dataset (public transport timetables) managed for the Czech state by a private company (CHAPS). They have a duty to release the data for free, but instead they only release near-useless cut-down versions. If you want usable data, you have to pay them for the "enhanced" version. The ministry that oversees this is not interested in changing anything, so despite external efforts, this has been going on for almost a decade.
- yriggs 3y agoYes, I can't think of an API has caused me more grief than METRC's. Recently, I discovered that they do some strange XSS protection on text fields that sanitize any appearance of the characters "SCRI" appearing in sequence. I was scratching my head wondering why the "described" we were sending through the API turned into "debed" on the record itself.