How to deal with static JSON "variables" across different triggering platforms?

Sorry. Noob question.

I set up my first flow yesterday and I'm stoked it's working! I'm triggering it via a webhook POST from an app called Geofency which POSTs to webhookrelay. Geofency doesn't provide an option to supply custom JSON code. You can only use their immutable JSON variables and values (some of which I can set a value for). I piped the payload to a series of 2 switches that check "name" (of the geofence location) and "entry" (1=entry, 0=exit).

However, I'm preparing to add a few more functions to the switch that come from things other than geofency (e.g. IFTTT -> webhookrelay) and it seems limiting to be corralled into using these variables and trying to keep their values unique across different triggering platforms. There does not seem to be a variable in the static JSON whose value is something like "geofency" that I could switch on per platform, so I could put another switch in front of it to be able to set up different types of triggers without variables stepping on one another.

I learned that webhookrelay only gives you one free public URL endpoint, so I believe I have to differentiate the types of triggers using the JSON content.

First of all, what's the best practice? Should I create a different flow with a webhookrelay input for each triggering platform? Or should I put all actions triggered by a webhookrelay input in the same flow?

Is there a way to inject a variable in the JSON somehow, e.g. "triggering_platform": "geofency" (like a way to detect where the POST came from and inject JSON based on the source) or do I need to treat the "variable" "name" as reserved for geofency and set values to some delimited value like "geofency-home" and "ifttt-weather", split on the dash, and switch on the first value? If not, or if I encounter another platform that doesn't have a "name" variable in a static JSON payload that I can set, how would I check if the "name" variable is present in the switch?

I don't want to start down some path and discover a flaw in my method and have to redo everything? Has anyone else encountered this issue? How did you design your flows around it?

It sounds like it would be best to use a single input and then split from there.

The trick is understanding what triggered the input so unless webhookrelay allows you to capture the originating url (for example) into the output JSON, this wouldn't be possible.

It would be possible if the hook were being provided directly by Node-RED since you would also have access to the response object from ExpressJS which would tell you who the originator was. But then you wouldn't have an issue anyway since if you can do one hook on your own device, you could do any number of them. You can certainly do this with Node-RED but you have to create some paths that are accessible from the Internet which is more complex to set up and maintain as you also need to think carefully about security.

I was thinking about this (since I took the Node-Red survey today). I don't know if it's possible to easily enable/disable flows on the go, but if I wanted the ability to temporarily do this per action, I'm guessing that I'd have to use separate flows for different actions. Is there added overhead if I were to create separate flows, each with a webhookrelay input with the same endpoint trigger (splitting on JSON content)?

Yeah, that's why I went with webhookrelay. No exposure of ports. But I see what you mean.

I can't really visualise how this would work. But really I don't think there is a need. A single input can then easily be split into multiple flows (flow channels?) Assuming you have a way to do the split sensibly.

There really isn't (as far as I know) actually much overhead regarding channels in your flows that aren't actively handling messages and it rarely seems to be a real issue.

Of my flows, the main live flows.json is 621k, my secondary is 397k. So both pretty large. Neither has any real problems in regard to performance. So I doubt you need to worry about being able to disable flows.

Thanks. I'll have to look into handling JSON variables not being present, like how to check for "undefined". And I hope that webhookrelay uses some global web socket instead of one for each flow. Don't know how I would check that.