It would be extremely beneficial to have the ability to perform JSON parsing directly within the webhook trigger, with the parsed variables displayed in the output variables section. This approach would simplify and organize the process. In my case, my webhook contains 13 fields, and manually parsing each one is not only tedious but also adds unnecessary complexity to the flow by increasing the number of blocks.
Having this not only with JSON parsing blocks but also within the trigger page would be extremely better.
I’ve explored the idea of a usage-defined variable parse, where you could somehow create a variable that is known to be a JSON object, then reference it like [VARIABLE].value, it’s just difficult to create good UX around this.
For example, if you set the ‘json path’ when you insert the var, and it becomes part of the ‘blue box’, it then needs some kind of edit mechanic, which we’re currently not setup to support. It could go outside of the box, but that feels pretty unintuitive.
I’ve considered a ‘bulk json parse’ block that allows you to set an input JSON object at the top, then accepts a number of ‘display name’ and ‘path’ pairs. The display names would be made available as outputs of the block, and their values would be whatever was found at the corresponding paths.
This (to me) seems like the best solution, and given that dynamic output names aren’t (currently) available for custom blocks, it (to me) is worthwhile to have as a builtin block.
1 Like
I’ve considered a ‘bulk json parse’ block that allows you to set an input JSON object at the top, then accepts a number of ‘display name’ and ‘path’ pairs. The display names would be made available as outputs of the block, and their values would be whatever was found at the corresponding paths.
Sounds like a solution. But is anyone using a webhook trigger without parse json? That’s why I cited that the parsing should be done in the trigger page. If it’s not doable, that “Bulk JSON parse” fits.
But is anyone using a webhook trigger without parse json?
Most definitely. Inventor is a large enough platform with varied enough use-cases that we cannot make assumptions like this. This isn’t worth making a breaking change.
You may be correct that it is very small group of users, but a similar thing can be said for the send network request block, and it makes no sense to duplicate efforts/work.
If it’s not doable, that “Bulk JSON parse” fits.
It’s not about what is ‘doable’. In general, the design of Inventor is to provide a large and varied ‘toolbox’ that is modular enough that you can find what you need. A big part of this is making sure everything has a single purpose. This has the nice side-effect of minimizing duplication.
Added this to Trello:
1 Like