Note form Cory about what the meeting was going to be about: Cannapages has been trying to connect to Leafly through our API. We have opened up two API's for them but they are still having issues. Steve suggested a quick meeting with you to help facilitate this.

Here are my notes from the call, conversation, and meeting:

- They, the Cannapages guys, are super into their own vertical. They had some deep questions about things that are very specific to their industry. We use a very general or generic tool that has lots of dynamics. That works great for our clients as they are able to setup whatever key datapoints that they need. That is not very good if you are trying to standardize things and play with economy of scale (lots of people doing the same thing). There is a need for things to be standardized.

- Lots of talk about setting standards for certain 3rd party solutions and integrations. We can allow our users to set them up or we could automate things and either lead them through a valid setup and/or force them to use certain attributes and flows. If things are more standard, it just helps downstream flow and data transfer and sharing. Basically, a way to get normalized data for a specific integration and/or 3rd party solution.

- Our developers have full access to the whole adilas database. Some of the outside developers have to use API sockets and connections to open up specific endpoints. That is great and all but can be very frustrating, if they don't know which endpoints to use (virtual windows and doors into the data and records). Lots of talk about documentation and ease of use, from an outside developer's point of view.

- What is the best or biggest value for our customers or for the people using it? Some of our customers are real clients and some are outside developers. Keep those different parties in mind when developing. They have different needs.

- There are costs to do industry specific hook-ups. There needs to be a plan, settings, requirements, and set standards per integration. Otherwise, the outside developers feel like they are chasing their tails.

- Making things human readable... Many of our API sockets (backend developer endpoints through the API) are coded to id numbers or techy look-ups. Some of these outside developers really want an easy way to get at the data (plain English vs techy id look-ups). We spent some time talking about building different attribute look-ups based on text or names vs id or control number stuff. That led to talks about requirements, possible mapping options, and making settings that help with setup and automation. Otherwise, there are too many variables.

- This 3rd party needs lots of specific and categorized data (called meta data). We talked a lot about meta publishing data and being able to construct the names and associated data values. We need to put the data in the correct columns and in the correct format (standards). That makes it easier for filtering and matching things. Eventually, things will get parsed or broken up into smaller and smaller parts and pieces. This allows for things to be tagged and flagged as certain things. Once again, getting clear down to the meta data level.

- They gave us a few wish lists for the existing API. Cory took some notes there. Basically, was to standardize things and make it go and flow faster for them.

- I didn't know this, but the Cannapages guys are actually building a standalone side project to help some of our clients. Imagine something like this... a bulk tool that takes raw inventory data from adilas, strips out what they need (for their industry), standardizes it, allows for bulk edits and classifications, and then takes the new data (in bulk) and adds it to their database. They then serve up that modified data to an outside 3rd party that does or has a key industry specific website and data filtration process. I didn't really know what they were doing until this meeting. We are not even as close to industry specific as these guys are. It's basically a 3rd party bulk tool to provide data to another 3rd party. Kinda interesting.

- The last major topic was data and views. We have data (what is needed and recorded) and views (what it looks like) for multiple different parties. We have to have views and data for employee/users, data and views for state compliance agencies, and data and views for outside or normal customers, clients, and patients. That's a lot of different data and possible views (what it looks like). All of that, based off of stored data that got stored and entered into the system. Pretty high requirements.

- Some of the above notes may apply to our future fracture and adilas lite build outs. Whether it is dealing with different views, industry specific skins, normalizing data, and making the API sockets and endpoints easier to use and consume (plain English vs techy id/number stuff). Lots of good lessons being learned by being in the trenches.