API-Governed Firms and External Dependency Enforcement

Introduction

API-governed firms are businesses whose commercial activities depend substantially on application programming interfaces (APIs) controlled by another undertaking. APIs determine how software systems communicate, authenticate users, exchange data, request services, process transactions, and obtain access to infrastructure.

An external dependency arises where a firm cannot effectively operate, scale, or compete without access to an API, platform, data interface, authentication system, payment interface, cloud service, operating-system function, marketplace interface, or other digitally controlled infrastructure supplied by another undertaking.

Competition concerns arise when the API controller uses that dependency to:

• deny or restrict access;
• impose discriminatory technical conditions;
• degrade API functionality;
• change technical specifications selectively;
• impose excessive or discriminatory fees;
• tie API access to unrelated services;
• restrict interoperability;
• prevent multi-homing;
• impose exclusivity or parity obligations;
• obtain competitively sensitive information from dependent firms;
• use API access to favour its own downstream products; or
• make switching technically or economically difficult.

The central legal question is therefore not simply whether one firm controls an API, but whether that control constitutes an exclusionary or exploitative use of market power.

I. Meaning of API-Governed Firms

An API-governed firm can be understood as an undertaking whose business model is materially conditioned by rules, technical specifications, permissions, pricing, or access decisions made through another firm's API infrastructure.

Examples include:

1. Payment platforms dependent upon banking APIs.
2. Fintech firms dependent upon open-banking interfaces.
3. Travel platforms dependent upon airline or hotel APIs.
4. E-commerce sellers dependent upon marketplace APIs.
5. Mobile applications dependent upon operating-system APIs.
6. Cloud applications dependent upon cloud-provider APIs.
7. AI applications dependent upon foundation-model APIs.
8. EV applications dependent upon charging-network APIs.
9. Healthcare applications dependent upon hospital or health-data APIs.
10. Logistics applications dependent upon mapping, routing, or delivery APIs.

The dependency may be contractual, technical, economic, or a combination of all three.

II. External Dependency Enforcement

External dependency enforcement occurs when an API controller uses its control over an external dependency to influence the commercial behaviour or competitive position of another undertaking.

It can take several forms.

1. Access denial

The API controller refuses access altogether.

2. Conditional access

Access is granted only if the dependent firm accepts additional contractual or commercial conditions.

3. Technical degradation

The API technically remains available but is made slower, less reliable, less functional, or less compatible.

4. Discriminatory access

The controller provides superior functionality to its own downstream service while giving competitors inferior access.

5. Data restriction

The API controller prevents dependent firms from obtaining data generated through their own activities or from transferring that data to alternative providers.

6. Switching restrictions

The API makes migration difficult through technical incompatibility, proprietary formats, contractual restrictions, or excessive transition costs.

7. Self-preferencing

The API owner gives its own downstream service privileged access, latency, data, functionality, or integration.

III. Competition-Law Framework

The principal analytical framework is generally based upon:

A. Relevant market

Authorities must determine the relevant product and geographic markets.

An API may constitute:

• a separate relevant market;
• an input within a broader digital-services market;
• an essential infrastructure component;
• an interoperability layer; or
• part of a wider platform ecosystem.

B. Dominance or market power

The API controller's position may depend upon:

• market share;
• network effects;
• switching costs;
• interoperability;
• access to data;
• ecosystem effects;
• technical standards;
• economies of scale;
• user lock-in;
• absence of substitutes; and
• control over an essential commercial interface.

C. Conduct

The relevant conduct may constitute:

• refusal to deal;
• discriminatory access;
• tying;
• exclusive dealing;
• self-preferencing;
• margin-related exclusion;
• excessive pricing;
• degradation;
• interoperability restrictions; or
• exploitation of dependency.

D. Competitive effects

Authorities generally examine whether the conduct can:

• exclude rivals;
• raise rivals' costs;
• reduce innovation;
• restrict consumer choice;
• prevent entry;
• reinforce dominance;
• weaken interoperability; or
• exploit dependent businesses.

IV. API Dependency and the Essential-Facility Concept

One of the most important doctrines is the essential-facility/refusal-to-deal framework.

Historically, competition law has been cautious about imposing duties to deal because firms ordinarily retain freedom to choose their commercial partners.

However, intervention becomes more plausible where:

1. the input is effectively indispensable;
2. there is no realistic substitute;
3. access is necessary for competition in a downstream market;
4. refusal eliminates or seriously restricts competition;
5. duplication is technically or economically impracticable; and
6. access can be provided without undermining legitimate interests.

For APIs, the concept may apply to:

• proprietary operating-system interfaces;
• payment infrastructure;
• critical interoperability interfaces;
• dominant marketplace interfaces;
• essential data-access interfaces; and
• infrastructure APIs that cannot reasonably be replicated.

V. Six Major Case Laws

1. United States v. Microsoft Corp. (2001)

Court: U.S. Court of Appeals for the District of Columbia Circuit

Microsoft concerned Microsoft's control over the Windows operating-system platform and its conduct toward competing technologies.

The case is important to API dependency because Microsoft's operating system functioned as a platform through which third-party applications interacted with the computing environment.

The court examined Microsoft's use of its dominant position to disadvantage competing technologies, including restrictions affecting browser competition.

Relevance to API-governed firms

The case illustrates how control over a technical platform can become a competition concern when the platform owner uses technical or contractual control to disadvantage downstream or adjacent competitors.

The important principle is:

Control over an important technological interface can provide the platform owner with competitive leverage in neighbouring markets.

2. European Commission v. Microsoft — Commission Decision (2004)

The European Commission found Microsoft liable for, among other matters, restricting interoperability information necessary for competing work-group server products.

The Commission required Microsoft to disclose interoperability information under specified conditions.

API relevance

Although the case did not concern a modern REST API in the contemporary sense, its importance is considerable for API governance.

The underlying issue was whether a dominant technology provider could withhold technical information necessary for interoperability.

The case demonstrates that competition law may treat interoperability information as competitively significant infrastructure where withholding it impairs effective competition.

3. Bronner v. Mediaprint (1998)

Court: Court of Justice of the European Union

The case concerned access to a newspaper-delivery system controlled by another undertaking.

The CJEU established a demanding framework for compulsory access under Article 102 TFEU.

API relevance

Bronner is important because it demonstrates that not every commercially useful infrastructure constitutes an essential facility.

For an API dependency claim, the dependent undertaking would ordinarily need to demonstrate something more substantial than inconvenience or increased costs.

Questions include:

• Is the API genuinely indispensable?
• Is there a realistic alternative?
• Can the API be replicated?
• Would denial eliminate effective competition?

Principle

API dependency alone does not automatically create a legal duty to provide access.

4. IMS Health GmbH & Co. KG v NDC Health (2004)

Court: Court of Justice of the European Union

IMS Health concerned access to a data structure used in pharmaceutical sales information.

The CJEU addressed circumstances in which refusal to license intellectual-property-related infrastructure could constitute an abuse of dominance.

API relevance

The case is particularly relevant to API-controlled data ecosystems.

An API may embody or provide access to:

• proprietary data structures;
• databases;
• interoperability formats;
• technical specifications; and
• information necessary to compete downstream.

IMS Health demonstrates that refusal involving proprietary infrastructure may raise Article 102 concerns when the stringent conditions for intervention are satisfied.

5. Slovak Telekom a.s. v European Commission (2021)

Court: Court of Justice of the European Union

The case concerned access to telecommunications infrastructure and the relationship between refusal-to-deal principles and competition-law obligations imposed upon a dominant undertaking.

The judgment is particularly significant for distinguishing between different forms of exclusionary conduct.

API relevance

Modern API dependency can similarly involve an upstream infrastructure provider controlling an interface required by downstream firms.

The relevant questions include:

• whether access is indispensable;
• whether the dominant firm has already undertaken to provide access;
• whether the conditions of access disadvantage competitors;
• whether access terms raise rivals' costs; and
• whether the conduct restricts effective downstream competition.

Broader principle

Competition law may scrutinize the terms on which infrastructure access is supplied, not merely an absolute refusal.

6. Google Android — European Commission (2018)

Case: Google Android, Commission Decision AT.40099

The European Commission examined Google's conduct concerning the Android mobile ecosystem.

The Commission considered, among other matters, contractual arrangements involving Google Search, the Play Store, and mobile-device manufacturers.

API/ecosystem relevance

Android demonstrates the importance of ecosystem governance.

A platform controller may influence competition through control over:

• operating-system functionality;
• application distribution;
• compatibility requirements;
• licensing;
• default settings;
• technical integration; and
• access to ecosystem components.

For API-governed firms, the case illustrates how contractual and technical conditions imposed at one ecosystem layer can affect competition at another.

7. Google Shopping — European Commission (2017)

Case: Google Search (Shopping), Commission Decision AT.39740

The Commission found that Google had abused its dominant position in general search by favouring its comparison-shopping service in search results.

API relevance

The case is relevant to API governance because it demonstrates the importance of non-neutral control over an infrastructure layer.

Where an API controller also competes downstream, the controller may possess incentives and capabilities to manipulate access conditions in favour of its own service.

Comparable API conduct could involve:

• preferential API quotas;
• better latency for the controller's own service;
• privileged access to new API functions;
• preferential data access;
• early technical updates; or
• better authentication mechanisms.

The competition concern is therefore potentially vertical self-preferencing through infrastructure control.

VI. Additional Relevant Case: Qualcomm

Qualcomm — European Commission and EU Courts

The Qualcomm litigation concerning payments and exclusivity illustrates another dimension of dependency enforcement.

Where an important technology supplier conditions commercial relationships upon arrangements that discourage customers from using competing suppliers, competition concerns can arise even without an outright refusal to supply.

API application

An API provider could similarly use:

• rebates;
• preferential pricing;
• minimum-volume commitments;
• exclusivity;
• technical certification;
• preferential quotas; or
• bundled API services

to make alternative providers commercially unattractive.

The important issue is whether the arrangement forecloses effective competition rather than merely whether the contract contains an exclusivity-related provision.

VII. Types of API Dependency Enforcement

VIII. API Degradation as External Dependency Enforcement

API degradation deserves particular attention because it can be difficult to detect.

A dominant API provider does not necessarily need to terminate access.

Instead, it may:

• increase response latency;
• reduce request limits;
• remove functionality;
• introduce incompatible versions;
• increase error rates;
• impose additional authentication steps;
• delay technical updates; or
• discontinue important endpoints.

The crucial evidentiary issue is whether the deterioration reflects legitimate technical or security reasons or strategically disadvantages competitors.

Relevant evidence can include:

• historical API-performance data;
• change logs;
• internal technical documents;
• comparative latency;
• error-rate statistics;
• access quotas;
• treatment of affiliated businesses;
• customer complaints;
• development timelines; and
• technical justification for changes.

IX. Self-Preferencing Through API Governance

Self-preferencing becomes particularly significant where the API controller operates competing downstream services.

For example:

API Owner

↓

Controls authentication, data, quotas and technical standards

↓

Independent API Users

compete against

API Owner's downstream service

A potential competitive problem arises if the API owner gives its own service:

• greater data access;
• lower latency;
• higher API limits;
• earlier access to new functionality;
• better documentation;
• superior technical support; or
• privileged interoperability.

The relevant comparison is not simply whether competitors receive access, but whether the conditions of access materially differ in ways capable of affecting competition.

X. Data as an External Dependency

Modern APIs frequently serve as gateways to commercially valuable data.

Dependency may arise concerning:

• transaction histories;
• customer information;
• inventory;
• location information;
• behavioural data;
• payment records;
• search data;
• device information;
• usage statistics; and
• performance data.

Competition issues may arise when the API controller:

1. prevents portability;
2. prevents interoperability;
3. combines dependent-firm data with its own datasets;
4. uses competitors' API data to compete against them;
5. restricts access to essential datasets; or
6. makes departure from the ecosystem economically difficult.

Thus, API control and data control can reinforce one another.

XI. Switching Costs and API Dependency

External dependency becomes stronger when switching is costly.

Switching costs can include:

• rewriting software;
• changing authentication architecture;
• migrating databases;
• redesigning integrations;
• retraining employees;
• obtaining new certifications;
• renegotiating contracts;
• losing historical data;
• losing customer functionality; and
• temporary service disruption.

An API provider may therefore acquire substantial economic leverage even without formal exclusivity.

The competition-law question becomes whether the switching barrier is:

a legitimate consequence of technical integration

or

a strategically created barrier designed to preserve market power.

XII. API Lock-In

API lock-in can arise through:

Technical lock-in

Proprietary APIs cannot easily be reproduced elsewhere.

Data lock-in

Historical data cannot easily be exported.

Contractual lock-in

Long-term contracts or minimum commitments restrict switching.

Economic lock-in

Migration costs are substantial.

Ecosystem lock-in

The API is integrated with numerous complementary services.

Knowledge lock-in

Employees and developers acquire expertise specific to one API.

These forms can operate simultaneously.

XIII. Legitimate Business Justifications

API restrictions are not inherently anticompetitive.

An API provider may legitimately restrict access for:

• cybersecurity;
• fraud prevention;
• privacy;
• regulatory compliance;
• system stability;
• capacity management;
• intellectual-property protection;
• protection of confidential information;
• technical compatibility; or
• prevention of abusive automated access.

Therefore, an authority would ordinarily need to distinguish legitimate technical governance from strategic exclusion.

This distinction is particularly important because API ecosystems require continuous technical governance.

XIV. Evidence Required in an API Competition Case

A strong investigation would examine several categories of evidence.

Technical evidence

• API documentation;
• version histories;
• uptime;
• latency;
• rate limits;
• error rates;
• authentication requirements.

Commercial evidence

• API pricing;
• discounts;
• minimum commitments;
• licensing agreements;
• exclusivity provisions.

Competitive evidence

• downstream market shares;
• customer switching;
• entry attempts;
• alternative APIs;
• competitor costs.

Internal evidence

• strategy documents;
• product-development communications;
• technical roadmaps;
• pricing decisions;
• communications concerning competitors.

Comparative evidence

Particularly important is comparison between:

independent firms' API access

and

the API owner's affiliated services' access.

XV. Remedies

Competition authorities may employ several remedies.

1. Access remedies

Require non-discriminatory API access.

2. Interoperability remedies

Require publication of technical specifications.

3. Data-portability remedies

Allow dependent businesses to retrieve and transfer their data.

4. Non-discrimination obligations

Prevent materially different treatment between equivalent API users.

5. API-performance monitoring

Require measurable service-level commitments.

6. Structural remedies

In exceptional cases, separation of infrastructure and downstream activities may be considered.

7. Contractual remedies

Remove exclusivity, tying, parity, or restrictive licensing conditions.

8. Transparency obligations

Require advance notice of material API changes.

XVI. Relationship Between API Governance and Competition Law

The central conceptual structure can be represented as:

API Control

↓

External Dependency

↓

Switching Costs / Network Effects

↓

Potential Market Power

↓

Access or Technical Restriction

↓

Rival Foreclosure / Exploitation

↓

Competitive Effects

↓

Competition-Law Assessment

The presence of the first three stages does not automatically establish an infringement. The conduct and its competitive effects remain essential.

XVII. Comparative Doctrinal Lessons from the Cases

XVIII. Key Legal Tests

When examining an API-governed firm, the following questions are particularly important:

Question 1 — Is the API commercially indispensable?

Can the dependent firm reasonably operate through another interface?

Question 2 — Is the API provider dominant?

Does it possess substantial market power in the relevant market?

Question 3 — Is the dependency externally imposed?

Is the dependent firm's reliance the result of genuine market conditions or deliberate restrictions?

Question 4 — What is the nature of the restriction?

Is it:

• denial,
• discrimination,
• degradation,
• tying,
• exclusivity,
• self-preferencing,
• excessive pricing, or
• interoperability restriction?

Question 5 — What is the competitive effect?

Does the conduct exclude rivals, raise their costs, restrict innovation, or exploit dependent businesses?

Question 6 — Is there an objective justification?

Can the API restriction be explained by legitimate security, technical, regulatory, or operational considerations?

Conclusion

API-governed firms represent a modern form of vertical dependency in which technical interfaces can function as commercially significant infrastructure. The competition-law significance arises when control over an API enables its owner to influence the ability of dependent firms to enter, compete, innovate, interoperate, or switch providers.