1. Introduction

API Access Governance refers to the legal, technical, and institutional rules governing how businesses, developers, competitors, and third-party service providers access an application programming interface (API). An API allows different software systems to communicate, exchange data, and use each other's functions.

For example, a digital platform may provide an API that allows independent developers to access payment services, customer data (with appropriate authorization), mapping functions, product listings, or cloud computing resources.

API access becomes an antitrust issue when a business controlling an important digital service uses its control over an API to restrict competition. Such conduct may include refusing access to competing businesses, charging discriminatory access fees, degrading the performance of third-party integrations, restricting interoperability, or using technical rules to favour its own products.

The central legal question is:

When is an API owner's decision to control access a legitimate exercise of technical and commercial rights, and when does it become an unlawful restriction of competition?

The answer depends on the relevant jurisdiction, the market position of the API owner, the importance of the API to competitors, the justification for the restrictions, and their effects on competition.

API access governance intersects with competition law, data protection, intellectual property, cybersecurity, contract law, consumer protection, and digital-platform regulation.

2. Meaning and principal forms of API access governance

API governance includes the policies and mechanisms used to determine who can access an API, under what conditions, and for what purposes.

These practices are not automatically unlawful. A company may legitimately impose access controls to protect user privacy, prevent fraud, maintain security, preserve system reliability, and protect intellectual property. Competition law becomes relevant when the conduct has the legally required connection to market power and competitive harm.

3. Legal framework governing API access

A. Competition law in India

The principal statute is the Competition Act, 2002, administered by the Competition Commission of India (CCI).

Section 4 — Abuse of dominant position

Section 4 is particularly relevant where a dominant digital platform controls an API that competitors need to access customers or develop interoperable products.

Potentially relevant forms of conduct include:

Imposing unfair or discriminatory conditions on API access.

Limiting technical development or the provision of services to the prejudice of consumers.

Denying market access to competing businesses.

Leveraging dominance in one market to protect another market.

Using different integration standards to favour affiliated products.

The legal analysis must establish dominance in a properly defined relevant market and abuse of that dominance. Possessing a popular API, charging a high fee, or refusing a particular integration does not automatically establish a violation.

Sections 3 and 19

Section 3 addresses anti-competitive agreements, including certain exclusive arrangements, while Section 19 provides the framework for CCI investigations into relevant competition concerns. Section 4 is often the central provision where unilateral conduct by a dominant platform is challenged.

Remedies

Under Section 27, the CCI can direct an enterprise to discontinue abusive conduct and may impose penalties and other legally available remedies. In an API dispute, an appropriate remedy might involve removing discriminatory restrictions, permitting non-discriminatory access, or changing contractual or technical practices.

B. European Union competition law

Article 102 of the Treaty on the Functioning of the European Union (TFEU) prohibits abuse of a dominant position. It can apply to discriminatory access, exclusionary refusals, tying, and other conduct that harms competition.

The EU framework is particularly important because API access can determine whether third-party applications can function on operating systems, vehicles, messaging platforms, and other digital ecosystems.

The Digital Markets Act (DMA), Regulation (EU) 2022/1925, adds specific obligations for designated gatekeepers. Article 6(7), for example, requires effective interoperability and access to specified operating-system hardware and software features for third parties, subject to the regulation's scope and safeguards.

European Commission

+1

The distinction is important: traditional competition law generally requires an assessment of market power and abusive conduct, whereas the DMA imposes defined obligations on designated gatekeepers without requiring every case to satisfy the same abuse analysis.

4. Important case laws

The following cases establish principles that can be applied to API access, interoperability, digital-platform restrictions, and control of commercially important technical infrastructure. Not every case concerns a conventional REST or web API; their relevance lies in the underlying legal principles.

Case 1: Google LLC v. Competition Commission of India — Android ecosystem

Competition Appeal (AT) No. 1 of 2023, NCLAT, judgment dated 29 March 2023

Facts: The CCI investigated Google's Android-related agreements and practices, including the pre-installation of Google applications, restrictions concerning Android forks, and the bundling of applications and Google services. The dispute also involved access to Google Play Services APIs.

Legal issues: Whether Google's contractual and technical arrangements restricted competition, limited market access, and leveraged its position in licensable mobile operating systems and Android app stores.

Decision and significance: The NCLAT addressed the CCI's findings and remedies in its appellate judgment. Its directions included a requirement that Google not deny access to Play Services APIs in a way that disadvantaged device manufacturers, developers, and actual or potential competitors, alongside directions concerning exclusivity and Android forks.

Indian Kanoon

+1

Principle for API governance: When access to an ecosystem's APIs is important to application compatibility, restricting that access may reinforce the platform owner's market position and disadvantage rival operating systems or services.

Practical application: A platform that allows its own applications to use essential integration functions while selectively preventing competing applications from using comparable functions may face scrutiny under Section 4 of the Indian Competition Act.

The assessment still depends on the market, the precise restrictions, their effects, and any legitimate technical justification. This judgment should not be read as establishing that every API owner must provide unrestricted access.

Case 2: Google and Alphabet v. European Commission — Google Android

Case T-604/18, General Court of the European Union, 14 September 2022

Facts: The European Commission challenged several Android-related practices, including arrangements linking Google applications and services to access to its mobile ecosystem, and contractual restrictions affecting competing mobile operating systems.

Legal issues: Whether contractual and ecosystem restrictions could preserve or strengthen Google's dominance and restrict competition.

Legal significance: The General Court substantially upheld the Commission's Android abuse findings, while adjusting the fine. The case demonstrates how the combined effect of contractual restrictions, application distribution arrangements, and ecosystem control can be relevant to competition law.

Principle for API governance: An API restriction should not always be assessed in isolation. Its competitive significance may depend on how it operates alongside app-store rules, licensing arrangements, default settings, and restrictions on alternative systems.

For example, a seemingly neutral API licensing condition may be more concerning if it works together with exclusivity obligations that prevent competitors from building viable alternatives.

Case 3: Microsoft Corp. v. Commission

Case T-201/04, General Court of the European Communities, 17 September 2007

Facts: The dispute concerned Microsoft's refusal to disclose interoperability information needed by competing work-group server operating systems, as well as separate concerns about tying Windows Media Player to Windows.

Legal issue: Whether a dominant firm could lawfully withhold technical information needed by competitors to achieve interoperability.

Decision: The General Court upheld the Commission's principal finding concerning Microsoft's refusal to supply interoperability information, subject to the legal framework and specific facts of the case.

Principle for API governance: Technical interfaces and interoperability information can be competitively significant. A dominant undertaking's refusal to provide such information may constitute abuse where the applicable legal requirements are satisfied.

This case is especially relevant where a platform owner controls documentation, protocols, authentication mechanisms, or interface specifications that rivals need to make their products compatible.

However, the decision does not establish a universal obligation to disclose source code, trade secrets, or every proprietary interface.

Case 4: Alphabet Inc. and Others v. AGCM — Android Auto interoperability

Case C-233/23, Court of Justice of the European Union, Grand Chamber, 25 February 2025

Facts: Enel X developed JuicePass, an application for electric-vehicle charging services. It sought to make the application compatible with Google's Android Auto platform. Google refused to provide the necessary interoperability, citing the absence of an appropriate template for that category of application.

Legal issue: Could a dominant platform's refusal to make an application interoperable violate Article 102 TFEU even if the platform was not indispensable to the rival application's commercial operation?

Judgment: The Court held that a refusal to ensure interoperability can constitute an abuse where the platform was developed with a view to enabling third parties to use it and the refusal is capable of restricting competition and harming consumers. In such circumstances, the strict indispensability requirement from the Bronner judgment does not necessarily apply. The Court also recognised that security, integrity, and genuine technical limitations can justify certain refusals.

EUR-Lex

+1

Principle for API access governance: A platform cannot necessarily avoid competition scrutiny merely by arguing that a competing application can operate without its API. Interoperability may make the application more attractive and improve its ability to compete.

The Court also addressed the need to develop an appropriate software template. The mere fact that interoperability requires additional development work is not automatically a sufficient justification for refusing access.

This is one of the most directly relevant modern judgments for API governance, particularly in connected vehicles, operating systems, smart devices, and digital services.

Case 5: Oscar Bronner GmbH & Co. KG v. Mediaprint

Case C-7/97, Court of Justice of the European Communities, 26 November 1998

Facts: Bronner, a newspaper publisher, sought access to Mediaprint's established home-delivery distribution system.

Legal issue: When can a dominant business be required to provide a competitor with access to infrastructure it controls?

Judgment: The Court established a demanding test for certain refusals to grant access to infrastructure developed for the dominant undertaking's own business. Among other requirements, the infrastructure must be indispensable, the refusal must be capable of eliminating all competition by the applicant on the relevant market, and the refusal must lack objective justification.

Principle for API governance: A company is not ordinarily required to open every proprietary API to competitors simply because access would make competing products easier to develop.

However, the Bronner test must be applied carefully. The later Android Auto judgment clarified that the strict indispensability requirement does not automatically govern a refusal to provide interoperability with a digital platform designed to accommodate third-party services.

EUR-Lex

+1

Case 6: IMS Health GmbH & Co. OHG v. NDC Health GmbH & Co. KG

Case C-418/01, Court of Justice of the European Communities, 29 April 2004

Facts: The dispute involved a pharmaceutical sales-data structure used to organise regional pharmaceutical sales information. IMS Health had intellectual-property rights in the structure, and a competitor sought access to it.

Legal issue: Under what circumstances can refusal to license intellectual property prevent competition in a neighbouring market?

Judgment: The Court identified exceptional circumstances relevant to compulsory licensing, including the indispensable character of the protected material, the prevention of a new product for which there was potential consumer demand, the exclusion of competition in a secondary market, and the absence of objective justification.

Principle for API governance: Proprietary interface specifications, data structures, and technical schemas may have intellectual-property significance. Competition law must balance those rights against the exceptional circumstances in which refusal to license may exclude competition.

This case is particularly relevant to proprietary data APIs, industry-standard schemas, and interfaces needed to build complementary products. It does not establish a general obligation to license all API-related intellectual property.

Case 7: Magill — Radio Telefis Éireann and Independent Television Publications

Joined Cases C-241/91 P and C-242/91 P, Court of Justice of the European Communities, 6 April 1995

Facts: Television broadcasters refused to license copyright-protected programme listings needed by a publisher seeking to produce a comprehensive weekly television guide.

Legal issue: Whether refusal to license protected information could constitute an abuse of a dominant position.

Judgment: The Court upheld the finding of abuse in the exceptional circumstances of the case, including the prevention of a new product for which consumer demand existed.

Principle for API governance: Control over an indispensable information resource can restrict the development of new products. Where an API exposes information that competitors need to develop a genuinely different service, refusal to provide access may warrant scrutiny.

The case must be distinguished from ordinary disputes over licensing or the commercial exploitation of intellectual property. The exceptional circumstances matter.

5. Comparative legal principles

The overarching lesson is that competition law protects the competitive process rather than guaranteeing every developer access to every technical resource.

6. Common anti-competitive API practices

A. Discriminatory API access

Suppose a dominant payment platform allows its own payment application to access real-time transaction data, while competing payment applications face unnecessary delays or are denied comparable access.

The relevant questions include:

Are the platform's own services and rival services comparable?

Is there a difference in access conditions or technical performance?

Does the difference have an objective justification?

Does the difference disadvantage competitors or distort competition?

Different treatment may be legitimate where it is necessary for security, privacy, technical compatibility, or another objectively supportable reason. But unexplained discriminatory treatment by a dominant platform can raise concerns under Section 4 of the Indian Competition Act or Article 102 TFEU, as applicable.

B. API tying and bundling

A platform may require developers to use its payment API, authentication service, analytics system, or advertising service as a condition of accessing another product.

Tying or bundling is not automatically unlawful. Competition authorities examine market power, the relationship between the products, the contractual conditions, foreclosure effects, and possible efficiencies.

The Android litigation demonstrates why API conditions must sometimes be assessed alongside application distribution agreements and other ecosystem restrictions.

C. Sudden withdrawal of API access

A company may discontinue an API for security reasons, product redesign, or commercial restructuring. However, sudden withdrawal can create competition concerns when the company controls an important platform and the change selectively disadvantages rivals.

Relevant evidence includes:

Whether advance notice was given.

Whether equivalent access remains available to the platform owner's products.

Whether alternative interfaces exist.

Whether the change is technically necessary.

Whether competitors have become commercially dependent on the API.

Whether the withdrawal is capable of excluding or obstructing competition.

There is no general rule requiring an API to remain available forever. The legality depends on the applicable law and the circumstances.

D. Self-preferencing

Self-preferencing occurs when a platform favours its own downstream products over competing services. In an API setting, this might involve granting affiliated products early access to new features, better technical documentation, or more reliable integration.

Such practices can be particularly consequential in markets with network effects: users prefer services compatible with the dominant platform, and developers prefer platforms with the largest user base.

Under EU law, the Google Shopping litigation and the DMA provide additional context for examining certain forms of preferential treatment. The precise legal test differs according to the applicable regime.

7. The Digital Markets Act and mandatory interoperability

The EU DMA is important because it moves beyond relying exclusively on individual abuse-of-dominance cases.

Article 6(7) requires designated gatekeepers providing operating systems or virtual assistants to permit specified forms of effective interoperability with hardware and software features controlled by those systems. The obligation is intended to allow third-party products to compete on more equal terms, while permitting strictly necessary and proportionate safeguards for system integrity and security.

European Commission

+1

For API governance, this has three implications:

Interoperability by design: Gatekeepers may need to design systems so that qualifying third-party services can access relevant features effectively.

Comparable technical opportunities: A gatekeeper cannot necessarily provide a feature to its own services while making access ineffective for third parties.

Justified safeguards: Security and system integrity remain legitimate considerations, but restrictions must meet the applicable legal standards.

The DMA does not impose identical access duties on every business. Its obligations apply to designated gatekeepers and specified core platform services.

8. How competition authorities should assess an API access dispute

A sound investigation should proceed through a structured analysis.

Step 1 — Define the relevant market

Identify the product or service in which the API operates, including potential upstream infrastructure and downstream services. Avoid assuming that every API is a separate market.

Step 2 — Establish market power

Examine market shares, entry barriers, switching costs, network effects, alternative APIs, and the ability of developers to reach users through other channels.

Step 3 — Examine the access restriction

Identify refusals, delays, fees, technical limitations, discriminatory terms, or differences in access between the platform owner's services and independent rivals.

Step 4 — Test the justification

Evaluate cybersecurity, privacy, intellectual-property rights, technical feasibility, capacity constraints, and whether the restriction is proportionate to the stated objective.

Step 5 — Evaluate competitive effects and remedies

Determine whether the conduct excludes or obstructs competitors, limits innovation or consumer choice, and what proportionate remedy could restore effective competition.

9. Evidence in API-related antitrust proceedings

The legal outcome often depends on technical evidence, not simply contractual wording.

Important evidence may include:

API documentation, version histories, and access policies.

Records of access requests and the platform's responses.

Rate limits, latency measurements, error logs, and uptime records.

Internal documents concerning decisions to grant or deny access.

Pricing schedules and comparisons between affiliated and independent developers.

Evidence of alternative APIs and the cost of switching.

Security assessments and records of alleged vulnerabilities.

Market evidence showing effects on entry, innovation, prices, or consumer choice.

A claimant should distinguish an actual technical limitation from an exclusionary restriction disguised as a technical limitation. Conversely, a defendant should document genuine security or engineering reasons rather than rely on unsupported assertions.

10. Remedies and compliance mechanisms

Depending on the jurisdiction and legal findings, possible measures include:

Non-discriminatory access conditions.

Transparent API eligibility and pricing rules.

Reasonable notice before material changes or discontinuation.

Published interoperability specifications.

Independent technical audits or monitoring.

A clear process for reviewing denied access requests.

Proportionate security controls applied consistently to comparable users.

Cease-and-desist orders, financial penalties, or other statutory remedies.

A well-designed governance system should separate security decisions from competitive decisions, document material changes, and provide a review mechanism for disputed access restrictions.

11. Critical legal challenges

API access governance raises several difficult questions.

First, compulsory access versus innovation. Excessively broad access obligations may reduce incentives to develop and maintain valuable infrastructure. But excessive control may allow a dominant platform to exclude rivals from complementary markets.

Second, security versus exclusion. Interoperability can create genuine cybersecurity risks. However, security justifications require evidence, and less restrictive alternatives may sometimes be available.

Third, intellectual property versus competition. API documentation, software, and interface designs may involve protected intellectual property. Antitrust law does not automatically override those rights; the relevant legal conditions must be satisfied.

Fourth, technical neutrality versus substantive equality. Applying identical rules to every developer may not always create effective competition, particularly where the platform's own service has privileged technical access. On the other hand, different treatment can be justified by genuine differences in technical or security requirements.

Fifth, jurisdictional differences. India, the EU, and the United States do not apply identical tests to refusals to deal, interoperability restrictions, or compulsory access. A legal assessment must identify the governing jurisdiction before drawing a conclusion.

12. Conclusion

API access governance is a significant emerging area of competition law because technical interfaces increasingly determine whether independent businesses can participate in digital markets.

The Indian Android litigation demonstrates how API restrictions can form part of broader ecosystem practices that affect competition. The European cases Microsoft v. Commission, Bronner, IMS Health, and Magill establish important principles concerning interoperability, access to infrastructure, and intellectual property. Most directly, the Court of Justice's 2025 judgment in Alphabet v. AGCM clarifies that refusal to ensure interoperability with a third-party application can constitute abuse even where the platform is not strictly indispensable, provided the applicable conditions are satisfied.

Indian Kanoon

+2

Ultimately, lawful API governance requires a balance between legitimate control of technical infrastructure and the prevention of exclusionary conduct. The legal focus is not whether an API is proprietary, but whether the access restrictions, in their specific market context, are lawful, objectively justified, and consistent with the applicable competition rules.