v1
latestOpenAPI 3.1.02026-07-241080412.6 KBRegister Google Play purchase
Use this endpoint to register a purchase made via Google Play Billing to initiate an asynchronous synchronization process. This process involves verifying the purchase with Google Play and updating the user's entitlement status in Cleeng's system. <br><br> Due to the time required for Google's verification, this operation is asynchronous. Upon successful registration, the API will return a 202 Accepted status with a unique synchronizationId in the response body. <br><br> You can then use the following methods to check the status of the synchronization process: <br><br> - Polling: Use the /purchases/synchronizations/{synchronizationId} endpoint to periodically retrieve the status. This endpoint provides a concise response with the essential status information. <br><br> - Webhooks: Subscribe to the inappPurchaseSyncResult webhook to receive real-time updates on the synchronization status. The webhook payload (WebhookSynchronizationStatus) includes detailed information about the synchronization, including the synchronizationId, purchase details (purchaseToken, packageName, cleengCustomerId), accessGranted, offerId, and result. <br><br> You can choose to use either the polling mechanism, the webhook, or both, depending on your needs. <br><br> The cleengCustomerId is used to identify the user in Cleeng's system and associate the purchase with their account. <br><br> Important: Requests to this endpoint are idempotent by purchaseToken. If a duplicate request is detected - whether a synchronization is already in progress or was already completed for the given purchaseToken - a 409 Conflict error will be returned containing the existing synchronizationId. <br><br> The productType field determines which Google Play API is used to verify the purchase: <br> -subscription - uses purchases.subscriptionsv2.get <br><br> Scope: Only subscription is supported. One-time products are not supported - requests with any other productType are rejected with 400. <br><br>Please note that this endpoint can be authorized with a publisher (X-Publisher-Token) or JWT (Bearer) token. Depending on how you integrate with Cleeng (directly or through middleware), use either a <glossary:JWT> or X-Publisher-Token header authorization. <br> <br> <span style="color:green">Please use JWT (Bearer) token to try out the endpoint in the API console in this documentation.</span>
Headers
Can be used within both server-to-server and client integrations. Either a <glossary:JWT> or X-Publisher-Token header authorization is required, depending on how you integrate with Cleeng. <br> <span style="color:green">Please use JWT (Bearer) token to try out the endpoint in the API console in this documentation.</span>
Can be used only within server-to-server integrations. Either a <glossary:JWT> or X-Publisher-Token header authorization is required, depending on how you integrate with Cleeng.
Correlation ID for the request, which is used to link the initial purchase registration or transfer request with the subsequent synchronization process. This ID is not used as the synchronizationId but is included in the response for tracking and correlation purposes. <br><br> It is recommended to provide a Correlation-Id for easier tracking of requests, especially if you need to correlate the purchase registration with other events or processes in your system. Ensure that the Correlation-Id is unique within the context of your specific client integration to avoid conflicts.
Version of the publisher's application making the API request. <br> This header helps you track which versions of the publisher's app are being used and how they interact with Cleeng API. It can be valuable in identifying compatibility issues, understanding the impact of app updates on API usage, and providing support for different app versions.
Unique identifier for the device making the request (if applicable). <br> This header is useful for tracking requests at the device level, especially in mobile app integrations. It can help you identify issues related to specific devices, analyze user behavior across devices, and gather insights into device-specific usage patterns.
Specifies the type of device the request is coming from. <br> This header provides additional context about the device making the request, beyond just its unique ID. It helps you categorize devices (e.g., "Pixel 8", "Samsung Galaxy S24", "Android TV") and identify potential issues or trends related to specific device types. <br><br> This information can be particularly useful for debugging, as it allows you to narrow down issues that may be specific to certain device models or types. It also helps in understanding user behavior and preferences across different device categories. Example: Android TV.
Specifies the action performed by the user in the publisher's application. <br> This header provides additional context about the user's actions within the app, such as "Purchase", "Restore Purchase", "Updating Plan", "Content Access", etc. It helps you understand user behavior, track specific actions that trigger API requests, and analyze usage patterns based on user actions. <br><br> By capturing user actions in the app, you can gain insights into user engagement, preferences, and interactions with your API. This information can be valuable for optimizing the user experience, tailoring content recommendations, and improving app performance.
Request body
Response
202