| REQUIRED USER ROLE API User |
If a webhook fails, four more attempts are made to deliver the event notification within an hour. If the webhook continues to fail after the fourth try, the webhook will be deactivated, and all Gladly users assigned the API User role are notified by email indicating which webhook(s) was deactivated.
Review webhook logs #
Avoid reactivating a webhook without first troubleshooting the cause of the failure using the webhook logs.
- Click
on the top left corner of the screen. - Click Settings.
- Under the App Developer Tools category, click Webhooks. The Webhooks page will show you a list of webhooks you currently have configured.
- Look for the webhook with next to it, indicating the webhook was deactivated. Hover over the webhook and click .
- Scroll down to the Logs section to find the event(s) log.
- Note – Click Show More to see all events, up to the last 100 events.
- Each event in the webhook will show one of these statuses:
- [A] – Error – Your webhook threw an error that caused Gladly to deactivate the webhook (i.e., they failed all of the retry attempts Gladly made). These are the events you need to troubleshoot first before [C]. Use the log to help you determine the root cause of the failure.
- [B] – Success – The request was delivered to your webhook. No action is needed for these events.
- [C] – Debug – Your webhook threw an error, but we did not deactivate your webhook. Expect to see debug errors if your webhook fails on the first delivery or during one of our retry queues leading up to deactivating the webhook. Troubleshoot these events after [A].
- Click next to the event that failed to see the Request and Response log.
- Review the information in the Request and Response tabs:
- Request contains the payload sent by the Lookup Adaptor to the external system.
- Response displays the response or error sent by the external system.
on the top left corner of the screen.
next to it, indicating the webhook was deactivated. Hover over the webhook and click 
.
next to the event that failed to see the Request and Response log.
Common response errors #
Wait 30 seconds between changes #
When troubleshooting and actively making changes, wait at least 30 seconds before refreshing the log to confirm if your fix resolves the issue.
Only reactivate a webhook once all the events have a check mark [B].
Remove events no longer used #
Event(s) failing but no longer used should be removed.
Click X next to remove an event (see log), then click Save.
Reactivate webhook #
Once all the events in a webhook are working, reactivate the webhook on the webhook settings page.
- Click on the top left corner of the screen.
- Click Settings.
- Under the App Developer Tools category, click Webhooks. Click the toggle next to the webhook with the to activate it.
Read the FAQ section below for additional information regarding this process.
FAQs #
How do I know what webhooks I have set up?
- As a user assigned the API User role, go to Settings > Webhooks and check if any Webhooks are enabled. If they are, you are utilizing Webhooks. You can click on each webhook to see what Events you are subscribed to and which URLs they ping.
What does it mean for a webhook to fail?
- A webhook fails if it sends a response outside the 2xx HTTP status code range or does not send a response/times out within 15 seconds of Gladly’s request.
- Webhooks could also get deactivated if rate limits are exceeded . We understand that there are legitimate business processes in place that might unintentionally deactivate webhooks due to exceeding rate limits, causing errors. Please contact Gladly Support if you experience these issues.
. We understand that there are legitimate business processes in place that might unintentionally deactivate webhooks due to exceeding rate limits, causing errors. Please contact How do I make sure we receive these email notifications?
- Make sure you’re assigned the API User role.
- Allowlist [email protected] to prevent the webhook alerts from going to spam. We suggest allowing @gladly.com domain to prevent any Gladly emails from going to spam.
What happens when a webhook is deactivated?
- When a webhook is deactivated, it stops receiving notifications for the specific events it was subscribed to. For example, if a webhook is subscribed to the “CONVERSATION/CREATED” event and gets deactivated, it will no longer receive any notifications when a new conversation is created.
Will I lose data while my webhook is deactivated?
- Potentially. When a webhook is deactivated, all event notifications will be ignored. For instance, if a webhook is subscribed to both “CONVERSATION/CREATED” and “CONVERSATION/CLOSED” events, and a notification for the “CONVERSATION/CREATED” event fails to deliver within an hour, you will no longer receive notifications for both the “CONVERSATION/CREATED” and “CONVERSATION/CLOSED” events.
How can I recover my data when my webhook is deactivated?
- To retrieve any missing event data that would have been delivered to your deactivated webhook, you can utilize our Events API. We will provide a timestamp indicating when we first encountered a delivery issue for your webhook’s notifications. You can filter and retrieve the missing events using this timestamp as a date parameter in the Event API.
- Note that this is only available for 24 hours, and the Events API is unable to retrieve some information like Customer Profile updated, Customer Profile created, Customer Profile deleted, Export job completed, the Export job failed, Payment request created, Payment status changed, Payment request viewed and Automation message received.
- Historical data can be retrieved via reports, for example, Contact Timestamps, Agent Timestamps, and Task Timestamps, though these reports are subject to the same limitations that the Events API.
Is Gladly able to send me the data I missed manually?
- No. To recover your data, you may use our Event API. See the previous question for more details.
How will I get notified when my webhook fails? What if I am unavailable?
- API users in your organization will be notified via email when a webhook has been deactivated.
- Suppose you only have one API User listed, API users that belong to partners/are not real email addresses vs. in-house employees. In that case, we recommend adding at least another API User (e.g., in case the API user is on vacation).
What if a third party owns a webhook and it’s deactivated?
- If a third party owns a webhook and it gets deactivated, we recommend contacting the owner to determine the necessary steps to get it working. Additionally, if a third-party system is down for more than an hour and then comes back online, you should visit the Webhook admin page and proceed to reactivate your webhook.
Does deactivating a webhook only affect certain events within that webhook?
- No, when a notification for one event within a webhook fails to deliver within an hour, we deactivate all events for that webhook.
Are all webhooks subject to deactivation if they don’t respond after the fourth attempt?
- No. We are excluding the following webhook-based Apps developed by Gladly: Klaviyo, Qualtrics, Segment, and Zauis.
How to prevent webhook failures?
- Make sure to audit the status codes you are sending with your webhook to ensure you respond with a 2xx if successfully processed so your webhook doesn’t get accidentally turned off.
- Make sure to add at least one (ideally two) API User roles in your organization with real email addresses so that you can be appropriately notified when a webhook is deactivated due to the retry limit.
