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.

The same six operations at one POST endpoint, whose path each provider documents, executing exactly the generated schema projection (generated/bindings/operations.graphql). 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"
    }
  }
}

# Use your provider's GraphQL URL and complete server Authorization header.
curl --fail-with-body "$COMMERCE_GRAPHQL_URL" \
  -H "Authorization: $COMMERCE_SERVER_AUTH" \
  -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.