Currently there is only one mechanism that can be used to store some data from Webhook and it is Event tags. There are multiple downsides to this approach:

1. Tags are always visible to end-user. So there is no way to store some technical data without it being shown in Frontend.
2. Tags are not scoped so one Webhook could "overwrite" tags from the other Webhook. In fact tags are not overwritten, but macro {EVENT.TAGS.tag_name} will be expanded to "the first one". Adding some sort of scope with complex tag names is just making case #1 worse as user will see ugly long tag names.
3. There are no event tags for Internal events and other non-trigger based actions so the same mechanism is not good for all of the use-cases.

It would be great to have some sort of local storage for Webhooks. The best option would be to have multiple layers of storage:

• Global storage for Webhook. This allows Webhook to store some data like data schema once and reuse it later. For example, Jira webhook requires to get metadata from Jira to format customfields properly. Currently there is no way to cache this request so it is executed every time. This could be seen as data cache for Webhooks so some cache lifetime param is a nice to have feature.
• Event level storage for Webhook. This allows Webhook to store some data accross event processing (problem / update / recovery). For example, Jira webhook requires to store ticket id to allow add comments to the ticket on event update or event resolve. Currently it is impossible to do so for Internal events.

Additionaly there should be an option to invalidate cache from Frontend to allow Webhook to reload some data once again.