It sounds so easy: “we’ll just create an API connection with a machinery manufacturer so we can ‘just receive’ all their data straight into our own platform”. This initial setup is often a lot harder than it sounds but, still – “just get the work done; once we’re finished, we’re finished”. Right?
Well, no – not really. Thinking about an API connection as a ‘set and forget’ piece of technology is an often-made mistake. In reality, it is quite different. As API providers make upgrades to their platform and products, change the structure of their data warehouse, or maybe create a new piece of hardware that outputs data in a different format, APIs change on a regular basis.
What that means for those connected to these APIs, is that they have to be continuously aware of these changes and make updates to their API connection in a timely manner so that their clients don’t experience errors or failed data transfers. And, because the API provider sets the timeline for changes, it’s easy to lose control over your technical roadmap by having to delay the projects you should be working on in favor of the projects you have to work on to avoid failures.
A good example that I saw of this recently, is this deprecation of Trimble’s API V2 in favor of V3. What this means is that Trimble had so many changes to make to their API structure that, instead of making changes to their current API structure (V2), they have decided to make this structure completely obsolete and create a new API (V3) for their data partners to connect to. In general, this is great! We love seeing companies launch new features and data types via their API. However, these positive changes can also add months to years of work for the teams that now need to rewrite their integration to remain compatible with a provider.
When I first heard about this change, I got a simple message from our product team: “Hey, we’ve updated Trimble from V2 to V3 on our end. Big changes on the Trimble side but we were able to not introduce any breaking changes for our clients, but maybe just let them know in case they see a message from Trimble and they’re not sure if they have to take any action. If they ask, the answer is: ‘no action needed from them’.”
Leaf works with many data providers that all use different formats, abstractions, and structure and are constantly making changes to their API. We are used to adapting to them while still making sure that the data output to our clients is in the same standardized and consistent format at the other end; no matter the number of changes they make. Our engineers are API experts and they deal with this kind of work every day; talk about making life easy!
I often ask our clients what they feel the biggest benefit is of accessing their data through Leaf, and API maintenance rarely features in their answers. I think there’s an easy explanation for this: if you don’t know about the maintenance that is happening behind the scenes, it is easy to forget the benefit you are deriving from not having to worry about it. But, just imagine having to start from the beginning with connecting to an API that you’ve been connected to for a while already just because the old version is getting deprecated and won’t be live in a couple of months…
Anyway, hereby my message to all of those who access Trimble data through Leaf: nothing changes, it’s business as usual. If you do have any questions, just send me a message!
