Earlier this year I wrote an article about ‘Avoiding API Maintenance’ and why API connections can’t be thought of as a ‘set and forget’ piece of technology when connecting directly with data providers. Over the past couple of weeks I was once again reminded of how topical this article is, with many Leaf clients contacting me about an email they’ve received about ‘breaking change’ updates to the MyJohnDeere API. ‘Breaking change’ in this case means that changes must be made by API users before a certain date in order to prevent the API connection from ceasing to function. Spoiler: if you are a Leaf customer, you can ignore that email 🙂.
What’s changing?
I’ll list the technical details below for those looking for a complete overview but, if you’re more interested in what this means for you, just skip to the next section.
Paging Parameters are being updated from URI matrix parameters to query parameters. As of 1-1-2024, all MyJohnDeere systems will stop accepting matrix parameters for requests. This means that those businesses who are connected to the John Deere API need to update their parameters before this date to prevent disruption.
The Paging Header Format is updated to become compliant with HTTP standards and avoid incompatibility with some systems. As of 1-1-2024, all MyJohnDeere systems will stop accepting the old header name formats. This means that those businesses who are connected to the John Deere API need to update their header name format before this date to prevent disruption.
The eTag Responses are changing to become faster, more accurate and consistent. Removal records will no longer be returned and eTag responses will now be paged instead of returning all records.
What do I need to do?
Leaf users that already access the John Deere API via Leaf’s unified API don’t need to do anything; we make all the changes with John Deere on our end so that you don’t experience any service interruption on your side, and you don’t have to task your development team with any work to achieve this.
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!
If you have any additional questions about these changes or how they might impact your systems, please feel free to contact us so we can discuss this further.
