I implemented a simple webhook forwarding system, as described in #46.
When a POST request is made to bots/:id/events/:name, a new event is added. A bot instance can fetch new events by POSTing it's key to events.json; this request will return the event's name, request headers, request content, and whether the event is a "broadcast" event. Fetching the events will remove them from the DB, so events.json will only return new events.
By default, events will only be delivered to one instance, but "broadcast" events will be delivered to all of the bot's instances. A broadcast event can be created by setting the broadcast parameter to true; for example POST bots/1/events/some_name?broadcast=true.
Important: Client-side event validation must be performed. Since different webhooks implement validation differently, Redunda does not perform any server-side validation; as Art put it, "any old Joe" can create an event. GitHub's webhooks, for example, include a X-Hub-Signature header which can be used to validate the event.
I implemented a simple webhook forwarding system, as described in #46.
When a
POSTrequest is made tobots/:id/events/:name, a new event is added. A bot instance can fetch new events byPOSTing it'skeytoevents.json; this request will return the event's name, request headers, request content, and whether the event is a "broadcast" event. Fetching the events will remove them from the DB, soevents.jsonwill only return new events.By default, events will only be delivered to one instance, but "broadcast" events will be delivered to all of the bot's instances. A broadcast event can be created by setting the
broadcastparameter totrue; for examplePOST bots/1/events/some_name?broadcast=true.Important: Client-side event validation must be performed. Since different webhooks implement validation differently, Redunda does not perform any server-side validation; as Art put it, "any old Joe" can create an event. GitHub's webhooks, for example, include a
X-Hub-Signatureheader which can be used to validate the event.