Upon receiving a receipt request in the Receipt Validator, we can forward the App Store response to your server endpoint for further processing. This allows implementing custom behaviour on your backend for potentially backing up user inventory or getting more insights into user workflows using advanced purchase statistics.
INDIE plan and higher.
You can enter your server endpoint in the app settings, by navigating to
Apps > App Options > Edit. When saving a webhook address for the first time, your endpoint must respond with a 200 status code to prove its existence. Also, a new header private key will be generated.
Please be informed that only valid purchase receipts are sent to your server. A valid receipt is defined as a successful purchase that reduced your validation quota, i.e. a new purchase or subscription renewal. Additionally in case of subscriptions, subscription status changes (i.e. paused, expired) are processed as well.
Currently two types of webhooks can be used. Please refer to your app plan on the pricing page in order to see your supported type.
|In case of system outages or failures on the receiving server, there is no retry or queue mechanism and the webhook message sent is lost. This type can be used for analytical purposes but should not be used to replicate user inventory.|
|In case of a failed response on the receiving server, the webhook message is retried every 5 minutes up to a maximum of 30 minutes (6 times) after the original message was sent. This type can be used to replicate user inventory.|
|Your 16 alphanumeric characters long app identifier.|
|Auto-generated private key. Check this in your backend to ensure the request source is actually valid. Contact Support if your key was compromised.|
A string in JSON format.
|App Store-generated unique transaction identifier.|
|Receipt data of the purchase. For more information please refer to the validation response.|
|The originating App Store. |
|Only present on user-initiated receipt requests. App Store server-server notifications do not provide user identifiers. |
The client-provided or server generated (v4 UUID) unique user identifier.
|UNIX timestamp when the request was created. If you are using Reliable Webhooks, check this field to determine whether the message is still valid in case it has been sent with a retry delay.|