Vendors promise "easy integration." Building owners end up with six-figure bills for something that was supposed to "just work." The gap between those two realities cost one organization $200,000 for a single API integration—and then the same amount a year later when the vendor changed their API.
Drew DePriest knows these stories because he's lived them. He leads technology for real estate operations at McKesson, a Fortune 10 pharmaceutical distributor responsible for a third of the daily pharmaceutical supply in the United States. When your data pipelines feed ESG reports that carry financial penalties if they fail, you learn to spot vendor BS quickly. At NexusCon 2025, DePriest shared what building owners actually face when vendors wave "open API" in marketing materials—and offered a framework for separating real interoperability from expensive disasters.
The challenges are real. Poor documentation, inconsistent data formats, and missing sandbox environments plague API implementations across the building automation industry. But there's a path through. DePriest's team has built integrations that run mission-critical reporting at Fortune 10 scale, and the patterns they've learned apply whether you're managing five buildings or 500. Think of APIs as plumbing for your building systems. You only notice them when they fail.
Vendors lean hard on "API = openness." Building owners hear flexibility, choice, lower total cost of ownership. The reality? APIs vary wildly in quality, maturity, stability, and cost to maintain.
The question building owners need to answer: does this particular API belong in your integration strategy? DePriest reached into an unexpected place for his framework—Dungeons & Dragons character attributes. In the building automation world, the challenge lies in simplifying integration, a task that often involves complexity and confusion, which makes clear thinking frameworks essential.
Intelligence means knowing a vendor has an API.
Wisdom means knowing that doesn't mean it belongs in your integration strategy.
Charisma means vendors who can "sell you a tomato fruit salad"—technically possible, but probably not what you want.
DePriest used the tomato framework to cut through common API terminology. An API is knowing how to ask for data. REST is the polite way to ask. OpenAPI or Swagger is having documentation that tells you exactly how to ask. OAuth2 is needing permission before you can ask. Building owners don't need to become API experts, but they do need to recognize when technical jargon is covering for weak implementation.
Before presenting at NexusCon, DePriest crowdsourced feedback from industry practitioners on LinkedIn. He asked a simple question: what makes an API bad? The responses painted a clear picture.
Poor documentation topped the list—by a significant margin.
"If you can't understand what data is available or how to get it, you can't start from anything," DePriest said during his presentation.
The feedback illuminated patterns that owners rarely see during vendor demos. Legacy systems may lack the necessary APIs or data interfaces required for seamless integration, necessitating the development of custom middleware or data conversion solutions. Authentication complexity, rate limits, inconsistent data formats, lack of versioning—each weakness multiplies integration cost and risk.
The chart from DePriest's crowdsourcing revealed the frequency of common pain points. Poor documentation led, followed by inconsistent data formats and authentication complexity. No sandbox environment, lack of versioning, and rate limits rounded out the top complaints. Each represents a cost that lands on building owners, not vendors.
Consider inconsistent data formats. One system sends a number. Another sends a text string representing the same data. Everything breaks. Your integration team spends hours debugging something that should have been standardized from the start.
Or take the absence of sandbox environments. At McKesson, lower testing environments are mandatory for everything. But many building automation vendors don't provide them. Without a safe place to test, every change carries production risk.
The missing element in most vendor conversations? What happens when their API changes. Changes to an API frequently damage compatibility with existing client integrations; modifications such as eliminating fields, adjusting endpoints, or changing response formats can disrupt client operations. Maintaining backward compatibility ensures that existing clients can continue to use the API without breaking when new changes are introduced—but many vendors don't prioritize it.
DePriest didn't just catalog problems. His team has identified vendors and patterns that work.
Clean REST patterns. OpenAPI or Swagger specifications. Proper use of HTTP verbs. Working code samples from the vendor, not just documentation promising they exist. OAuth templates that actually function.
The gold standard? Twilio.
DePriest cited the communications platform repeatedly as an example of how API providers should operate. Twilio has always been a developer-focused company, investing in its documentation early and helping pioneer what are now best practices, such as automatically generating API reference pages from specifications, and providing tested code samples that developers can copy, paste, and run.
Twilio's approach includes public specifications on GitHub in both JSON and YAML formats. OAuth2 authentication that works out of the box. Postman tools and code samples that developers can actually use. Because this document is used across Twilio's whole API development experience, these documents are automatically kept up to date and used to validate Twilio API requests.
Why should building owners care? A moderately complex API integration typically sits between $15,000 and $40,000, while advanced or custom integrations demand budgets ranging from $50,000 to well over $150,000. Good APIs lower cost, shorten timelines, and make integrations maintainable. Bad APIs multiply expenses every time something changes.
Within the building automation industry, a few vendors stood out in DePriest's LinkedIn feedback. One mentioned Clockworks Analytics for embedded KQL queries that give owners direct access to their data. Another cited proper API-first architecture with HATEOAS principles and correct HTTP verb usage at Dartmouth College.
The pattern? Vendors treating APIs as products, not afterthoughts.
At Fortune 10 scale, data reliability isn't optional. McKesson's real estate technology team manages mission-critical pipelines that feed ESG reporting, energy management, and portfolio analytics.
"If any of these fail… that has financial penalty for publicly traded companies," DePriest explained.
The stakes clarify thinking. McKesson can't afford to wait three days for vendor support when an API breaks. They can't accept incomplete historical data. They can't tolerate vendors who treat integration as someone else's problem.
This led to a specific architectural choice: portfolio snapshotting. Rather than trusting vendors to maintain historical data, McKesson pulls complete datasets into Snowflake on a regular cadence. When business units ask about portfolio changes over the last quarter, McKesson has answers. Most vendor platforms don't retain that history.
The use cases building owners actually need illustrate why API quality matters:
ESG reporting that must run monthly without failure. Three different source systems feed one target system through API-led integration blocks. Data integration and correlation requires integrating data from disparate sources and correlating it to identify meaningful patterns and relationships essential for gaining holistic insights into building performance. If any pipeline fails, financial penalties follow.
Dynamic occupancy and floor consolidation. Imagine a five-story office building learning from occupancy sensors, meeting room bookings, and badge access data. If the system predicts only two floors will be needed on Friday, APIs should enable canceling third-floor meetings, redirecting occupants, and shutting down unnecessary HVAC—automatically.
Real-time energy and demand response. DePriest remembers chasing real-time pricing APIs back in 2005-2006, trying to pull ISO data into building management systems to automate chiller shutdowns during peak pricing. The concept made sense at scale. But if you only save 17 cents per week, the business case evaporates.
Getting closer to the source instead of chaining API-to-API integrations. An attendee during the Q&A session made the point bluntly: "API to API integration is a major money pit, whether for the vendor or the building owner."
The preference at organizations like McKesson? Pull raw data directly from building systems into an owner-controlled data layer. Many proprietary BMS providers restrict integrations to their own ecosystem which makes future upgrades expensive and limits choices for expansion. Vendor APIs should feed the owner's warehouse, not the other way around.
DePriest's perspective surprised some attendees. He's not anti-vendor. He's not pushing for owners to build everything themselves.
Point solutions aren't bad—as long as they have clean APIs and you own your data layer.
The architecture McKesson aims for:
This aligns with broader industry movement toward open-source operational technology and building management systems. Owners increasingly recognize that the overarching need is for a unified approach to connect disparate building systems, with IT departments showing preference for open standards in APIs and MQTT.
But "open" has become a four-letter word in this industry. Vendors slap "open API" on marketing materials while maintaining proprietary data models, undocumented endpoints, and integration paths that only work with their preferred partners.
DePriest's LinkedIn post used intentionally careful language when discussing what "open" should mean:
Entirely vendor-neutral specifications. Governed by industry-recognized open bodies. Freely and openly developed—not controlled by a single vendor calling the shots.
The difference matters. An API that requires vendor permission to access your own building data isn't open. An API that only works with the vendor's cloud platform isn't open. An API that changes without notice and backward compatibility isn't open.
The framework building owners need comes down to due diligence questions. Ask before procurement, not after implementation fails.
Does your API have publicly accessible documentation?
Not a PDF you email to prospects. Public documentation that developers can access, search, and reference during implementation.
Is there an OpenAPI or Swagger specification?
An OpenAPI specification compatible file allows description of a complete REST API, generally written in YAML or JSON file format. If the vendor can't produce this, they're not serious about integration.
Can you show me a live example or code sample?
Working samples, not pseudocode. Something a developer can copy, modify, and run.
Do you provide a sandbox environment?
Every change to production carries risk. Owners need safe testing environments. If the vendor doesn't provide this, factor in the cost of building your own.
How do you handle version control?
Some companies only provide documentation for the latest API version, meaning that clients consuming older API versions cannot find relevant information. Vendors should support multiple versions concurrently and provide clear deprecation timelines.
What happens to integrations when your API changes?
Will existing integrations break? How much advance notice do you provide? What's your backward compatibility policy?
What historical data is available through the API?
Many vendors only expose current state. If you need trend analysis or time-series data, confirm the API provides it.
Who pays when things break?
This question reveals vendor accountability. If their API changes break your integration, who bears the cost of fixing it?
Each question traces back to pain points DePriest and his industry colleagues have experienced. They're not theoretical. They're the difference between a $15,000 integration and a $200,000 disaster.
"An API is like plumbing—keep your pipes clean," DePriest said in his closing remarks.
The metaphor captures something essential. Good plumbing is invisible. It works. Water flows where it should, when it should, without anyone thinking about it. You only notice plumbing when it fails.
Bad plumbing? Everyone notices. Water goes the wrong direction. Pressure drops. Things leak. Costs multiply.
Building owners must treat integrations as ongoing infrastructure, not one-time line items. Technical debt grows faster without proper maintenance. A security incident after two years of neglected updates can cause four days of system downtime and millions in lost revenue. Plan for governance. Budget for versioning and iteration. Manage APIs like products that require care and feeding.
The future belongs to buyers who demand:
When vendors oversell APIs, the costs fall on owners. When owners ask the right questions up front, they avoid the fruit-salad scenarios that never should have happened.
The vendor pitch sounds great: "We have an API, so integration will be simple." But as DePriest demonstrated, having an API tells you almost nothing about whether it will actually work in your environment.
Before signing any contract that promises API integration:
Stop assuming all APIs are created equal. They're not. Quality ranges from gold-standard platforms like Twilio to barely-documented endpoints that will cost you six figures to integrate.
Ask the due diligence questions listed above. If vendors can't answer them clearly, that's your answer. Walk away or budget for the true cost of making their API work.
Insist on owning your data layer. Don't let vendors trap your historical data in their platform. Pull it into a warehouse you control. Your future self will thank you when you need to switch vendors or answer questions about portfolio changes over time.
Plan for API maintenance as an ongoing cost, not a one-time expense. The Total Cost of Ownership includes initial build costs plus annual maintenance, vendor fees, and infrastructure costs over a three-year period. That $80,000 integration might really cost $125,000 when you factor in three years of support.
Consider point solutions with clean APIs over all-in-one platforms. The best tool for each job, connected through open APIs into your data layer, gives you flexibility that monolithic platforms can't match.
The smart building industry is moving toward more open systems and protocols. But "open" has to mean something beyond marketing language. Demand the real thing: vendor-neutral specs, public documentation, stable versioning, and data ownership that stays with you.
DePriest's tomato framework remains useful even after the presentation ends. Intelligence—knowing a vendor has an API—is common. Wisdom—knowing whether it belongs in your stack—is rare. Building owners who develop that wisdom avoid the expensive mistakes others keep making.
This article is based on Drew DePriest's presentation at NexusCon 2025. DePriest is MCR.w, WELL AP, and Director of Real Estate Operations Technology at McKesson.
Vendors promise "easy integration." Building owners end up with six-figure bills for something that was supposed to "just work." The gap between those two realities cost one organization $200,000 for a single API integration—and then the same amount a year later when the vendor changed their API.
Drew DePriest knows these stories because he's lived them. He leads technology for real estate operations at McKesson, a Fortune 10 pharmaceutical distributor responsible for a third of the daily pharmaceutical supply in the United States. When your data pipelines feed ESG reports that carry financial penalties if they fail, you learn to spot vendor BS quickly. At NexusCon 2025, DePriest shared what building owners actually face when vendors wave "open API" in marketing materials—and offered a framework for separating real interoperability from expensive disasters.
The challenges are real. Poor documentation, inconsistent data formats, and missing sandbox environments plague API implementations across the building automation industry. But there's a path through. DePriest's team has built integrations that run mission-critical reporting at Fortune 10 scale, and the patterns they've learned apply whether you're managing five buildings or 500. Think of APIs as plumbing for your building systems. You only notice them when they fail.
Vendors lean hard on "API = openness." Building owners hear flexibility, choice, lower total cost of ownership. The reality? APIs vary wildly in quality, maturity, stability, and cost to maintain.
The question building owners need to answer: does this particular API belong in your integration strategy? DePriest reached into an unexpected place for his framework—Dungeons & Dragons character attributes. In the building automation world, the challenge lies in simplifying integration, a task that often involves complexity and confusion, which makes clear thinking frameworks essential.
Intelligence means knowing a vendor has an API.
Wisdom means knowing that doesn't mean it belongs in your integration strategy.
Charisma means vendors who can "sell you a tomato fruit salad"—technically possible, but probably not what you want.
DePriest used the tomato framework to cut through common API terminology. An API is knowing how to ask for data. REST is the polite way to ask. OpenAPI or Swagger is having documentation that tells you exactly how to ask. OAuth2 is needing permission before you can ask. Building owners don't need to become API experts, but they do need to recognize when technical jargon is covering for weak implementation.
Before presenting at NexusCon, DePriest crowdsourced feedback from industry practitioners on LinkedIn. He asked a simple question: what makes an API bad? The responses painted a clear picture.
Poor documentation topped the list—by a significant margin.
"If you can't understand what data is available or how to get it, you can't start from anything," DePriest said during his presentation.
The feedback illuminated patterns that owners rarely see during vendor demos. Legacy systems may lack the necessary APIs or data interfaces required for seamless integration, necessitating the development of custom middleware or data conversion solutions. Authentication complexity, rate limits, inconsistent data formats, lack of versioning—each weakness multiplies integration cost and risk.
The chart from DePriest's crowdsourcing revealed the frequency of common pain points. Poor documentation led, followed by inconsistent data formats and authentication complexity. No sandbox environment, lack of versioning, and rate limits rounded out the top complaints. Each represents a cost that lands on building owners, not vendors.
Consider inconsistent data formats. One system sends a number. Another sends a text string representing the same data. Everything breaks. Your integration team spends hours debugging something that should have been standardized from the start.
Or take the absence of sandbox environments. At McKesson, lower testing environments are mandatory for everything. But many building automation vendors don't provide them. Without a safe place to test, every change carries production risk.
The missing element in most vendor conversations? What happens when their API changes. Changes to an API frequently damage compatibility with existing client integrations; modifications such as eliminating fields, adjusting endpoints, or changing response formats can disrupt client operations. Maintaining backward compatibility ensures that existing clients can continue to use the API without breaking when new changes are introduced—but many vendors don't prioritize it.
DePriest didn't just catalog problems. His team has identified vendors and patterns that work.
Clean REST patterns. OpenAPI or Swagger specifications. Proper use of HTTP verbs. Working code samples from the vendor, not just documentation promising they exist. OAuth templates that actually function.
The gold standard? Twilio.
DePriest cited the communications platform repeatedly as an example of how API providers should operate. Twilio has always been a developer-focused company, investing in its documentation early and helping pioneer what are now best practices, such as automatically generating API reference pages from specifications, and providing tested code samples that developers can copy, paste, and run.
Twilio's approach includes public specifications on GitHub in both JSON and YAML formats. OAuth2 authentication that works out of the box. Postman tools and code samples that developers can actually use. Because this document is used across Twilio's whole API development experience, these documents are automatically kept up to date and used to validate Twilio API requests.
Why should building owners care? A moderately complex API integration typically sits between $15,000 and $40,000, while advanced or custom integrations demand budgets ranging from $50,000 to well over $150,000. Good APIs lower cost, shorten timelines, and make integrations maintainable. Bad APIs multiply expenses every time something changes.
Within the building automation industry, a few vendors stood out in DePriest's LinkedIn feedback. One mentioned Clockworks Analytics for embedded KQL queries that give owners direct access to their data. Another cited proper API-first architecture with HATEOAS principles and correct HTTP verb usage at Dartmouth College.
The pattern? Vendors treating APIs as products, not afterthoughts.
At Fortune 10 scale, data reliability isn't optional. McKesson's real estate technology team manages mission-critical pipelines that feed ESG reporting, energy management, and portfolio analytics.
"If any of these fail… that has financial penalty for publicly traded companies," DePriest explained.
The stakes clarify thinking. McKesson can't afford to wait three days for vendor support when an API breaks. They can't accept incomplete historical data. They can't tolerate vendors who treat integration as someone else's problem.
This led to a specific architectural choice: portfolio snapshotting. Rather than trusting vendors to maintain historical data, McKesson pulls complete datasets into Snowflake on a regular cadence. When business units ask about portfolio changes over the last quarter, McKesson has answers. Most vendor platforms don't retain that history.
The use cases building owners actually need illustrate why API quality matters:
ESG reporting that must run monthly without failure. Three different source systems feed one target system through API-led integration blocks. Data integration and correlation requires integrating data from disparate sources and correlating it to identify meaningful patterns and relationships essential for gaining holistic insights into building performance. If any pipeline fails, financial penalties follow.
Dynamic occupancy and floor consolidation. Imagine a five-story office building learning from occupancy sensors, meeting room bookings, and badge access data. If the system predicts only two floors will be needed on Friday, APIs should enable canceling third-floor meetings, redirecting occupants, and shutting down unnecessary HVAC—automatically.
Real-time energy and demand response. DePriest remembers chasing real-time pricing APIs back in 2005-2006, trying to pull ISO data into building management systems to automate chiller shutdowns during peak pricing. The concept made sense at scale. But if you only save 17 cents per week, the business case evaporates.
Getting closer to the source instead of chaining API-to-API integrations. An attendee during the Q&A session made the point bluntly: "API to API integration is a major money pit, whether for the vendor or the building owner."
The preference at organizations like McKesson? Pull raw data directly from building systems into an owner-controlled data layer. Many proprietary BMS providers restrict integrations to their own ecosystem which makes future upgrades expensive and limits choices for expansion. Vendor APIs should feed the owner's warehouse, not the other way around.
DePriest's perspective surprised some attendees. He's not anti-vendor. He's not pushing for owners to build everything themselves.
Point solutions aren't bad—as long as they have clean APIs and you own your data layer.
The architecture McKesson aims for:
This aligns with broader industry movement toward open-source operational technology and building management systems. Owners increasingly recognize that the overarching need is for a unified approach to connect disparate building systems, with IT departments showing preference for open standards in APIs and MQTT.
But "open" has become a four-letter word in this industry. Vendors slap "open API" on marketing materials while maintaining proprietary data models, undocumented endpoints, and integration paths that only work with their preferred partners.
DePriest's LinkedIn post used intentionally careful language when discussing what "open" should mean:
Entirely vendor-neutral specifications. Governed by industry-recognized open bodies. Freely and openly developed—not controlled by a single vendor calling the shots.
The difference matters. An API that requires vendor permission to access your own building data isn't open. An API that only works with the vendor's cloud platform isn't open. An API that changes without notice and backward compatibility isn't open.
The framework building owners need comes down to due diligence questions. Ask before procurement, not after implementation fails.
Does your API have publicly accessible documentation?
Not a PDF you email to prospects. Public documentation that developers can access, search, and reference during implementation.
Is there an OpenAPI or Swagger specification?
An OpenAPI specification compatible file allows description of a complete REST API, generally written in YAML or JSON file format. If the vendor can't produce this, they're not serious about integration.
Can you show me a live example or code sample?
Working samples, not pseudocode. Something a developer can copy, modify, and run.
Do you provide a sandbox environment?
Every change to production carries risk. Owners need safe testing environments. If the vendor doesn't provide this, factor in the cost of building your own.
How do you handle version control?
Some companies only provide documentation for the latest API version, meaning that clients consuming older API versions cannot find relevant information. Vendors should support multiple versions concurrently and provide clear deprecation timelines.
What happens to integrations when your API changes?
Will existing integrations break? How much advance notice do you provide? What's your backward compatibility policy?
What historical data is available through the API?
Many vendors only expose current state. If you need trend analysis or time-series data, confirm the API provides it.
Who pays when things break?
This question reveals vendor accountability. If their API changes break your integration, who bears the cost of fixing it?
Each question traces back to pain points DePriest and his industry colleagues have experienced. They're not theoretical. They're the difference between a $15,000 integration and a $200,000 disaster.
"An API is like plumbing—keep your pipes clean," DePriest said in his closing remarks.
The metaphor captures something essential. Good plumbing is invisible. It works. Water flows where it should, when it should, without anyone thinking about it. You only notice plumbing when it fails.
Bad plumbing? Everyone notices. Water goes the wrong direction. Pressure drops. Things leak. Costs multiply.
Building owners must treat integrations as ongoing infrastructure, not one-time line items. Technical debt grows faster without proper maintenance. A security incident after two years of neglected updates can cause four days of system downtime and millions in lost revenue. Plan for governance. Budget for versioning and iteration. Manage APIs like products that require care and feeding.
The future belongs to buyers who demand:
When vendors oversell APIs, the costs fall on owners. When owners ask the right questions up front, they avoid the fruit-salad scenarios that never should have happened.
The vendor pitch sounds great: "We have an API, so integration will be simple." But as DePriest demonstrated, having an API tells you almost nothing about whether it will actually work in your environment.
Before signing any contract that promises API integration:
Stop assuming all APIs are created equal. They're not. Quality ranges from gold-standard platforms like Twilio to barely-documented endpoints that will cost you six figures to integrate.
Ask the due diligence questions listed above. If vendors can't answer them clearly, that's your answer. Walk away or budget for the true cost of making their API work.
Insist on owning your data layer. Don't let vendors trap your historical data in their platform. Pull it into a warehouse you control. Your future self will thank you when you need to switch vendors or answer questions about portfolio changes over time.
Plan for API maintenance as an ongoing cost, not a one-time expense. The Total Cost of Ownership includes initial build costs plus annual maintenance, vendor fees, and infrastructure costs over a three-year period. That $80,000 integration might really cost $125,000 when you factor in three years of support.
Consider point solutions with clean APIs over all-in-one platforms. The best tool for each job, connected through open APIs into your data layer, gives you flexibility that monolithic platforms can't match.
The smart building industry is moving toward more open systems and protocols. But "open" has to mean something beyond marketing language. Demand the real thing: vendor-neutral specs, public documentation, stable versioning, and data ownership that stays with you.
DePriest's tomato framework remains useful even after the presentation ends. Intelligence—knowing a vendor has an API—is common. Wisdom—knowing whether it belongs in your stack—is rare. Building owners who develop that wisdom avoid the expensive mistakes others keep making.
This article is based on Drew DePriest's presentation at NexusCon 2025. DePriest is MCR.w, WELL AP, and Director of Real Estate Operations Technology at McKesson.
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.
This is a great piece!
I agree.