Posting Webhooks from OFN

Software improvement (Archived)
1

What is the need / problem ?

To improve the functionality that we can perform using our API it would be very helpful if OFN could post webhooks. This will enable an external system to know to call our API at a specific time.

There are a number of places in which this would be useful:

  • On a button click from the dashboard
  • When an order is placed/changed

This particular wishlist will focus on creating a system in which webhooks can be triggered from the dashboard, as this is a smaller, simpler precursor for more risky webhooks.

Who does it impact ?

This will open a world of possibility enabling users to press a button within their dashboard to trigger any API calls or Zaps in Zapier etc. We can create much more complex integrations and workflows that trigger when a user decides so. Reports that generate externally to OFN when the user wants them to, for example. It will mean that we can create bespoke workflows for more complex users use cases using our API.

It is also a BIG STEP toward enabling OFN to be useful and small as complex bespoke work can be taken out of OFN and into other systems that are simpler to develop with simple web scripting languages that consume from the API to populate.

What is the current impact of the problem ?

Currently Zaps and integrations are limited as there is no way for a user to trigger an event from OFN and have something happen externally. Currently this requires a whole separate website to be built or to use Zaps triggered by a new line in a DB. This is lacking in flexibility.

What is the benefit of focusing on this ?

The ability to create much more complex bespoke reporting and integrations triggered from within OFN. Some examples:

  • Create invoices in an accounting package AFTER all orders have been finalised for an OC.
  • Create bespoke reports that are generated when the user has made all the updates and changes they wish to make
  • Send a feedback form to everyone who ordered in a particular order cycle (or a subset)

Potential solutions that will solve the problem ?

From the User side the result is a simple button with a payload selector. I think payload selectors would be limited. This could be a text field but I think that would be daft in security terms.

trigger
trigger1058×1000 63.3 KB

On pressing the button the payload is sent to the URL. This then enables external systems to consult the API using the payload.

Creating the trigger could be done in super admin or Edit Enterprise. The UI for this should be super simple. User should be able to create any number of Trigger buttons. Creating the trigger would require the user to supply:

  • The URL for the webhook
  • The payload type (eg OC ID)

Here is a post about creating webhooks in Rails…

Selection of a feature candidate

[value x ease matric if needed]

T-shirt size of our selected feature candidate

Metrics to measure if need is satisfied after feature is implemented

As a user:
I can press a button in my dashboard and have a specific payload delivered to a specific URL.
Perhaps the first step is to specify the payload types? OC ID would be the first one that I think will create most value.

Feature owners

Epic/projet where you can follow implementation

Connected wishlist and discovery discussions*

[list precedent discussions]

2

@maikel . . This seems relevant . .

3

Just wondering if there is any further discussion on this. I’ve just been re-reading issues and this is one I’d like to see advanced. Are we approaching a time in our pipe when we might talk about a new issue like this?

4

It would be a great feature !
Is there any notification mechanism in the plateform? It would be a good place to plug it in.

Here is how works webhooks :

image
image973×895 34.5 KB

As you said, it’s very dangerous to let user input text to query the database.

Yes, there should be an URL to call the webhook configured somewhere at an enterprise and/or user basis.

But instead of additional UI everywhere on the dashboard, I would check if there is any “event manager” in the software, in which we could add a webhook channel, with a per-event type switch ON/OFF. Otherwise, it could be a dedicated page accessible from the user’s/enterprise’s notifications settings.

5

This could be the structure (2 aggregates) :

  • WebhookEndpoint, defines the client endpoint : endpoint url, endpoint authentication, retry configuration
  • WebhookSubscription, defines what events the client wants to be notified about and which endpoint to send the events to : the event name(s), the filters (marketplace, shop/producer/entreprise, group, customer, category?) and the associated endpoint. [out of authorization scope events would be filter out]

The events could be more or less created, updated and deleted for all aggregates listed here + itemAdded/itemUpdated/itemRemoved for those having items + the additionnal ones (in AdditionnalEvents column)

6

This tutorial is quite nice about how to implement it in ruby (with sidekig) : How to Build a Webhook System in Rails Using Sidekiq

7

This is covered in OFN Webhooks · Issue #9615 · openfoodfoundation/openfoodnetwork · GitHub