Sorry, we don't support your browser.  Install a modern browser


Feature Requests & Roadmap

Let us know how we can improve. Which features would you love to see in GraphCMS?

Vote on existing ideas or suggest new ones.

Granular Webhooks#36 

The ability to define the webhook trigger.

Makenna Smutz
2 months ago

It would be great to see a payload preview of the webhook based on the type of content that is bring configured to fire the webhook.

2 months ago

One of the addition that could make sense is to add the ability to configure the webhook trigger’s rule.

Currently, the rule is “one trigger for one content change”, but that doesn’t fit all use cases.

For instance, when handling changes in a batch (like a mass delete, or import script), one could be interested to debounce the triggers, and instead of triggering 100 times (for 100 content changes) only trigger once.

The rule in such case would be “debounce 2000ms at the end”, so that if those 100 changes are made within 2s of each other, they’d be debounced and only one event would be sent once no content change is detected for 2s. (for use-cases such as refreshing a cache, for instance)

Extensive discussion on Slack at

Another really handy addition would be to add a few more metadata by default for all webhooks, such as:

  • query name: We have the ability to name our queries with GraphQL. If we can know which query was the origin of a data change, we could do some very workflow-related stuff based on it. It’d definitely be the base of a super flexible webhook handler, because we could know exactly where the query was sent from.
mutation queryNameProvidedToWebHook {
  • source: GraphCMS UI vs API?
    I may want to do something very specific if a delete was made through the GUI, like trigger some other process. Use case could be a follow-up action after deleting an item manually, to clean up data in another service for instance. This could be made configurable through headers for instance, to identify the origin of an API-related operation, and perform an action only when X service made the API request that triggered a content change.
Ambroise Dhenain
a month ago

After re-reading the discussion and thinking on it, it may be easier to think of this functionality as two pieces: granular Webhooks, and customizable Triggers. Triggers would basically just be logic you can define on top of API events, and Webhooks would be a valid output type. I think that’s easier to develop, easier to build UX around, and easier to explain in docs. For big-scaling, it would also make more sense to have a high-throughput, read-only stream of all API events, where Triggers can then drop actions into a queue when criteria are met.

Aaron Fuleki
a month ago

It makes sense indeed, it could/should be 2 different features, I’m just not familiar with what “granular webhooks” is supposed to bring to the table (any example?)

in any case, both could be implemented in the next webhook planned update

Ambroise Dhenain
a month ago

It pretty much revolves around Model based webhooks with a payload in form of a gql query you can specify. Its similar to the setup we had in our legacy platform.

Fabian Beliza
a month ago