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. Apple and Google have subscription events; Meta and Amazon do not. 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
{
  "specVersion": "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.