Competition Law and API Dependency and Competition Concerns

1. Introduction

Application Programming Interfaces (APIs) are technical interfaces through which one software system communicates with another. Modern digital markets depend heavily on APIs for payments, cloud computing, operating systems, app stores, search, advertising, social media, financial services, healthcare, logistics, travel, artificial intelligence, and data exchange.

API dependency becomes a competition-law concern when a business cannot effectively operate, compete, innovate, or reach customers without access to an API controlled by another undertaking possessing substantial market power. The issue is not simply that one firm depends technologically on another. Competition law becomes relevant where API control is used to exclude rivals, discriminate between downstream users, raise competitors' costs, prevent interoperability, facilitate tying or bundling, or reinforce an existing dominant position.

The central question is therefore:

When does legitimate control over an API become an instrument for restricting competition?

Competition authorities may examine API dependency through doctrines concerning abuse of dominance, refusal to deal, essential facilities, interoperability, discriminatory access, tying, self-preferencing, exclusionary conduct, vertical foreclosure, and anticompetitive technical standards.

2. Meaning of API Dependency

An API dependency exists where a business's product or service requires access to an API controlled by another undertaking.

Examples include:

a payment application depending upon a bank's payment API;

an independent application depending upon an operating-system API;

a travel platform depending upon airline or hotel APIs;

an AI application depending upon a foundation-model API;

a fintech depending upon banking APIs;

a cloud application depending upon a hyperscaler's infrastructure APIs;

an advertising intermediary depending upon a platform's advertising API;

a mapping application depending upon a mapping API;

a healthcare application depending upon an electronic-health-record API.

API dependency can range from commercially convenient access to technically indispensable access.

Basic structure

API owner → API → downstream business → consumers

The competition problem becomes particularly serious when the API owner also competes with the downstream business:

API owner → API access → dependent competitor

while simultaneously operating:

API owner → competing downstream service

This creates a potential incentive for vertical foreclosure.

3. Why APIs Create Competition Concerns

APIs can become strategically important because they control access to:

Data

Customers

Platforms

Technical functionality

Authentication

Payment infrastructure

Interoperability

Cloud infrastructure

Distribution

Network effects

An API can therefore operate as a technical gateway.

If the gateway is controlled by a dominant undertaking, changing the API's functionality, access conditions, pricing, rate limits, authentication requirements, or technical documentation can substantially affect downstream competitors.

4. Relevant Market Definition

API disputes often require careful market definition.

A competition authority could examine several potentially relevant markets.

A. API services market

The market may consist of access to a particular technical API or category of APIs.

B. Underlying infrastructure market

The relevant market may instead concern:

cloud computing;

payment processing;

mobile operating systems;

digital advertising;

search;

mapping;

social networking;

AI models.

C. Downstream market

The API may be important because the controller also operates in a downstream market.

For example:

Dominant operating system → API → independent application developers

The relevant competitive concern may therefore arise in the downstream application market rather than in a separately defined "API market."

D. Aftermarket analysis

API dependency can sometimes resemble an aftermarket problem.

A business may initially choose a platform and subsequently become dependent upon APIs associated with that platform.

This can create:

switching costs;

technical lock-in;

migration costs;

loss of accumulated data;

loss of users;

loss of application functionality.

5. Market Power and API Dependency

API dependency alone does not establish market dominance.

A competition authority would normally examine factors such as:

market share;

network effects;

switching costs;

interoperability;

availability of alternatives;

technical substitutability;

data advantages;

intellectual-property rights;

contractual restrictions;

infrastructure ownership;

economies of scale;

entry barriers;

consumer dependence;

developer dependence.

A particularly important question is:

Can a competitor realistically switch to an alternative API without losing substantial functionality or customers?

If the answer is no, API dependency becomes substantially more significant.

6. Refusal to Provide API Access

One of the most important theories is refusal to deal.

Suppose a dominant platform previously provides API access and subsequently withdraws it from competing businesses.

Competition law may ask:

Was access previously supplied?

Is the API objectively necessary?

Does the withdrawal eliminate or substantially restrict competition?

Is there an objective justification?

Does the platform continue using the API internally?

Is the refusal selective?

Does the refusal disadvantage competitors while protecting the platform's own service?

The classic difficulty is balancing competition law with the legitimate right of firms to choose their commercial partners.

7. Essential-Facilities Doctrine

API dependency can sometimes raise an essential-facilities issue.

An API is more likely to attract this analysis when:

it is indispensable;

duplication is technically or economically impracticable;

access is necessary to compete;

the API owner has substantial market power;

denial of access eliminates effective competition;

access can technically be provided.

However, courts have generally treated compulsory access as an exceptional remedy rather than a general rule.

8. Case Law 1: United States v. Terminal Railroad Association

United States v. Terminal Railroad Association of St. Louis, 224 U.S. 383 (1912)

This is one of the foundational cases for access to infrastructure controlled by a dominant group.

A group of railroad companies controlled essential terminal facilities in St. Louis, creating significant barriers for competing railroads.

The Supreme Court required arrangements that prevented exclusionary control over the facility.

Relevance to APIs

The analogy is:

Terminal facility → API infrastructure

Where an API constitutes a critical gateway through which competitors must pass to reach a market, exclusive control may produce foreclosure effects.

The case supports the broader principle that control over an important bottleneck cannot necessarily be used to exclude rivals.

9. Case Law 2: Otter Tail Power Co. v. United States

Otter Tail Power Co. v. United States, 410 U.S. 366 (1973)

Otter Tail operated electricity transmission facilities and refused to provide transmission services to municipalities that competed with it in electricity distribution.

The Supreme Court found antitrust significance in the company's use of control over transmission facilities to protect its downstream position.

API relevance

The structural analogy is particularly strong:

Transmission infrastructure → API infrastructure

If an undertaking controls an infrastructure necessary for downstream competition and simultaneously competes downstream, refusal to provide access may create foreclosure concerns.

The case illustrates how infrastructure control can become an antitrust issue when used to protect downstream market power.

10. Case Law 3: Aspen Skiing Co. v. Aspen Highlands Skiing Corp.

Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985)

The dominant ski operator had historically participated in a joint ticketing arrangement with a competing ski area but later terminated that cooperation.

The Supreme Court treated the withdrawal from an established cooperative relationship as relevant to exclusionary conduct.

API relevance

The case is important for API disputes involving:

previously available API access;

interoperability agreements;

API partnerships;

sudden API termination;

discriminatory withdrawal.

A platform that historically supplied an API may face greater scrutiny if it suddenly withdraws access from competitors while retaining equivalent functionality for its own services.

The case does not mean that every API termination is unlawful. The surrounding competitive circumstances remain critical.

11. Case Law 4: MCI Communications Corp. v. AT&T

MCI Communications Corp. v. AT&T Co., 708 F.2d 1081 (7th Cir. 1983)

The Seventh Circuit considered AT&T's refusal to provide access to telecommunications facilities needed by MCI.

The case became an important reference point for the essential-facilities doctrine and refusal-to-deal analysis.

The court considered factors concerning:

control of the facility;

competitor dependence;

feasibility of duplication;

denial of access;

competitive consequences.

API relevance

The case provides a useful analytical framework for determining whether an API is genuinely indispensable rather than merely convenient.

For example:

If ten alternative APIs perform substantially the same function, dependency is weaker.

But:

If a dominant platform controls the only practical gateway to an important network, dependency becomes substantially stronger.

12. Case Law 5: United States v. Microsoft Corp.

United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001)

Microsoft involved exclusionary conduct surrounding operating systems, browsers, and software developers.

The D.C. Circuit examined Microsoft's use of its operating-system position to restrict competitive threats.

API relevance

This is highly relevant to API-dependent ecosystems.

Operating systems frequently provide APIs that determine:

which applications can function;

what data applications can access;

what hardware can communicate with software;

which functionalities developers can use.

If a dominant operating-system provider gives its own applications privileged API access while restricting competitors, competition concerns may arise.

Potential theories include:

discriminatory access;

self-preferencing;

tying;

interoperability restrictions;

exclusionary technical design.

13. Case Law 6: European Commission v. Google — Android

Google Android, Commission Decision AT.40099 (2018)

The European Commission examined Google's conduct concerning the Android ecosystem, including contractual restrictions associated with Google Search and Google Play.

The case demonstrates how control over a technological ecosystem can allow contractual and technical arrangements to influence competition in adjacent markets.

API relevance

Modern API ecosystems frequently contain:

Operating system + APIs + app distribution + search + advertising + data

A dominant undertaking may use contractual or technical restrictions at one layer to reinforce market power at another.

The Android decision therefore provides an important conceptual model for analysing ecosystem-level API dependency.

14. Case Law 7: Google Search (Shopping)

Google Search (Shopping), Commission Decision AT.39740 (2017)

The European Commission found that Google had given systematic advantages to its comparison-shopping service in search results.

Although the case was not specifically an API case, it is important for understanding self-preferencing in platform ecosystems.

API relevance

Imagine a platform that provides an API to competing services while simultaneously operating its own competing service.

It could potentially:

provide rivals with slower API access;

impose lower rate limits;

restrict functionality;

delay access to new features;

provide richer data to its own service;

degrade third-party API performance.

Such conduct can raise self-preferencing and exclusionary-conduct concerns.

15. Case Law 8: FTC v. Qualcomm

FTC v. Qualcomm Inc., 969 F.3d 974 (9th Cir. 2020)

The case concerned Qualcomm's licensing and business practices involving cellular technology and modem chips.

Although not an API dispute, it is important for understanding competition issues arising from control over technologically important inputs.

The Ninth Circuit ultimately rejected the FTC's principal antitrust theory in that case, illustrating that possession of important technology and demanding commercial terms do not automatically establish an antitrust violation.

API relevance

The case provides an important limiting principle:

Technological importance alone is not sufficient.

Competition analysis must establish the connection between the challenged conduct and competitive harm.

16. Case Law 9: Allied Tube & Conduit Corp. v. Indian Head, Inc.

Allied Tube & Conduit Corp. v. Indian Head, Inc., 486 U.S. 492 (1988)

This case concerned manipulation of a private standard-setting process to disadvantage a competitor.

The Supreme Court recognized that private technical standard-setting can have significant competitive effects.

API relevance

API specifications often function as technical standards.

A dominant ecosystem can influence:

API specifications;

authentication standards;

interoperability protocols;

certification requirements;

technical compatibility rules.

If standard-setting is manipulated to exclude competitors rather than achieve legitimate technical objectives, competition concerns can arise.

17. Discriminatory API Access

A dominant API provider may offer access to several businesses but provide different technical conditions.

For example:

Such differences are not automatically unlawful.

The competition inquiry would ask whether the differences have an objective and legitimate technical or commercial justification or whether they function as exclusionary discrimination.

18. API Tying and Bundling

API control can facilitate tying.

Suppose:

Product A requires access to API B.

A dominant undertaking could require businesses to purchase or use another product before receiving API access.

Examples could include:

cloud service tied to an API;

payment processing tied to access to a platform API;

advertising services tied to API access;

identity verification tied to platform access;

storage services tied to developer APIs.

Competition concerns become stronger where the undertaking has market power in the tying product and the arrangement forecloses meaningful competition in the tied product.

19. API Self-Preferencing

Self-preferencing can occur when the API owner competes with the businesses that depend on its API.

For example:

Platform API

↓

Third-party sellers

↓

Consumers

while the platform also operates:

Platform's own seller service

The platform could theoretically manipulate technical access to disadvantage independent sellers.

Potential mechanisms include:

preferential API quotas;

privileged data access;

superior API latency;

exclusive endpoints;

earlier feature releases;

better authentication;

preferential ranking signals.

The central competition issue is whether technical design is being used to exclude rivals rather than improve the platform.

20. API Degradation

An API does not necessarily have to be completely withdrawn to create competitive problems.

A platform might technically continue access while degrading it.

Examples include:

increased latency;

reduced request limits;

removal of functionality;

unstable endpoints;

delayed updates;

restrictive authentication;

reduced data fields.

This can create a constructive refusal to deal.

The competitive effect may be similar to an outright refusal even though formal access remains available.

21. API Pricing and Margin Squeeze

API access may be priced in a way that creates a margin-squeeze concern.

Suppose:

Dominant API provider → API price = ₹100

while its own downstream service effectively incurs:

Internal API cost = ₹10

and independent competitors cannot profitably compete because they must pay ₹100 for the same functionality.

The legal issue is not simply that the API is expensive.

The relevant questions include:

market power;

pricing structure;

downstream competition;

cost benchmarks;

discrimination;

foreclosure;

economic justification.

22. API Rate Limits as a Competition Instrument

Rate limiting is normally a legitimate technical tool.

It can:

prevent server overload;

control cybersecurity risks;

manage congestion;

reduce abuse;

allocate scarce resources.

However, rate limits may raise competition concerns where:

competitors receive unusually restrictive limits;

the dominant firm's own service receives substantially higher limits;

the difference lacks objective justification;

the restriction materially impairs competitors.

Thus:

Rate limiting is not inherently anticompetitive; discriminatory rate limiting can become a competition issue.

23. API Data Access and Data Advantages

APIs frequently determine who can access valuable datasets.

Examples:

consumer transaction data;

search data;

location data;

advertising data;

social-network data;

financial data;

purchasing data;

logistics data.

A dominant platform could potentially use data obtained through API interactions to improve its own competing service.

This creates a possible conflict:

API provider as infrastructure operator + API provider as competitor + API provider as data beneficiary

Competition authorities may therefore examine:

data access;

data portability;

data discrimination;

data aggregation;

exclusive data arrangements;

use of competitor-generated data.

24. API Interoperability

Interoperability is one of the most important competition issues.

Interoperability permits different systems to communicate.

Restrictions can produce:

network isolation;

switching costs;

lock-in;

reduced innovation;

reduced multi-homing;

reduced entry.

A dominant undertaking may deliberately design APIs that make interoperability difficult.

However, interoperability restrictions can also be justified by:

cybersecurity;

privacy;

system integrity;

intellectual property;

fraud prevention;

technical reliability.

The competition inquiry must therefore distinguish legitimate technical protection from strategic exclusion.

25. API Lock-In

API dependency can create substantial switching costs.

A company may build its entire software architecture around one API.

Switching may require:

rewriting code;

changing databases;

changing authentication;

migrating users;

retraining employees;

renegotiating contracts;

replacing infrastructure;

losing historical data.

This creates technical lock-in.

Where a dominant undertaking knows that customers cannot easily migrate, it may possess increased bargaining power.

26. API Ecosystems and Network Effects

API ecosystems often exhibit network effects.

More developers create more applications.

More applications attract more users.

More users attract more developers.

This can produce:

API → Developers → Applications → Users → Data → Developers

Such feedback loops can make markets highly concentrated.

A dominant API provider may therefore benefit from a self-reinforcing ecosystem.

Competition law becomes particularly relevant where the platform uses this position to prevent competing ecosystems from achieving sufficient scale.

27. Algorithmic API Management

Modern APIs are increasingly managed algorithmically.

An API provider may automatically determine:

access limits;

prices;

authentication;

ranking;

data availability;

resource allocation;

fraud detection;

performance;

access approval.

This raises new concerns.

If an algorithm systematically disadvantages competing businesses, the competition authority may investigate the underlying conduct even though the decision was automated.

Automation does not remove competition-law responsibility.

28. API Dependency and Algorithmic Collusion

APIs can also facilitate coordination between independent firms.

For example, multiple competitors may use a common pricing API.

If the API automatically synchronizes prices or pricing information, it could facilitate:

price coordination;

information exchange;

algorithmic collusion;

parallel pricing.

Competition law therefore needs to distinguish:

legitimate interoperability

from

technical mechanisms facilitating coordinated conduct.

29. API Dependency in AI Markets

AI creates particularly significant API competition issues.

Many developers now build applications on top of model APIs.

The structure may be:

AI infrastructure → model API → developers → AI applications → consumers

If a small number of companies control:

foundation models;

cloud infrastructure;

specialized chips;

training data;

model APIs;

they may possess significant leverage over downstream AI markets.

Potential issues include:

discriminatory API access;

exclusive contracts;

API pricing;

model switching costs;

data portability;

interoperability;

preferential access;

bundling AI APIs with cloud services;

self-preferencing;

acquisition of dependent applications.

30. API Dependency and Cloud Computing

Cloud providers often expose services through APIs.

Customers may build applications using:

storage APIs;

database APIs;

computing APIs;

machine-learning APIs;

identity APIs;

monitoring APIs.

Once applications are deeply integrated into one cloud provider's APIs, switching can become expensive.

Competition concerns may therefore involve:

cloud interoperability;

data portability;

egress costs;

proprietary APIs;

technical incompatibility;

preferential treatment of the provider's own services.

31. API Dependency in Financial Markets

Fintech provides another important example.

A fintech company may depend on:

bank APIs;

payment APIs;

identity APIs;

account-information APIs;

credit-data APIs.

If a bank both controls an important API and competes with fintech firms, it could theoretically use API access to disadvantage competitors.

Potential conduct includes:

refusing access;

discriminatory authentication;

delayed access;

excessive charges;

restrictive data fields;

preferential access to its own affiliates.

32. API Dependency and Mergers

API dependency can also matter in merger control.

Suppose:

Company A controls a dominant API

and acquires:

Company B, a major downstream application

The transaction may eliminate a significant independent customer of the API while integrating the API provider with a downstream competitor.

Authorities could examine:

foreclosure incentives;

data combination;

elimination of potential competition;

interoperability;

input foreclosure;

customer foreclosure;

ecosystem effects.

Thus, API dependency may be relevant even when the API itself is not the principal market involved in the merger.

33. Killer Acquisitions in API Ecosystems

A dominant API provider may acquire emerging applications that depend upon its infrastructure.

Such acquisitions can eliminate potential future competitors.

Competition analysis may therefore consider:

whether the target could become a competitive threat;

whether it possesses innovative technology;

whether it has valuable user data;

whether it can reduce dependence upon the dominant API;

whether the acquisition strengthens ecosystem lock-in.

34. Exclusive API Agreements

Exclusive API arrangements may also raise competition concerns.

For example:

API provider + major application → exclusive technical integration

If competing API providers are thereby excluded from access to a substantial customer base, the arrangement may produce foreclosure.

Relevant factors include:

duration;

market coverage;

market power;

switching possibilities;

alternatives;

exclusivity percentage;

effects on innovation.

35. Competition Concerns from API Terms of Service

Competition issues can sometimes be hidden in technical contracts.

Examples include:

prohibitions on interoperability;

restrictions on multi-homing;

minimum-volume requirements;

exclusivity clauses;

non-compete provisions;

restrictions on reverse engineering;

data-use restrictions;

limitations on alternative APIs.

A competition authority may therefore need to analyse both:

technical architecture

and

contractual architecture.

36. Objective Justifications

API providers may have legitimate reasons for restricting access.

These can include:

Cybersecurity

Unlimited API access can facilitate attacks.

Privacy

Data cannot always be disclosed to third parties.

Fraud prevention

Payment APIs may require strict controls.

System stability

Excessive API calls can overload infrastructure.

Intellectual property

Certain functionality may be legally protected.

Safety

Healthcare, aviation and financial APIs may require additional safeguards.

Therefore, competition law should not transform every API restriction into an antitrust violation.

The key question is whether the restriction is necessary, proportionate and objectively justified, particularly where the provider possesses significant market power.

37. Remedies for Anticompetitive API Conduct

Competition authorities could consider several remedies.

A. Mandatory API access

A dominant firm may be required to provide access under specified conditions.

B. Non-discrimination

Competitors could receive access on equivalent technical terms.

C. Interoperability

Authorities may require technical interoperability.

D. Data portability

Users and businesses may be permitted to move their data to competing services.

E. API transparency

Providers may be required to disclose material changes to API terms.

F. Non-exclusivity

Anticompetitive exclusive API arrangements may be restricted.

G. Structural remedies

In exceptional circumstances, structural separation may be considered.

H. Monitoring

Independent monitoring may be used to ensure continuing compliance.

38. Important Legal Principles from the Case Law

39. Six-Part Test for Analysing API Dependency

A useful competition-law framework is:

1. Is there substantial market power?

Determine whether the API provider possesses dominance or significant market power.

2. Is the API genuinely important?

Distinguish between:

convenient API;

commercially valuable API;

technically important API;

indispensable API.

3. Is the provider vertically integrated?

Competition concerns are generally stronger where the API owner competes with API-dependent firms.

4. What conduct occurred?

Examples:

refusal;

discrimination;

degradation;

tying;

excessive restrictions;

exclusivity;

self-preferencing.

5. What is the competitive effect?

Examine:

foreclosure;

increased costs;

reduced innovation;

reduced entry;

higher prices;

reduced quality;

reduced consumer choice.

6. Is there an objective justification?

Security, privacy, reliability, safety and intellectual property may legitimately explain restrictions.

40. Difference Between Legitimate API Management and Anticompetitive Conduct

The distinction depends on market power, purpose, effects, proportionality and objective justification.

41. Broader Competition-Law Significance

API dependency represents a transition from traditional physical bottlenecks to digital bottlenecks.

Historically, competition law dealt with control over:

railways;

electricity transmission;

telecommunications networks;

ports;

pipelines.

Modern competition concerns increasingly involve:

APIs;

cloud infrastructure;

digital identity;

app stores;

data platforms;

AI models;

payment networks;

interoperability layers.

The economic function can be similar:

Control over an indispensable gateway can confer significant competitive leverage.

The difference is that digital bottlenecks can be altered through software, contractual terms and algorithms much faster than physical infrastructure.

42. Conclusion

API dependency is becoming an important competition-law issue because APIs increasingly function as gateways to digital markets.

The existence of dependency by itself does not establish an antitrust violation. Competition law must examine:

the relevant market;

market power;

indispensability;

network effects;

switching costs;

vertical integration;

discriminatory access;

refusal to deal;

interoperability;

self-preferencing;

tying;

exclusivity;

data access;

technical degradation;

competitive effects;

objective justification.

The principles emerging from Terminal Railroad, Otter Tail, Aspen Skiing, MCI v. AT&T, Microsoft, Google Android, Google Shopping, FTC v. Qualcomm, and Allied Tube provide useful analytical foundations.

The central competition-law challenge is to prevent a dominant undertaking from converting technical control into exclusionary market power, while preserving legitimate incentives to innovate, maintain security, protect privacy, and develop commercially valuable infrastructure.

In the digital economy, therefore, API access can operate as the functional equivalent of access to an essential technological gateway. Where that gateway becomes indispensable to effective competition, the design, pricing, interoperability and governance of the API may become central questions of antitrust law.