Webhooks
Receive purchase and subscription changes from connected providers.
Provider webhooks send purchases, renewals, refunds, and other store changes to Nuxie. A customer can renew a subscription without opening your app; the notification lets Nuxie update their access before their next visit.
This page covers inbound provider notifications. To run a Task when a connected event occurs, use an Automation.
Endpoint URL
Nuxie hosts the receiver for provider notifications. These URLs belong to the connection and use this path:
/connector-webhooks/{connectorKey}/{endpointId}The connector key is google_play for Google Play or app_store_connect for Apple. The host and endpoint ID are supplied by Nuxie.
An endpoint’s ID identifies its configuration; it is not an app ID. Test and live purchases use the environment rules below, rather than a test or live path suffix.
Verification and environments
Each provider has its own verification method:
| Provider | Verification | Environment |
|---|---|---|
| App Store Connect | Signed Version 2 notification | Apple’s signed Sandbox or Production value maps to test or live. |
| Google Play | Authenticated Pub/Sub push, followed by a Developer API lookup | Google’s test-purchase evidence determines test or live. |
Apple notifications must match the configured bundle ID and environment. Google Play messages must come from the expected push service account and use the generated endpoint as the identity-token audience. Nuxie reads the purchase from Google to establish its state and environment.
If Google Play’s optional verification token is configured, include it as the push URL’s token query parameter. The identity-token audience remains the original generated URL.
Follow App Store Connect setup or Google Play setup for credentials and provider configuration.
Delivery and processing
A notification goes through two stages:
- Delivery: the provider sends a message to the configured endpoint, and Nuxie checks that it belongs to the connection.
- Processing: Nuxie resolves the verified purchase state and applies the resulting customer and entitlement changes.
For example, Apple can show a successful delivery before the customer’s updated subscription appears in Nuxie. Check delivery first when a message seems missing, then check the purchase and its Feature grants when the message arrived but access is unexpected.
A provider test notification checks that the endpoint receives and accepts a message. It does not create a purchase or exercise entitlement updates. Use an actual sandbox or license-tester purchase to check the complete path, then inspect Feature access.
Retries and duplicate notifications
Providers may retry delivery or send duplicate notifications. Use the provider event identity or transaction identity when tracing an update; the number of deliveries does not represent the number of purchases.
For Google Play, RTDN indicates that purchase state changed. Nuxie reads current state through the Developer API rather than treating the message’s notification name as a complete record of access.
Troubleshooting
| Problem | Where to look |
|---|---|
| The provider has no delivery record | Its notification settings, topic or subscription, and whether the event is enabled. |
| Delivery fails authentication | Apple’s signed Version 2 configuration, or Google’s push account, audience, and optional token. |
| The endpoint cannot be found | The complete generated URL and the connection that owns it. |
| Delivery succeeds but the purchase does not update | Provider verification, the app and environment, and customer association. |
| Purchase state is correct but access is unexpected | The Product’s entitlement mapping and the Feature the app checks. |
Keep the provider event or transaction identifier, app identifier, customer, and environment together when investigating. This distinguishes a delivery problem from an unrelated purchase or access configuration.