Webhooks Not Firing When Given Port Number

[Noah Cardoza]

After about 5 hours troubleshooting why my server wasn't receiving requests from Eventbrite, I discovered the webhooks would not fire when a port number was specified in the payload URL.

In my opinion, the webhooks are broken and a bug is in need of fixing. 

If there is some reason this behavior is intended Eventbrite should mention it in the webhook documentation. I also would expect them to then correctly validate the payload URL rejecting any format to which they will not send a request to.

On a related note, it would be awesome if we were able to pass basic auth urls like "http://username:pass...@example.com/" because at the moment it claims that isn't a valid URL.

If this is the wrong place to post this let me know, but regardless I hope the next person who runs into this problem finds this before spending 5 hours racking their brain over when the webhook isn't firing.

[jas...@eventbrite.com]

Hi Noah, 

We have been encountering overload issues with our webhooks. We are working hard to make sure they get caught up and we are also working on revamping our webhooks entirely. 

Here is a general document we have put together to send to external developers using Eventbrite. (Some of this may not apply to you and/or your use case.)

Webhooks Update

We are having overload issues with our webhooks. While we have been working very hard to keep up with the demand on our webhooks, we have found that they are continuing to be overloaded with requests. We are really excited about a large number of external developers using Eventbrite and our API. It is incredible seeing all of the amazing things being created by developers, such as yourself, and we look forward to empowering developers to make even more amazing things in the future. Here are a few things to keep in mind while building with our webhooks.

#1) Webhooks on Eventbrite are a tool, not a solution.

Part of the reason we are having overload issues is that we are finding many developers are using our webhooks as a SOLE solution to their problems. This is just a friendly notification/reminder that you should not rely on webhooks as an end-all solution. Instead, use them as a tool to reinforce the solutions that you are building build.

#2) Try and use the most specific webhook possible.

While it is sometimes necessary to use higher-level webhooks such as our event.updated webhook, this is a high-level approach and carries a lot of “overhead” (non-actionable items) in response. If you’re able, we encourage all developers using our webhooks to be as specific as possible with the actions that you look for via webhooks. This will help reduce the number of unnecessary/redundant calls. We also encourage that you reinforce with a full sync (via API calls) a couple times per day.

#3) We are in the process of revamping our webhooks.

This will hopefully bring clarity and reliability to our webhooks allowing external developers to build more efficient, more reliable, and more seamless applications with our webhooks. We are looking toward the future and aiming to provide the best API experience available. Thank you for your continued use of our API and keep building amazing things that bring the world together through live experiences.

Again, some of the above may not apply to you or your use case. I hope this helps and answers some of your questions. 

As far as your other feedback goes, I am happy to pass it over to our Product Teams. Thanks, again. I appreciate you bringing this to light. 

Jason