Is this the intended behaviour? It was quite confusing to get up and running, and means the pattern of working with the output is a two step process - getting the post request and then parsing the json as a string:
I was expecting it to be a standard json object, so I could just pull up the various fields directly, and was getting quite confused when the result below kept giving me nulls:
Any clarity on why the payload is set up the way it is?
Ping @cristi - we’ve been having quite some flamewars internally about this setup. Right now, safe bet, is to deserialise again the payload. We’ll probably move it to what you expect it to be 
Currently we tried to optimize for compatibility with older web server frameworks and different setups with modern frameworks, which expect key-value pairs of type string when processing post-ed form data. Like in most frameworks, you can have a parameter payload that gets assigned a string that is passed.
This way of working, with the framework parsing the POST body for you, usually doesn’t support nested json payloads by default. So putting the payload directly into the POST body would trigger some issues with various setups, so we opted to have a string parameter in the POST body, with all the information, and require a json parsing, to eliminate struggles with receiving the needed information in various frameworks/setups.
Since there is a lot of debate around this, we were indeed thinking of changing this behavior, but it’s tricky because of backwards compatibility. We may temporary introduce an option when setting up the webhook, to ease transition before the current way becomes obsolete.
Also, for the Pyhton developers, there was an idea to introduce this connectivity process inside the python sdk, so you can use specklepy to listen for webhooks, but this needs more internal discussion.
