Use this page with AI

Copy this into your coding assistant and add your request.

Read https://openiap.dev/commerce-protocol/capabilities and https://openiap.dev/llms.txt. Follow the reading instructions, detailed reference, and linked guides relevant to my task before making changes.
Inspect my existing project and reuse its framework and conventions. Ask me for missing product decisions. Implement the requested behavior and run the applicable checks.
Show the working result, the commands and actual test results, and any remaining limitations. Keep your explanation brief.

My request: [describe what customers should be able to do]
See an example request →
ReferenceFollow the purchase walkthrough →

Capabilities

Capabilities are a provider’s list of supported features. Read it before connecting so your app does not ask a service to do something it cannot do.

For Alice’s subscription, check three things:

  1. Responsibilities: can it verify the purchase, associate it with Alice, and return her access? These are its profiles.
  2. API format: can your backend call it using REST or GraphQL? These formats are called bindings.
  3. Store integration: does this implementation support the store and signals your product needs?

The public providerCapabilities request returns this information without a credential or customer data. Your AI can check it before building the connection.

Different scope, declared explicitly

Run the flow locally

openiap-commerce-protocol-example

The descriptor names a fictional fixture store and makes no complete-profile claim. All six REST operations let you study the flow, including account deletion; they do not establish support for real stores or the full protocol.

Read code: capabilities
See the service implementation

IAPKit

IAPKit declares profiles, both API bindings, and support per store. IAPKit emits subscription events for Apple and Google, not yet for Meta or Amazon. Read the descriptor before choosing a store integration.

Read code: PROVIDER_CAPABILITIES
How to check this behavior

Example. Local checks validate the teaching flow and published vectors. They are not a full provider conformance report. Inspect reference

IAPKit. Capability tests compare the served descriptor, store mappings, and implementation declarations. Inspect reference

Read a capability response#

JSON example and exact fields
{
  "commerceProtocolVersion": "1.0",
  "profiles": {
    "verification": "1.0",
    "entitlements": "1.0",
    "events": "1.0",
    "accountLifecycle": "1.0"
  },
  "bindings": {
    "rest": "1.0",
    "graphql": "1.0"
  },
  "stores": {
    "google": {
      "serverNotifications": {
        "provider": true,
        "implementation": true
      }
    }
  }
}

This is an excerpt from the package's complete example, not a response to copy unchanged. Include every required field and replace its profiles, event types, and store support with what your own implementation demonstrates. Validate the result against ProviderCapabilities in the installed schema bundle.

Each store capability carries two deliberate booleans — provider (what the store offers) and implementation (what this backend consumes) — because collapsing them hides whose gap a missing signal is. Declaring a profile or binding is a conformance claim: partial support must not be declared. See SPEC.md §10.