# Product as an API Endpoint: Why Discovery Is Not Permission

Source: https://activatedigital.ai/knowledge/guides/product-identity-api-endpoint
Last verified: 4 September 2026
Summary: Product identity can make a service discoverable. It cannot make the call authorised. See what has to be in place before software may act on a product.

## In 60 seconds

**A product does not literally host an API. The phrase describes the product identity acting as the stable entry point through which software discovers a relevant service, reads the action it exposes, proves the required authority and invokes the correct API.**

- Identifying a product, verifying it, being authorised to act and acting are separate checks. A pass at one is not a pass at the next.
- The MCP tools specification dated 28 July 2026 makes machine-discoverable tools a current primitive. It does not define ownership, warranty or delegated authority.
- Bounded deployments exist: eBay's Browse API returns part compatibility against a vehicle, and CCC reported **115** Digital Key certifications in 2025.
- A cross-brand registry of product actions is POSSIBLE, not deployed. No general cross-brand standard was found.

## A product does not host an API

That moves the product from an information endpoint towards an action endpoint, so the rest of this page is about permission rather than discovery.

In practice the identity leads software, often through a [resolver](https://activatedigital.ai/knowledge/passport/from-question-to-published-passport), to a service it may or may not be allowed to call.

The [GS1-Conformant Resolver Standard](https://ref.gs1.org/standards/resolver/) supports typed links from an identified object to different resources, and [GS1 Digital Link URI Syntax](https://ref.gs1.org/standards/digital-link/uri-syntax/1.7.0/) 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 rule 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. So the identity has to be stable and the service reference current: the two change at different rates.

A plain URL isn't enough either. 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 proves is worked through elsewhere](https://activatedigital.ai/knowledge/passport/identity-authentication-and-ownership).

## How identity becomes addressable

Before a product can anchor any service, its identity has to be resolvable on the web. [GS1 Digital Link](https://activatedigital.ai/knowledge/fields/gs1-digital-link) covers one standard way to do that, and [what changes when product identity becomes a join key for external data](https://activatedigital.ai/knowledge/guides/product-identity-external-data-context) covers what connected identity makes possible.

## The chain this page does not own

Identifying a product, verifying it, being authorised to act and acting are separate checks.

A pass at one 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](https://activatedigital.ai/knowledge/guides/ai-agent-act-on-specific-product), and [how an AI agent proves permission to buy](https://activatedigital.ai/knowledge/guides/ai-agent-permission-to-buy) covers payment and purchasing authority. This page covers 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](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx) 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](https://blog.modelcontextprotocol.io/posts/2026-07-28/) includes authorisation hardening.

So MCP proves that 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.
A generic tool protocol doesn't define a human-control requirement either. 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 discovery still does not prove

The same product identity can now lead software into several different discovery systems. That makes the boundary on this page more important, not less. Finding a link, a digital twin or an executable tool is still only the start of the decision.

### Resolution tells you where to look, not what to trust

[The UN Transparency Protocol's Identity Resolver](https://activatedigital.ai/knowledge/product-data/untp) is a useful example. Its resolver can return machine-readable typed links associated with an identifier. A client can discover that a DPP, conformity credential or another resource is available.

The resolver does not thereby verify the linked credential. The client still has to retrieve the target and check the relevant proof, status and content. A link type such as `dpp` or `dcc` tells software what kind of resource it is looking for. It does not guarantee that the resource is valid, current, conformant or factually correct.

Finding the link, retrieving the resource, checking what came back and deciding whether the caller may act are separate controls. Removing one because the previous step succeeded weakens the chain.

For the credential-verification boundary itself, see [what a verifiable credential actually proves](https://activatedigital.ai/knowledge/evidence/verifiable-credentials).

### Resolver, Digital Twin Registry and connector are three different jobs

Industrial exchange adds two more layers that can look like "discovery" from a distance.

| Component | Its job | What it does not establish |
|---|---|---|
| Web resolver | Map an identifier or URI towards a resource or service | Permission to receive restricted data |
| Catena-X Digital Twin Registry | Register and discover digital twins and their aspects inside Catena-X | EU DPP registration or authority to change a passport |
| Dataspace connector | Participate in catalogue, contract, policy and transfer flows | Truth of the product facts being exchanged |

Controlled exchange may require a contract or policy path after discovery. But a successful contract negotiation still does not make the connector the legal owner of the product data or give it authority to rewrite a DPP.

The wider division of labour is covered in [what a data space is and how Catena-X fits DPP architecture](https://activatedigital.ai/knowledge/product-data/data-spaces-catena-x).

### Protocol access is not product truth

The same boundary applies when an AI agent is the caller.

The Model Context Protocol can expose tools and resources through a common protocol. Shopify's UCP and Storefront Catalog MCP work shows how agent-facing commerce capabilities can expose product, variant, price and availability data through machine-readable interfaces.

Those protocols do not become the canonical source of the underlying facts.

MCP does not define which product specification is correct. A UCP-aligned catalogue does not make a stale price current. Exposing a tool does not prove that the caller owns the product, has a warranty entitlement or is allowed to spend money. The interface still depends on governed upstream systems for product identity, offer state, inventory, evidence and permissions.

An agent-ready product architecture has two separate contracts:

- **the protocol contract**, which says how software discovers and calls a capability;
- **the product truth and action contract**, which says which product the capability applies to, which current facts it relies on and what must be true before the action is allowed.
The product-data requirements for agentic commerce are owned separately in [what product data AI shopping agents need](https://activatedigital.ai/knowledge/guides/ai-shopping-agents-product-data). This page remains the owner of the discovery and permission boundary.

## What a product service has to state

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?

Those answers belong with the service, in a form software can read before the call is made, not in the caller's guesswork. Proof from a secure tag can be one input, with its scope stated, never a yes or no authenticity flag.

MCP demonstrates the tool-schema side and the GS1 resolver the discovery side. Neither answers the product questions. A cross-brand registry that ties products to the actions they support is **POSSIBLE**, not a deployed universal standard: we found no general cross-brand standard that does this 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](https://activatedigital.ai/knowledge/guides/who-can-update-a-dpp), and [which system owns each fact is another](https://activatedigital.ai/knowledge/product-data/which-system-owns-each-fact). 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 vertical, 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?](https://activatedigital.ai/knowledge/guides/product-parts-services-resolver), and this article covers what happens once that compatible service is 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](https://carconnectivity.org/ccc-digital-key-certifications-surged-in-2025/), deployment-scale evidence for this composition in automotive. Certification volume is adoption evidence, not a causal return measure. The CCC material is industry consortium reporting, the ecosystem describing its own deployment: adequate for a bounded existence claim, 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. Imagine an agent that has identified a household appliance and discovered a supported diagnostic or repair-booking action.

The agent still needs to know:

- whether the service contract applies to this exact model or item;
- which current state or diagnostic inputs are required;
- whether the user is entitled to use the service;
- whether the agent has been delegated authority to invoke it;
- whether the action is consequential enough to require confirmation;
- 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.

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.

The same test works when someone shows you a list of things a product record can do. For each proposed use, ask for the question it answers, the input it needs, the operation, the access condition and the output. Then ask whether that operation is documented, has actually been exercised or is still a design.

A [governed product record](https://activatedigital.ai/knowledge/guides/the-data-you-already-have#reusable-product-data) gives each operation a stable identity and the evidence behind each fact to work from. It doesn't make a retailer integration, an agent action or a service workflow live. Keeping those three states apart is what turns a list of uses into something you can plan against.

## 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 registry of the actions each product supports.
- **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-specific service 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**.

## Keep exploring

The questions this page usually raises next.

- [CompareNext questionWhat has to be true before an AI agent can act on a specific product?→](https://activatedigital.ai/knowledge/guides/ai-agent-act-on-specific-product)
- [CompareNext questionHow does an AI agent prove it has permission to buy?→](https://activatedigital.ai/knowledge/guides/ai-agent-permission-to-buy)
- [CompareNext questionCan a product tell software which parts and services it needs?→](https://activatedigital.ai/knowledge/guides/product-parts-services-resolver)
- [Another angleNext questionIdentity, authentication and ownership: what each proves→](https://activatedigital.ai/knowledge/passport/identity-authentication-and-ownership)
- [CompareNext questionThe economics of a product that answers calls→](https://activatedigital.ai/knowledge/guides/connected-product-business-models-who-pays)

## Where this connects

Related resources this page depends on.

- [Evidence behind thisConnectedWhen Does Product Proximity Become a Permission?when product proximity becomes a permission→](https://activatedigital.ai/knowledge/labs/product-proximity-permission)

## Related

- [What Does a Secure NFC Tap Actually Prove?](https://activatedigital.ai/knowledge/guides/secure-nfc-authentication-what-tap-proves):

## Primary sources

- [GS1-Conformant Resolver Standard 1.2.1: typed resource discovery from stable GS1 identifiers. Establishes discovery, not execution or entitlement.](https://ref.gs1.org/standards/resolver/) Standards body
- [GS1 Digital Link URI Syntax 1.7.0: Web-addressable product identity that can participate in machine-readable service discovery.](https://ref.gs1.org/standards/digital-link/uri-syntax/1.7.0/) 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.](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx)
- [Model Context Protocol, 28 July 2026 release: background for currency and authorisation hardening in the same family, not an independent claim, and not a source for any human-control recommendation.](https://blog.modelcontextprotocol.io/posts/2026-07-28/)
- 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.](https://developer.ebay.com/api-docs/user-guides/static/trading-user-guide/compatible-parts-api-support.html)
- [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.](https://carconnectivity.org/ccc-digital-key-certifications-surged-in-2025/)
- [CCC Digital Key use cases: industry consortium self-reporting. Bounded architecture for authentication, operation entitlement and secure ranging before access or start.](https://carconnectivity.org/digital-key-use-cases/)