Slash-escapes (\n, \r, etc.) in Marketo webhooks

Been meaning to write this up for ages, but was reminded today by this FlowBoost JS payload a user was working on

try {
  const phoneNumber = FBUtil.phone.parse( {{Lead.Phone Number}}, "US" );

  var phoneNumberFormattedNatl = FBUtil.phone.format(phoneNumber, FBUtil.PNF.NATIONAL);
      phoneNumberFormattedIntl = FBUtil.phone.format(phoneNumber, FBUtil.PNF.INTERNATIONAL);
      phoneNumberFormattedE164 = FBUtil.phone.format(phoneNumber, FBUtil.PNF.E164);
      phoneNumberNumericOnly = phoneNumberFormattedE164.replace(/^\+1/,"");
} catch(e){
   var error = "Invalid original number";
}

In the last line of the try block, there’s a regular expression to remove the leading + sign from a libphonenumber-formatted E.164 result:

      phoneNumberNumericOnly = phoneNumberFormattedE164.replace(/^\+1/,"");

(E.164 is +12126741234 but the user wanted 12126741234, which isn’t a built-in named format AFAIK.)

Because + has special meaning in regexland, it’s slash-escaped as \+.

Problem is Marketo’s webhook setter-upper — for reasons I can’t quite fathom, but can’t quite do anything about — reparses the webhook payload into a String[1], as opposed to putting its bytes on the wire as-is.

And that parsing step means certain sequences are treated as slash-escapes (i.e. ways of encoding characters like line breaks). Such unescaping can of course mess with your expectations in its own right, without throwing a visible error. But only these 8 C-style slash-escape macros are recognized without errors:

\b  \t  \n  \f  \r  \\  \"  \'

A list which doesn’t include \+, of course.

So while the above is totally valid raw JavaScript, it’ll throw an error on the Call Webhook activity:

Marketo is actually very helpful here — the error message is both quite clear and repeated 3 times!

So when pasting the webhook code into Marketo, you need to tweak that \+ so it’s \\+ in the webhook definition:

      phoneNumberNumericOnly = phoneNumberFormattedE164.replace(/^\\+1/,"");

Now, on the wire to the remote server, the code will be what you originally intended, and Marketo won’t throw an error.

Note you also have to make the same fix for literal \n → \\n, etc. or what’s sent to the server will be silently altered. And Unicode \u escapes like \u0024 will throw noisy errors — that has to be \\u0024 in the webhook payload. And this isn’t a FlowBoost-only problem at all as it affects pure JSON payloads for other services.

What about dynamic {{lead.tokens}} and other variables?

The above examples are pretty easy to find and fix because you’re hand-coding them in the payload (so presumably can fix them up on the way).

But what if you’re using tokens, where you have no control whatsoever of the possible values? Luckily, Marketo performs the double-escaping for you with tokens, so you’re good to go. Whew!

(Well, good to go unless you’re using XML. But I dunno what to do about that.😬)

Notes

[1] A Scala string, to be exact.

← TEKNKL :: Blog

What about dynamic {{lead.tokens}} and other variables?

Notes