API Restriction Strategies as Exclusionary Conduct

1. Introduction

API (Application Programming Interface) restriction occurs when a platform, operating system, cloud provider, payment network, marketplace, data intermediary, or other digital infrastructure operator limits how competing or complementary businesses can access its APIs.

API restrictions are not inherently unlawful. An operator may impose restrictions for security, privacy, cybersecurity, technical reliability, intellectual-property protection, capacity management, fraud prevention, or legitimate product design. Competition law becomes relevant where API restrictions are used strategically by a firm with substantial market power to exclude competitors, raise rivals’ costs, foreclose complementary products, or preserve ecosystem dependence.

The central competition-law question is therefore:

Is the API restriction a legitimate technical or commercial limitation, or is it a strategy through which market power is used to disadvantage actual or potential competitors?

The analysis is particularly important in digital markets because an API can function as an access gateway, interoperability layer, data channel, payment interface, identity mechanism, or distribution channel.

2. Meaning of API Restriction Strategies

API restriction strategies may include:

1. Complete API refusal – denying competitors access altogether.
2. Selective access – granting access to affiliated products while refusing independent competitors.
3. Discriminatory API access – different terms, functionality, or technical conditions for competing users.
4. Rate limiting – imposing materially lower API-call limits on competitors.
5. API degradation – technically slowing, interrupting, or reducing functionality available to competing services.
6. Delayed API access – giving the platform's own service access to new functionality before competitors.
7. Data-access restrictions – preventing competitors from obtaining data necessary to compete.
8. Authentication restrictions – controlling API keys, tokens, credentials, or identity verification in ways that impede rivals.
9. Interoperability restrictions – preventing third-party products from interoperating with the dominant ecosystem.
10. Excessive API fees – making access economically impracticable.
11. Unfavourable API terms – imposing contractual conditions that make competing services less viable.
12. Bundled API access – requiring purchase of unrelated services as a condition of access.
13. Anti-steering restrictions – preventing API-connected businesses from directing customers toward competing services.
14. Technical documentation restrictions – withholding information necessary for effective interoperability.
15. Version-control restrictions – abruptly withdrawing or changing APIs to disrupt competing applications.

3. Relevant Competition-Law Theories

API restrictions can potentially fall under several theories of anticompetitive conduct.

A. Refusal to Deal

A dominant API operator may refuse access to an infrastructure that competitors require in order to operate.

The relevant questions include:

• Is the API indispensable?
• Is there a realistic alternative?
• Is access technically feasible?
• Would refusal eliminate effective competition?
• Has access previously been supplied?
• Is there an objective justification?

B. Raising Rivals' Costs

A dominant platform may technically permit API access but impose conditions that make competitors substantially more expensive to operate.

Examples include:

• expensive API calls;
• low call quotas;
• expensive authentication;
• additional certification;
• excessive compliance requirements;
• latency restrictions;
• separate charges for essential functionality.

The competitor technically remains in the market but is placed at a structural cost disadvantage.

C. Discriminatory Access

A particularly important concern arises where the platform provides:

better API access to its own downstream business than to competing downstream businesses.

For example:

Platform owner → API → affiliated service

receives:

• unlimited access;
• real-time data;
• advanced functionality;

while:

Platform owner → API → independent competitor

receives:

• delayed data;
• restricted functionality;
• lower quotas;
• higher fees.

This may constitute discriminatory treatment depending on market power, effects, and justification.

4. API Restriction as Exclusionary Conduct

4.1 Refusal of Essential API Access

Where an API is indispensable to participation in a downstream market, refusal can resemble the traditional essential-facilities/refusal-to-deal problem.

However, competition law generally does not impose a universal duty upon firms to assist competitors.

The strongest case usually requires several elements:

• dominance;
• indispensability;
• absence of viable alternatives;
• elimination or substantial weakening of competition;
• inability to justify the restriction;
• potentially disproportionate harm to competition.

5. Six Major Case Laws

5.1 United States v. Microsoft Corp. (2001)

Court: U.S. Court of Appeals for the D.C. Circuit

Facts

Microsoft controlled the Windows operating-system ecosystem and imposed contractual and technical restrictions affecting competing browsers, particularly Netscape.

Microsoft also used its control over Windows interfaces and technical relationships with manufacturers and software developers to protect Internet Explorer.

Competition-law principle

The case is important because exclusionary conduct can arise from the strategic use of control over an important technological platform.

The court distinguished between legitimate product design and conduct whose purpose and effect were to exclude competitors.

Relevance to API restrictions

An API operator may similarly use technical interfaces to:

• restrict competitor functionality;
• prevent interoperability;
• impose discriminatory conditions;
• make rival applications less effective.

The Microsoft precedent demonstrates that technical architecture can itself become an instrument of exclusion.

5.2 Bronner v. Mediaprint (1998)

Court: Court of Justice of the European Union

Facts

Bronner sought access to Mediaprint's newspaper home-delivery system.

The CJEU considered whether refusal by a dominant undertaking to provide access to infrastructure could constitute abuse.

Principle

The Court established a demanding standard for compulsory access.

A refusal is particularly problematic where the facility is:

1. indispensable;
2. impossible or extremely difficult to duplicate;
3. necessary to eliminate effective competition; and
4. unjustifiably refused.

API significance

An API will not automatically constitute an essential facility simply because it is commercially important.

A competitor should ordinarily be able to use:

• alternative APIs;
• independent data sources;
• alternative technical infrastructure;
• substitute distribution channels.

Only where meaningful alternatives are unavailable does the Bronner-type analysis become particularly significant.

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

Court: CJEU

Facts

IMS Health controlled a pharmaceutical-data system involving standardized regional structures used by pharmaceutical companies.

Competitors sought access to the relevant structure.

Principle

The CJEU applied the exceptional circumstances doctrine associated with refusal to license/access.

The relevant considerations included:

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

API significance

The case is highly relevant to data APIs and interoperability APIs.

Suppose a dominant data platform controls a standardized API through which customers receive essential information.

If competitors cannot realistically reproduce the underlying data or interface, refusing API access could potentially have greater competition-law significance.

5.4 Slovak Telekom a.s. v Commission (2021)

Court: CJEU

Facts

Slovak Telekom controlled telecommunications infrastructure and was found to have engaged in conduct concerning access to its network that restricted competition.

Principle

The CJEU clarified the relationship between refusal-to-deal principles and access obligations imposed upon dominant infrastructure operators.

Importantly, not every exclusionary access practice must be assessed under the exceptionally strict Bronner conditions where the undertaking is already subject to a regulatory access obligation or where the conduct involves another form of abusive access strategy.

API significance

This distinction is highly relevant to regulated APIs.

Examples include:

• banking APIs;
• telecommunications APIs;
• payment-system APIs;
• financial-data APIs;
• regulated interoperability interfaces.

Where legislation or sector regulation already imposes an access obligation, a dominant firm's attempt to circumvent that obligation through technical or contractual API restrictions may attract closer scrutiny.

5.5 Google Shopping / Google Search (General Court, 2021)

Case: Google and Alphabet v Commission

Facts

The European Commission found that Google had favoured its own comparison-shopping service in general search results while placing competing comparison-shopping services at a disadvantage.

The General Court largely upheld the Commission's findings.

Principle

A dominant digital platform may abuse market power where it uses control over a critical platform interface to favour its own downstream service and disadvantage competing services.

API significance

The analogy to APIs is substantial.

Consider:

Platform API

↓

Platform-owned application

versus

Platform API

↓

Independent competing applications

If the platform:

• provides superior API functionality to its own application;
• gives its own service preferential data access;
• limits competitors' API calls;
• delays competing applications;
• denies functionality needed by competitors;

the conduct can raise self-preferencing and discriminatory-access concerns.

The key issue remains whether the conduct constitutes exclusionary abuse under the applicable legal regime.

5.6 FTC v Qualcomm Inc. (2020)

Court: U.S. Court of Appeals for the Ninth Circuit

Facts

The litigation concerned Qualcomm's licensing practices involving cellular-standard technology and handset manufacturers.

Principle

The Ninth Circuit emphasized the limits of antitrust intervention in situations involving a firm's dealings with customers and competitors. The court rejected several theories advanced by the FTC and stressed the importance of demonstrating harm to competition rather than merely harm to individual competitors.

API significance

The case provides an important counterweight to aggressive theories of API restriction.

A company does not automatically violate antitrust law merely because its commercial terms make life harder for competitors.

There must be a legally cognizable theory of competitive harm.

This is particularly important for:

• API pricing;
• licensing;
• access fees;
• contractual restrictions;
• technical limitations.

6. Additional Important Case Law

6.7 Aspen Skiing Co. v Aspen Highlands Skiing Corp. (1985)

The U.S. Supreme Court considered a dominant firm's termination of an established cooperative arrangement with a competitor.

The case is significant for the principle that a refusal to cooperate can become problematic where the defendant:

• previously supplied/cooperated;
• terminated the relationship;
• appeared willing to sacrifice short-term economic benefits;
• thereby harmed competition.

API relevance

This is particularly relevant to API withdrawal.

For example:

Platform provides API access for five years → competitor builds dependent service → platform abruptly withdraws API solely after competitor becomes successful.

The historical course of dealing can become important.

6.8 FTC v Actavis (2013)

Although not an API case, Actavis demonstrates that competition law can examine contractual structures where apparently legitimate agreements potentially delay or suppress competitive entry.

API relevance

API contracts should therefore not be assessed only by their formal wording.

Authorities may examine:

• practical effects;
• entry barriers;
• duration;
• exclusivity;
• payment structures;
• competitive foreclosure.

6.9 Android / Google Search and Mobile Ecosystem Decisions

The European Commission's Google Android decision examined contractual restrictions surrounding Google's mobile ecosystem.

API relevance

The broader lesson is that digital ecosystems can create competition concerns when contractual and technical conditions collectively make it difficult for competing services to obtain distribution.

An API restriction can therefore be particularly significant where it operates together with:

• app-store restrictions;
• default settings;
• device certification;
• contractual exclusivity;
• data restrictions.

7. Major Forms of API Exclusion

8. API Degradation as Exclusionary Conduct

API degradation is particularly difficult to detect.

A platform may not formally refuse access. Instead, it can provide an API that technically works but performs substantially worse.

Examples:

• 100 ms latency for affiliated services;
• 1-second latency for competitors;
• 10,000 requests/minute for the incumbent;
• 500 requests/minute for competitors;
• real-time data for the incumbent;
• five-minute delayed data for competitors.

The legal issue is whether the difference results from:

legitimate technical management

or

strategic competitive foreclosure.

Evidence such as internal communications, historical API performance, engineering records, comparative access terms, and changes following competitive entry may become relevant.

9. API Access and Raising Rivals' Costs

An API operator can exclude competitors without completely blocking them.

Example

Suppose:

• incumbent's API cost = ₹1 per 1,000 calls;
• competitor's API cost = ₹25 per 1,000 calls;
• competitor requires millions of calls daily.

The competitor technically has access but faces a significantly higher marginal cost.

The competition analysis should examine:

1. market power;
2. price difference;
3. availability of substitutes;
4. competitor dependence;
5. downstream margins;
6. duration;
7. competitive effects;
8. objective justification.

10. API Restrictions and Self-Preferencing

Self-preferencing occurs where an integrated platform allegedly gives its own downstream product an advantage over competing products.

Example

A marketplace operates an API.

Its own logistics service receives:

• complete customer data;
• real-time inventory;
• unlimited calls.

Third-party logistics companies receive:

• incomplete information;
• delayed data;
• restrictive quotas.

This can create a structural advantage for the platform's downstream business.

The relevant question is not simply:

"Was the competitor treated differently?"

It is:

Did the platform's conduct use market power at the API layer to distort competition in the downstream market?

11. API Restrictions and Tying

API access can also become a tying mechanism.

For example:

Access to essential API functionality is conditional upon purchasing an unrelated cloud-storage service.

Potential competition concerns include:

• dominance in the tying market;
• separate products;
• coercion;
• foreclosure of competitors in the tied market;
• lack of objective justification.

Digital ecosystems can make this especially significant because several services may technically appear separate while being commercially interconnected.

12. API Restrictions and Data Portability

Data APIs are increasingly important for switching.

A dominant platform may restrict:

• export APIs;
• customer-data APIs;
• interoperability APIs;
• migration tools;
• real-time data portability.

This can increase switching costs and reinforce customer lock-in.

Competition concerns become stronger where:

restricted portability + network effects + high switching costs + dominant platform

combine to make market entry or expansion substantially more difficult.

13. Objective Justification

API restrictions can have legitimate purposes.

Security

Limiting API calls can prevent:

• denial-of-service attacks;
• credential abuse;
• automated fraud.

Privacy

Data access may be restricted to comply with:

• privacy laws;
• consent requirements;
• confidentiality obligations.

Technical stability

Rate limits may be necessary to prevent infrastructure overload.

Intellectual property

Some information may legitimately be protected.

Fraud prevention

Payment and financial APIs may require enhanced authentication.

Cybersecurity

Highly sensitive APIs may require certification or access controls.

Therefore:

The existence of an API restriction is not itself evidence of an antitrust violation.

The proportionality and competitive effects of the restriction matter.

14. Evidence Used to Detect Exclusionary API Conduct

Competition authorities may examine:

Technical evidence

• API logs;
• response times;
• error rates;
• rate-limit histories;
• API versions;
• access tokens;
• uptime records.

Commercial evidence

• pricing schedules;
• contracts;
• access agreements;
• discounts;
• exclusivity clauses.

Internal communications

• strategy documents;
• emails;
• engineering instructions;
• product-management discussions.

Comparative evidence

Comparison between:

• affiliated users;
• independent users;
• competitors;
• different geographical markets;
• different API versions.

15. Economic Effects

API exclusion may produce several competitive effects.

A. Foreclosure

Competitors may be unable to access an essential input.

B. Increased costs

Competitors incur higher technical or financial costs.

C. Reduced innovation

Developers may stop investing in applications dependent on the API.

D. Entry deterrence

Potential entrants may conclude that API access is too uncertain.

E. Consumer harm

Consumers may experience:

• fewer choices;
• higher prices;
• reduced functionality;
• slower innovation.

F. Ecosystem lock-in

API restrictions can strengthen network effects and make customers increasingly dependent upon the dominant ecosystem.

16. Legitimate Restriction vs Exclusionary Restriction

17. Cumulative Conduct

One of the most important points in digital competition law is that multiple API restrictions may have a cumulative exclusionary effect.

For example:

API access restriction

↓

Data limitation

↓

Rate limiting

↓

Higher fees

↓

Delayed functionality

↓

Customer lock-in

Individually, each measure might appear commercially defensible.

Collectively, however, they may significantly increase competitors' costs and reinforce the dominant platform's position.

The competition authority may therefore examine the overall ecosystem strategy rather than each restriction in isolation.

18. Regulatory Frameworks

European Union

The principal framework includes:

• Article 102 TFEU;
• abuse of dominant position;
• refusal to supply;
• discriminatory access;
• tying;
• self-preferencing-related theories;
• interoperability concerns;
• digital-platform regulation, including the Digital Markets Act for designated gatekeepers.

United States

Relevant doctrines arise principally under:

• Sherman Act §2;
• monopolization;
• attempted monopolization;
• exclusionary conduct;
• refusal-to-deal doctrine;
• tying;
• essential-facilities-related theories.

The U.S. approach generally places substantial emphasis on demonstrating harm to the competitive process rather than merely harm to an individual rival.

India

In India, the principal framework is:

• Competition Act, 2002;
• Section 4 concerning abuse of dominant position;
• discriminatory or unfair conditions;
• denial of market access;
• leveraging;
• tying/bundling;
• exclusionary conduct.

The Competition Commission of India (CCI) may examine digital-platform conduct where control over an API or digital interface gives an enterprise the ability to affect competition in another market.

19. Six-Case Comparative Framework

20. Exam-Oriented Legal Test

A useful framework for analysing an API restriction is:

Step 1 — Define the market

Identify:

• API market;
• platform market;
• downstream application market;
• data market;
• interoperability market.

Step 2 — Establish market power

Examine:

• market share;
• network effects;
• switching costs;
• ecosystem dependence;
• data advantages;
• technical barriers.

Step 3 — Identify the API restriction

Determine whether the conduct involves:

• refusal;
• discrimination;
• degradation;
• pricing;
• rate limiting;
• interoperability;
• bundling;
• exclusivity;
• data restriction.

Step 4 — Establish foreclosure

Ask whether competitors are:

• excluded;
• disadvantaged;
• forced to incur higher costs;
• prevented from entering;
• prevented from expanding.

Step 5 — Examine indispensability

Determine whether meaningful alternatives exist.

Step 6 — Examine intent and implementation

Relevant evidence may include:

• internal documents;
• technical records;
• API changes;
• timing;
• communications with competitors.

Step 7 — Consider objective justification

Examine:

• cybersecurity;
• privacy;
• capacity;
• fraud prevention;
• technical integrity;
• legitimate IP concerns.

Step 8 — Apply proportionality

Even a legitimate objective may not justify a restriction that is unnecessarily broad or discriminatory.

21. Conclusion

API restrictions become competition-law concerns when control over a technically important interface is converted into a mechanism for excluding or disadvantaging competitors.

The most important distinction is between:

neutral, proportionate API governance

and

strategic API control designed or implemented in a manner that forecloses competition.

The major case-law principles from Microsoft, Bronner, IMS Health, Slovak Telekom, Google Shopping, Qualcomm and Aspen Skiing provide different analytical components: technological exclusion, indispensability, refusal to deal, discriminatory access, self-preferencing, competitive harm, and termination of established cooperation.