Global API Economy Competition and Standardization Issues

1. Introduction

The API economy refers to the economic ecosystem in which application programming interfaces (APIs) allow software applications, platforms, cloud services, financial systems, devices and data repositories to communicate with one another.

APIs have therefore become a form of digital infrastructure. Control over an important API can determine:

• which competitors can interoperate with a platform;
• which data can be accessed;
• what technical standards competitors must follow;
• whether users can switch between services;
• how third-party developers reach customers;
• whether complementary products can enter a market; and
• whether a dominant platform can extend its market power into adjacent markets.

Competition law consequently faces a difficult question: when does legitimate technical standardization become exclusionary standardization?

A standardized API can reduce transaction costs and promote interoperability. Conversely, a dominant undertaking may design, restrict, degrade, modify or selectively expose APIs in ways that increase switching costs and exclude rivals.

2. Meaning of API Economy Competition

The API economy has several interconnected competitive layers.

A. API ownership

A platform may control the technical interface through which third parties access:

• data;
• functionality;
• authentication;
• payments;
• search;
• advertising;
• cloud resources;
• operating-system functions; or
• artificial-intelligence models.

Control of the interface can therefore become control over access to an ecosystem.

B. API access

A platform may determine:

1. who receives API access;
2. what functions are available;
3. how frequently calls may be made;
4. what data can be retrieved;
5. whether commercial use is permitted;
6. whether access is free or paid; and
7. whether access can subsequently be withdrawn.

C. API standards

Standards may concern:

• authentication;
• data formats;
• communication protocols;
• identity;
• payments;
• cybersecurity;
• interoperability;
• metadata;
• developer documentation; and
• API response structures.

D. API governance

The entity controlling a widely used API may effectively become a private rule-maker for an ecosystem.

This produces a competition concern when technical governance determines commercial opportunities.

3. Why Standardization Can Promote Competition

Standardization is not inherently anticompetitive.

A common API standard can:

• reduce integration costs;
• facilitate interoperability;
• permit multi-homing;
• lower barriers to entry;
• increase consumer choice;
• encourage innovation by complementary businesses;
• improve security;
• make services portable; and
• prevent fragmented technical ecosystems.

For example, a common payment API can allow numerous merchants and financial-service providers to connect without individually negotiating a completely different technical architecture.

Thus, competition authorities generally need to distinguish open and pro-competitive standardization from strategic standardization designed to foreclose competition.

4. Major Competition Problems

A. API foreclosure

A dominant platform may refuse competitors access to an API that is important for competing with the platform.

The competitive theory is similar to an essential-input or interoperability problem.

Potential harm arises where:

Platform dominance → API control → restricted interoperability → rival disadvantage → reduced competition.

However, not every refusal to provide an API constitutes abuse. Competition authorities normally have to examine factors such as indispensability, feasibility, objective justification and effects on competition.

5. API Discrimination

A platform may provide API functionality to its own affiliated service on better terms than to competing third parties.

Examples include:

• higher API rate limits for the platform's own service;
• earlier access to new API functions;
• superior data fields;
• lower latency;
• preferential authentication;
• greater reliability;
• preferential API pricing; or
• access to information unavailable to rivals.

This can create a vertical discrimination problem.

The competitive concern is particularly strong where the platform simultaneously operates downstream businesses that compete with API-dependent firms.

6. API Degradation

An API does not have to be completely blocked to produce anticompetitive effects.

A dominant platform could theoretically:

• increase latency;
• reduce rate limits;
• remove functionality;
• introduce technical incompatibilities;
• change authentication requirements;
• make documentation less usable;
• restrict data fields; or
• introduce unstable interfaces.

This may constitute de facto exclusion even where formal API access continues.

The relevant comparison is therefore not merely:

"Does the rival have API access?"

but also:

"Is the API access commercially meaningful and technically equivalent?"

7. API Versioning and Competitive Lock-In

API versioning is essential for legitimate software development.

However, frequent or strategically timed API changes may create:

• migration costs;
• developer dependency;
• compatibility burdens;
• sunk integration costs;
• technical debt;
• switching costs; and
• ecosystem lock-in.

A dominant platform might maintain a proprietary API architecture such that developers must repeatedly redesign their applications whenever the platform changes its technical specifications.

This creates a potential dynamic lock-in problem.

8. API Standards as Barriers to Entry

Technical standards can indirectly become entry barriers.

Suppose a market uses a dominant API standard that requires:

• expensive certification;
• proprietary credentials;
• specialized infrastructure;
• access to confidential technical information; or
• compatibility with proprietary software.

A new entrant may face substantial costs before it can compete.

The competition-law question becomes whether the standard reflects objective technical requirements or has been designed to protect incumbency.

9. Standard-Essential APIs

Traditional standard-essential-patent theory primarily concerns patents incorporated into technical standards.

The API economy creates a broader question:

Can an API itself become economically indispensable even when it is not legally patent-essential?

This may occur where a dominant platform's API becomes the de facto industry interface.

Its economic importance can result from:

• network effects;
• developer adoption;
• accumulated integrations;
• user expectations;
• interoperability requirements; and
• switching costs.

Thus, economic essentiality may arise independently of formal standard-setting.

10. Network Effects

API ecosystems frequently exhibit strong network effects.

More developers using an API can produce:

More integrations → more users → more complementary services → greater developer incentives → still more integrations.

This can create a feedback loop favouring an incumbent.

Once an API becomes sufficiently widespread, competing API standards may struggle to gain adoption even if they are technically superior.

This is sometimes described as standard-induced path dependence.

11. API Interoperability and Market Power

Interoperability is particularly important in:

• cloud computing;
• social networking;
• messaging;
• payments;
• digital identity;
• operating systems;
• app stores;
• advertising;
• AI services; and
• enterprise software.

A dominant undertaking may gain competitive advantage by controlling the interface between its ecosystem and competing ecosystems.

The resulting issue is not simply access to technology, but access to the market architecture itself.

12. APIs and Data Portability

APIs increasingly provide the mechanism through which consumers or businesses transfer data.

Examples include:

• banking APIs;
• health-data interfaces;
• cloud migration APIs;
• advertising data interfaces;
• enterprise SaaS APIs; and
• social-media portability tools.

A technically available but practically unusable portability API may provide formal portability without effective portability.

Competition law therefore increasingly has to consider the quality, completeness, speed and cost of API-enabled portability.

13. API Pricing

API providers can monetize access through:

• per-call charges;
• subscription fees;
• volume tiers;
• data-access fees;
• compute charges;
• minimum commitments; and
• revenue-sharing arrangements.

Pricing becomes a competition concern where a dominant platform uses API charges to disadvantage downstream rivals.

Potential theories include:

• excessive pricing;
• margin squeeze;
• discriminatory pricing;
• predatory pricing;
• tying;
• exclusionary rebates; and
• discriminatory access conditions.

14. Margin Squeeze in API Markets

Consider a platform that supplies API access to downstream competitors.

If the platform charges rivals a high API price while providing its own downstream business with the same input at an economically favourable internal cost, rivals may be placed in an artificial competitive disadvantage.

The basic structure becomes:

Wholesale API price ↑ + downstream competitive price constrained → rival margin squeezed.

This makes traditional margin-squeeze principles potentially relevant to digital API ecosystems.

15. Tying and Bundling

APIs can facilitate technological tying.

A dominant provider might require developers to use:

• its authentication API;
• its payment API;
• its cloud API;
• its advertising API; or
• its identity API

as a condition for accessing another service.

Competition concerns arise when separate products become technically bundled in a way that prevents competitors from supplying the tied component.

16. Self-Preferencing Through APIs

Self-preferencing may occur at the technical rather than visual level.

For example, a platform could give its own application:

• privileged API endpoints;
• superior data access;
• lower latency;
• higher transaction limits;
• early API releases; or
• preferential system permissions.

The result can be algorithmic or infrastructural self-preferencing.

This is particularly important because conventional antitrust analysis may focus on rankings or search displays while overlooking the underlying API architecture.

17. API Governance and Private Regulation

A dominant API provider may effectively determine:

• eligibility;
• technical standards;
• access conditions;
• compliance requirements;
• developer permissions;
• data architecture;
• security rules; and
• acceptable uses.

The platform consequently performs a quasi-regulatory function.

This raises a broader competition-law question:

Can control over a technical standard become a form of private market governance?

The answer becomes especially important where the API serves an entire industry.

18. Six Important Case Laws

1. Microsoft Corp. v Commission — EU

European Commission, Microsoft interoperability case

Microsoft's refusal to provide sufficient interoperability information concerning its work-group server products became a landmark European competition-law case.

The case established important principles concerning interoperability and exclusionary conduct by a dominant undertaking.

Relevance to APIs

Although the case predates today's API economy, its logic is highly relevant where a dominant digital ecosystem controls technical interfaces necessary for competing products.

It demonstrates that:

• interoperability can have competition significance;
• technical information can constitute an important competitive input;
• exclusion may occur through technical restrictions rather than traditional pricing; and
• proprietary interfaces can reinforce ecosystem dominance.

2. Bronner v Mediaprint — EU

Oscar Bronner GmbH & Co. KG v Mediaprint

This case established the restrictive conditions associated with the EU essential-facilities doctrine.

The Court emphasized that refusal to supply an input becomes abusive only under demanding circumstances.

API significance

The case is important for API access disputes because it prevents competition law from automatically converting every commercially important API into a mandatory shared facility.

Questions include:

• Is the API indispensable?
• Is duplication realistically possible?
• Would refusal eliminate effective competition?
• Is there an objective justification?

Thus, API indispensability must be demonstrated rather than presumed.

3. IMS Health — EU

IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG

The dispute concerned access to a pharmaceutical data structure protected by intellectual-property rights.

The Court developed important conditions concerning compulsory access to protected infrastructure.

API significance

IMS Health is relevant to proprietary API structures because it illustrates the tension between:

intellectual property + interoperability + competition.

A proprietary API provider can argue that its interface represents legitimate innovation and intellectual property.

A competition authority may respond that refusal to provide access can become problematic where the relevant technical structure is indispensable for effective competition and satisfies the applicable exceptional circumstances.

4. Slovak Telekom — EU

European Commission and Slovak Telekom

The case involved access conditions relating to telecommunications infrastructure and margin-squeeze/exclusionary conduct.

The Court's jurisprudence is particularly relevant to vertically integrated infrastructure providers.

API significance

Modern APIs frequently occupy a similar economic position to infrastructure inputs:

platform → API/input layer → downstream applications.

Where the platform controls the upstream API and competes downstream, discriminatory or economically unreasonable access conditions may potentially create foreclosure.

5. Google Shopping — EU

European Commission v Google / Google Shopping

The Google Shopping litigation concerned Google's treatment of its comparison-shopping service within its search ecosystem.

The case is important for understanding how a dominant platform can use control over a critical digital interface to advantage its own downstream service.

API significance

The broader lesson extends beyond search rankings.

Digital platforms may possess multiple layers of control:

• interface;
• data;
• algorithms;
• APIs;
• infrastructure; and
• downstream services.

Competition analysis therefore increasingly has to examine technical architecture rather than merely consumer-facing screens.

6. United States v Microsoft Corp.

United States v Microsoft Corp.

The Microsoft antitrust litigation is one of the foundational cases concerning technological platform power.

Microsoft's conduct involving Internet Explorer, Windows and software developers demonstrated how a dominant platform can use control over an ecosystem to disadvantage competing technologies.

API significance

The case is highly relevant to the API economy because APIs can function as ecosystem-control mechanisms.

A dominant platform may use technical integration to:

• reinforce entry barriers;
• increase developer dependency;
• disadvantage rival technologies;
• make alternative platforms less attractive; and
• preserve network effects.

19. Additional Relevant Authorities

Several other authorities are useful when analysing API competition.

Google Android — EU

The Android case is relevant to questions involving:

• tying;
• interoperability;
• defaults;
• ecosystem restrictions;
• app distribution; and
• platform leverage.

Apple App Store Litigation

The various Apple-related antitrust disputes provide important examples concerning:

• API access;
• platform rules;
• payment interfaces;
• developer restrictions;
• alternative distribution; and
• ecosystem control.

Qualcomm — EU/US

Qualcomm litigation demonstrates the importance of technology licensing, vertically related markets and exclusionary strategies in technology ecosystems.

Huawei v ZTE — EU

The telecommunications standard-essential-patent litigation is relevant to the relationship between technical standards, interoperability and intellectual-property rights.

20. Standardization Through Industry Consortia

API standards are often developed by:

• standards organizations;
• industry consortia;
• cloud providers;
• financial institutions;
• technology alliances; and
• government-backed technical bodies.

Standardization can become problematic if incumbents manipulate the process.

Potential risks include:

A. Exclusion from standard-setting

Small competitors may be prevented from participating effectively.

B. Information asymmetry

Large firms may possess technical information unavailable to smaller participants.

C. Strategic specification

A standard may contain technical characteristics disproportionately benefiting an incumbent's existing infrastructure.

D. Proprietary extensions

An ostensibly open standard may be accompanied by proprietary extensions that restore incumbent control.

21. Open APIs vs Closed APIs

Neither model is automatically lawful or unlawful.

A closed API may be justified by:

• cybersecurity;
• privacy;
• fraud prevention;
• reliability;
• intellectual property; or
• legitimate commercial strategy.

The competition concern arises where restrictions lack credible justification and materially foreclose competition.

22. API Standardization and Competition Law

Competition authorities may examine standardization under several theories.

Article 101-type concerns

Coordination among competitors concerning API standards can potentially create:

• exclusionary standards;
• information exchange;
• collusion;
• coordinated refusal to interoperate; or
• restrictions on technical innovation.

Article 102-type concerns

A dominant API provider may face scrutiny for:

• refusal to supply;
• discriminatory access;
• self-preferencing;
• tying;
• margin squeeze;
• exclusionary design;
• discriminatory technical standards; or
• exploitative API pricing.

US antitrust

Relevant concepts include:

• monopolization;
• attempted monopolization;
• tying;
• exclusive dealing;
• refusal to deal;
• vertical foreclosure; and
• standard-setting conduct.

23. Global Fragmentation Problem

One of the biggest future problems is the development of competing regional API standards.

For example:

US API ecosystem
↕
EU interoperability regime
↕
Chinese digital ecosystem
↕
Indian digital public infrastructure

Different rules concerning:

• data localization;
• privacy;
• cybersecurity;
• identity;
• payments;
• AI;
• cloud infrastructure; and
• interoperability

can create fragmented technical markets.

This can generate regulatory-induced API barriers.

24. API Standards and Digital Sovereignty

Governments increasingly view APIs as part of strategic digital infrastructure.

States may therefore require:

• local interoperability;
• domestic data access;
• standardized APIs;
• open banking interfaces;
• cloud portability;
• digital identity interoperability; or
• government-system integration.

Such requirements can promote competition by reducing incumbent lock-in.

But excessive localization can also fragment markets and increase compliance costs.

25. API Competition in AI

The issue is becoming particularly important in generative AI.

AI APIs provide access to:

• foundation models;
• inference;
• embeddings;
• moderation;
• agents;
• multimodal processing;
• fine-tuning;
• retrieval;
• vector databases; and
• autonomous workflows.

If a few firms control the principal AI APIs, developers may become dependent upon them.

Potential competition problems include:

• API lock-in;
• model-switching costs;
• proprietary data formats;
• incompatible agent protocols;
• discriminatory access;
• preferential treatment of affiliated AI applications;
• cloud/API bundling; and
• restrictive usage conditions.

Thus, AI API standardization could become the next major digital competition battleground.

26. API Portability as a Competition Remedy

Competition authorities could potentially impose remedies such as:

1. interoperability obligations;
2. standardized APIs;
3. data portability;
4. non-discriminatory API access;
5. transparent API documentation;
6. reasonable API pricing;
7. API version stability;
8. migration periods;
9. third-party auditing; and
10. prohibition of discriminatory technical treatment.

The objective should not necessarily be to force every platform to disclose its entire technology stack.

Instead, the objective may be:

sufficient interoperability to restore effective competition without destroying legitimate innovation incentives.

27. The Problem of Dynamic APIs

Traditional competition remedies often assume relatively stable markets.

APIs are different.

A platform can modify its API every few weeks or months.

Therefore, a remedy requiring access today may become ineffective tomorrow.

This creates the need for dynamic interoperability supervision, including:

• version-change notification;
• compatibility requirements;
• monitoring;
• technical audits;
• incident reporting; and
• dispute-resolution mechanisms.

28. API Neutrality

A possible future regulatory principle is API neutrality.

It would require a dominant API operator not to discriminate between:

• its own applications;
• affiliated companies;
• independent developers; and
• competing services.

API neutrality would resemble the broader concept of neutrality applied to digital infrastructure.

However, neutrality cannot mean identical treatment in every technical circumstance. Security, capacity and legitimate functionality differences may justify differentiated access.

29. Key Legal Test

A useful competition-law analytical framework is:

Step 1 — Define the relevant market

Determine whether the relevant market concerns:

• API services;
• cloud services;
• application distribution;
• data access;
• payments;
• AI inference;
• operating systems; or
• a broader digital ecosystem.

Step 2 — Establish market power

Consider:

• market share;
• network effects;
• switching costs;
• developer dependence;
• data advantages;
• technical barriers;
• interoperability;
• multi-homing; and
• ecosystem effects.

Step 3 — Identify API conduct

Determine whether the conduct involves:

• refusal;
• restriction;
• discrimination;
• degradation;
• tying;
• bundling;
• excessive pricing;
• exclusionary standards; or
• preferential access.

Step 4 — Assess foreclosure

Ask:

Does the API practice materially reduce rivals' ability to compete?

Step 5 — Examine justification

Possible legitimate reasons include:

• security;
• privacy;
• technical integrity;
• fraud prevention;
• capacity management;
• intellectual-property protection; and
• legitimate innovation.

Step 6 — Assess proportionality

The restriction should be no broader than reasonably necessary to achieve the legitimate objective.

30. Emerging Concept: API Gatekeeper Power

The most important conceptual development is that market power may exist at the interface layer.

Traditional economic analysis often focuses on:

Manufacturer → Distributor → Consumer.

The digital economy increasingly looks like:

Infrastructure → API → Platform → Developers → Applications → Consumers.

Control over the API can therefore determine who is able to participate in downstream markets.

This makes the API potentially analogous to a digital gate.

31. Overall Assessment

Global API competition presents a fundamental tension between two objectives:

Standardization

Interoperability + portability + innovation + lower transaction costs

versus

Strategic control

Lock-in + exclusion + discrimination + ecosystem dependency.

The six principal authorities discussed above—Microsoft interoperability, Bronner, IMS Health, Slovak Telekom, Google Shopping and United States v Microsoft—provide important legal building blocks even though most arose before the modern API economy fully developed.

The central principle for future competition law should therefore be:

Standardization should facilitate competition, not become a mechanism through which dominant digital firms control access to adjacent markets.

As APIs increasingly mediate cloud computing, financial services, digital identity, AI, advertising, operating systems and public digital infrastructure, control over interoperability may become as economically significant as control over the underlying technology itself.