In our recent State of the Market API Economy Report, produced by apidays for their sponsor Boomi, we identified 5 key API Economy trends that will evolve the landscape across 2025.

Here on our blog, we will provide a little more detail on our thinking behind each of the trends, starting with Trend 1:

You can also download the full report from apidays.

Trend influencers: Regulations, Standards and Federation

The role of regulations

Global regulations in the digital age are increasingly stipulating that data must be shared or accessed by other actors within and across industry sectors, while also aiming to shift traditional imbalances of power amongst existing industry stakeholders to foster greater competition and choice. Alongside these regulations are industry transformations (such as improved data governance and new interoperability tooling) that seek to codify these regulations. This has occurred most notably with banking , but is also occurring in the health, telecommunications, agriculture, and energy sectors.

Europe is often unfairly seen as stifling innovation by over-regulating. While there are plenty of examples of complexity in regulations that need further clarity, Europe has been a world leader and inspiration for other countries in modelling how to find a balance between the needs of citizens and local businesses and the need to reduce power imbalance risks with the introduction and scaling of new technologies and digital approaches. That balance hasn't always been achieved, and the recent Draghi report on EU Competitiveness is set to shape the agenda going forward.  (I plan to do a deep dive into the Draghi report before the end of the year: please contact me if you would like to discuss more).

Regulations that enable data sharing, advance interoperability,  restrict monopolisation, and that explicitly call for APIs have led to market expansion and innovation. Globally, as part of our API economy data analysis, so far we are tracking 71 regulations that explicitly state that APIs should be used to enable interoperability, to share data, and to enable composable services to be built. That is, there is recognition that APIs should be created as part of a country's digital public infrastructure and stakeholders in particular sectors are required to make APIs available in order for that infrastructure to then enable open ecosystems to be cultivated on top of this. 

Often, APIs are not specifically mentioned in regulations for several reasons:

• Policy-makers are unaware of technology choices or uncomfortable with digging too deep into describing them in regulatory mechanisms, and instead speak in broader terms of data exchange or secure data sharing, or interoperable systems, and so on
• There is a mistaken belief that by stating any specific technological approach, that it will quickly date regulations if there is a new technology that comes along
• There is some fear of upsetting legacy approaches: so if regulations mention specific technological approaches such as APIs, that this will augment technical debt by requiring existing solutions and approaches to be rebuilt to meet the new regulatory environment.

However, we do have examples that show that if APIs are not specifically mentioned, then implementation teams will choose a wider array of options or build new approaches that splinter and fragment industry sectors even further, reduce interoperability and the potential for future-proofed systems, or create stagnation. In Europe, for example, a regulation that required public services to identify and expose government high value datasets initially stagnated for years, as governments grappled with how that data should be made available. It also helped obfuscate other political decision-making, for example, public service department reluctance to share data publicly could hide behind the confusion in how to enable data sharing. A review of the regulation found that implementation had been severely curtailed, and a new regulation was introduced that explicitly stated that high value datasets should be released "via APIs". This recognised the technology solution without overly restricting future potential developments or increasing technical debt.

With APIs, there are a range of protocols and approaches that can be taken: SOAP is a legacy format that is too convoluted to use in the present day, but a lot of government and traditional industries have already built SOAP APIs. REST is the most common format at the moment, with newer approaches like GraphQL and gRPC, alongside methods focused on real-time event-driven triggers also gaining prominence. Stating "by APIs" in regulations doesn't limit these choices, but it does prevent someone from proposing a whole new method of data exchange or using methods like bulk downloads that are brittle and introduce confusion around the single source of truth for data (for example, am I using the latest downloaded dataset?).

While I reference European regulations most often, we do analyse a global regulatory environment: for example, the US health regulations around APIs are world leaders and new Consumer Financial Protection Bureau regulations are requiring data exchange (although they have fallen into the trap of avoiding mentioning APIs instead preferencing the oblique term 'developer interfaces'); UK has a number of relevant regulations although APIs might not be specifically stated; India has regulated the India Stack as the core public digital infrastructure; and Brazil is a world leader in APIs for health, banking, insurance and so on. Speaking with businesses and multilateral organisations of all sizes, however, suggests that most do look at benchmarking themselves and their regulatory compliance systems against Europe: it is often the most detailed and advanced, so the feeling is if they meet European requirements, they will be able to adhere to other global regulatory environments with the same data systems.

Some of the regulations that mention APIs include:

• In the United States, the 21st Century Cures Act requires APIs to enable access to electronic health records programmatically, without special effort.
• In Brazil, open banking regulations require APIs to be used for data sharing
• In Europe, the Digital Markets Act requires "gatekeepers" (that is bigtech platforms with millions of users) to make APIs available for data portability. 
• In Australia, the Consumer Data Right legislation requires data holders to make data available to consumers/users via API.

In 2025, we expect to see more regulations specifically mention that data exchange and services should be exposed via API.

The increased adoption of standards

Concurrently, industry leaders are often working together to improve standards to enable interoperability and provide clarity around data models and web services. With recognition that over 4,000 new standards "will be needed to keep pace with the transformation of the global economy as digitalisation accelerates over the next 10 years"¹, industry is shifting its mindset.

There are two types of standards that we are seeing influence digital transformation and adoption of APIs in industry sectors:

• API standards bodies that set norms for building APIs
• Industry standards that recognise the role of APIs in data exchange and service exposure.

API standards bodies that set norms for building APIs

This includes:

• OpenAPI Specification (OAS) standards for defining and designing REST APIs
• AsyncAPI standards for realtime, event-driven APIs,
• GraphQL for graph-based APIs , and so on.
• In addition, bodies like the World Wide Web Consortium and IETF also publish standards on APIs, and documenting building blocks for APIs.

Amongst API specific and protocol standards, some significant advances have occurred over the past year:

• OpenAPI introduced the Arazzo specification to support API workflows and the Overlay specification to augment an OpenAPI description.  
• OpenAPI has also released version 3.1.1 of their specification.
• GraphQL hosted a major user conference.
• GraphQL is currently working on an updated draft of their standards.
• AsyncAPI released version 3.0.0 at the end of 2023 and maintains a detailed roadmap outlining current and future priorities.
• gRPC also hosted a conference in 2024 and updated a lot of their user tutorials and documents in July 2024.

Industry standards that recognise the role of APIs in data exchange and service exposure

In part because of the maturing of API protocols and standards, industry standards bodies are increasingly defining how data exchange or digital services should be designed, and these may include standards for APIs specific to their industry. These, at times, reference the above API standards that should be followed.

For example, the following industry standards include standards requirements that APIs be described with an OpenAPI Specification file, with some also include standards requirements on using AsyncAPI and GraphQL:

• International Air Transport Association (IATA) standards
• Open Banking standards bodies in UK and Brazil
• Open Transport standards body
• National Health Service standards in UK, Health New Zealand standards, and standards published by the US Office of the National Coordinator of Health Information.

In our various industry work analysing digital transformation and the growth of platform and ecosystem approaches, we have seen that while regulations often do create an impetus for new market entry and innovation, it is a focus on interoperability and the adoption of standards that enables this to scale while also allowing non-regulatory environments to welcome in new entrants.

Industry approaches to standards

We are observing other indicators that industry standards are impacting on the API economy:

• New industry sectors are increasingly proposing the use of interoperability, open source, and open standards approaches to generate open ecosystem environments (although there are also  some examples of "open washing" as our guest policy writer Mariam Sharia pointed out at the start of 2024).
• Some sectors that had a high level of maturity regarding the development and adoption of standards, such as voluntary sustainability standards in traceability of commodities in the supply chain sector, are now seeing regulations introduced in their sector (such as due diligence regulations) that in future will require APIs to share data and enable regulatory reporting at scale.
• Industry players in some sectors that traditionally sought to build walled gardens, such as the home automation and facilities management sectors, are now coming together to define interoperability solutions to support growth (for example, the Coalition for Open Digital Ecosystems in Europe and the Connectivity Standards Alliance bring together companies that had previously been notoriously focused on creating walled technologies for the Internet of Things).
• New data sharing regulations in health and advancements in personalised medicine are pushing standards to become more interoperable in order to build datasets that can be used to drive new innovation, in particular with standards like FHIR and openEHR seeking to find common ground for aggregating data from electronic health records.
• Social media is facing an unbundling and reckoning as widespread dissatisfaction with big tech social media options like the extreme right takeover of Twitter giving rise to an unbundling of digital public spaces and increasing interest in interoperable standards-based solutions such as Bluesky and Mastodon, which in turn creates greater awareness of the potential for decentralised, interoperable tech solutions that better enable users to carry their data where they want and to co-create their own solutions².

Federation: Enabling organisations and developers to use multiple types of APIs

The need for APIs to align with regulations, standards and protocol advances has led to an approach referred to as 'federated API management'.  Steve Lucas, CEO at Boomi describes federated management as an approach that gives customers "the ability to quickly provision, discover, secure, and infinitely scale in one end-to-end enterprise platform.” This includes drawing on APIs of different protocol types, for example, using both REST and event-driven architecture APIs. API management providers like Kong and Gravitee are also doubling down on federated API management approaches, which has helped spur both further into the leadership quadrant according to Gartner's most recent API Management analysis³. IBM's API Connect also enables federated management, focusing on enabling GraphQL and REST APIs to be managed together, for example.

But overall, tooling in the API space is still fairly protocol-specific. Apart from API management solutions, many tools focus on one or two specific protocols only. out of 966 tools that specifically mention which protocols/types of APIs they function with, 887 mention REST APIs. Only 1 in 5 tools can work with more than one protocol.

The API Landscape is also looking at how to expand the directory of tooling for various protocols, with just 56 tools at present listed that are specifically designed to support API protocol activities (mostly for OpenAPI tooling, but there are some GraphQL tools included, although we know there are more to catalogue). If you are interested in helping support this work or would like to update your own tooling, please get in touch.

From platforms to ecosystems

With regulations being introduced to better govern and grow digital spaces, industry acceptance of standards as a means to enable interoperability and support faster digital product growth, and the rise in digital infrastructure and greater use of data, many organisations are realising the need to adopt an ecosystem approach that seeks to understand when to compete, when to collaborate with partners, when to focus on co-creation with API and data consumers, and when to coordinate around challenges like standards and interoperability.

There is a growing recognition that organizations cannot provide everything to all people. This occurs in digital businesses where organisations rely on others for specific infrastructure (like payments infra or specific datasets), and especially in regulated industries that seek to address complex, wicked problems that face society (problems like financial inclusion and financial wellbeing, population health and health equity, climate crisis responses, and population movement and globalization, for example).

Organisations are understanding they need to take an ecosystem approach to understanding the context in which they are operating and will need new partnerships that support complying with regulations, defining and adopting standards, accessing digital components as the raw materials they need to use in their own products and services,  onboarding co-creators that experiment with innovation and help build for new customer markets, being present in marketplaces and distribution channels to help promote and make products and services available and so on...

Thinking from an ecosystem approach draws on some market research type activities that an organization may have used in the past to understand user/customer needs or to map competitors, but ecosystem approaches go beyond that to also understand the operating context and identify potential partnerships. This has given rise to ecosystem design practices, starting with an organisation defining their own role and position in an ecosystem. (For API providers, it may mean thinking beyond traditional publishing of APIs to the use of API contracts as a means to explaining to potential partners and other external stakeholders how to participate in your API ecosystem.)

Where ecosystems sit on the Gartner Hype Cycle

But understanding ecosystems will require new tooling and approaches. The Gartner Hype Cycle places business ecosystem modeling and partner ecosystem management platforms at the very start of the Hype Cycle, with expectations for maturity over the next 2-10 years. Harnessing benefits from existing business ecosystems is seen as at the peak of inflated expectations, with predictions of heading into the trough of disillusionment over the next 2-5 years. How long that will actually take before rising on the slope of enlightenment will depend on the availability of tooling and resources to support training and literacy in ecosystem-based approaches.

We are already seeing a growing discussion and recognition of the importance of ecosystems. Where businesses talked about becoming platforms several years ago, they now speak of building out ecosystems, or participating in the open ecosystems created on top of digital public infrastructure like payments and digital identity⁴.

2025 predictions

What I expect to see next (and what Platformable will help build in 2025) are catalogues, dashboards and ecosystem resources that bring together these aspects outside of a federated API management solution. We need tooling and knowledge platforms for each industry that lists relevant regulations, standards, API style guides and norms, open data models and schema, and so on in one place to support businesses to conduct their own ecosystem modeling and for developers to create solutions that adhere to API standards alongside industry standards and regulations. We will be releasing examples for banking/finance, health and supply chain traceability in the coming month.

Ecosystem business modeling, tooling to map ecosystems, and new ways to understand the landscape of stakeholders that influence digital transformation, data exchange, web service adoption and interface design will grow in importance over the next year. New business growth will come from understanding who to co-create or collaborate with, who will be a competitor, and when competitors and collaborators need to coordinate to enable interoperability.

Addressing this API Economy Trend: Where to Start

For Data and API consumers

Understand what regulations and standards impact on your industry sector and seek out API providers that are addressing compliance and interoperability.

For Data and API providers

Adopt ecosystem design practices to better understand the standards bodies, data models and providers, regulatory authorities, and potential collaborators that will seamless use of your APIs internally and externally.

For Data and API tools providers

Understand emerging regulations and standards in your industry use cases, look at interoperability opportunities, consider how to ensure multiple API design patterns/protocols can make use of your products (or how they will acknowledge the existence of other API patterns, even if your tooling does not directly offer solutions). Consider building tools that position your products and services in a wider ecosystem, for example, in your industry are there open standards or data models that you need to assist customers to use alongside your own tooling product?