Use this page with AI

Copy this into your coding assistant and add your request.

Read https://openiap.dev/commerce-protocol/conformance 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 →

Conformance

Conformance checks test whether a provider keeps the contract it advertises. If it promises to connect purchases to users, for example, a verification-only credential must not be able to change an owner.

Use this when reviewing your implementation or comparing providers. Ask for a passing report tied to the source and configuration you will run. An API response with the right field names is only part of that evidence.

  1. Choose the responsibilities and REST or GraphQL format the provider supports.
  2. Run the checks against an isolated instance with disposable users.
  3. Fix failures, rerun, and keep the result with the implementation.

Read the checks alongside the implementation

Run the flow locally

openiap-commerce-protocol-example

verify.mjs replays the purchase flow, expiry boundaries, signatures, retries, and receiver recovery. These checks explain what this small backend demonstrates; it makes no full-profile claim.

Read code: verifyLab
See the service implementation

IAPKit

The published conformance runner calls IAPKit’s real REST and GraphQL routes against fixture store/database I/O. Separate worker and mutation tests cover persistence responsibilities.

Read code: IAPKit dual-binding conformance
How to check this behavior

Example. Install dependencies, then run npm test in the example repository. Bun runs its HTTP server and SQLite. Inspect reference

IAPKit. Run bun run test -- server/api/commerce/conformance.test.ts convex/commerce/spec.conformance.test.ts from packages/kit. These are local contract checks, not live store tests. Inspect reference

Run and read the checks#

Runner setup and implementation requirements

First run the runnable local example to explore the purchase flow. It does not claim full profile conformance. To test your own implementation, use an isolated test instance with disposable identities: the operation vectors call binding and erasure as well as reads. Supply credentials from that instance.

Follow the contract installation guide and add ajv with your package manager. Save the script in SPEC.md §11.2 as check-conformance.mjs and run it with Node.js or Bun. Set COMMERCE_BASE_URL, COMMERCE_VERIFICATION_TOKEN, and COMMERCE_SERVER_TOKEN as in Connect to a provider, and COMMERCE_GRAPHQL_URL only when testing that binding. The adapters send each credential as a Bearer token.

The runner talks only through the fetch you give it; the URL may point to a local test provider. A provider whose capability descriptor declares the events profile also supplies an eventsAdapter — the runner drives §9 signing, verification, the delivery envelope, response semantics, the entitlement gate, and the emission rules through it, and a signing-only adapter fails.

Implement the EventsAdapter interface in the installed conformance/index.d.ts against your own emitter. An advertised events profile without this adapter fails the run. Read report.results and report.parityFailures for failures; the script exits nonzero when report.ok is false.