In our past discussions, we’ve unpacked some big themes:

• Why API reusability matters
• How APIs and agentic AI fuel innovation
• The flywheel effect of effective reuse

For the final post in this series, I want to share some advice on how to make this all real, and discuss ways I’ve seen enterprises move from theory to a practical, scalable API program that actually delivers on its promise. This isn’t just a tech conversation. It’s about business strategy, culture, communication, and even a bit of marketing.

Why APIs Need to Be a Business-First Strategy

Modern enterprises run on APIs. When reviewing some of the more sophisticated and evolved API standards, they typically have around 100 to 150 resources defined.  Your business likely has at least this many resources that are being digitally stored, managed and shared.

While the actual design and deployment of APIs resides with technical teams, the conversation must start with business goals: Where are we going? What new capabilities or efficiencies do we need? Analyzing your domains and identifying the concepts, behaviors and relationships of the various resources in your organization is a task that requires intimate business knowledge. Further, it requires knowledge not just how the resources are being used currently, but how business objectives and strategies will change the resource utilization.

Here’s what business-first API strategy really means:

• Prioritize APIs that create momentum—for customers, partners, or employees.
• Evolve governance from rule-setting to value-enabling.
• Treat APIs like products, not just integration tools. That means thinking about users, feedback loops, and ongoing improvement.

Some organizations even have API product owners or API executives—people who bridge the gap between business vision and engineering execution. Whether that role sits in Enterprise Architecture, Product, or IT, the point is clear: APIs need a seat at the strategic table.

However you place this within your organization, you want someone with the creativity to ask, “how can I use this technology to drive customer engagement, open new channels, or generate revenue?” and the subsequent business acumen to fund and implement these strategies.

Marketing APIs: Speak the Business Language

One of the biggest blockers to API adoption is effectively communicating your APIs’ value. Not enough people know what APIs are for, let alone how they can help.

Tech companies like Amazon and Google have demonstrated the huge rewards that can be realized by going all-in on APIs, but their audiences were already technically fluent. Other companies that are more “traditional” may not find business partners that understand the technology that deeply. 

Consider reframing your messaging in an API marketing and education program that puts APIs into language that business can relate to:

• Don’t say “RESTful API with OAuth2.” Say “new partner integration in two weeks instead of two months.”
• Don’t talk about payloads. Talk about customer reach, faster onboarding, and reduced manual work.
• Avoid acronyms. Aim for outcomes.
• Focus on communicating connectivity, partnership, channel expansion and even revenue opportunities.

Start with your customer-facing teams— Sales, Marketing, Customer Service, and Product Strategy. These are the people that will hear the demand from external consumers first, and you want to make sure they understand what they are hearing and can bring that demand to the API developers and product owners.  Additionally, these are the people that see impact of external need and might provide the creativity of new product APIs that become significant revenue generators.

Secondly, focus your developers on creating APIs for all new resources and consuming reusable APIs.  Additionally, this type of campaign should help your developers better understanding the organizational definition of robust, high-quality APIs, and the necessity for the necessity developing to that definition.   

Use your marketing internal marketing to build trust with your business partners.  Set delivery goals that are aligned with business expectations and meet those expectations. Share real metrics, those that demonstrate the security and robustness of the APIs in the catalog as well as consumer adoption and use. If you can report that some high percentage of APIs meets SLA excellence, that consumer responses (stars if you will) are very positive, and that security breaches are extremely small, you will grow trust in your API products and continue to promote use. 

Keep in mind that all of this information should be readily available in your API catalog and API management solutions and can be pulled out and packaged for distribution. On top of sharing this type of delivery and security success, make sure the business opportunities that are enabled are widely shared across the organization.

Rethinking External API Marketing

Most companies put APIs behind a “Developer” tab on the website and call it a day. That’s not enough.

If APIs are products, we need to market them like products. Ask yourself:

• Can users easily search and explore your API catalog?
• Do you proactively promote new APIs or improvements?
• Are you tracking what users need, not just what you’ve built?

Your API portal should feel more like a digital storefront than a document dump. If you’re not there yet, talk to your API platform provider about features like search, personalization, and notifications. Look at how your portal can be promoted to your customers and potential customers.  Is there intelligence built into your catalog and portal to drive this type of marketing?  Make it easy for partners, developers, and internal teams to find, evaluate, and gain access to APIs that fit their use cases.

Building an API Strategy: Where to Start

If you don’t already have an API strategy, perhaps you are looking for a framework or place to start from.  As in any strategy you need to understand your current situation before you can define some go ahead strategy.  You might want to consider assessing your API status using the following dimensions. 

Use this framework to spot gaps, prioritize action, and fund your API roadmap in a way that drives maturity and measurable value. For instance, if your investment and capabilities for security are so far beyond the norm for your industry, perhaps you want to shift funding to other areas of your API strategy for a while.

What Makes a Catalog of Robust and “High-Quality” APIs?

Throughout this series, robust, high-quality APIs have been mentioned without explicitly defining what that means. If you’re wondering what “good” really looks like, here’s a starter checklist for a high-quality API:

Business Aligned

Does the API map to some resource of your business?  Think of this in terms of how the resource is defined in my organization.  Not, how do I think of this resource for this current use case.  If your business is selling widgets and you don’t have APIs that provide information about the widgets on offer, the current inventory of widgets and an Order API you really need to ask why.

Uniqueness

Your catalog should not be cluttered with overlapping APIs.  These provide noise for consumers to filter out, create a larger surface area for malicious attack, eat up resources that could be more effectively used. 

Documentation

The business purpose and semantics of the API, its operations and attributes should be complete, clear and explicit.  Additionally, consumers should be provided with operational metrics that identify the performance metrics of the API.

Maturity Level

Using the Richardson Maturity Model for APIs, offering a FHIR API that only supports ‘GET’ on a resource and lacks Hypermedia capabilities is limited. This is especially true given the increasing use of AI Agents to consume APIs. Keep in mind that this model will likely need to evolve alongside Agentic APIs.

Availability

APIs should be discoverable in a catalog, with accessible credentials and test APIs available. While scalability to new consumption is expected, extreme new consumption should be handled through an exception process rather than as the rule.

Completeness

In addition to the clear and comprehensive API documentation and specification, efforts should be made to ensure resource APIs map to the complete resource, including attributes, behavior, and relationships. If version 1 is not complete, have a release plan to achieve completeness soon. 

Robustness

Not only should your APIs performance metrics be available they should also reflect performance and availability statistics that show your consumers that they can have confidence in using the API for their purposes.

Secure

Ideally, APIs should use advanced trust-based mechanisms and have capabilities for active scanning, proactive responses to various detected threats.

Under Management and Governance

A product owner should take responsibility for the API lifecycle, with governance processes ensuring adherence to API quality, maturity goals, architectural, and security policies.  All of your APIs should be known – APIs that are not catalogued and managed represent significant risk and resource depletion.

Consumer Rated

Consumer ratings should be consistently high, and there should be a capability to capture and share consumer feedback about APIs.

So How Do You Get There?

If you are starting from scratch and there is an existing industry standard you should probably default to that standard first and deviate only when necessary.  However, it is far more likely that you already have APIs, and you probably already have duplicate APIs and are now wondering, “How do I achieve a catalog of reusable, high-quality APIs?”. The goal isn’t more—it’s better.

Start here:

1. Audit your APIs. Find the ones that shine—make them your gold standard and migrate as much as possible to using that API and enhancing that API rather continuing investment into “lesser” APIs.
2. Promote and reuse. Encourage teams to build on what works.
3. Cull the clutter. Deprecate overlapping or low-value APIs. Move redundant APIs into a “deprecate” state so that you don’t invest further in those APIs and, when consumers need upgrades, migrate them to reusable “gold-standard” APIs. 
4. Fill the gaps. Create what’s missing, based on real business needs and tapping API product managers and/or your product council to identify missing resource APIs.
5. Version responsibly. Improve without breaking. Keep in mind you don’t have to get it all done in version 1.
6. Invest strategically. Use your maturity framework to guide funding.

Closing Thoughts

I’d like to end this series on a more personal note – I really hope that some of this is helpful insight.  One of my favorite business partners to work with on APIs was a sales executive who had little understanding of the technology but really got the business impact.  This made for a great partnership. 

Creating that technically aligned business, business aligned technical personnel is so important to IT and business organizations. 

I hope you’re capturing that theme in these blog pages as well as the belief that APIs can really deliver more value than most organizations are currently deriving from them.