Use this page with AI

Copy this into your coding assistant and add your request.

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

GraphQL

GraphQL is another way to make the same provider requests. You send a query to one endpoint and choose the result fields your backend needs. A binding defines how those requests follow the protocol.

Use it if your backend already works with GraphQL. Alice’s ownership and access rules stay the same as REST; supporting both formats is optional for a provider.

It serves the same six operations at one POST endpoint, whose path each provider documents. The served schema defines everything in the generated projection (generated/bindings/operations.graphql) exactly as the projection defines it; a newer compatible MINOR may add to it but never change it. The same authentication and account rules apply to both bindings.

One optional format, the same operations

Run the flow locally

openiap-commerce-protocol-example

This example implements REST only. Follow its handlers to understand the behavior, then use IAPKit’s adapter as a reference if your provider also needs GraphQL.

Read code: REST operation handlers
See the service implementation

IAPKit

The GraphQL adapter executes the generated schema and calls the same handlers as REST. A format change does not create a second ownership or access implementation.

Read code: executeCommerceGraphql
How to check this behavior

Example. The README scopes the example to six REST operations; its tests do not establish GraphQL support. Inspect reference

IAPKit. The same operation vectors run over both bindings and check matching outcomes with fixture data. Inspect reference

Calling it#

query SubscriptionStatus($input: SubscriptionStatusInput!) {
  subscriptionStatus(input: $input) {
    active
    subscription { productId state active expiresAt }
  }
}

Save this request as request.json. Replace the sample user ID with the identity selected by your authenticated backend:

json
{
  "query": "query SubscriptionStatus($input: SubscriptionStatusInput!) {\n  subscriptionStatus(input: $input) {\n    active\n    subscription { productId state active expiresAt }\n  }\n}",
  "operationName": "SubscriptionStatus",
  "variables": {
    "input": {
      "userId": "backend-selected-user"
    }
  }
}
sh
# COMMERCE_GRAPHQL_URL is your provider's GraphQL endpoint.
curl --fail-with-body "$COMMERCE_GRAPHQL_URL" \
  -H "Authorization: Bearer $COMMERCE_SERVER_TOKEN" \
  -H 'Content-Type: application/json' \
  --data-binary @request.json

Check errors before using data.subscriptionStatus. A protocol-coded error uses HTTP 200, so HTTP success alone does not mean the operation succeeded. A codeless request-validation error may use HTTP 400; treat either request-validation form as INVALID_REQUEST.

Providers advertising both bindings must return equivalent results. The local example implements REST only; use your GraphQL provider and the conformance runner to verify this binding.