It is understood that you wouldn’t be ready with Webhooks at the time of preparing configurations to integrate your app with AppVirality.
We would advise you to utilize 3rd party (free) HTTPS request/Webhook debug tools like RequestBin to test if the webhook integration done above, is working properly.
RequestBin, enables you to utilize ready-to-use URLs (generated on the fly) to collect requests made from any HTTP client, and then inspect/debug the responses.
While there are many similar services, and we have no affiliations to RequestBin, for the sake of simplicity & context – we will stick to using this as the platform to explain how you can test/inspect/debug your webhook configuration with AppVirality.
Go to https://requestb.in/ and create a RequestBin, by clicking on the button + Create a RequestBin
A new session gets created for your browser tab, and a dedicated URL is generated. This URL would be able to record and show all HTTP requests that are sent its way. This would be crucial to your debugging of the configuration during your webhook setup.
Copy the Bin URL generated and retain.
Come back to AppVirality Dashboard now.
Navigate back to Webhook Configurations
(Dashboard >> Reward Configurations >> Reward Type -Wallet >> Webhook Configurations)
Add the Bin URL to your desired Event Webhook among the 3 webhook URLs available.
Click on Test button, in Request tab you can see JSON payload which AppVirality Server sends to your end point URL. In Response tab you can see status of request (success or fail).
You can use Resend button to send the request again to given endpoint URL.
Your Webhook URL configuration for testing using RequestBin URLs is done.
Now every time a conversion event takes place, you will receive a JSON payload on the event’s dedicated Bin URL. You can inspect/debug the response and the payload data.
The above payload should have reached your configured Request Bin too. In fact in a production environment, it should have been intercepted by your webhook host. You can use the Request Bin method to tweak and configure the webhook host to handle such incoming payloads appropriately.
Open the Request Bin session for dedicated webhook. For this example, lets consider the one for Conversion Event:
As shown above, you should read the response in two parts: Headers and Raw Body
The Raw Body you find in RequestBin would be the same as the one you would see in the Logs section, as explained in the previous section o this article.
You can run similar comparisons for all the Webhook URLs configured in your Dashboard
Once the End Point is setup in a test/production environment change the Webhook URL configuration in AppVirality Dashboard – it is time to fire some conversion events. This implies you should begin testing your integration and the webhook configuration, by running a test cycle in accordance to your defined Reward Rules and Testing Guide.
When one test cycle completes, you should have ideally initiated/triggered a few conversion events.
By principle, these events would have triggered Webhook payloads to be fired and delivered to the configured receivers in the Dashboard, as was explained above.
Navigate to the Logs section on your Dashboard to check for these payloads. You can edit and resend these payloads too.
In here, you would also find additional info on the webhook payload status i.e.
- Webhook type (Referrer / Friend / Conversion event)
- Payload contents
- Response intecepted (Error, OK, etc.)
- Created Timestamp
- Last Sent Timestamp
- Total Attempts made (i.e. re-fired)
NOTE: Webhooks shall be fired a maximum of 5 times.
Click on Edit button, and you can copy/modify and resend the payload contents.
Copy them, and parse it in any free source parser available on the web to make it an easy read.
In the above example, you can see that the payloads were not delivered properly for Friend & Referrer Reward webhooks. The Response field clearly states that it intercepted a 404 Error.
However, the Conversion Event webhook was delivered fine.
In case of any failure, AppVirality will set off automatic retries as below:
|5 minutes after the failure
|30 minutes after the previous retry
|120 minutes after the previous retry
|360 minutes after the previous retry