- Defining the parameter for the URL BEFORE the message. I'm not 100% sure if that is necessary, but seemed like it makes sense, assuming the code is executed from top to bottom.
The order doesn't matter, because JSON object properties are not ordered, by definition (same as JS Object props).
One of my favorite interview questions is about using Object.keys() on an Object as if it has a guaranteed order. 
The order doesn't matter, because JSON object properties are not ordered, by definition (same as JS Object props).
Michael Mason also, just to be clear since I know you're trying to pick up some development skills, it's not that the insertion order (the order in which the properties are added to an object) does not factor into initializing the object. It's that after the object is initialized the properties are unordered.
If you initialize a JS object like so:
var i = 0;
var myObject = {
inserted1 : ++i,
inserted2 : ++i,
inserted3 : ++i
}
Then you can be guaranteed that the object will contain these property values, reflecting the order in which you assigned and incremented the properties:
myObject.inserted1 == 1; // true
myObject.inserted2 == 2; // true
myObject.inserted3 == 3; // true
But what you can't rely is that if you loop over the object keys, they will be looped in insertion order. Each key, of course, will be found, but the order is not determined. So if you do::
console.log(Object.keys(myObject));
In most environments you'll happen to see an array like so:
["inserted1","inserted2","inserted3"]
But this is coincidental and not guaranteed. It's just as valid to see:
["inserted2","inserted3","inserted1"]
Nothing's broken if it comes out like that, that's what "unordered" means.
What super-duper-confuses people is that ["inserted2","inserted3","inserted1"] is itself an ordered array. That is, in the second result, index 0 is "inserted2", index 1 is "inserted3", and index 2 is "inserted1". Arrays are always sorted, it's inescapable. But the source object was unordered and should be considered to have a random order. Imagine it kind of (?) like a lottery drawing with numbered balls. Which ball comes up each time is random. Then once laid out on their little tray or what-have-you, they definitely have a distinct order, but that doesn't mean the lottery was fixed or anything. (It's late, I'm sure I can come up with a better analogy tomorrow.)
So when you were wondering if the order of the JSON keys could matter to the webhook service, it can't. The keys are static strings by the time they reach the remote server, and even though the JSON object is indeed parsed from top to bottom, relying on the insertion order is prohibited by the JSON standard.*
And YES I know this is probably deeply obscure to you and anyone else reading at this point, but this kind of thing is the meat of... well, everything in development. So much software is subtly (or glaringly) broken because people (including yours truly at times) either forget or never learned these core things.
*To be totally anal about it, you could theoretically parse a JSON object as if it's some other kind of proprietary object where order matters.
But then it's not JSON. I think Google, to my dismay, has some APIs that work like this, where JSON-looking objects aren't JSON.
.png)