API Openness Obligations for Ecosystem Access Fairness

Introduction

API openness obligations refer to competition-law principles that may require a dominant digital platform, infrastructure provider, operating-system operator, cloud service, payment network, or other technological gatekeeper to provide fair, reasonable, non-discriminatory, and technically meaningful access to application programming interfaces (APIs) where competitors, complementors, or downstream businesses depend upon those interfaces to participate effectively in an ecosystem.

The central competition concern is not simply whether an API exists. The relevant questions are:

1. Who controls access to the API?
2. Can rivals obtain access on commercially and technically reasonable terms?
3. Does the platform discriminate between its own services and independent competitors?
4. Can the platform degrade, delay, restrict, or selectively withdraw API functionality?
5. Are access conditions transparent and objectively justified?
6. Does API control create ecosystem dependency or foreclosure?
7. Can interoperability or access remedies preserve competition without requiring the platform to give away proprietary technology indiscriminately?

API openness therefore connects traditional doctrines of refusal to deal, essential facilities, discriminatory access, tying, self-preferencing, interoperability, leveraging, and abuse of dominance with modern digital-platform economics.

I. Meaning of API Openness

An API is a technical interface through which one software system communicates with another.

For example:

Platform → API → Third-party application

The API may permit access to:

• user authentication;
• payment functionality;
• mapping;
• search;
• advertising;
• cloud infrastructure;
• messaging;
• device functions;
• financial data;
• identity verification;
• app distribution;
• logistics;
• AI models;
• interoperability functions.

An ecosystem can therefore become dependent upon APIs even when the API provider does not directly compete with every API user.

Example

Suppose Platform A operates a dominant mobile ecosystem.

Independent applications require Platform A's authentication API, payment API and notification API.

Platform A subsequently:

• provides competitors with slower access;
• gives its own application additional API functionality;
• imposes excessive fees;
• changes API specifications without reasonable notice;
• limits data fields available to rivals;
• prevents competing applications from interoperating.

The competition issue is whether the API controller is using control over an upstream technological interface to distort downstream competition.

II. API Openness and Ecosystem Access Fairness

API openness does not necessarily mean unrestricted access.

A competition-law framework generally has to balance two interests.

Platform's legitimate interests

A platform may legitimately protect:

• cybersecurity;
• privacy;
• intellectual property;
• system stability;
• technical integrity;
• fraud prevention;
• capacity constraints;
• consumer safety.

Competition interests

At the same time, access restrictions can become problematic where they:

• exclude competitors;
• discriminate against independent developers;
• increase switching costs;
• prevent interoperability;
• protect the platform's downstream business;
• reinforce network effects;
• create artificial entry barriers.

The legal question is therefore generally whether the restriction is objectively justified and proportionate to a legitimate purpose.

III. Relevant Competition-Law Doctrines

1. Refusal to Deal

A dominant undertaking may, under exceptional circumstances, face competition-law scrutiny when it refuses access to an input or interface that competitors require.

An API may become particularly significant where:

• competitors cannot reasonably replicate it;
• access is technically indispensable;
• the API is controlled by a dominant undertaking;
• refusal eliminates effective competition;
• there is no objective justification.

The doctrine is traditionally applied cautiously because compulsory access can interfere with property rights and incentives to innovate.

IV. Essential-Facilities Considerations

The essential-facilities doctrine asks whether a facility controlled by a dominant undertaking is indispensable for competitors and whether access can reasonably be provided.

For APIs, the analysis may involve:

Indispensability

Can competitors realistically reproduce the API functionality?

Duplication

Could a competitor develop an alternative interface?

Economic feasibility

Would duplication require disproportionate expenditure or technical resources?

Elimination of competition

Would denial substantially eliminate downstream competition?

Justification

Does the API owner have legitimate technical, security, privacy or commercial reasons for restricting access?

The doctrine should not automatically convert every popular API into an "essential facility."

V. Interoperability as a Competition Concern

Interoperability is particularly important in digital ecosystems.

An API can determine whether:

Service A ↔ Platform B

can communicate effectively.

A dominant ecosystem can potentially reduce interoperability by:

• withholding APIs;
• limiting API functionality;
• imposing discriminatory technical requirements;
• providing incomplete documentation;
• requiring competitors to accept restrictive contractual conditions;
• introducing technical incompatibilities;
• giving proprietary services privileged API access.

Competition authorities may therefore examine functional interoperability, rather than merely formal API availability.

VI. Non-Discrimination Obligations

An important concept is equivalent access.

A platform does not necessarily have to provide identical APIs to every participant. However, differences can raise competition concerns when they lack legitimate technical justification.

Potentially problematic differentiation

Such differences can become evidence of self-preferencing or discriminatory foreclosure.

VII. API Access and Self-Preferencing

Self-preferencing occurs where a platform gives its own downstream products or services preferential treatment.

API control can facilitate this.

Example

A dominant marketplace gives:

Own logistics service:
Full delivery API + real-time tracking + customer-data integration.

Third-party logistics providers:
Limited API + delayed information + restricted customer interaction.

Even if third parties technically have "API access," the practical effect may be discriminatory.

The competition analysis therefore needs to examine substantive functionality rather than merely formal access.

VIII. API Access and Tying

API restrictions can also support tying.

For example:

Access to dominant operating-system API → conditional upon using the platform's payment service.

Or:

Access to cloud API → conditional upon purchasing another platform service.

The competition concern arises when control over an indispensable technological interface is used to extend market power into an adjacent market.

IX. API Degradation

One particularly important modern issue is strategic API degradation.

Instead of completely refusing access, a platform can make competing services progressively less effective.

Possible techniques include:

• lower rate limits;
• slower response times;
• removal of functionality;
• reduced data fields;
• reduced API reliability;
• delayed updates;
• higher authentication burdens;
• increased compliance requirements.

This can be more difficult to detect than an outright refusal.

Competition authorities may therefore examine changes over time.

X. API Fees and Access Charges

API openness can also involve pricing.

An API provider may impose:

• per-call charges;
• subscription fees;
• minimum commitments;
• revenue-sharing;
• certification fees;
• data-access charges.

Competition concerns may arise where fees are:

• discriminatory;
• excessive;
• predatory;
• exclusionary;
• designed to disadvantage competitors;
• substantially different from the costs or conditions imposed on the platform's own services.

The relevant analysis depends on the applicable jurisdiction and market circumstances.

XI. API Governance and Transparency

Fair access can require more than technical availability.

A platform may need appropriate governance mechanisms concerning:

Documentation

Clear API specifications.

Versioning

Reasonable notice before material changes.

Deprecation

Adequate transition periods.

Certification

Objective and transparent certification criteria.

Rate limits

Rules applied consistently.

Security

Requirements proportionate to actual risks.

Appeals

Mechanisms for challenging unjustified access decisions.

These measures can reduce the ability to use technical governance as an instrument of exclusion.

XII. Six Important Case Laws

1. Bronner v Mediaprint — CJEU

Case: Oscar Bronner GmbH & Co. KG v Mediaprint Zeitungs- und Zeitschriftenverlag GmbH & Co. KG, Case C-7/97.

Principle

The Court of Justice adopted a strict approach to refusal-to-supply claims.

The facility must generally be indispensable and there must be no viable alternative.

API relevance

The case provides an important caution:

Not every technologically important API automatically becomes an essential facility.

A claimant would need to demonstrate genuine indispensability rather than merely showing that access would be commercially advantageous.

2. IMS Health v NDC Health — CJEU

Case: IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG, Joined Cases C-418/01.

Principle

The Court developed important criteria concerning refusal to license intellectual-property-related infrastructure.

The circumstances included:

• indispensability;
• elimination of effective competition;
• prevention of a new product for which consumer demand existed;
• absence of objective justification.

API relevance

Where an API is protected by intellectual property or proprietary technology, IMS Health provides a useful framework for assessing when competition law may justify access despite proprietary rights.

3. Microsoft — European Commission

Case: Microsoft Corp. v Commission, T-201/04.

Principle

The case concerned Microsoft's refusal to provide interoperability information to competing work-group server operating systems.

The European Commission and General Court treated interoperability as a significant competition issue.

API relevance

The case is highly relevant to API ecosystems because it demonstrates that interoperability information can itself constitute an important competitive input.

It supports the proposition that a dominant technology provider cannot necessarily use technical control to prevent competitors from interoperating with its dominant ecosystem.

4. Google Android — European Commission

Case: Google and Alphabet v Commission, T-604/18.

Principle

The case concerned Google's Android ecosystem and several practices involving search, licensing arrangements and device manufacturers.

The broader competition analysis examined how contractual restrictions could reinforce Google's position within interconnected digital markets.

API relevance

The Android ecosystem illustrates how control over an operating-system environment can influence downstream competition.

For API regulation, the relevant lesson is that authorities may consider the entire ecosystem and network of contractual/technical dependencies, rather than examining an individual interface in isolation.

5. Slovak Telekom — CJEU

Case: European Commission v Slovak Telekom a.s., Joined Cases C-152/19 P and C-165/19 P.

Principle

The case concerned access to infrastructure and exclusionary conduct by a dominant telecommunications operator.

The Court considered the relationship between refusal-to-supply principles and other forms of exclusionary abuse.

API relevance

The telecommunications context provides a useful analogy for API ecosystems:

Control over an upstream infrastructure layer can give the operator substantial ability to affect downstream competition.

API access can therefore be analysed as an infrastructure-access question where downstream competitors depend heavily upon the interface.

6. Deutsche Telekom — CJEU

Case: Deutsche Telekom AG v Commission, Case C-280/08 P.

Principle

The case concerned access pricing and the ability of a dominant telecommunications operator to disadvantage downstream competitors.

The Court upheld the importance of assessing whether the conduct could produce exclusionary effects.

API relevance

The case is relevant to API ecosystems where the dominant provider controls an upstream interface and competes downstream.

It illustrates how control over an upstream input combined with downstream competition can create foreclosure concerns.

XIII. Additional Important Authorities

7. Google Shopping

Case: Google and Alphabet v Commission, Case T-612/17.

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

API relevance

It is relevant to the broader concept of leveraging control over an important platform layer into an adjacent market, particularly where the platform's own service receives preferential treatment.

8. Magill

Cases: RTE and ITP v Commission, Joined Cases C-241/91 P and C-242/91 P.

The case concerned refusal to provide copyrighted television programme information.

API relevance

It demonstrates the exceptional circumstances under which proprietary information can become subject to competition-law intervention.

For API ecosystems, the lesson is that proprietary status does not automatically end competition-law analysis, but intervention requires the applicable stringent conditions.

XIV. Comparative Case-Law Matrix

XV. Conditions Supporting an API Openness Obligation

A stronger competition-law case generally exists where several factors converge:

1. Dominance

The API controller possesses substantial market power.

2. Dependency

Downstream firms significantly depend on the API.

3. Limited alternatives

Comparable alternatives are unavailable or commercially unrealistic.

4. Downstream competition

The API users compete with the API provider or its affiliates.

5. Discrimination

The platform provides materially better access to its own services.

6. Foreclosure

The restriction substantially impairs rivals' ability to compete.

7. Lack of justification

The provider cannot demonstrate legitimate technical, security or other reasons.

8. Proportionality

The requested access remedy can be implemented without disproportionate harm to legitimate platform interests.

XVI. Legitimate Reasons for Restricting APIs

An API openness obligation should not become an unrestricted access requirement.

A platform may legitimately restrict API access because of:

• cybersecurity vulnerabilities;
• privacy requirements;
• fraud;
• excessive server loads;
• network stability;
• consumer protection;
• intellectual-property protection;
• regulatory obligations;
• malicious applications;
• inadequate authentication.

However, the restriction should ideally be:

objective + transparent + proportionate + consistently applied.

A platform should not simply label a restriction "security-related" without meaningful evidence where the restriction disproportionately disadvantages competitors.

XVII. API Openness and Data Portability

API access and data portability overlap but are not identical.

Data portability

Concerned primarily with allowing users or businesses to retrieve and transfer their data.

API interoperability

Concerned with enabling systems to communicate and function together.

API openness

A broader concept encompassing:

• interoperability;
• technical access;
• functionality;
• authentication;
• documentation;
• pricing;
• governance;
• non-discrimination.

A competition authority may therefore consider API openness alongside data-access and portability obligations.

XVIII. API Openness in Financial Technology

Financial APIs provide particularly important examples.

Consider an incumbent financial platform controlling:

• account APIs;
• payment APIs;
• identity APIs;
• transaction-data APIs;
• fraud APIs.

If the incumbent gives affiliated fintech services comprehensive API access but limits competing fintech firms, this can potentially create:

infrastructure control → data advantage → downstream foreclosure → ecosystem reinforcement.

Competition-law scrutiny may therefore overlap with financial-sector interoperability and open-banking regulation.

XIX. API Openness in Cloud Computing

Cloud ecosystems create similar issues.

A dominant cloud provider may control APIs for:

• storage;
• databases;
• computing;
• AI services;
• identity;
• security;
• orchestration.

Potential concerns include:

• interoperability restrictions;
• data-transfer barriers;
• preferential API functionality;
• technical incompatibility;
• excessive switching costs;
• proprietary APIs that make migration difficult.

This can create ecosystem lock-in even without an explicit refusal to provide access.

XX. API Openness in AI Ecosystems

AI creates a newer version of the problem.

A dominant AI platform may control APIs providing access to:

• foundation models;
• embeddings;
• inference;
• agent tools;
• identity;
• safety systems;
• proprietary datasets.

Potential competition issues include:

1. discriminatory model access;
2. preferential API pricing for affiliated products;
3. restrictions on multi-homing;
4. API throttling of competing applications;
5. exclusive integration;
6. interoperability restrictions;
7. migration barriers.

The key question is whether API control allows an undertaking with substantial market power to extend or preserve dominance in adjacent AI markets.

XXI. Remedies for API Openness Violations

Competition authorities may consider several remedies.

1. Non-discrimination

Require equivalent treatment of comparable API users.

2. Interoperability

Require technical compatibility with competing services.

3. API documentation

Require sufficient technical documentation.

4. Reasonable notice

Require advance notice for material API changes.

5. Access commitments

Require access under specified objective conditions.

6. Independent monitoring

A trustee or regulator may monitor compliance.

7. Data portability

Permit transfer of relevant data.

8. API performance parity

Where technically justified, require comparable functionality or performance.

9. Transparent certification

Prevent arbitrary exclusion through developer-certification systems.

XXII. Limits of API Openness Remedies

Compulsory openness also creates risks.

Excessive intervention could:

• reduce cybersecurity;
• undermine privacy;
• expose proprietary technology;
• increase system vulnerability;
• discourage innovation;
• impose substantial compliance costs;
• facilitate free-riding;
• interfere with legitimate product differentiation.

Therefore, an appropriate remedy should normally target the specific competitive harm, rather than requiring indiscriminate disclosure of all proprietary interfaces.

XXIII. Practical Competition-Law Test

An authority assessing API openness can use the following framework:

Dominant API controller?
↓
Relevant downstream market identified?
↓
Competitors materially dependent on API?
↓
Reasonable alternative access available?
↓
Access restricted/refused/degraded/discriminated?
↓
Own service receives preferential treatment?
↓
Actual or likely foreclosure?
↓
Objective justification?
↓
Proportionality?
↓
Appropriate interoperability/access remedy

XXIV. Key Legal Distinction

The most important distinction is:

API availability ≠ meaningful API openness.

A dominant undertaking can technically publish an API while still making effective competition difficult through:

• restrictive terms;
• inferior functionality;
• discriminatory rate limits;
• delayed access;
• excessive fees;
• poor documentation;
• arbitrary certification;
• selective deprecation;
• data restrictions.

Competition law should therefore examine economic and functional access, rather than merely asking whether an API technically exists.

Conclusion

API openness obligations for ecosystem access fairness represent an extension of established competition-law principles into technologically mediated markets.

The strongest legal foundation comes from the combined doctrines of:

• refusal to deal;
• essential facilities;
• interoperability;
• discriminatory access;
• leveraging;
• self-preferencing;
• tying;
• exclusionary conduct.

The leading authorities—Bronner, IMS Health, Microsoft, Google Android, Slovak Telekom, Deutsche Telekom, Google Shopping and Magill—provide different components of the legal framework.

The central competition-law proposition is that control over an API can become economically significant when the interface functions as a gateway to a downstream ecosystem. Where a dominant undertaking uses that gateway to discriminate against competitors, degrade their access, impose unjustified restrictions, or privilege its own downstream services, competition authorities may examine whether the conduct unlawfully forecloses competition.