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 formatted E.164 result:
phoneNumberNumericOnly = phoneNumberFormattedE164.replace(/^\+1/,"");
(PNF.E164 is +12126741234 but the user wanted 12126741234, which isn’t a named libphonenumber format, AFAIK.)
Because + has special meaning in regexland, it's slash-escaped as \+ to be just a literal plus sign.
Problem is Marketo’s webhook setter-upper 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:
\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:
The Activity Log detail is 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 the Marketo UI 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 only an issue with application/javascript payloads, as it affects pure JSON payloads as well. |
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.
.png)