5 Replies Latest reply on Sep 25, 2018 11:27 PM by Sanford Whiteman

    URL not showing up in webhook for SMS

    Michael Mason

      We're using a webhook to send Marketo data to Amazon SNS to then send an SMS. We've been success sending an SMS with a tokenized field for the message, however, we want to ultimately use this message field with a URL stored in a Marketo field to drive a renewal communication. I'm having trouble getting the URL to populate from the webhook in the text message. We've tried a few different permutations, but so far no luck.

       

      This works and populates the mobile number and message, but the resulting SMS does not populate the URL.

      [

      {

         MobileNumber : {{lead.Mobile Phone Number}},

         Message : {{lead.Amazon SNS Message}},

         Url : "www.google.com?test=test",

      }

      ]

       

       

      Tried this also with same result:

       

      [

      {

         MobileNumber : {{lead.Mobile Phone Number}},

         Message : {{lead.Amazon SNS Message}},

         Url : {{lead.Enrollment Cart URL}},

      }

      ]

       

       

      Any ideas?

        • Re: URL not showing up in webhook for SMS
          Sanford Whiteman

          Your examples have trailing commas and thus are invalid JSON (some servers will allow it, but they shouldn't and you should still fix it up).

           

          Anyway, you haven't specified exactly what endpoint you're posting to. I assume there's something up with case, i.e. the property is actually "URL".

            • Re: URL not showing up in webhook for SMS
              Michael Mason

              Thanks Sanford, your input is always appreciated.

               

              I'll fix those trailing commas and the URL case and see if that helps.

               

              As far as the endpoint, I'm not 100% sure. My architecture team settled on Amazon SNS, but I believe they are trying using an API to get the data out of Marketo, shorten the URL via bitly and then sending the SMS. They seem like they know what they're saying, but not 100% sure as they know worlds more than I do. Should I ask them what the actual endpoint is?

            • Re: URL not showing up in webhook for SMS
              Michael Mason

              So after three weeks of going back and forth with our IT team, we finally got it working where we can send the URL to the API which shortens the URL and then sends the SMS.

               

              Two things happened that I think helped, though I'm sure there's some clean-up to do, as per Sanford's previous reply.

               

              1. 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.
              2. The second thing that finally put us over the edge, was the case-sensitivity which I probably would have figured out eventually, but was made much easier because of Sanford's suggestion.

               

              The code that actually works:

              [

                          {

                                      MobileNumber : {{lead.Mobile Phone Number}},

                                      Parameters: [],

                                      Url: {{lead.Amazon SMS URL}}, 

                                      Message : "Your Direct Energy Business energy plan expires soon. Locking in a new rate only takes a few minutes. Get started now! #Url# Text HELP for help. Text STOP to opt-out of messages.",

                          }

              ]

              Once again, thank you Sanford. I really would like to buy you a case or bottle of your favorite beverage!

                • Re: URL not showing up in webhook for SMS
                  Sanford Whiteman
                  1. 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.

                    • Re: URL not showing up in webhook for SMS
                      Sanford Whiteman

                      The order doesn't matter, because JSON object properties are not ordered, by definition (same as JS Object props).

                      Michael 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 *****. 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.