Recently BioTrackTHC introduced some breaking changes in the data-set returned by the sync_vendor API call. These are breaking changes and the data-set now does not match with the documentation – at all.

Here is what one of these broken records looks like

{
    "address1": "1445 INDUSTRIAL WAY",
    "address2": "STE 19A",
    "city": "LONGVIEW",
    "location": "412233",
    "locationtype": null,
    "name": "MAMA J'S",
    "processor": null,
    "producer": null,
    "retail": null,
    "state": "WA",
    "transactionid": "31019131",
    "transactionid_original": "31019131",
    "ubi": "603478376",
    "zip": "986321033"
}

Notice that the ‘locationtype’ field is null, as are the producer, processor and retail records. This record is describing a licensee that is none of the possible options for a licensee in Washington State! How can it be nothing?

I filed a bug with BioTrackTHC. Their response was that I should read a Wikipedia article about the JSON syntax and then described some changes they had made to privileges. That’s not even on point!

So we responded with:

TJ,

It’s clear you didn’t read my message at all. I’ll try again. Look at the data I sent you, the ‘locationtype’ field is NULL. So are the retailer, producer and processor flags. This is not a permissions issue as you claim, this is missing data! This data behaving in a way that is AGAINST THE DOCUMENTATION. Your system documentation says these fields will be integers or booleans. NULL is not that. Your data is broken for this record. I call in to question the integrity of other data in this system.

While we’re don the topic of how JSON works, why does BioTrack still use the WRONG MIME TYPE!?

What response did we get from that? A pointer to a Wikipedia article about NULL followed by legal threats; here’s a snippet of the response from BioTrack

Furthermore, we would suggest you start treading lightly when publicly using inflammatory language in writing that you simply cannot back up with facts. Yes, this communication is considered public. While we have decided against pursuing you in the past for your more obvious cases of libel, I most certainly cannot guarantee that will be sustained in the future.

I’ve added in-house counsel to this email chain, for their records. Should it become necessary, we will start adding outside counsel and our litigation team to any public correspondence received from you in the future.

Please govern yourself accordingly.

And we’ve then fired back this response:

TJ,

Well, it’s nice you’ve avoided answering my question and at the same time threatened me with legal action for filing bugs against your software. Bugs, that still exist, bugs that you have not explained.

Why are these records showing null? How can we have records in the system that are not Producers, Processors or Retailers? Why would the records show null when the documentation shows they will be an integer value? Null is not an integer. Either fix your code or fix your documentation to explain how a Vendor could be neither a Producer, Processor, or Retailer. It’s not a null vs integer debate anyway. The issue is that, once again, your data does not match your documentation. Once again you have changed things in your system to not match the expectations set by your documentation. This demonstrates BioTrack is a poor selection for a technical implementation. What good API vendors do is to publish updates to their documentation FIRST; then change code. Using this method you can actually help third party integrators.

I know these communications are public, it’s how reporters get my phone number.

Please continue to add lawyers to a technical discussion; it will add weight to our position that you cannot solve problems with engineering so you must use legal threats. I could not ask for any better validation of our business – in addition to the free press.

We have yet to receive any explanation regarding the original issue from BioTrack. Their system is delivering broken records, with no explanation.