Municipal API Access Discrimination — Detailed Explanation

1. Introduction

Municipal API access discrimination arises where a municipality, municipal corporation, public utility, or municipally controlled platform provides an API or digital interface that is necessary for private undertakings to access public data, infrastructure, permits, transport information, payment systems, mapping information, utility data, or other municipal services, but gives unequal, preferential, delayed, restricted, or technically inferior access to competing businesses.

The competition-law concern becomes particularly significant where:

• the municipality controls a facility or dataset that competitors cannot reasonably reproduce;
• the API is necessary to compete downstream;
• the municipality itself operates a commercial service competing with private API users;
• a municipality-owned enterprise receives preferential API access;
• access conditions discriminate between similarly situated undertakings;
• API restrictions increase switching costs or foreclose competing platforms;
• the municipality uses technical standards or authentication requirements selectively; or
• access is granted to one undertaking on better pricing, rate limits, latency, documentation, or functionality.

The precise legal treatment depends on whether the municipality is acting as a public regulator or as an economic undertaking. That distinction is fundamental.

2. Meaning of Municipal API

An API (Application Programming Interface) is a technical mechanism allowing one software system to communicate with another.

A municipality might operate APIs providing:

• public-transit schedules and real-time vehicle locations;
• parking availability;
• charging-station information;
• building and planning data;
• property or cadastral information;
• environmental data;
• waste-collection information;
• public procurement information;
• licensing and permit status;
• utility consumption information;
• municipal payment systems;
• geospatial information;
• emergency and road-closure information; or
• smart-city sensor data.

For example:

Municipality A operates a transport-data API. Its own mobility application receives real-time vehicle data, unlimited API calls and full technical documentation, while independent mobility applications receive delayed data, a restrictive rate limit and incomplete documentation.

That could create a competition issue if the municipality or its commercial affiliate has market power and the API is important for competing downstream services.

3. Why API Access Can Become a Competition Issue

API discrimination can affect competition through several mechanisms.

A. Input foreclosure

The municipality controls an important upstream input and prevents rivals from obtaining equivalent access.

B. Customer foreclosure

Preferential API arrangements may prevent competing downstream platforms from reaching municipal customers or users.

C. Self-preferencing

A municipality-owned commercial undertaking may receive better API access than independent competitors.

D. Raising rivals' costs

Competitors may technically receive access but under:

• higher fees;
• lower API limits;
• slower response times;
• reduced functionality;
• inferior documentation;
• more frequent authentication requirements.

This can substantially increase their operating costs.

E. Data advantage

A municipal platform may receive real-time or more granular data while competitors receive historical or aggregated data.

F. Interoperability foreclosure

The municipality may refuse to provide technical interfaces necessary for interoperability between municipal infrastructure and third-party services.

4. Relevant Competition-Law Framework

A. Abuse of Dominance

Where the municipality or a municipal undertaking qualifies as an undertaking and possesses a dominant position, discriminatory API access may potentially fall within abuse-of-dominance rules.

Under Article 102 TFEU, relevant forms of conduct can include:

• discriminatory conditions;
• refusal of access;
• exclusionary conduct;
• tying or leveraging;
• unfair trading conditions; and
• conduct that restricts competition.

The central questions are:

1. Is there a relevant market?
2. Does the municipal entity qualify as an undertaking for the activity concerned?
3. Does it possess substantial market power?
4. Is the API an important or indispensable input?
5. Are similarly situated users being treated differently?
6. Does the difference have an objective justification?
7. Does the conduct restrict effective competition?

5. Municipality as Regulator vs Municipality as Undertaking

This distinction is particularly important.

A municipality performing purely governmental functions may not be treated in the same way as an undertaking carrying out an economic activity.

For example:

Therefore, simply calling an entity a "municipality" does not resolve the competition-law question.

6. Municipal API as an Essential Facility

The strongest competition argument arises where the API constitutes, or forms part of, an essential facility.

The traditional refusal-to-supply doctrine requires careful examination because competition law does not normally impose a general obligation upon dominant undertakings to deal with competitors.

The classic Bronner conditions are particularly important.

Generally, the analysis asks whether:

1. access is indispensable;
2. there is no realistic alternative;
3. refusal is capable of eliminating effective competition;
4. access cannot reasonably be replicated; and
5. the refusal lacks objective justification.

The CJEU has subsequently clarified the application of these principles in regulated-access situations.

7. Discrimination Can Exist Even Where Access Is Technically Available

A municipality cannot necessarily avoid competition scrutiny simply by saying:

"We provide API access to everybody."

The real question may be whether the access is genuinely equivalent.

For example:

Municipal platform

• 10,000 requests/minute;
• real-time data;
• complete API documentation;
• priority technical support;
• direct authentication;
• full historical database.

Private competitor

• 100 requests/minute;
• 15-minute delayed data;
• incomplete documentation;
• restricted fields;
• slower authentication.

Formally, both receive access.

Economically, however, the access may be substantially different.

8. Forms of Municipal API Discrimination

8.1 Price discrimination

Different undertakings may be charged different API fees without objective justification.

8.2 Technical discrimination

One undertaking receives:

• higher rate limits;
• greater bandwidth;
• lower latency;
• additional endpoints;
• superior authentication.

8.3 Data discrimination

One undertaking receives:

• real-time data;
• higher-resolution information;
• historical datasets;
• predictive information;

while competitors receive less useful data.

8.4 Timing discrimination

A municipality may provide information to its own commercial platform first and competitors later.

8.5 Documentation discrimination

A preferred operator may receive technical documentation, software-development kits and testing environments that competitors do not receive.

8.6 Enforcement discrimination

The municipality may strictly enforce API terms against competitors while tolerating violations by its own commercial undertaking.

9. Objective Justification

Different treatment is not automatically unlawful.

A municipality may have legitimate reasons for imposing different conditions.

Possible objective justifications include:

• cybersecurity;
• protection of personal data;
• network stability;
• API capacity limitations;
• emergency-service requirements;
• protection against abusive automated requests;
• technical interoperability;
• protection of critical infrastructure;
• statutory obligations;
• legitimate public-service requirements.

However, the justification should normally be:

legitimate + objectively connected to the difference + proportionate.

A municipality should therefore avoid relying upon vague statements such as:

"The municipal platform is different."

It should be able to demonstrate precisely why different access conditions are technically or legally necessary.

10. Six Important Case Laws

Because reported cases specifically involving municipal APIs remain limited, the following authorities provide the principal competition-law doctrines that can be applied by analogy to municipal API discrimination.

Case 1 — Commercial Solvents Corp. v Commission

Cases 6/73 and 7/73, Commercial Solvents v Commission (1974)

Principle

The CJEU recognised that a dominant undertaking controlling an important upstream input could abuse its position by restricting supply to downstream competitors.

Relevance to municipal APIs

A municipality controlling a critical upstream digital input may create similar concerns where it:

• supplies its own downstream service;
• refuses equivalent access to competitors; and
• thereby disadvantages competing downstream operators.

Application

Suppose a municipal transport authority supplies real-time transit data to its own mobility application but refuses equivalent access to independent mobility applications.

The Commercial Solvents principle supports examining whether control over the upstream input is being used to disadvantage downstream competition.

Case 2 — United Brands v Commission

Case 27/76, United Brands v Commission (1978)

Principle

The CJEU examined discriminatory treatment under Article 102 and recognised that a dominant undertaking must not apply dissimilar conditions to equivalent transactions where the difference places trading partners at a competitive disadvantage.

Municipal API relevance

This is highly relevant where a municipality or municipal undertaking provides API access under different conditions.

Potentially relevant variables include:

• API pricing;
• access quotas;
• response times;
• functionality;
• technical support;
• data quality.

The crucial question is whether undertakings are in equivalent situations and whether differential treatment creates a competitive disadvantage.

Case 3 — Bronner v Mediaprint

Case C-7/97, Oscar Bronner GmbH v Mediaprint (1998)

Principle

Bronner established the stringent conditions associated with compulsory access to infrastructure controlled by a dominant undertaking.

The CJEU emphasised that compulsory access interferes with contractual freedom and property rights and therefore requires particularly strong justification.

Municipal API relevance

This case is important when a private undertaking demands access to a municipal API.

The claimant would need to demonstrate more than mere usefulness.

Questions include:

• Is the API indispensable?
• Is there a practical alternative?
• Can the API reasonably be replicated?
• Would refusal eliminate effective competition?
• Is there objective justification?

Important qualification

Municipal APIs may sometimes present a stronger access argument than privately created infrastructure where the underlying data or infrastructure is uniquely generated through governmental authority.

Case 4 — IMS Health v NDC Health

Case C-418/01, IMS Health v NDC Health (2004)

Principle

The CJEU developed the exceptional circumstances surrounding compulsory licensing/access to an indispensable facility or intellectual property right.

The criteria included:

• indispensability;
• elimination of competition;
• prevention of the emergence of a new product for which consumer demand exists; and
• absence of objective justification.

Municipal API relevance

The case is particularly useful where the API incorporates:

• proprietary database structures;
• unique municipal datasets;
• digital interfaces;
• protected technical architecture.

If independent businesses cannot realistically reproduce the underlying municipal information, the indispensability analysis becomes particularly important.

Case 5 — Microsoft v Commission

Case T-201/04, Microsoft Corp. v Commission (2007)

Principle

The General Court upheld findings concerning Microsoft's refusal to provide interoperability information to competing work-group server products.

The case demonstrates the importance of interoperability in digital competition.

Municipal API relevance

This is one of the most useful analogies for API disputes.

A municipality could potentially create competitive foreclosure by withholding:

• API specifications;
• authentication protocols;
• interoperability documentation;
• interface information;
• necessary technical information.

The issue is not merely physical access. Information required to make systems interoperable can itself be competitively significant.

Case 6 — Slovak Telekom v Commission

Case C-165/19 P, Slovak Telekom v Commission (2021)

Principle

The CJEU dealt with access obligations concerning the incumbent telecommunications operator's local-loop infrastructure.

The Court distinguished situations involving an existing regulatory access obligation from the stricter Bronner refusal-to-deal framework.

Municipal API relevance

This is highly relevant where legislation, regulation, licence conditions or public procurement rules already require API access.

If a municipality or municipal undertaking is already subject to an access obligation, a dispute may concern:

• discriminatory implementation;
• unreasonable technical conditions;
• excessive charges;
• restrictive access parameters;
• discriminatory quality of service.

The existence of a regulatory access framework can therefore materially alter the legal analysis.

Case 7 — Deutsche Telekom v Commission

Case C-152/19 P, Deutsche Telekom v Commission (2021)

Principle

The CJEU considered access to the local telecommunications loop and the relationship between regulatory access obligations and Article 102 TFEU.

The case is particularly relevant to regulated infrastructure access.

Municipal API application

Where a municipality operates an infrastructure subject to statutory or regulatory access obligations, discriminatory implementation may be analysed differently from an ordinary refusal by a privately developed facility.

For example:

A municipal transport authority is legally required to provide standardized real-time transit data but gives its own commercial application superior access conditions.

The regulatory obligation can become an important part of the competition analysis.

Case 8 — LUKOIL Bulgaria / LUKOIL Neftohim Burgas

Case C-245/24, judgment of 18 December 2025

This is a particularly significant recent authority concerning infrastructure controlled through public involvement.

The CJEU held that the Bronner conditions may apply to infrastructure developed by public authorities and subsequently acquired or controlled by a dominant undertaking, subject to the conditions identified by the Court concerning the circumstances of privatization or transfer and the undertaking's decision-making autonomy.

Municipal API significance

This authority is useful by analogy where:

• a municipality originally developed the digital infrastructure;
• a municipal undertaking subsequently operates it;
• the undertaking obtains exclusive control;
• competitors seek access.

It demonstrates that the public origin of infrastructure does not automatically eliminate the refusal-of-access analysis.

11. Comparative Case-Law Table

12. Essential-Facility Analysis for Municipal APIs

A useful analytical framework is:

Step 1 — Identify the facility

What exactly is controlled?

• API?
• dataset?
• authentication gateway?
• digital infrastructure?
• municipal payment system?

Step 2 — Define the relevant market

Possible markets include:

• urban mobility applications;
• parking platforms;
• EV charging aggregation;
• municipal-data services;
• digital permitting;
• smart-city services.

Step 3 — Establish control

Who actually controls the API?

• municipality;
• municipal corporation;
• public utility;
• concessionaire;
• private technology operator.

Step 4 — Determine economic activity

Is the entity acting commercially or exercising sovereign governmental authority?

Step 5 — Examine dominance

Consider:

• market share;
• network effects;
• regulatory control;
• exclusive rights;
• switching costs;
• availability of alternatives.

Step 6 — Test indispensability

Can competitors obtain equivalent information elsewhere?

Step 7 — Compare access conditions

Assess:

• price;
• functionality;
• speed;
• rate limits;
• data completeness;
• latency;
• documentation;
• technical support.

Step 8 — Examine competitive effect

Has the conduct:

• foreclosed competitors?
• raised rivals' costs?
• reduced innovation?
• degraded interoperability?
• protected a municipal commercial affiliate?

Step 9 — Examine justification

Determine whether differential access is objectively justified and proportionate.

13. Hypothetical Example

Assume City X operates a public parking API.

The API provides:

• parking-space availability;
• location;
• prices;
• occupancy;
• payment status.

City X also operates a commercial parking application.

Access provided to City X's application

• real-time information;
• 5,000 requests/minute;
• full historical database;
• direct payment integration.

Access provided to competitors

• five-minute delay;
• 100 requests/minute;
• no payment API;
• incomplete historical data.

If City X's commercial application competes with private parking applications, the differential treatment could raise questions concerning:

1. dominance;
2. discriminatory access;
3. self-preferencing;
4. raising rivals' costs;
5. leveraging municipal infrastructure into a downstream market; and
6. possible essential-facility considerations.

The municipality could nevertheless justify some restrictions if, for example, unlimited API access threatened cybersecurity or system stability.

14. Municipal API Access and Self-Preferencing

Self-preferencing is especially important in municipal digital ecosystems.

Consider:

Municipal authority → controls API → operates platform → competes with private platforms

The competition concern becomes stronger where the authority:

1. gives itself superior access;
2. gives competitors inferior access;
3. uses municipal data to improve its own product;
4. limits interoperability for competitors; and
5. uses regulatory powers to reinforce its commercial position.

The analysis should distinguish legitimate public-service prioritisation from preferential treatment that protects a commercial activity from competition.

15. Remedies

If discriminatory API access is established, possible remedies may include:

A. Non-discriminatory access

Require equivalent undertakings to receive equivalent technical access.

B. Transparent access rules

Publish objective:

• eligibility criteria;
• API fees;
• rate limits;
• technical specifications;
• security requirements.

C. Functional equivalence

Require competitors to receive substantially equivalent API functionality.

D. Interoperability remedy

Provide necessary technical documentation or interface specifications.

E. Monitoring

An independent authority may monitor:

• API uptime;
• latency;
• access denials;
• rate limits;
• pricing;
• complaints.

F. Firewalls

Where appropriate, separate the municipal regulator/data controller from the commercial operation.

G. Non-discrimination obligation

Require access terms to be applied consistently to similarly situated users.

16. Important Defences for Municipalities

A municipality may rely on several legitimate grounds.

Cybersecurity

Higher restrictions may be justified for sensitive endpoints.

Privacy

Personal or sensitive information may require restricted access.

System capacity

Rate limits can be legitimate if objectively based on infrastructure capacity.

Public safety

Emergency or critical-infrastructure APIs may require special access.

Statutory obligations

Certain information may legally be restricted.

Data-quality protection

Restrictions may prevent inaccurate or manipulated data from entering municipal systems.

Public-service obligations

The municipality may have obligations that commercial competitors do not have.

The key issue is whether the difference is objectively justified rather than commercially protectionist.

17. Competition-Law Risk Matrix

18. Key Legal Test

For examination purposes, municipal API discrimination can be reduced to the following formula:

Municipal control + economic activity + market power + unequal API access + competitive disadvantage + absence of objective justification = potential competition-law concern.

Where access is indispensable, the essential-facilities/refusal-to-deal jurisprudence becomes particularly important.

Where access is already mandated by regulation, the analysis can focus more directly on whether the access obligation is being implemented in a discriminatory or unreasonable manner. The EU telecommunications jurisprudence illustrates this distinction.

19. Conclusion

Municipal API access discrimination represents a modern intersection of competition law, public infrastructure regulation, data governance and digital interoperability.

The strongest cases arise where a municipality or municipal undertaking controls a unique digital gateway or dataset, competes downstream, and provides itself or an affiliated undertaking with materially better API access than independent competitors.

The principal legal concepts are:

• abuse of dominance;
• discriminatory conditions;
• refusal to supply;
• essential facilities;
• interoperability;
• self-preferencing;
• raising rivals' costs; and
• regulated access obligations.

The most useful authorities are Commercial Solvents, United Brands, Bronner, IMS Health, Microsoft, Slovak Telekom, Deutsche Telekom, and the recent LUKOIL judgment. In particular, LUKOIL confirms that infrastructure originating from public authorities can still raise Article 102 access questions under specified conditions.

Exam takeaway: The decisive issue is not simply whether a municipality provides an API. It is whether a municipality with relevant economic power uses control over a necessary digital input to treat competing undertakings unequally in a way that restricts competition without adequate objective justification.