03-10-2026 05:13 AM - edited 03-10-2026 05:17 AM
Hi
I was excited to find an EXACT match for my issue (as per the Subject Line) right here... it's just that the response didn't give me enough to get started 😥
I have a SaaS system to which I can subscribe to webhooks. But there will be a variety of different JSON payloads being sent to my single Recipe, depending on the Event being sent.
Therefore I need to branch my workflow depending on the type of Event/JSON being received.
When I follow the guided setup for a new Recipe of type "Trigger from a Webhook" it asks for a sample event and then configures the schema of the Trigger accordingly. But obviously that won't capture the variety of Events being received.
Could someone give me the "dummies guide" to how to achieve what I'm after in Workato?
If JSON Event = "Create" then... {expect this JSON payload and map these values to datapills} and then go do stuff
If JSON Event = "Update" then... {expect this JSON payload and map these values to datapills} and then go do stuff
etc
The bit that's not clicking with me is simply how to replace the single guided JSON mapping for the Trigger with alernative nuanced logic (as above). There can be only one Trigger for a Recipe, so how to handle different incoming JSON payloads? I'm sure the "Parse JSON Document" action is involved but I ain't seeing how it comes together!
It feels like this must be an FAQ, so I think a simple "How To" that others could use would be generically helpful.
Thanks in advance
Russell
Solved! Go to Solution.
03-12-2026 09:47 AM
My friend, you may be overthinking this...
From my first response:
I would just ignore the schema entirely and pass the "Payload" object on the webhook trigger into a JSON parser.
The webhook's Payload data pill will be a hash of anything you send to the webhook. It doesn't need to match the input schema.
Here's my webhook trigger, completely undefined other than POST JSON:
Here's my cURL to call it from Terminal:
curl -X POST "https://webhooks.workato.com/webhooks/rest/top_secret/test" \
-H "Content-Type: application/json" \
-d '{"event_type": "do stuff", "anything": "yadayadayada"}'
Here's my JSON parser to capture the event type:
And that's a wrap!
From here you'll have your event type parsed, and then you can route to other JSON parsers. When calling other functions, do the exact same thing as the JSON parser: pass the Payload as .to_json and parse it in the next recipe.
03-10-2026 09:27 AM
When using this kind of model, I would recommend structuring your JSON so it's easy to pivot between events.
For example, I always use this format for a basic message queue:
{
"action:" "porkchop sandwiches",
"message": "anything at all"
}Because action is always present you can reliably use its value to control the recipe flow. It's pretty much the same as event type.
Once you know your action/event type, you can throw in a JSON parser for a schema that is specific to the event/action.
I'm assuming this ship has sailed and you're not able to change the incoming format, but the bottom line is that each payload must have some sort of indicator of it's event/action/purpose. Use that value to create different conditionals, and use a schema-specific parser within the conditional.
Hopefully this helps!
03-10-2026 09:35 AM
And sorry, I may have overlooked the core issue: the webhook requires you to define the schema.
I would just ignore the schema entirely and pass the "Payload" object on the webhook trigger into a JSON parser.
If you do have a single consistent key across all incoming payloads (like "action" or "event_type"), this should be a cake walk.
If you don't have a single key then this becomes more difficult but it's still completely possible. You'll have to put it through multiple JSON parsers, each configured to look for a specific key to identify the event type (one looks for "action", one looks for "event_type", one looks for "yadayadayada", etc.). Once you get a hit, you'll be able to control the flow.
03-10-2026 10:10 AM
Hey Gary
Thanks so much for you reply!
Yup, I do have a common "action" value across all events/JSON payloads, so that's easy enough for the IF.
And you have indeed come to the core issue - the webhook requires you to define the schema.
The walk is verily CONSTRUCTED OF PURE CAKE... it's just... I still can't see how to stuff the incoming Payload into a JSON parser. The "Document" field in the JSON parser Action wants to take indiividual fields (e.g. Id and Event) from the output of my Trigger (see screengrab below)...
How do I pass in ALL OF THE JSON PAYLOAD into the Document field of the JSON Parser?
The issue may be caused by my having based this Trigger on the JSON generated by the Guided thingy, I guess?
03-10-2026 01:33 PM
You can't have a dynamic sample document, but this is still doable.
Let's say I have a bunch of different events:
// event type 1
{
"event": "build spaceship",
"ship_name": "nostromo"
}
// event type 2
{
"event": "emergency landing",
"where": "lv-426"
}
// event type 3
{
"event": "destroy xenomorph",
"how": "airlock"
}One option is to make a JSON parser and use a merge all of the different schemas as the sample document. The benefit of this approach is using a single JSON parser but I personally find this difficult and annoying to maintain -- especially when you have more complex events than my example.
{
"event": "build spaceship",
"ship_name": "nostromo"
"where": "lv-426"
"how": "airlock"
}Another option is to route to a JSON parser configured to parse the schema of the event. I find this easier to maintain since you don't need to merge multiple schemas.
If event == "build spaceship" then route to a parser that is set up with an example payload. Repeat this for each event type.
Lastly, once you identify the event type you should route to a function recipe to handle the processing of that event. Try to avoid making a monolithic recipe that handles everything. Break it up, make it modular.