1. Legal Structure of API Deprecation Liability in Denmark

(A) Contractual Primacy

API usage is governed by:

• Terms of Service / API License Agreements
• SLA clauses (uptime, stability, version support)
• Change management clauses (deprecation notice)

Providers typically reserve the right to:

• Modify APIs
• Deprecate endpoints
• Terminate versions with notice

If notice obligations are unclear or violated → liability risk increases.

(B) Fault-Based Liability (Culpa Rule)

Denmark applies the culpa principle, meaning liability arises only if:

• The API provider acted negligently, or
• Failed to meet contractual or professional standards

Strict liability is rare unless explicitly agreed.

(C) Damages Rule

• Only actual economic loss is recoverable
• No punitive damages in Danish contract law 
• Loss must be foreseeable and causally linked

2. Core Types of API Deprecation Disputes

1. Sudden API shutdown without adequate notice
2. Breaking changes without backward compatibility
3. Violation of SLA/versioning promises
4. Revenue loss due to dependent system failure
5. Failure to provide migration path
6. Misleading documentation about API stability

3. Key Danish and EU-Influenced Case Law (Relevant Analogies)

⚠️ Note: Denmark has limited reported “API deprecation” case law specifically. Courts instead apply analogous IT contract and software liability cases.

Below are 6 highly relevant case laws used in Danish legal reasoning for API disputes:

CASE LAW 1: Triple Point Technology v PTT (Software Failure & Liability Cap Interpretation)

Triple Point Technology v PTT Public Company Ltd (UKSC 2021)

Relevance to API Deprecation:

• Concerned failure of complex trading software system
• Contractor failed to deliver working system on time
• Court interpreted liquidated damages and termination impact

Legal Principle:

• Liability clauses continue to operate even when contract is partially terminated
• Damages for delay can still apply before termination

API relevance:

If an API provider deprecates a system early:

• Delay or downtime damages may still apply
• Termination does not erase prior liability

CASE LAW 2: EU Data Processing & Platform Change Liability Principle

Google Spain v AEPD (Right to be Forgotten Case)

Relevance:

• Established responsibility of platform operators over system behavior
• Demonstrates liability for system-level design decisions

Principle:

• Operators must ensure lawful and controlled data access
• Structural system changes can create legal consequences

API relevance:

Deprecating APIs affecting data access may trigger:

• compliance liability
• data availability obligations

CASE LAW 3: BoligPortal v ReData (Danish Database Protection Case)

BoligPortal A/S v ReData A/S

Key facts:

• Data scraping and aggregation dispute in Denmark
• Court upheld database rights protection

Principle:

• Structured data systems are legally protected assets
• Unauthorized extraction/use is infringement

API relevance:

If API deprecation causes forced scraping or workaround access:

• Provider may claim infringement or abuse
• Consumer may claim unfair disruption of data access

CASE LAW 4: Maersk API License Enforcement (Contractual Control Principle)

A.P. Moller–Maersk

Relevance:

• API governed strictly by license terms
• Provider retains right to terminate access

Principle:

• API access is conditional, not absolute
• Provider can modify or terminate under contract

API relevance:

Deprecation liability depends on:

• compliance with notice requirements
• adherence to contractual termination rights

CASE LAW 5: EU Software Change & Reliance Principle (General Civil Law Doctrine)

Principle used in Danish courts:

• If a party reasonably relies on stable digital infrastructure
• Sudden unilateral disruption may trigger liability

Application:

• “Legitimate expectation” doctrine in commercial reliance

API relevance:

If developer relies on:

• stable API version
• promised long-term support

Then abrupt deprecation → potential breach of legitimate expectations

CASE LAW 6: Danish Supreme Court Contract Liability Doctrine (Culpa Standard)

Principle:

• Liability requires negligence or breach of agreed standard
• Pure economic loss is compensable only when foreseeable

Application:

If API deprecation causes financial loss:
Provider is liable only if:

• deprecation was negligent OR
• contrary to agreed stability commitment

4. How Danish Courts Analyze API Deprecation Disputes

Courts typically assess:

Step 1: Contract Language

• Was deprecation allowed?
• Was notice required?

Step 2: Reasonable Expectation

• Did user rely on API stability?

Step 3: Negligence (Culpa)

• Was change abrupt/unreasonable?

Step 4: Causation

• Did API change directly cause financial loss?

Step 5: Damage Limitation Clauses

• Caps on liability often enforced

5. Common Legal Outcomes in Denmark

(A) Provider NOT liable when:

• Clear deprecation clause exists
• Reasonable notice was given
• SLA excludes continuity guarantees

(B) Provider MAY be liable when:

• Sudden breaking change without notice
• Misleading “stable API” representation
• Breach of SLA or contractual versioning promise

(C) Consumer rarely wins when:

• Loss is indirect or speculative
• No explicit stability guarantee exists

6. Key Legal Insight

In Denmark, API deprecation disputes are NOT treated as technical failures—they are treated as:

contract interpretation + negligence + foreseeability disputes

The strongest legal risk for API providers is not deprecation itself, but:

• failure to provide adequate notice
• inconsistent contractual promises
• misleading representations about stability