API Failures and Product Liability | ProductLiability.help

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

An API failure describes an interface event

An application programming interface failure can contribute to a product liability investigation, but the term covers many different events. A request may time out, return an incorrect value or succeed after a dangerous delay. Directive (EU) 2024/2853 does not create an automatic liability category for API errors. Identify the software, service or product behaviour allegedly made unsafe and the resulting harm.

The SaaS and cloud services framework explains why remote software can be a product while ordinary services require their own classification. An API is a means of communication between systems, not a complete legal description of either supplier. The investigation must identify what each side was supposed to send, what actually crossed the interface and how the receiving product responded.

Describe the interface contract and actual exchange

Record the endpoint, request type, relevant fields, units and response status. The interface documentation establishes expected behaviour only for the version in use. A current specification can conceal an earlier field meaning or error-handling rule. Preserve the applicable specification together with examples of the actual request and response, using proportionate safeguards for credentials, personal information and unrelated customer data.

Separate transport success from semantic correctness. A successful response code can accompany an unsafe numerical value, and a timeout can occur after a command was already executed. A client that retries may therefore repeat an action. These possibilities require evidence from both sides where available. They should not become assumed facts merely because a generic API troubleshooting guide lists them as common risks.

Establish the product and service relationship

Software exposed through an API can be a product in its own right. A digital service can also be a related service where its integration and functional dependence satisfy Article 4(3). The canonical connected-product and related-service definition distinguishes that test from ordinary connectivity. Not every external endpoint becomes a component simply because a product is capable of calling it.

Identify who selected and authorised the integration. Article 4(5) and recital 18 distinguish manufacturer control from mere technical compatibility. An approved backend supplying control instructions may raise different issues from a customer-created connection to an unrelated service. Record the approval, device configuration and supplied instructions, rather than allocating responsibility solely from the branding displayed in a developer portal.

Trace how the receiving product handles failure

An API supplier's error does not resolve whether the final product was defective. Examine input validation, timeouts, local safety limits, stale-data handling and fallback behaviour. A product may reject a bad response safely. It may also continue using a value after it has become unsafe. The same upstream error can therefore produce different consequences in products with different handling of foreseeable interface problems.

Article 7 assesses safety in all circumstances and includes reasonably foreseeable effects of interconnected products. Consider the intended users and function as well as the technical specification. If a product's purpose is preventing damage, its failure to fulfil that purpose is specifically relevant. A system that reports normal operation after losing a safety-critical input presents a different question from one that stops safely and warns the user.

Build a causal chain across both systems

Use request identifiers, device identifiers and timestamps to match the relevant exchange. A trace should distinguish when the request was created, received, processed and acted upon. Clock drift and queued jobs can produce misleading apparent sequences. Note whether records show actual execution or merely submission to a queue. Where correlation identifiers are absent, explain how events were matched and the uncertainty involved.

For example, a remote temperature service might return a stale value that a domestic appliance accepts as current. The inquiry would examine the age of the data, the meaning of the response fields, local validation and the physical outcome. The error could lie in the remote calculation, the timestamp representation or the receiving software. An outage graph cannot select among those causes without more specific evidence.

Separate injury from service and financial loss

Article 6 covers specified harm, including personal injury, certain property damage and destruction or corruption of data not used professionally. A rejected API call causing an inconvenience, delayed report or missed sale is not automatically qualifying damage. Pure economic loss is not an independent covered category, while material losses resulting from covered harm require a separate assessment.

The data category does not cover professional data, including data with professional use alongside personal use. Property used exclusively professionally is excluded under its separate wording. These distinctions matter for business integrations, where the largest reported loss may be interrupted operations rather than a covered damaged interest. Contractual availability promises, service credits and other national remedies should be identified separately from the Directive claim.

Preserve evidence and responsibility limits

Relevant evidence includes incident-time interface documentation, safely retained request and response records, code versions, configuration and integration approvals. Preserve original material with its provenance, and create redacted working copies rather than distributing production credentials or unrelated data. Avoid reproducing a failure by sending dangerous commands to live equipment. Recovery work should record the changes made so it does not erase the historical explanation.

Article 8 determines relevant responsibility routes, while Article 10 sets proof requirements and conditional presumptions. A cloud provider's involvement does not make it responsible for every downstream event. A sound API assessment identifies the supplied object, approved integration, unsafe behaviour and supported causal steps. National implementing law, temporal scope and procedural rights remain questions for the applicable jurisdiction rather than assumptions derived from the interface error alone.

Records that help the review

Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.

Incident-time software, device and deployment identifiers
Functional dependency and authorisation records
Original logs with timestamps and recorded limitations

Independent educational information at EU Directive level. National implementing law, product timing and procedure require separate review.

Primary sources and legal scope

This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.

Original Official Journal Directive: recitals 13, 17 and 18 read with the Article references above ↗

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.