Product as an API Endpoint: Why Discovery Is Not Permission

A product does not host an API

The physical product usually does not literally host an API.

"The product becomes an API endpoint" is useful shorthand for a different architecture: the product identity becomes the stable entry point through which software can discover a relevant service, understand the action it exposes, prove the required authority and invoke the correct API. That moves the product from an information endpoint towards an action endpoint.

The accurate sequence is:

physical product → stable identity → resolver/service discovery → action contract → authorised API/tool call

The GS1-Conformant Resolver Standard supports typed links from an identified object to different resources, and GS1 Digital Link URI Syntax provides the Web-addressable identifier syntax that can participate in that resolution. Both are cited here for typed resource discovery from a stable identifier and for nothing else. Neither is an execution layer and neither confers entitlement.

The critical rule, which the rest of this page works through, is that discovery is not permission. Finding an endpoint does not mean the caller may invoke it. Verifying a credential does not mean the action is authorised. Product identity does not prove ownership or entitlement.

What the product identity actually anchors

A QR code or identifier can already take a person to a webpage. A resolvable product identity can go further by helping software find a machine-readable resource. Neither means the product is running an API server.

The product identity is the anchor. The executable service can live anywhere: a brand platform, repair network, retailer, insurer, logistics provider, device cloud or another authorised system. That is why the identity has to be stable and the service reference has to be current — the two change at different rates.

This is also why a plain URL is not enough. A URL may lead to information. An action-capable system needs machine-readable semantics for what can be done, what inputs are required, what state matters, who is allowed to do it and how errors or revocation are handled.

Identification, authentication and ownership are three different things, and what each one actually proves is worked through elsewhere.

The chain this page does not own

A reliable product action separates seven gates: identify, resolve, discover the action, verify, authorise, decide, act.

A pass at one gate is not a pass at the next. Identity does not prove authenticity or entitlement. Resolution does not grant access. A discoverable operation is not an approved one. Verification establishes what a credential says, not what its holder may do. Authorisation still leaves the question of whether the action is right for the product's current state.

The full treatment of that chain belongs to what has to be true before an AI agent can act on a specific product, and how an AI agent proves permission to buy owns payment and purchasing authority. This page owns the missing service-discovery contract between product identity and a callable action.

Discovery is not permission

This is the boundary most likely to be lost as products become easier for software to resolve.

A resolver can tell software that a particular service exists. It can expose a link relation or direct the caller to a machine-readable resource. That proves discoverability, not permission.

The same is true of generic agent tooling. The Model Context Protocol tools specification dated 28 July 2026 allows a server to expose tools with structured input and output schemas that a client or model can discover and invoke. The 28 July 2026 release includes authorisation hardening.

MCP therefore proves something important: machine-discoverable tools are a current software primitive.

It does not define:

• which physical product the tool should act on;
• whether the product identity maps to the correct service contract;
• whether a part or service is compatible;
• whether the caller owns the product;
• whether a warranty applies;
• whether a user has delegated this action to an agent;
• whether the agent may spend money, unlock hardware or submit a consequential claim.

Nor is a human-control requirement among the things a generic tool protocol defines. That requirement is ours: a consequential operation requires human control, and we state it as a design rule rather than attributing it to any specification. It sits beside the three boundaries this page keeps everywhere — discovery is not permission, verification is not authorisation, and identity is not ownership or entitlement.

What a product action contract must contain

An API specification can describe an operation such as bookRepair, orderPart, startReturn, requestInspection, unlockAsset or changeConfiguration.

That still leaves the product questions unanswered. Which exact products does the operation support? Does it apply to a model or an individual serial number? Which firmware, configuration, market or service status is required? What evidence must the caller provide? Does the action require current ownership, a warranty entitlement, a service subscription, a delegated key or human confirmation?

This is where a generic API contract stops and a Product Action Contract begins. The important word is contract. It is not a link to an API. It tells a machine what the service means in relation to the product and what must be true before the call is valid.

Secure product interaction belongs in required_evidence as an optional bounded input with its scope stated, never as a boolean authenticity flag. What it establishes travels with it.

MCP demonstrates the tool-schema side and the GS1 resolver demonstrates the discovery side. Both are components of this object rather than the object itself. A cross-brand registry that binds product scope, action semantics, current endpoint, state requirements and entitlement together is POSSIBLE, not a deployed universal standard: we found no general cross-brand standard that binds all three for arbitrary product lifecycle services.

What the passport platform does not own

Exposing a service-discovery route or an action endpoint does not make the passport platform the system of record for the underlying master data, and it does not confer write permission to the systems behind it.

Discovery, authority over a fact and the right to change it are three separate questions. A platform can be the place software finds the action without being the place the fact lives, and it can hold neither the authority to assert the fact nor the right to change it.

Who may update a passport is its own question, and which system owns each fact is another. Neither is answered by the platform being able to expose an endpoint.

Three bounded examples

A product identifies the correct part and exposes an order or booking action

A product identifier can resolve a model or configuration. A compatibility system can determine which part fits. A service API can expose stock, ordering or booking.

eBay's Browse API can return compatibility status for a part against a specified vehicle. That is a fitment answer in one bounded mature vertical, vehicle parts, and it proves compatibility can be represented and consumed by software there. It is documented first-party material from an interested party, so it establishes that the interface exists and is documented rather than how widely it is used. Separately, eBay's Trading compatible-parts documentation covers the Trading interface; the two are different interfaces and neither reads across to the other.

Compatibility is a fitment answer, not authorisation to act. Discovery is not permission here either.

The compatibility question itself belongs to can a product tell software which parts and services it needs?. This article owns what happens after that compatible service becomes machine-discoverable and executable.

A nearby authorised device unlocks or starts a product

The Car Connectivity Consortium's Digital Key ecosystem shows why proximity, verification and authorisation are separate. CCC describes a flow in which a device and vehicle mutually authenticate, operation entitlement is checked and secure ranging can be used before access or start.

CCC reported 115 certifications in 2025, which is deployment-scale evidence for this composition in automotive. Certification volume is adoption evidence and not a causal return measure. The CCC material is industry consortium reporting, the ecosystem describing its own deployment, which is adequate for a bounded existence claim and not for a generalisation to other product categories.

The lesson for product APIs is not that every product should have ranging hardware. It is that a caller can be near the correct product, present a valid credential and still need an action-specific entitlement check before the operation occurs.

That deeper proximity question belongs to when product proximity becomes a permission.

A product exposes a service action to an agent

This third example is hypothetical, and labelled as such. Imagine an agent that has identified a household appliance and discovered a supported diagnostic or repair-booking action.

The agent still needs to know:

1. whether the service contract applies to this exact model or item;
2. which current state or diagnostic inputs are required;
3. whether the user is entitled to use the service;
4. whether the agent has been delegated authority to invoke it;
5. whether the action is consequential enough to require confirmation;
6. what result or error should be recorded.

A generic tool protocol can carry the call. It does not supply those product-specific semantics automatically.

What is missing for cross-brand interoperability

The software primitives are mature. The shared product semantics are not. That is an interoperability and governance problem rather than evidence that APIs or agents are immature.

Across the records reviewed for this page, a general cross-brand system still needs agreement on:

• how a product identity advertises supported actions;
• how an action is named consistently across brands;
• how compatibility and state preconditions are expressed;
• how warranty, ownership, subscription or delegated rights are represented;
• how an agent proves the scope of its authority;
• how rights are revoked or transferred;
• how sensitive actions request human confirmation;
• how the result is logged so another organisation can understand what happened.

Those are gaps in what we reviewed rather than assertions about every system in existence.

Design the action before the endpoint

If you are designing a connected-product service, do not start by asking whether the product can "have an API". Start with the action.

Name the exact product scope. Define the service operation. State its inputs and current-state requirements. Decide which evidence and entitlement are required. Specify when a human must confirm. Then expose the service through an API or tool interface and make it discoverable from the product identity.

That produces a safer architecture than publishing an endpoint first and hoping the caller understands what it is allowed to do. The near-term pattern is:

product ID → typed service discovery → product action contract → verification → authorisation → policy decision → API/tool call → auditable result

For a consequential action the record it leaves should be able to state which product was in scope, which service was discovered, what evidence was verified, which entitlement authorised the caller, which product state and policy supported the decision, whether a human confirmed the action, and what the service returned. That is a stronger basis for automation than a model inferring permission from context.

Maturity as at 4 September 2026

• NOW: GS1 identity and resolver mechanisms can point to machine-readable resources; APIs and webhooks can expose actions; MCP can expose structured tools for machine invocation.
• NOW, bounded: automotive digital key and vehicle parts compatibility combine product identity with specific service or entitlement semantics.
• POSSIBLE: a reusable cross-brand Product Action Contract Registry that binds product scope, action semantics, current endpoint, state requirements and entitlement.
• NOT SUPPORTED: a QR code automatically creates an API; a resolver is an execution layer; verification equals authorisation; payment authority equals ownership or warranty authority; generic agent protocols supply product-specific permission automatically.

What would change this answer

Recheck this page if GS1 or another major product-identity ecosystem standardises product action contracts, if agent protocols add portable product-entitlement semantics, or if multiple unrelated brands deploy a common product-to-service action profile in production.

The threshold is not more APIs. Those already exist. The meaningful change would be a standard way for software to move from this is the product to this is the action, these are the preconditions and this caller is authorised to invoke it.

Primary sources

• GS1-Conformant Resolver Standard 1.2.1: typed resource discovery from stable GS1 identifiers. Establishes discovery, not execution or entitlement.
  Standards body
• GS1 Digital Link URI Syntax 1.7.0: Web-addressable product identity that can participate in machine-readable service discovery.
  Standards body
• Model Context Protocol, Tools, 28 July 2026: the specification carrying the claim that machine-discoverable tool schemas and invocation are a current primitive. One source family with the release note below.
• Model Context Protocol, 28 July 2026 release: background for currency and authorisation hardening in the same family, not an independent proposition, and not a source for any human-control recommendation.
• eBay Browse API compatibility documentation, including the CompatibilityResponse type: eBay first-party API documentation, interested party. Establishes that the Browse interface documents compatibility status against a specified vehicle, bounded to vehicle parts fitment, and not its usage volume.
• eBay Developers, compatible parts API support (Trading): eBay first-party API documentation, interested party. Covers the Trading interface only and does not read across to Browse.
• CCC Digital Key certifications surged in 2025: industry consortium self-reporting. Source of the 115 certifications figure, which is adoption evidence and not a causal return measure.
• CCC Digital Key use cases: industry consortium self-reporting. Bounded architecture for authentication, operation entitlement and secure ranging before access or start.