I am not sending this to 50K endpoints. Another system will parse and send the notifications. I would prefer not to deal with large payloads (unless you are in a very closed and tightly coupled environment). But if you are talking about a scale of 1M users, it is just not efficient. So some option to filter would make it really efficient & work for all use cases.
There doesn’t seem to be a way to differentiate between what website is sending the webhook, is it possible to add a domain in the discourse config to the request headers, something like x-discourse-domain? or maybe something unique to each instance of discourse?
Use case:
I have a Discord bot that is going to post to when someone creates a topic or reply, and notifies certain discord servers. I am currently running 2 discourse instances on my server, and they both have webhooks to the same API on the bot, but there appears to be no difference in request headers.
2 Likes
I love the webhooks feature! I have some critique to offer, though.
First, it seems like the permalink/URL would be central to the post/topic events, but this is not included in the payload. It’s not a big deal since I was able to build the URL myself from the properties provided, but it seems logical that this should be added for topics and posts in the post stream.
Second, it looks like only the cooked posts are delivered. Receiving the raw posts could be useful, too, if that’s possible, especially when used in an application that doesn’t parse HTML.
While I appreciate the copious number of properties sent from topic and post webhooks, some of the data seems irrelevant, like can_act, can_edit, and unseen, among others. Not an issue at all, but some fields may be unnecessary.
4 Likes
Webhooks is a great addition to Discourse! I’d like to +1 @r3trosteve’s earlier comment:
Triggering webhooks on a “Badge Event” would be incredibly useful. We could use these to toggle on permissions in external applications when badges are earned in Discourse (e.g., you can edit our wiki once you’ve earned trust level 2 in our forum).
Extra credit: reduce unnecessary traffic by allowing badge events to be scoped to specific badge(s)
First of all, just want to say thanks! This looks really fantastic!
I was playing around with it earlier today and noticed a couple of things:
-
Post Event doesn’t work on edits.
The description on the webhooks page says “When there is a new reply, edit, deleted or recovered.” but I can’t get it to work with edits for some reason… -
Payload format?
The Setting up webhooks howto makes it looks as if the a Post event will trigger a payload with just the relevant post, however I seem to be getting the whole topic and post_stream in my payloads. Is this expected or am I doing something wrong?
4 Likes
@fantasticfears, do you think adding Badge Event to webhooks would be hard? Would it take a lot more than adding support for user_badge_granted and user_badge_removed events to web_hooks.rb?
This feature would be a game-changer for the OpenMRS community. 
(the Camel’s nose … “you give 'em an inch and they want a mile”)
4 Likes
Added per https://github.com/discourse/discourse/commit/3daba9351a14d6d74dde4bfc3db6334046f65429. You can try X-Discourse-Instance. The value is your Discourse instance url including domain. If you uses subfolder feature, it would also include the subfolder name.
3 Likes
I missed this event. I will submit the pull request.
My intention is to push as most information as possible. But a lot of people complains about it. Later I would send only the relevant model. E.g. Post webhook for only post.
As of the fields in the payload, I would eliminate some fields only used by the Ember app. The query language mentioned by @Lapinot might be better in a plugin.
@burke Badge Event is on the way. I will need some time for testing.
4 Likes
Is there any documentation on the Payload format? I would like to write my own client and that documentation would make getting started way easier.
1 Like
I realised I probably posted on the wrong post before -
on the user creation / update is it possibly to get the email address added into the payload? As was surprised to see this is missing.
Also I have noticed that it only seems to be sending out users that have updated their profile rather than new ones registered. For example I sent an invite to an email, registered via the invite of which auto approves the user but is not showing up in the list having been sent only the ones that I have updated.
User Event
When a user is created, approved or updated.
2 Likes
@fantasticfears, any closer with Badge events? Anything we could do to help? Thanks!
Still salivating about how Badge Event webhooks could revolutionize spam filtering for our community by allowing Discourse badge assignments to manipulate LDAP entries. 
1 Like
@jackzampolin The payload is almost the same as the Discourse web application gets. The generic format is like this:
{
"user": {
// user payload
}
}
You can read the payload examples in the webhook event page.
@mikechristopher Thanks for mention that. I included this within the submitted pull request.
@burke The team will focus on some important event types. Once the pull request which allows easy customization is ready, I’ll write a documentation to show how to add some types on your own.
2 Likes
@fantasticfears By the webhook event page do you mean this topic: Webhook for Discourse events
It would be nice to have exact JSON examples for each event type. That way developing clients is very easy.
4 Likes
As the recent change to webhooks (many thanks to @tgxworld for the help), the serialization payload includes only relevant object. i.e. Payload for topic event type includes only topic.
Please start a new topic for any other webhook feature requests and bug report.
4 Likes