Skip to main content
Use the Consume API to manage these Microsoft Store consumable types:
  • Store-managed consumable: Report a quantity as consumed and remove it from the specified user’s current quantity balance. Users can repurchase store-managed consumables repeatedly without your service having to report them as consumed or fulfilled. For more information, see Store-managed consume request.
  • Developer-managed consumable: Report a consumable product as fulfilled for a specified user. Before a user can repurchase a developer-managed consumable product, your app or service must report the consumable product as fulfilled for that user. For more information, see Developer-managed consume request.

Using trackingId to validate fulfillment completion

trackingId provides retry-safe fulfillment validation. If your service doesn’t receive a confirmation response, resend the same request body. The service recognizes prior requests and treats retries as confirmation checks. Each request to the API should have a unique trackingId. If the original request didn’t succeed, or the response wasn’t received, the service completes the requested transaction when the request is retried. If the fulfillment was completed in a previous request, the API recognizes the request and sends a confirmation response. In this case, the API doesn’t fulfill or deduct a second time from the user’s balance. Instead, the API responds with a success as if the item was consumed with the user’s remaining balance. Therefore, cache the values and trackingId of each request on your server or in your logs until you receive a confirmation response that the request was fulfilled. For an example, see the Game Service Sample. When your request has the includeOrderIds parameter, these behaviors are expected based on the consumable’s product type: If you use developer-managed consumables, you can’t get the order IDs from a retry request.

Prerequisites

Review Prerequisites for service-to-service APIs. This API supports both Microsoft Entra ID and delegated auth X-token auth types.
Sandbox limitation for developer-managed consumables: When you consume developer-managed consumable products in a development sandbox (non-RETAIL), authentication using User Store ID or Microsoft Entra ID isn’t supported. In sandbox environments, you must use delegated authorization XSTS tokens to successfully consume developer-managed consumable products. This limitation doesn’t apply to store-managed consumables or to the RETAIL sandbox.
If you don’t publish product configuration in Partner Center, calls can succeed but return no results.

User Store ID authentication error codes

Error codes by using X-token authentication

Request

Request syntax

Request header

Request body

Consume request examples

The following examples use a User Store ID for authentication and require the beneficiary object in the request JSON body.

Store-managed consume request

Developer-managed consume request

The following example uses User Store ID authentication. However, this authentication method doesn’t work for developer-managed consumables in development sandboxes. If you’re testing in a sandbox environment, use XSTS token authentication instead. See Authenticating through delegated authentication XSTS tokens for details.

Response

Response body

The ConsumeOrderTransaction object contains the following parameters.

Consume response example

Manage products from your services Authenticating your service with the Microsoft Store APIs Using publisherQuery (Collections v9) to query a user’s products and entitlements Managing consumable products from your service Managing refunds and chargebacks from your service
Last modified on August 19, 2026