TEKNKL :: Blog

Bulk export Marketo notifications with this UI hack

Sanford Whiteman — Sat, 26 Sep 2026 23:45:53 -0400

In the Notifications UI, you can drill into SFDC Sync and other errors one-by-one:

But unfortunately there’s no bulk export, making it harder to track trends & fixes.

Hacker’s delight

Conveniently, the underlying (private) endpoint /data/inboxRecord/retrieve supports get-everything requests, not just get-summaries and get-single-details.

That is, though the UI lists only summaries – you click a summary to load its details – it’s easy to get the whole notifications “inbox” for offline crunching. Just open your browser console, click any notification in the list or the details pane[1], and run this JS:

{
    const sanitizer = new Sanitizer({
      removeElements: ["br"],
      attributes: ["class","id"],
      dataAttributes: true
    });
    
    const currentURL = new URL(document.location.href);
    
    const notificationsInboxURL = new URL(currentURL.origin);
    notificationsInboxURL.pathname = "/data/inboxRecord/retrieve";
    
    const payload = new URLSearchParams([
    	["sort", JSON.stringify([{ property: "timestamp", direction: "DESC" }])],
    	["fields", JSON.stringify(["id","classType","type","notificationSubtype","subject","timestamp","status","body"])],
    	["context", "NO"],
    	["uShell", "true"],
    	["xOrigin", "true"],
    	["symfony", currentURL.searchParams.get("symfony") ],
    	["xsrfId", Mkt3.Config.getEnv('xsrfId')],
    	["ids_sso", Mkt3.Config.getEnv('ssoId') ]
    ]);
    
    fetch(notificationsInboxURL, {
      "headers": {
        "content-type": "application/x-www-form-urlencoded; charset=UTF-8",
      },
      "body": payload.toString(),
      "method": "POST",
      "mode": "cors",
      "credentials": "omit"
    })
    .then( (resp) => resp.json() )		
    .then( (inbox) => inbox.data.map( (values) => {
        const assembled = {};
        values.forEach( (value,idx) => assembled[inbox.fields[idx]] = value );
        const tmpl = document.createElement("template");
        tmpl.setHTML(assembled.body,{sanitizer});
        assembled.body = tmpl.innerHTML;
        return assembled;
    }) )
    .then( console.log )
}

That’ll dump the full inbox to the console, and if you copy it[2]:

You get a JSON array shaped like this:

[
  {
    "id": 638245,
    "classType": "info",
    "type": "linked_in_lead_gen_failure",
    "notificationSubtype": "linkedin_failure",
    "subject": "LinkedIn Lead Gen sync error : Mismatched datatype for field mapped",
    "body": "\n  \n        
\n  
\n  \n  \n\n  \n          \n          \n\n          Why: \n          \n          linkedIn field name: WORK_EMAIL\n          \n          marketo field name: Email Address\n          \n          datatype: email\n          \n          field value: swhiteman @example.com\n          \n          adFormResponseId: 4721eb0d-5d42-4d82-a65e-2f3b7010f14b-3\n          \n          formId: 1003116022\n          \n          failure reason:Received invalid email from LinkedIn.\n\n          \n          \n          What to do now? \n          The Marketo field (Email Address) expects a valid email address.Make sure your LinkedIn form containing the (WORK_EMAIL) field requests a valid email address.\n          \n          If (WORK_EMAIL) is not expected to have the above response, go to LinkedIn Lead Gen Launchpoint:\n          \n          1) Edit the Launchpoint.\n          \n          2) In field mappings dialog, remap the LinkedIn field name (WORK_EMAIL) to a Marketo field which is of String datatype.\n          \n          \n    \n    \n  
\n",
    "timestamp": "2026-09-26 15:41:56",
    "status": "unread"
},
{
    "id": 638216,
    "classType": "error",
    "type": "salesforce_sync_failure",
    "notificationSubtype": "sfdc_sync",
    "subject": "Salesforce Sync Error: Invalid Cross Reference Key",
    "body": "\n    \n        Salesforce Sync Error
\n    
\n    \n          Why: Salesforce CampaignMember creation failed due to invalid cross reference key error\n      \n      \n      Error details:\n      Received error message from salesforce while creating CampaignMember: INVALID_CROSS_REFERENCE_KEY, invalid cross reference id\n      \n      \n      What to do now? \n      Contact your Salesforce administrator for further troubleshooting\n      \n      ",
    "timestamp": "2026-09-26 10:12:01",
    "status": "read"
},
{
    "id": 638147,
    "classType": "error",
    "type": "salesforce_sync_failure",
    "notificationSubtype": "sfdc_sync",
    "subject": "Salesforce Sync Error: Unable to update Person",
    "body": "\n  \n    Salesforce Sync Error
\n  
\n  \n      Why: Marketo is unable to update Lead in Salesforce.\n    \n    \n    Error details: \n    INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id    \n    \n    Sample People:\n    Showing 3 of total 3 affected Leads\n    \n    \n    \n                  swhiteman@example.org
            rodger.dodger@example.ch
            jobert@example.com
      
\n    
\n    \n    What to do now? \n    Contact your Salesforce administrator for further troubleshooting\n    \n    ",
    "timestamp": "2026-09-26 01:32:18",
    "status": "read"
},
/* ... more entries... */
]

Going further

With this code, the HTML in the body property is simplified by removing and style attributes, but that’s it.

You could also leave body as a Document Fragment and traverse it to create a nested JS object. Thing is, the HTML is unstructured, i.e. different error types have different HTML shapes. So it’d be pretty hairy to work out the semantics for each error, especially those that haven’t shown up in my test instances! You’re welcome to give it a shot and let me know in the comments.😃

It’s a hack, but that’s okay

This code, like my other UI hacks, is 0% supported by Adobe: the underlying private API endpoint is subject to change at any time. But hopefully, if this endpoint changes bulk export will also be natively available!

Notes

[1] This focuses the inner IFRAME, which is where the fetch must originate. You can also pick app-.marketo.com from the JS context chooser:

[2] For this case, I assume you’ll copy-paste into a text editor. Automatically downloading a .json file is left as an exercise for the reader (hint: see my other UI hack posts).

Toggle WebFonts on/off in Email Editor to simulate different mail clients

Sanford Whiteman — Fri, 04 Sep 2026 00:25:24 -0400

💡

This solution uses the same tech as toggling images in Email Editor. I’ll omit some details you can read about over there.

You might be surprised that WebFonts (via CSS @font-face) are supported in Apple Mail for desktop and mobile. Those apps comprise at least 20% of email opens; using some methodologies, as much as 60%. Even the low end, IMO, doesn’t match the common take that “few” end users will see your fancy fonts!

Yes, you must fallback forcefully for Outlook. But it’s totally doable: this month (August 2026) I’ve seen WebFont-enabled emails from CDW, Dolby, London Review of Books, Malwarebytes, Mural, Salesforce, Verizon, and Zapier.

As with toggling images, you can easily add a WebFonts toggle to Email Editor 2.0:

A little Email 2.0 template code high up in :

And this

(Same

And preview by your test lead:

That’s it!

Toggle images on/off in Email Editor to simulate different mail clients

Sanford Whiteman — Thu, 03 Sep 2026 02:03:12 -0400

We all know Outlook blocks images by default, yet there’s no native way to preview without images in the Marketo UI. Turns out it’s super-easy to add a toggle to Email Editor 2.0:

Only takes a little Email 2.0 template code high up in :

And this

(As you might’ve figured, this

And preview by (sorry, “simulate content for”) your test lead:

Same underlying use of CSP ; not as pretty as the Email Editor 2.0 solution, but it works!

You should have one (1) rule in Form Editor » Custom CSS

Sanford Whiteman — Thu, 20 Aug 2026 13:50:02 -0400

Only so many “banes of your existence” before the term is meaningless. But form-level Custom CSS (Form Settings » Form Theme » ⚙) makes the cut for me. That Custom CSS box enables multiple bugs:

Styles meant for all forms are isolated within the form. They persist if cloned, but are lost when someone starts a form from scratch (and they will!).
Styles meant for one or a subset of forms are erroneously cloned to other forms, where they have to be overridden by sloppy !important rules.
Style changes aren’t propagated, by definition. It’s impossible to know whether a form uses the latest CSS.

💡

To target a specific form (in the business sense) don’t select form IDs in CSS, e.g. #mktoForm_nnnn. That’ll break when somebody clones the form to make changes. Instead, assign a data-attribute like

to find the form regardless of ID.

In my scarily long experience, it’s impossible to coordinate Custom CSS with page-level and site-level

Then in your forms-core.css (doesn’t have to be at the top, but that’s clearest):

#mktoStyleLoaded { border-top-color: #123456 !important; }

Why does it work?

Connecting a new download-circle

Create an otherwise blank LP and include the JS library directly after the standard HubSpot code:

Then set up your allowed origins (i.e. asset hosting domains, to not be an open proxy) and the redirect code:

redirect: {
  const allowedOrigins = [ // which domains are allowed for redirection
    "https://pages.example.com",
    "https://www.example.com",
    "https://example.com"
  ]; 

  const errNoAsset = "Asset URL not found or bad encoding."; // message when no asset in hash
  const errInvalidAsset = "Asset URL not allowed."; // when asset not our domain
  const redirectMs = 2000;

  let assetURL;
  try {
    assetURL = new URL(decodeURIComponent(document.location.hash.substring(1)));
  } catch(e){
    document.body.append(errNoAsset);
    break redirect;      
  }

  if( !allowedOrigins.includes(assetURL.origin) ){
    document.body.append(errInvalidAsset);
    break redirect;
  }

  enableHubspotHitEvent({ forceAfter: redirectMs, debug: true });
  
  document.addEventListener("hubspot.trackPageView", function (e) {
    document.body.append(`Redirecting to <${assetURL.href}>.`);
    document.location.href = assetURL.href;
  });

}

For simplicity, I used the same approach as the Marketo LP. allowedOrigins is an array of origins, errNoAsset and errInvalidAsset are error messages, redirectMs the fallback timeout (timeout is used only if the HubSpot JS is blocked).

At its simplest, build a Redirector LP URL like so:

https://redirectorpage.example.com#https://www.example.com/asset.pdf

But you should percent-encode the asset URL to not lose anything in edge cases:[1]

https://redirectorpage.example.com#https%3A%2F%2Fwww.example.com%2Fasset.pdf

`Notes`


[1] If the asset URL already has reserved characters that needed encoding, you don’t want to lose that. Like if the bare asset URL is:
https://www.example.com/assets/?asset=me%26mrjones.pdf
You need that %26 encoded to %2526 in the Redirector LP URL. Obviously best to avoid such situations, but they’re always lurking.



 You can’t get REST API Folder IDs from the Marketo Engage UI 
Sanford Whiteman — Sun, 15 Feb 2026 01:59:00 -0500
 The tl;dr: gotta use the API to use the API.
When browsing Marketing Activities, you’ll see the URL change to reflect Program IDs, Static List IDs, and Smart Campaign IDs:
.../marketo-engage/classic/PG3350A1
.../marketo-engage/classic/ST6331A1LA1
.../marketo-engage/classic/SC9850A1ZN19
In these cases, the first sequence of contiguous digits in the last path segment is the asset ID and can be used in the API. Above, you see Program ID 3350, Static List ID 6331, and Smart Campaign 9850. The structure works for Smart Lists as well. Other asset types like Forms and Emails also have their IDs in the URL.
Not Campaign Folders, though!
Selecting a Campaign Folder shows a tempting URL structure — 
.../marketo-engage/classic/MF2421A1
— leading you to think the Folder ID is 2421. Nope, in this case 2421 is the “tree node” ID, which is a UI thing only. It’s not the same as the REST API Folder ID, which reflects the persistent structure in the database.
Worse, the actual Folder ID 2421 can be located somewhere else in the database (it’s also possible for there to be no true Folder ID with that value). So if you make a destructive change to Folder ID 2421 using the API — deleting tokens, for example, or blindly deleting all its children and then deleting the folder itself! — you’ve hit the wrong target entirely. Yikes.
The solution is to use the Folders API endpoints to retrieve Folder IDs. An extra step if you’re just doing one-off tasks using Postman, but all in all it’s better to learn how to use those APIs (in particular, the difference between a Program-type Folder and a Folder-type Folder).
Also, some folders don’t even have tree node IDs
As you open/close folders inside Programs (not Campaign Folders) and folders in the Database section, you’ll notice the URL doesn’t change. Those types of folder are more “virtual”: for example, they don’t support tokens and you can’t focus them in the UI. They still have Folder IDs, of course, which you can get from the Folders API.   


 HOWTO: Make Marketo form onValidate/onSubmit/onSuccess idempotent, like native DOM events (plus learn what “idempotent” means!) 
Sanford Whiteman — Sat, 14 Feb 2026 15:11:07 -0500
 Marketo’s onValidate and friends stack like DOM event listeners: they run in the order they were added. But there are still major differences:
In Marketo, the listener stack isn’t deduped. If you add the same listener function 3 times, it’ll run 3 times. In contrast, DOM addEventListener(event,callback) checks if the callback was already added and if so, doesn’t add it again.
In Marketo, all listeners always run. There’s no short-circuit method like stopImmediatePropagation().
In Marketo, to stop submission you call submittable(). There’s no event-level preventDefault(). (Note onValidate — but only onValidate — respects the callback’s return value, kind of like DOM inline event handlers.) 
Adding (1) is an easy tweak that makes it a lot easier to manage advanced form behaviors with lots of coordinated components.
Adding (2) is quite tricky[1] and I’ll cover that another day. Might even throw in (3).😏
We’re adding idempotence to the Forms JS API
Idempotence is a show-offy CS term for an action that produces the same state, no matter how many times it runs.[2] DOM addEventListener is a great example. You can pass the same callback to addEventListener 1000x and the stack will be the same as if you only passed it once. 
Here’s a built-in example of idempotence in Marketo Engage: running Change Program Status even if a lead already has that status. Marketo won’t stop you from running the action, it’ll just log the skip.
Another example: loading the Forms 2.0 or Munchkin library multiple times. Only the first load will create the global MktoForms2 or Munchkin while subsequent loads will be ignored.[3]   
Anyway, wherever it’s feasible, idempotence makes code harder to break + easier to test.
Choosing our approach
First, note there’s no public access to the listener stack. (Same goes for DOM listeners, of course — you can’t access the stack of click or focus listeners from JS.)
That means we need to intercept calls to the on* and off* functions to maintain our own mirror of the current stack. In every on* call, check the mirror to see if if a callback is already present and ignore the call if so. In every off* call, delete the callback from our mirror and then process the call normally.
Get the code
If nothing else, this serves as a showcase for two JavaScript features, Set and Proxy. Those keep our code pretty short and sweet: 
/**
 * Enable DOM-like idempotent event stack for Marketo forms 
 * @author Sanford Whiteman
 * @version v1.0.0 2026-02-03
 * @copyright © 2026 Sanford Whiteman
 * @license MIT: This license must appear with all reproductions of this software.
 *
 */
function enableIdempotentListeners(readyForm){

   const events = ["Validate", "Submit", "Success"];
   const handlerPairs = events.map( event => ["on" + event, "off" + event] );
      
   handlerPairs.forEach( ([onHandler, offHandler]) => {
      
      const idempotentStack = new Set();
       
      readyForm[onHandler] = new Proxy(readyForm[onHandler], {
         apply(originalOnHandler, thisArg, [callback]){

            if( !idempotentStack.has(callback) ) {
               Reflect.apply(originalOnHandler, thisArg, [callback]);     
               idempotentStack.add(callback);
            }
            
            return readyForm;
         }
      });

      readyForm[offHandler] = new Proxy(readyForm[offHandler], {
         apply(originalOffHandler, thisArg, [callback]){
           Reflect.apply(originalOffHandler, thisArg, [callback]);   
           idempotentStack.delete(callback);

           return readyForm;
         }
      });
      
   });
}
In the distant past, we would’ve done this with Array indexOf() and storing the original handlers in a closure, but it’s fun to use later-model stuff.
Run enableIdempotentListeners on form load
Before enableIdempotentListeners starts intercepting, onValidate/onSubmit/onSuccess will work as they usually do. So ideally you start intercepting immediately by using onReady, i.e. the 4th argument to loadForm():
MktoForms2.loadForm("//123-ABC-456.mktoweb.com", "123-ABC-456", 999, enableIdempotentListeners);
If you absolutely can’t use onReady, you can use whenReady() right after loading the forms library:
MktoForms2.whenReady(enableIdempotentListeners);
Enjoy your newfound idempotence
Now, even if you add the same callback under multiple conditions, it’ll only run once:
function validateSpecial(nativeValid){
  if( !nativeValid ) return;
  console.log("something’s gonna be done for form", mktoForm.getId());
}

MktoForms2.whenReady(function(readyForm){
  if( someCondition ) {
    readyForm.onValidate(validateSpecial);
  }
  
  /* ... do lots and lots of other stuff... */

  if( someOtherCondition ) {
    // thanks to idempotence, this won’t add the callback again
    readyForm.onValidate(validateSpecial);
  }
});
Notes
[1] You might think, “Just use a variable in a shared scope,” e.g. check if skipFurtherValidation === true at the top of each listener function. That’ll work the first time through the stack, sure! But remember, there’s no event object passed to Marketo listeners.
(By contrast, with DOM submit events, a new SubmitEvent is created on each attempt and passed to each submit listener. One click ⇒ one distinct SubmitEvent.)
So consider someone trying to submit a Marketo form after correcting an initial error. How do you know if this is a new submit attempt, so skipFurtherValidation should be reset, rather than reading its last value? 😜
[2] Some people misdefine an idempotent action as an action that throws an error if it’s already run. But that’s not it. Idempotence means you can re-run without an error yet without further changes.
Others misdefine it as an action that never makes changes, like a database query. But that’s not it, either. A read-only query is implicitly idempotent, yes. But an update or insert can also be idempotent.
[3] When loading forms from different Marketo instances, this optimization becomes suboptimal and I’ve written before about how to disable it.   


 Why the back/forward cache (bfcache) loses Munchkin activities, and how to fix it 
Sanford Whiteman — Fri, 23 Jan 2026 21:27:00 -0500
 Modern browsers use the back/forward cache (“bfcache”) to accelerate simple ⇦ and ⇨ navigation. Confusingly, the bfcache is different from both the classic HTTP cache and the new Cache API, and its impact on 3rd-party JS isn’t widely measured.
The bfcache is dynamically managed and cleaned up by the browser: it doesn’t have user-tweakable settings and can’t be directly turned off. There are also lots of different reasons that the same page might be bfcache-able on one visit but not on the next. 
This all gives the bfcache a black-box vibe. But the bfcache usually leads only to Good Things™ so people don’t worry about it, aside from some devs trying to make sites as bfcache-able as possible.
Interestingly, Munchkin’s backward compatibility (pageview and link tracking still work with old browsers) conflicts with the bfcache design. This wasn’t deliberate, of course, but the product of different goals.
In this recording, check out when visitWebPage and clickLink events stop being sent to Marketo:
The initial visitWebPage fires, as do clickLink events for the top 2 internal links. When I click the 3rd off-page link (“This is a link to another page”) there’s a clickLink for that, too. Then I use the back button to return to the initial page. Upon returning, no events are fired, though I’m interacting with the same links.
Munchkin unhooks click events out of an abundance of caution
See, when Munchkin detects the page is about to unload, it unhooks itself (i.e. removes event listeners) from all interesting  elements and from the main document to avoid potential memory leaks. Using the beforeunload or unload event to free memory wasn’t controversial in the past. While the majority of browsers — even in those old days — didn’t have problems collecting memory, a few did, and there were no downsides.
Then came the bfcache. The bfcache changes what it means to “unload” a document. Now, unload can mean either:
the document is going away forever and its current state (DOM/JS/memory) is ready to be garbage collected (the old meaning); or
the document will be restored from a snapshot of its current state and resume running if a back/forward action — on-screen button, mouse button, or touch gesture — happens within a short time window (after that window, the document is removed from the bfcache and behaves as in (1))
It’s case (2) you’re seeing above. Munchkin, worried about memory leaks, removes all DOM listeners before the page unloads. As the page is bfcache-able, the browser caches its final state — that is, without the listeners. A back action is used quickly, so the bfcache’d state is restored rather than loading the page over the network.
The fix
The bfcache makes eligible pages available instantly: it’s more like showing a hidden page than “loading” a document in the traditional sense. Indeed, the event that can tell us if the document was restored from bfcache is called pageshow.[1]
If a pageshow event’s persisted property is true, the page was restored. So we:
check for persisted
remove previous evidence of Munchkin
reinject the Munchkin bootstrap (which loads the library)
Simple stuff:  
window.addEventListener("pageshow", function(e){
   if(e.persisted){
      delete window.Munchkin;
      delete window.MunchkinTracker;
      
      const munchkinBootstrap = document.createElement("script");
      munchkinBootstrap.src = "//munchkin.marketo.net/munchkin-beta.js";
      
      const munchkinInit = {
        handleEvent(e){
          Munchkin.init("123-ABC-456"); // plus Munchkin options
        }
      };

      munchkinBootstrap.addEventListener("load", munchkinInit, { once: true });
      document.head.append(munchkinBootstrap);
   }
});
Now,  a quick back-and-forth doesn’t lose any hits:
More on modernizing Munchkin
Also wrote recently about trimming down the Munchkin embed code if, like most people, you don’t care about Internet Explorer anymore. 
Notes
[1] Familiar events like DOMContentLoaded and window load don’t fire again when bfcache is used, which makes sense — it would be catastrophic to re-fire those events on a page that was merely temporarily hidden. 


 Properly preserving Marketo {{dotted.tokens}} in URL builders 
Sanford Whiteman — Thu, 22 Jan 2026 23:56:19 -0500
 Busy MOps teams use a URL builder to manage tracking params (and sometimes for add-to-calendar URLs and other areas). They have a UI like this:
And generate a copy-and-pasteable URL like this:
https://www.example.com/landingpage?baseparam1=value1&utm_campaign=nosferatrix-or-treat-2025&utm_medium=email&utm_source=marketo&utm_content=logo&utm_term=default
Sometimes they’re built using Excel or a Google Sheet (ugh) instead of a separate web app, but the idea is the same. 
Problem: most such builders have at least one fatal bug. They do not properly support Marketo {{dotted.token}} syntax in query param values.  This is bad, since tokens are a huge operational benefit on their own. Let’s say you want to use the built-in {{campaign.Name}} as the utm_campaign value:
A naïve URL builder will mistakenly think {{campaign.Name}} is a literal value, as opposed to an interpolated variable, and will URL-encode it, breaking the URL in Marketo:
https://www.example.com/landingpage?baseparam1=value1&utm_campaign=%7B%7Bcampaign.Name%7D%7D&utm_medium=email&utm_source=marketo&utm_content=logo&utm_term=default
To be clear, URL-encoding literal values is absolutely correct, and a builder that doesn’t even do that is useless! 
The problem is not understanding that some patterns must be left unencoded, so Marketo can replace them with the underlying value — which you must ensure is a URL-safe value on the Marketo side.[1]
Terminus almost gets it
The screenshots in this post are from Terminus, which URL-encodes and makes a good faith attempt at token support — even if it doesn’t succeed, as we’ll see below. (As one contrast, this builder from TrackFunnels doesn’t encode at all and is basically fraudulent!)
In Terminus, you can select “preserved characters” which won’t be encoded:
Looks promising. Except with Marketo {{dotted.token}}  syntax, characters inside the double brackets must not be encoded, either. Enter tokens with spaces in the Terminus builder:
And it’ll output those as {{my.Public%20Campaign%20Name}} and {{lead.Marketo%20Unique%20Code}} respectively. Which means Marketo will no longer substitute the token values; instead, it’ll output nothing, as it always does when a token isn’t recognized. Oops!
Covering both bases 
A proper URL builder, like the one I built specifically for this post, uses a regex to de-encode Marketo tokens:
encodedURL.replaceAll( /(%7B%7B.+?\..+?%7D%7D)/ig, decodeURIComponent )
The regex restores sequences of encoded {{ + dotted.string + encoded }} to the original unencoded value. 
Notes
[1] Yes, that’s right. Marketo will not automatically URL-encode {{my.tokens}}, {{campaign.tokens}} or {{lead.tokens}}. You must make sure that either:
all values are URL-safe to start, or
all values are URL-encoded using Velocity before sending
Achieving (1) is impossible if you use {{campaign.tokens}} or {{program.tokens}}, since you can’t truly stop users from introducing non-URL-safe characters via the Marketo UI. That’s the main reason I prefer a custom {{my.Public Campaign Name}} token over {{campaign.name}}. (The other reason being internal name privacy: you don’t want people knowing they’re in “Insufferable Fools Group 2”.) 
For example, say the campaign name in Marketo is 2025-12-04 Weekly Q & A. In this case, {{campaign.Name}} will break URLs because of the &. A separate {{my.Public Campaign Name}} lets you encode the value, i.e. 2025-12-04%20Weekly%20Q%20%26%20A, or use a custom URL-safe variant like 2025-12-04-wekly-q-and-a. 


 Streamline the Munchkin embed code, taking out outdated cruft 
Sanford Whiteman — Sun, 18 Jan 2026 23:28:10 -0500
 In my last post on the bfcache I mentioned the Munchkin library does some backward-compatible stuff that’s not necessary in modern browsers (it was only relevant for old versions of Internet Explorer).
In fact, the Munchkin embed code is also needlessly verbose. All you need to be compatible with the latest Chrome/Edge, Firefox, and Safari, on desktop and mobile, is this:
{
  const munchkinBootstrap = document.createElement("script");
  munchkinBootstrap.src = "//munchkin.marketo.net/munchkin-beta.js";

  munchkinBootstrap.addEventListener("load", function(e) {
    Munchkin.init("123-ABC-456"); // plus your custom Munchkin options, if any
  }, 
  { 
    once: true 
  });
  document.head.append(munchkinBootstrap);
};
(That could also have line breaks removed, but I wanted it to be readable.)
Contrast this with the default “async embed code” in the Marketo UI:
var didInit = false;
function initMunchkin() {
  if(didInit === false) {
    didInit = true;
    Munchkin.init("123-ABC-456"); // plus your custom Munchkin options, if any
  }
}
var s = document.createElement('script');
s.type = 'text/javascript';
s.async = true;
s.src = '//munchkin.marketo.net/munchkin-beta.js';
s.onreadystatechange = function() {
  if (this.readyState == 'complete' || this.readyState == 'loaded') {
    initMunchkin();
  }
};
s.onload = initMunchkin;
document.getElementsByTagName('head')[0].appendChild(s);
My changes were:
using block scope instead of a function
switching var to const
running the event handler once instead of the didInit flag (there are cases where you still need a separate flag, but not here)
removing explicit type and async (those are the HTML5 defaults)
assuming there’s only one  (let’s be serious, if you have duplicate  tags, things should break)
removing onreadystatechange, which was only fired in IE
If you want your site to look new-ish to those peeking under the hood, use the newer snippet. Doesn’t change how Munchkin works, just how it’s loaded. 


 Parse “Visit Web Page” {{trigger.tokens}} into individual query params using FlowBoost 
Sanford Whiteman — Sat, 17 Jan 2026 18:43:00 -0500
 Marketo uses offbeat definitions when it comes to web visits. For example, if you visit this URL in your browser: 
https://example.com/page/4?utm_campaign=2026-01-sample-sale&utm_medium=email&utm_source=marketo#fragmento
Munchkin insists the “web page” ({{trigger.Web Page}}) is:
example.com/page/4#fragmento
That is, it’s only the host + path + hash parts of the URL. Not the protocol or the query string, which is weird.
The query string didn’t even have an associated token for a long time (it was therefore unusable in webhooks/flow steps/emails) but now we have a separate {{trigger.Query Parameters}}:
utm_campaign=2026-01-sample-sale&utm_medium=email&utm_source=marketo
Nice, but there’s still no query string parser on the Marketo back end. You can’t get individual params (utm_campaign, utm_medium, and utm_source) and write them to their own fields. Also, when filtering, you’re forced to do pretty fragile [contains] matching on the whole query string.
FlowBoost has a standard URL parser, FBHttp.URL (same as URL in browsers) which can unweird the weirdness. You just need to feed the URL constructor correctly:
prepend a protocol — we assume https: these days — to the {{trigger.Web Page}} (host + path + hash)
construct a URL from the protocol + host + path + hash 
set the URL’s search property to {{trigger.Query Parameters}}, which is automatically parsed into name-value pairs
The FlowBoost payload:
const vwpContext = {
  Protocol : "https:",
  HostPathHash: {{trigger.Web Page}},
  Search: {{trigger.Query Parameters}}
};

const url = new FBHttp.URL(vwpContext.Protocol + "//" + vwpContext.HostPathHash);
url.search =  vwpContext.Search;

hostPath = url.origin + url.pathname;
origin = url.origin;
path = url.pathname;
hostname = url.hostname;
hash = url.hash.substring(1);
fullQuery = url.searchParams.toString();

queryParams = {};
for( const [name,value] of url.searchParams ){
  queryParams[name] = value;
}
The webhook response has lots of choices ready for Response Mappings:  
{
  "fullHref": "https://example.com/page/4?utm_campaign=2026-01-sample-sale&utm_medium=email&utm_source=marketo#fragmento",
  "hostPath": "https://example.com/page/4",
  "origin": "https://example.com",
  "path": "/page/4",
  "hostname": "example.com",
  "hash": "fragmento",
  "fullQuery": "utm_campaign=2026-01-sample-sale&utm_medium=email&utm_source=marketo",
  "queryParams": {
    "utm_campaign": "2026-01-sample-sale",
    "utm_medium": "email",
    "utm_source": "marketo"
  }
}
For example, map queryParams.utm_campaign to a custom field Last utm_campaign. 


 Be aware of decodeURIComponent() limitations (not only with Marketo forms, but with any 1ˢᵗ or 3ʳᵈ party JS) 
Sanford Whiteman — Sun, 04 Jan 2026 02:42:00 -0500
 Here’s a fun one. Open a URL that hosts a Marketo form and change the query string to ?utm_medium=email&utm_campaign=new-years-discount-10%.
Here’s how your form will look:
What the? Let’s check the browser console: 
⮾️ Uncaught URIError: URI malformed
    at decodeURIComponent ()
    at b.exports (forms2.min.js)
    at h.getPageFields (forms2.min.js)
    at yourpage.html?utm_medium=email&utm_campaign=new-years-discount-10%
    at q (forms2.min.js)
Hmm, that’s not great. Granted, we didn’t URL-encode the param names or values, like a certain blogger always reminds us to. Could that be it?
﹥ decodeURIComponent("utm_medium")
⋖ 'utm_medium'
﹥ decodeURIComponent("email")
⋖ 'email'
﹥ decodeURIComponent("utm_campaign")
⋖ 'utm_campaign'
﹥ decodeURIComponent("new-years-discount-10%")
⮾ Uncaught URIError: URI malformed
     at decodeURIComponent()
     at 
Yep, that was it: decodeURIComponent throws a URIError if a value contains invalid percent-encoding. Make no mistake, a % must be followed by 2 hex digits (0-9 or A-F, case-insensitive) in a URL, per RFC 3986. That URL, as innocent + unambiguous as it looks, is invalid.
Marketo’s forms library — as do many others, we’re definitely not alone here! — still uses decodeURIComponent to parse query strings. Since it doesn’t wrap calls in try/catch or do any pre-fixup, a URIError is fatal.
Out of curiosity, let’s see what URLSearchParams does with the same query string:
﹥ const searchParams = new URLSearchParams(document.location.search);
﹥ searchParams.get("utm_campaign");
⋖ 'new-years-discount-10%'
Interesting. URLSearchParams — the new(ish) native way to read and write query strings — is forgiving of the dangling % and doesn’t throw an error. It obeys Postel’s Law, in other words, accepting lightly-broken input but not producing broken output.
But decodeURIComponent isn’t completely strict, since it tolerates unencoded input
It’s tempting to conclude decodeURIComponent only supports output that would be generated by its companion function encodeURIComponent, but that’s not so. Check this out:
﹥ decodeURIComponent("😊")
⋖ '😊'
decodeURIComponent is cool with an unencoded emoji, even though that’s also invalid in a URL (it should be %F0%9F%98%8A)!
So it’s strict when input is incorrectly percent-encoded: it also fails on, say, trailing %F or %AZ anywhere in a string, since those aren’t % followed by 2 hex digits. But it’s loose when a value simply isn’t percent-encoded. 
Note URLSearchParams is consistently loose, also tolerating the unencoded emoji: 
﹥ new URLSearchParams("test=😊").get("test")
⋖ '😊'
Protect decodeURIComponent-dependent parsers from bad percent-encoding
Later, I’ll show how to modify a parser that uses decodeURIComponent so it’s more URLSearchParams-ishly tolerant of bad encoding (though you should migrate to URLSearchParams itself, it’s great).
But what if you didn’t write the parser, so you can’t modify it — and say you accidentally sent out a bad URL and 1000s of people are about to land on your LP? 
Not to worry, you have 2 great options and 1... let’s say, interesting option. Choose one and include it as high as possible in .
Option 1: Proxy decodeURIComponent while still using it under the hood
This option adds a one-line “shim” to replace invalid sequences with valid equivalents before calling native decodeURIComponent. In my tests, it’s lightning-fast (to the tune of 2 million calls/sec) so you don’t have to worry about overhead. It also replaces the troublesome + sign in the same shot, so you don’t need to repeat that step. 
window.decodeURIComponent = new Proxy(window.decodeURIComponent,{
    apply(target, thisArg, [encoded]) {
        const dUCSafeEncoded = encoded.replace(/(\+|%(?![0-9a-f][0-9a-f]))/ig, (match) => match === "+" ? "%20" : "%25" );
        return Reflect.apply(target, thisArg, [dUCSafeEncoded])
    }
});
Option 2: Overwrite decodeURIComponent to use URLSearchParams under the hood
This one is provided more as a curiosity. It overwrites decodeURIComponent to use the URLSearchParams parser. Short and sweet-looking, for sure. But URLSearchParams is designed to parse a full query string at once, not to be called for every component. There’s considerable overhead in parsing and getting the first value from the iterator. (We’re still talking ~400,000 calls/sec, so you’re really unlikely to feel any difference in MOps applications, but I can’t fully recommend it.)
window.decodeURIComponent = function(encoded){
    const uSP = new URLSearchParams("=" + encoded);
    return uSP.values().next().value;
}
Option 3: Canonicalize the query string upfront
This option leverages URLSearchParams’s loose input + strict output to in-place replace the query string (don’t worry, no refresh) with a properly encoded version. Any dangling % becomes %25[1], so native decodeURIComponent won’t have trouble.
const currentURL = new URL(document.location.href);
currentURL.search = currentURL.searchParams.toString();
history.replaceState({},"",currentURL.href);
Fix a decodeURIComponent-dependent parser
A ton of forms and analytics code still uses decodeURIComponent; again, Marketo users are not alone. Those query string parsers look like this:[2]
const queryParams = document.location.search
    .substring(1)
    .replace(/\+/g, "%20")
    .split("&")
    .reduce( (map, nextPair) => {
        const hasValue = nextPair.includes("=");
        const rawKey = hasValue ? nextPair.substring(0,nextPair.indexOf("=")) : nextPair,
              rawValue = hasValue ? nextPair.substring(nextPair.indexOf("=")+1) : "";
        const key = decodeURIComponent(rawKey),
              value = decodeURIComponent(rawValue);
        if( key ) {
          if( !map.has(key) ) { 
            map.set(key, value);
          } else if ( Array.isArray(map.get(key)) ) {
            map.get(key).push(value);
          } else {
            map.set(key, [map.get(key),value]);
          }
        }
        return map;
    }, new Map() );
Straightforward enough, right? 
split query string on & to separate params
split each param on the first = to separate names from values
set a single value or append to an array of values (remember, ?a=one&a=two is valid)
About the plus sign thing
Perhaps not self-explanatory is replacing + with encoded %20. This is necessary because decodeURIComponent supports only RFC 3986-strict percent encoding, while in the wild you’ll see both RFC 3986 and x-www-form-urlencoded strings.[3] The latter uses + for spaces because it’s more concise, creating 30 years of confusion and counting!
To adapt that code to be URLSearchParams-ish, also replace %, when not followed by 2 hex digits, with %25:
 const queryParams = document.location.search
    .substring(1)
    .replace(/(\+|%(?![0-9a-f][0-9a-f]))/ig, (match) => match === "+" ? "%20" : "%25" )
    .split("&")
    .reduce( (map, nextPair) => {
        const hasValue = nextPair.includes("=");
        const rawKey = hasValue ? nextPair.substring(0,nextPair.indexOf("=")) : nextPair,
              rawValue = hasValue ? nextPair.substring(nextPair.indexOf("=")+1) : "";
        const key = decodeURIComponent(rawKey),
              value = decodeURIComponent(rawValue);
        if( key ) {
          if( !map.has(key) ) { 
            map.set(key, value);
          } else if ( Array.isArray(map.get(key)) ) {
            map.get(key).push(value);
          } else {
            map.set(key, [map.get(key),value]);
          }
        }
        return map;
    }, new Map() );
Should you fix it, though? 🤔
decodeURIComponent’s strictness has an upside. Provided you catch errors during testing, it tells you something’s wrong with whoever/whatever is creating your URLs.
Hiding the problem with new-years-discount-10% encourages broken “URL builders” to stay broken in worse ways, like failing to encode literal & as %26 (which will never throw a parsing error, it’ll just break reporting and/or on-page logic).
Might be worth enduring a post mortem if your team pays attention to encoding in the future.
Notes
[1] You could debate whether bad encoding should result in stripping the % or encoding the %. That is, it’s easy to say discount-10% was meant to be discount-10%25, but not easy to know whether newsletter-%signup was meant to be newsletter-%25signup or if the % was a typo. I personally respect URLSearchParams’s take on this, that the % was intentional. 
[2] Okay, their code doesn’t usually use a Map but a regular JS Object. I couldn’t in good conscience publish code that mangles param order, so my example uses a Map.😛 
[3] You don’t need to worry about this with URLSearchParams because it outputs + but accepts either %20 or +  as input. 


 MktoForms2.whenReady() is always non-blocking (plus: what is and isn’t a race condition) 
Sanford Whiteman — Sat, 03 Jan 2026 18:40:59 -0500
 
Chronicles of Strange Code, §2026.01.03(a).let enrichableForms = [123,678];
let formsOnPage = [];

MktoForms2.whenReady( function(readyForm){
  formsOnPage.push(readyForm.getFormId());
});
if( enrichableForms.some( id => formsOnPage.includes(id) ){
  // load an external JS plugin
}
The code above was supposed to:
add the ID of each in-use form to an array, then
check the array against a list of “interesting” form IDs, then
load an enrichment plugin if there’s a match
Except it doesn’t do that. formsOnPage will always be empty when checked. There’s no condition under which this code works as desired.
“OK,” you might say. “I get how, if loadForm is just before this code, the forms won’t be done loading when whenReady is called. Is there a race condition, so it would work if a form had loaded, like, 5 minutes before?”
Nope. There’s no race condition because the callback passed to whenReady always runs asynchronously. Doesn’t matter when forms become/became ready. Run this code:
console.log("banana");
MktoForms2.whenReady( function(readyForm){
   console.log("jalapeno");
   MktoForms2.whenReady( function(readyForm){
      console.log("shishito");
   })
   console.log("ghost");
});
console.log("serrano");
100.00% of the time, the output will be:
⋖ banana
⋖ serrano
⋖ jalapeno
⋖ ghost
⋖ shishito
Remember, a race condition means factors like network quality, server response time, local processing power, disk & filesystem performance, and concurrently running code affect execution order.
That is, there must be an inadvertent “race” between components you can’t control — unlike here, where one code path always wins. Bugs related to execution order aren’t necessarily race conditions.
Assume adding an event listener is asynchronous
Shouldn’t expect MktoForms2.whenReady() to work any other way. Native addEventListener() never runs the callback immediately, either!
For example, if you add a DOMContentLoaded listener when DOM content was already loaded, the callback doesn’t run. If you add it when DOM content isn’t loaded yet, the callback runs later. There’s no case where it runs immediately upon being added.🞷
(Perhaps the author was half-remembering how jQuery.ready() works. But even there, the callback runs asynchronously; the special part is that it runs at all.)  
So if that’s not a race condition, what is?
With Marketo forms in particular, a race I sometimes see is loading the core library (forms2.min.js) asynchronously, yet not considering response time variance before accessing MktoForms2. Like this simplified example:




(In the real world, rather than an explicit async attribute, async is implied by using a tag manager like GTM to inject the library. Script-injected-scripts are always async.)
The code above is entirely dependent how long one.js + two.js take to load compared to forms2.min.js:
If those two external scripts load in in 70ms total but the library takes 71ms, the check for window.MktoForms2 fails and there won’t be a form. 
If the scripts take 71ms while the library takes 70ms, the check succeeds and the form will render.
That fragility is obviously unacceptable.
Unfortunately, most developers (not just juniors) don’t test their code against adverse network/server conditions. If they did, this code would never make it to production. One of my testing habits is exaggerating the load time of async resources, say to a full 30 seconds, to make sure my code still works. (I run a special “slowpoke” server to help with this.)
This kind of race is obscured — but in no way solved! — when there’s a lot more than the two sync scripts one.js and two.js. There could be a stack of 20 JS/CSS files between forms2.min.js and the attempt to use MktoForms2, each subresource adding just enough consistent delay so the library finishes loading 99% of the time. 
But go outside the comfort of your primary machine/connection and that’ll change, e.g. if you’re on a network where forms2.min.js takes 10ms more and other scripts take 10ms less.🞷🞷 That difference is invisible to the end user, but fatal to your code.
Notes
🞷 One native event-related feature that behaves a little weirdly is manually dispatching an Event. In this case, callbacks run synchronously to completion before the calling code continues. Surprises can ensue, as the same click listener is either blocking or non-blocking depending on whether it’s a trusted click or a synthetic MouseEvent. But addEventListener() is still asynchronous! 
🞷🞷 Note 4xx and 5xx errors can be much faster than 2xx responses. Pages with tons of random analytics/enrichment/tracking plugins eventually end up with errors from outdated vendors. Also consider ad blockers, which deliver near-instantaneous errors. If you really want to stress-test your code, ensure that a 60μs (60 microsecond!) response from disposable code doesn’t have any effect on mission-critical code like forms.    


 Tip: Add a initial row number to Bulk Lead Import CSVs for useful failure reports 
Sanford Whiteman — Wed, 24 Dec 2025 13:04:12 -0500
 If you already pre-flight CSVs before putting them on the wire to the Bulk Import API (/bulk/v1/leads.json), you won’t notice this li’l bug. We recommend at least these two pre-flight checks:
ensure the lookup field — email, id, sfdcContactId, etc. — is non-empty in every row
ensure field values are consistent with back-end data types, e.g. an Integer field can’t store a decimal or alphanumeric value
There are tons of other checks you should do on CSVs, but I like to confine the term “pre-flight” to stuff Marketo will throw an error on. (Other checks are business-level and won’t stop the row from importing, for better or worse!)
If you pre-flight, you usually get the all-clear from the Import Status endpoint (/bulk/v1/leads/batch/:importid.json) so you don’t need to fetch Import Failures (/bulk/v1/leads/batch/:importid/failures.json).
But say you don’t pre-flight and just upload CSVs as-is. Then it’s possible for a CSV to lookup on email yet have rows with empty email:
------WebKitFormBoundaryBQACkJZyaiIAXogC
Content-Disposition: form-data; name="file"; filename="leads.csv"
Content-Type: text/csv

firstName,lastName,phone,email
Joe,Hixie,212-555-1212,teknkl+test-import-01@figureone.com
Benji,Nordstrom,212-555-2323,
Dusty,Brix,212-555-3434,teknkl+test-import-03@figureone.com
Hank,Lovemore,212-555-4545,teknkl+test-import-04@figureone.com

------WebKitFormBoundaryBQACkJZyaiIAXogC--
The exact payload above won’t cause any confusion. Import Status will return "numOfRowsFailed": 1 and Import Failures returns a parseable CSV to feed into your error handling code:
firstName,lastName,phone,Import Failure Reason
Benji,Nordstrom,212-555-2323,Value for lookup field 'email' not found
If you reverse email and phone and leave that same value empty, you still get usable Failures:
------WebKitFormBoundaryBQACkJZyaiIAXogC
Content-Disposition: form-data; name="file"; filename="leads.csv"
Content-Type: text/csv

firstName,lastName,email,phone
Joe,Hixie,teknkl+test-import-01@figureone.com,212-555-1212
Benji,Nordstrom,,212-555-2323
Dusty,Brix,teknkl+test-import-03@figureone.com,212-555-3434
Hank,Lovemore,teknkl+test-import-04@figureone.com,212-555-4545

------WebKitFormBoundaryBQACkJZyaiIAXogC--
firstName,lastName,phone,Import Failure Reason
Benji,Nordstrom,212-555-2323,Value for lookup field 'email' not found
Things get wacky, though, when you not only have a missing lookup value or other data error, you also have empty fields in the same row:
------WebKitFormBoundaryBQACkJZyaiIAXogC
Content-Disposition: form-data; name="file"; filename="leads.csv"
Content-Type: text/csv

firstName,lastName,email,phone
Joe,Hixie,teknkl+test-import-02@figureone.com,212-555-1212
,Nordstrom,,
Dusty,Brix,teknkl+test-import-02@figureone.com,
Hank,Lovemore,,

------WebKitFormBoundaryBQACkJZyaiIAXogC--
 Then, the response gets mangled:
lastName,Import Failure Reason
Nordstrom,Value for lookup field 'email' not found
Hank,Lovemore,Value for lookup field 'email' not found
Check the number of headers vs. the number of fields in data row 1 vs. row 2. Nordstrom was row 1’s lastName, yes, but Hank wasn’t row 2’s lastName, it was its firstName. That mangled response can’t be parsed to find the original offending row! Unfortunately, the API gets confused when error rows have empty fields.😦  
To be clear: empty fields are totally valid in themselves and won’t cause a problem in the absence of fatal import errors. Also, the bug appears whether the empty field is double-quoted ,"", or simply empty ,, — as you should expect because those have exactly the same meaning in a CSV.
Truth is, even the non-mangled response CSV is suboptimal, IMO. It lacks a row number, so to seek the row in the original file you need to match every single field. That’s really inefficient if you already parsed a source CSV into an indexed collection (e.g. JS array) even if you didn’t pre-flight.[1]
Luckily, it’s easy to add a row number yourself, which patches over the bug while improving the Import Failures response in all cases. Add a Last Import Row Number (Integer) field in Marketo, and make that the first field in your CSV:  
------WebKitFormBoundaryBQACkJZyaiIAXogC
Content-Disposition: form-data; name="file"; filename="leads.csv"
Content-Type: text/csv

lastImportRowNumber,firstName,lastName,email,phone
1,Joe,Hixie,teknkl+test-import-02@figureone.com,212-555-1212
2,,Nordstrom,,
3,Dusty,Brix,teknkl+test-import-02@figureone.com,
4,Hank,Lovemore,,

------WebKitFormBoundaryBQACkJZyaiIAXogC--
Then the response reflects that field for easy seekin’:
lastImportRowNumber,lastName,Import Failure Reason
2,Nordstrom,Value for lookup field 'email' not found
4,Hank,Lovemore,Value for lookup field 'email' not found
The response still has an irregular number of fields per line, but you only need the first field so your code won't break.
Notes
[1] To prepend lastImportRowNumber  you must parse the CSV before creating the request payload. So in the unlikely-but-not-impossible case where you have a guaranteed pre-pre-flighted CSV from an outside source and want to just stream it into the payload (admittedly, the most efficient way to send a static file, as long as you skip the BOM) you can't do that anymore. 


 No, you don’t need a Wait step after Sync Person to SFDC: sync-related updates are immediate (i.e. synchronous) 
Sanford Whiteman — Tue, 02 Dec 2025 21:55:00 -0500
 
We talk a lot about race conditions in the Marketo community, and I love reminding folks certain operations aren’t guaranteed to complete in flow step order.[1] Unfortunately, users tend to overcorrect, forgetting Marketo does guarantee order in many cases, just not all sensitive cases!
This came up on a recent Nation thread where someone’s new lead flow included Sync Person to SFDC, followed by a 5-minute Wait, then Send Email. “Exactly what is the Wait step for?” I asked. 
Unfortunately, the OP ghosted the thread, but others guessed “To make sure the sync has actually happened.” They were thinking the email, which included a booking link, shouldn't go out until the lead is visible to sales.
But that’s wrong on 2 counts:
First, a Wait step is unnecessary because Sync Person is guaranteed to finish before the next step runs. If the sync succeeds, field updates triggered on the SFDC side will be synced to Marketo immediately. After the bidirectional sync, the API connection closes and it’s on to the next step. 
Second, even if a Wait were in there (again, totally unnecessary!) Sync Person merely finishing doesn’t mean the record was created in SFDC. Finishing includes both success and failure. A validation error from SFDC means the person is still Marketo-only.
A closer look at Sync Person success
Let’s run a real-world test. The flow runs Sync Person to SFDC and immediately logs an Interesting Moment — no Wait — and crucially, the IM description includes Lead Source, a field that’s only populated when Marketo gets the value from SFDC:
Here’s the corresponding activity log:
As you can see, Sync Person runs and is followed by a host of other data value changes fetched from SFDC. After all those updates comes the Interesting Moment, with Lead Source “Import (Employee Referral)” populated in the IM as desired.
You might wonder if the updates and IM are happening in parallel, since Marketo only shows minutes in the UI. Nope! The JSON response shows the last update at 02:26:17 and the IM at 02:26:18, one second later:
{
    "resultCode": "Succeeded",
    "actionName": "Interesting Moment",
    "detail": "SFDC Sync: Person Source (from SFDC) is Import (Employee Referral)!",
    "dateAndTime": "2025-11-23 02:26:18",
    "historyLogId": 886995328,
    "assetId": null,
    "detailJson": {
        "Choice Number": 0,
        "Description": "Person Source (from SFDC) is Import (Employee Referral)!",
        "Step ID": 130078,
        "Source": "Lead action",
        "operator": "is",
        "Date": "2025-11-23 01:26:18",
        "datatype": "string",
        "Lead ID": 33945529,
        "Type": "SFDC Sync"
    },
    "campaignId": 45378,
    "campaignName": "TEST Program > Engagement > Nurture SMR.Sync to SFDC and do stuff right after",
    "actionTypeId": 46,
    "actionAssetType": "mktInterestingMoment",
    "date": "2025-11-23 02:26:18",
},
{
    "resultCode": "Succeeded",
    "actionName": "Change Data Value",
    "detail": "Changed Discovery Data Status from [null] to \" No ID\"",
    "dateAndTime": "2025-11-23 02:26:17",
    "historyLogId": 886995327,
    "assetId": 2826,
    "detailJson": {
        "Choice Number": 0,
        "Reason": "Synched from salesforce.com Lead ID 00QNw00000MsRMkAAD",
        "DB Object ID": 2,
        "Attribute Name": "Discovery Data Status",
        "Step ID": 130077,
        "New Value": " No ID",
        "Old Value": null,
        "Source": "sfdc",
        "Lead ID": 33945529,
        "Attribute ID": 2826,
        "isCustomerCreated": true
    },
    "campaignId": 45378,
    "campaignName": "TEST Program > Engagement > Nurture SMR.Sync to SFDC and do stuff right after",
    "actionTypeId": 13,
    "actionAssetType": "mktDbAttribute",
    "date": "2025-11-23 02:26:17",
}
Capturing Sync Person failure
Mentioned above that Sync Person completing, whether you Wait for it or not, doesn’t mean the record was successfully upserted into SFDC: it just means Marketo tried to upsert.
To proceed only if Sync Person was successful, use a (second) campaign triggering on Person is Synced to SFDC:   
Marketo only fires this trigger if the person was actually synced. 
So you never need a Wait, but depending on how worried you are about sync failures, you may need a more complex overall setup.
Notes
[1] Updates from Call Webhook response mappings, for example. That’s why you need the Webhook is Called trigger.
 


 Marketo click tracking only works because 2 JavaScript bugs cancel each other out 
Sanford Whiteman — Tue, 02 Dec 2025 21:45:29 -0500
 An uncomfortable truth: the tiny bit of JavaScript that runs on Marketo’s click tracking servers (i.e. branding domains) has 2 pretty embarrassing bugs, but the resulting logic — by accident — works just fine!
Here’s the code, which runs 10s of millions of times per day: 
var redirecturl = 'https://www.example.com/landingpage?mkt_tok=NDEwLVhPUi02NzMAAA...';
document.getElementsByTagName('head')[0].addEventListener('load',redirect());
function redirect() {
  var anchor = window.location.hash;
  window.self.location = redirecturl + anchor;
}
If you suspend disbelief, this code seems to:
add a load event listener to the first  in the document
call the redirect function when that load event fires
But  elements don’t fire a load event
Except for a special few, like , 
The bootstrap creates a dumb version of the window.dataLayer variable, which is just a JavaScript array. This version doesn’t do anything but store events for the real GTM library to process when it’s ready.[1] It’s incapable of running callbacks or timing out. Basically, it sits there waiting for gtm.js.
Not all ad blockers block the core gtm.js library: as of this writing, AdBlock Plus doesn’t block it, but uBlock Origin and Ghostery do.[2] When they do block www.googletagmanager.com,  you’ll never see Data Layer Events (that’s the intent of blocking it, after all). But this section of the uBlock Origin extension code shows how they keep things otherwise running: 
    const dl = w.dataLayer;
    if ( dl instanceof Object ) {
        if ( dl.hide instanceof Object && typeof dl.hide.end === 'function' ) {
            dl.hide.end();
            dl.hide.end = ()=>{};
        }
        if ( typeof dl.push === 'function' ) {
            const doCallback = function(item) {
                if ( item instanceof Object === false ) { return; }
                if ( typeof item.eventCallback !== 'function' ) { return; }
                setTimeout(item.eventCallback, 1);
                item.eventCallback = ()=>{};
            };
            dl.push = new Proxy(dl.push, {
                apply: function(target, thisArg, args) {
                    doCallback(args[0]);
                    return Reflect.apply(target, thisArg, args);
                }
            });
            if ( Array.isArray(dl) ) {
                const q = dl.slice();
                for ( const item of q ) {
                    doCallback(item);
                }
            }
        }
    }
They check whether the “dumb” version of window.dataLayer exists — that is, whether you included the GTM bootstrap. If so, using a JavaScript Proxy, they substitute a more capable “callback only” version that just runs any eventCallback after a millisecond. Pretty cool, I think!
Notes
[1] window.dataLayer.push() works immediately after the bootstrap code, even though gtm.js isn’t loaded yet, because you’re calling native Array.prototype.push! gtm.js eventually replaces window.dataLayer with another array whose push property is overwritten with a custom function.
[2] Ghostery uses uBlock Origin’s open source code internally, so not surprising.  


 Check out my colleague Jo Pitts’s blog, too 
Sanford Whiteman — Wed, 19 Nov 2025 00:44:53 -0500
 You may already know Jo Pitts — a fellow moderator on the official Adobe Marketo community, member of the usual 3rd-party channels, and longtime collaborator with yours truly.
Jo’s in my Martech Developers I Trust Implicitly group chat (along with Joe Fusaro @ Datachef and Todd Sprinkel @ Sponge*) and after a hiatus, he just started blogging again. The kickoff post is on the Deleted Leads API endpoint. Check it out and subscribe here.  

* If you want your name dropped, we’ve gotta at least have monthly catchups.😛
 


 Using a Marketo form to register people in a Teams webinar (via FlowBoost) 
Sanford Whiteman — Fri, 31 Oct 2025 03:51:25 -0400
 Like many of you, I try to avoid the Teams ecosystem (though I’m a Windows guy in every other way). But Teams webinars are so easy to set up — Calendar » New » Webinar — that inevitably someone’ll ask if you can use Marketo to register people.
Indeed you can. There’s no Marketo connector comparable to Zoom and ON24, but if all you want to do is add registrants to a Marketo program (via a Marketo form or any other way) and push the registration to Teams, it’s very easy with a FlowBoost webhook.
⚠️ FlowBoost Standard required (sorry)
The vast majority of FlowBoost users are on the free Community plan, since they make < 50,000 calls per month and don’t need the few extra features offered by Standard.
Every other post on FlowBoost, give or take, works with Community. But this one’s connecting to a non-Marketo service, which requires Standard.[1] We’re grateful to the core group of Standard users that help us keep the lights on and hope you’ll join them if your org needs this functionality. Reach out for a Standard trial key.😀
And now, on to the code.
Teams Tenant ID and Event ID are all you need
A Microsoft subscription has a single Tenant ID shared across all users. Each webinar has its own Event ID. You can get both of those from the Teams-hosted Event URL, which follows this structure:
https://events.teams.microsoft.com/event/{{Microsoft Teams Event ID}}@{{Microsoft Teams Tenant ID}}
We won’t be sharing that URL for registration, obviously, but we need it to grab the IDs:
Once you copy those out (remember, it’s event@tenant) put the Tenant ID in a global token {{my.Microsoft Teams Tenant ID}}. Drop the Event ID into a program-level {{my.Microsoft Teams Event ID}} for each webinar.
Then set up this FlowBoost webhook and call it from a trigger campaign in any program:
const eventId = {{my.Microsoft Teams Event ID}};
const tenantId = {{my.Microsoft Teams Tenant ID}};

const email = {{lead.Email Address}};
const firstName = {{lead.First Name}} || "[Not Provided]";
const lastName = {{lead.Last Name}} || "[Not Provided]";
const ianaTimeZone = {{lead.Person Time Zone}} || "America/New_York";
const language = {{lead.Preferred Language}} || "en-US";

const getTokenURL = () =>
  `https://authsvc.teams.microsoft.com/v1.0/authz/visitor`;
const getRegisterURL = (eventId, tenantId) =>
  `https://teams.microsoft.com/api/virtualevents/prod/events/${encodeURIComponent(eventId)}@${encodeURIComponent(tenantId)}/attendee/register`;

const CONTENT_TYPE_JSON = { "content-type": "application/json" };

FBHttp.fetch(getTokenURL(), {
  method: "POST",
  headers : { ...CONTENT_TYPE_JSON },
  body: JSON.stringify({
      tenantId
    })
  })
  .then((tokenRespJ) => tokenRespJ.json())
  .then((tokenResp) => {

    return FBHttp.fetch(getRegisterURL(eventId, tenantId), {
      method: "POST",
      headers : { "x-skypetoken": tokenResp.tokens.skypeToken, ...CONTENT_TYPE_JSON },
      body: JSON.stringify({
        firstName,
        lastName,
        email,
        language,
        timeZoneDetails: {
          ianaTimeZone
        },
        answers: [],
        hasAcceptedTermsOfUse: null
      })
    })
    .then((registerRespJ) => registerRespJ.json())
    .then(success)
  })
  .catch(failure)
It’s really simple:
(1) get the rather nostalgically named x-skypetoken from the Teams auth endpoint
(2) pass the x-skypetoken together with lead fields to the Teams register endpoint
The person is immediately registered and Teams will send them a confirmation email and all follow-up emails.
The code assumes you have a person field for {{lead.Preferred Language}}. If not, hard-code your default corporate language. Or have a {{my.token}} if language varies at the webinar level, it’s up to you!
It’s a unidirectional, registration-time sync
With these endpoints, it’s impossible to get a joinWebUrl in the webhook response (Microsoft doesn’t provision it until after the registration.) So emails must still be sent via Teams as usual. 
Like I said, it’s no match for the Zoom and ON24 connectors, but it lets you present a nicely branded Marketo LP + form and work directly with Marketo program membership. You’re in control of registration, so you can also use FBCounter to limit registrants — that’ll mesh together nicely with the back end.
If you’re on very good terms with IT, we can go further    
There is a way to fetch joinWebUrl using the Graph API, getting you closer to an all-Marketo solution. However, coordinating Graph API tenant permissions with your IT team could be hairy. For FlowBoost Standard users, I’m happy to try to get that worked out with IT, after which I’ll provide the updated code, but can’t guarantee they’ll go for it.
Notes
[1] FlowBoost Community keys can only connect to Marketo APIs and assets. (Technically, Community can connect to any Marketo instance, not just the one calling the webhook.) Standard is required to hit SFDC, Teams, or other remote APIs. 


 Using the SFDC Type in Dynamic Chat audience criteria 
Sanford Whiteman — Wed, 29 Oct 2025 17:09:30 -0400
 Popping up different Dynamic Chat dialogues for known SFDC Contacts vs. SFDC Leads is a basic ask. It’s a smidge trickier than you might expect, though, for 2 reasons:
(1) you can’t sync SFDC Type from Marketo to the DC database
(2) you can’t sync SFDC Is Deleted, another key component
Don’t worry, it’s still easy. 
Mirror SFDC Is Deleted
Create a custom Boolean field SFDC Is Deleted Mirror. Keep that field updated with a simple trigger campaign:
Sync SFDC Contact ID, SFDC Lead ID, and the new mirror field
With the mirror field in hand, you have everything you need to reproduce SFDC Type in Dynamic Chat:
Build your audience criteria
Now you can match SFDC Contacts:
And SFDC Leads:
Not too intimidating, right? 


 Using native HTML ˂dialog˃ for modal Marketo forms instead of legacy lightbox() 
Sanford Whiteman — Tue, 28 Oct 2025 01:52:08 -0400
 The Forms 2.0 lightbox() method is fully functional, but commonly misused.[1] I’ve had a post in my drafts for ages — “Tips for a smoother lightbox() experience” — but in the meantime lightbox() has become unnecessary because all modern browsers support 
.
IMO, the coolest things about 
 are:
built-in responsiveness: desktop and mobile browsers automatically position the modal correctly
native controls: the Escape key and back-swipe both close the dialog
easier markup and styling: no need for extra s and z-index juggling, just style ::backdrop and ::backdrop-filter
Secondarily, 
 minimizes the need for JavaScript. The JS in this post is only necessary because Safari doesn’t support Invoker Commands yet. In Chrome and Firefox, you can close and open the modal using HTML alone, no extra JS!
Here’s a modal Marketo form inside a 
:
The markup is amazingly simple, just put the standard form embed inside a 
 and add a close 
Then anywhere else on the page, add a 
The above works without JS in Chrome/Edge/Firefox, including Android versions. Gotta support Safari too, though. This bit of code maps commandfor and command attributes to corresponding JS methods:
/* only required in Safari (a/o 2025-10-26) */
if( typeof CommandEvent !== "function" ) {
  MktoForms2.whenReady(function(readyForm){
  
    const formEl = readyForm.getFormElem()[0];
    const dialog = formEl.closest("dialog");
  
    if( dialog ) {
      const invokers = document.querySelectorAll(`button[commandfor="${CSS.escape(dialog.id)}"]`);
      invokers.forEach( (invoker) => {
        switch(invoker.getAttribute("command")){
          case "show-modal":
            invoker.onclick = () => dialog.showModal();
            break;
          case "close":
            invoker.onclick = () => dialog.close();
            break;
        }
      });
    }
  });
}
Note 
 on its own is supported on Safari, it’s the JS-less Invoker Commands that aren’t there yet. 
Notes
[1] The common lightbox() mistake is not rendering the form until the modal is opened — in extreme cases, not even loading forms2.min.js until it’s opened! This adds a user-facing delay. You should instead render the form immediately, hiding it using CSS, and show it when the lightbox is open:
.mktoForm {
   visibility: hidden;
   position: absolute;
}
.mktoModal .mktoForm {
   visibility: visible;
   position: static;
}
But lightbox() should really be considered obsolete.
[2] My only frustration with 
 is its lack of an automatically rendered close button. In the screenshot above, the 

 Microsoft “New Outlook” strictly enforces RFC 5545, potentially breaking ICS file generators (though not Marketo’s) 
Sanford Whiteman — Mon, 20 Oct 2025 01:35:52 -0400
 Violating the old Never Rewrite From Scratch rule (which, let’s be honest, is sporadically enforced) Microsoft created New Outlook in 2023. So far, it’s been a rocky rollout, with scant rewards for end users and mixed results for MOps.
On the bright side, email designers like the new rendering engine. You still need fallbacks for Classic Outlook, but more and more Microsoft shops will see your special effects. On the other side, the death of OFTs is pretty bad, but at least that’s a clean break.
More insidious are features ported over from Classic, but subtly “fixed” in a non-backward-compatible way. Case in point: Microsoft decided to rewrite their iCalendar (ICS) parser. The new parser hews so tightly to the standard, RFC 5545, that previously supported ICS files now don’t show the Location field:
The specific area Microsoft fixed was the order of VEVENT properties and VALARM reminders. The standard is unequivocal here. A valid VEVENT must have its eventprop entries (DTSTAMP, ORGANIZER, SUMMARY, LOCATION, etc.) before any alarmc components (VALARM):
   Format Definition:  A "VEVENT" calendar component is defined by the
      following notation:

       eventc     = "BEGIN" ":" "VEVENT" CRLF
                    eventprop *alarmc
                    "END" ":" "VEVENT" CRLF
In other words, this ICS file is invalid since you can see the VALARM is above the LOCATION property:
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20251016T041331Z
UID:20251016T041331Z-1266201208@ics.agical.io
DTSTART:20251112T190000Z
DTEND:20251112T230000Z
ORGANIZER:
SUMMARY:Logi Work Montréal
DESCRIPTION:Logi Work Montréal
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Alarm: Logi Work Montréal
ACTION:DISPLAY
END:VALARM
LOCATION:Maison Alcan, 2100 Stanley Street
END:VEVENT
END:VCALENDAR
The correct order is like so:
BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN
CALSCALE:GREGORIAN
BEGIN:VEVENT
DTSTAMP:20251016T041331Z
UID:20251016T041331Z-1266201208@ics.agical.io
DTSTART:20251112T190000Z
DTEND:20251112T230000Z
ORGANIZER:
SUMMARY:Logi Work Montréal
DESCRIPTION:Logi Work Montréal
LOCATION:Maison Alcan, 2100 Stanley Street
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Alarm: Logi Work Montréal
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR
Nevertheless, Outlook used to be fine with this. In fact, I can’t find a single ICS validator or library as strict as New Outlook! 
From “reference libraries” like Libical, ical.js and ical4j to apparently homebrewed validators at iCalendar.org and CorrectICS, none care that VALARM is supposed to be after all the properties.[1]  They should care, as they would’ve flagged bad files long ago, but since every major calendar app prior to New Outlook was permissive, there was little pressure from their communities.
The good news
Marketo’s own Calendar {{my.tokens}} are unaffected — they don’t support reminders at all, so there’s nothing to be out of order. The Agical.io ICS generator has been patched as well. I’ve also checked files generated by Zoom and On24 and they’re fine.
Your next step
If you generate ICS files via 3rd-party apps/libraries or internal code, thoroughly test in New Outlook.
Notes
[1] Google Calendar also doesn’t care about the order when importing. They likely use ical4j under the hood. 


 Returning false from an onSubmit() listener doesn’t stop submission — or do anything at all! 
Sanford Whiteman — Fri, 17 Oct 2025 02:46:27 -0400
 A user had buggy 3rd-party JS causing forms to be submitted 2x. Unable to find the root cause in their stack of plugins, they tried a desperate fix: add an onSubmit() listener and stop submission if the listener runs a second time. 
Like so:
MktoForms2.whenReady(function(readyForm){
   let stopFutureSubmissions = false;
   
   readyForm.onSubmit(function(submittingForm){
      if(stopFutureSubmissions) {
         return false;         
      }
      
      stopFutureSubmissions = true;
   });
                      
});
Fine idea in theory, but that’s not how you stop form submission. The Marketo onSubmit() listener stack doesn’t care if you return false from every single listener! That is, it’s not like DOM event handlers where return false is interpreted as canceling the event.[1]
To stop submission, assuming you have complete control over the listener stack, simply set form.submittable(false):
MktoForms2.whenReady(function(readyForm){
   
   readyForm.onSubmit(function(submittingForm){
      submittingForm.submittable(false);
   });
                      
});
(If something is trying to submit the form multiple times, you’ve still gotta fix that at the source. This hack is a “leave in place for a week, seek outside help if you can’t find the cause” type thing.)
Notes
[1] Not only is the Forms 2.0 API a custom API, even native addEventListener() doesn’t care about return false. Only the primitive element.onsubmit = someFunction method gives return false special meaning.  


 A bunch of “Unsubscribe Email” activities for different emails, 5 minutes apart? That’s Gmail’s Manage Subscriptions feature 
Sanford Whiteman — Wed, 01 Oct 2025 22:54:00 -0400
 You see a series of Unsubscribe Email activities, roughly 5 minutes apart, covering more or less all the emails someone received:
Each one’s Details show they used the List-Unsubscribe header:
Turns out that’s standard behavior of the newish Manage Subscriptions feature in consumer Gmail.
When you go to Manage Subscriptions, Gmail shows you addresses that’ve sent enough marketing email to be trusted, which it then considers a “Subscription”:
Clicking on a Subscription shows emails from that sender that are still in your mailbox:
If you click Unsubscribe on the Subscriptions tab, Gmail visits all the List-Unsubscribe URLs in sequence, waiting 5 minutes between URLs to ensure it doesn’t exceed rate limits. This is mentioned, in a dumbed-down way, in the docs:
Since every Marketo email has a unique List-Unsubscribe header — if it didn’t, we couldn’t track Unsubscribe Email at the asset level! — all emails are individually unsubscribed. This can mess with reporting, so look out for it.
Note neither side is misbehaving, although it does suggest a new SMTP header like List-Unsubscribe-All would be useful. (Good luck getting that through standards committees!)     


 A crazy way custom forms JS can cause “Submission failed,” with “checksum invalid” in the details 
Sanford Whiteman — Tue, 30 Sep 2025 01:27:50 -0400
 You might think I’ve contrived a situation with an infinitesimal chance of happening in real life, just for the love of blogging. But this just happened to a user who posted on the Nation!  
So here’s the weirdest Marketo Forms factoid you may ever learn: if the 20th field added to a form has an empty name, you’ll get this generic error on submit:
And inspecting the HTTP 400 response shows:
{
  "message" : "checksum invalid",
  "error" : true,
  "errorCode" : "400"
}
Hold on, a form field can have an empty name???
Well, no. An  and  are both prohibited by the HTML standard. A native HTML 
 submit will not send values for those inputs.
But while Marketo forms use standard HTML  elements — a very good thing, I always take care to say! — the data that goes on the wire is assembled using JS. (Most modern forms do this.)
The Forms 2.0 API lets you add a hidden field with an empty name:
MktoForms2.whenReady(function(readyForm){
  readyForm.addHiddenFields({
    "" : "abc"
  });
});
And that field will be sent to Marketo. Note empty query param names are allowed by the URL standard, so this is a perfectly legit x-www-form-urlencoded payload:
field1=value1&field2=value2&=abc
Again, a native, i.e. JS-less,  can’t create the above payload, but a JS-powered form can and the payload itself is legit, standards-wise. (Whether a given server parses it successfully is another question![2])
Only custom JS can create an empty name
You can’t have fields in Marketo whose Form Field Name is an empty string, so Form Editor will never trip you up like this. And deliberately adding a hidden form field with the name "" would obviously be bizarre, since it would never store anything in Marketo. 
Here’s the way an empty-named field got created without anyone knowingly doing so.
There’s 3rd-party UTM tracking JS on the site. That JS has a section where you’re supposed to map well-known UTM fields to business-specific Marketo Form Field Names: 
const queryParamToFieldMap = {
  "utm_medium" : "utm_medium__c",
  "utm_campaign" : "utm_campaign_latest__c",
  "utm_source" : "utm_source_real__c"
};
And then later in the code, that map is referenced to add hidden fields:
MktoForms2.whenReady(function(readyForm){
  readyForm.addHiddenFields({
    [queryParamToFieldMap.utm_medium] : stored.utm_medium,
    [queryParamToFieldMap.utm_campaign] : stored.utm_campaign,
    [queryParamToFieldMap.utm_source] : stored.utm_source
  });
});
But when the user set up their field map, they didn’t realize they’d literally set one field name to the empty string:
const queryParamToFieldMap = {
  "utm_medium" : "utm_medium__c",
  "utm_campaign" : "utm_campaign_latest__c",
  "utm_source" : ""
};
That is, the code doesn’t set the name to the default when it sees the "" or anything like that, it just uses "" as entered.
The dynamic object key [queryParamToFieldMap.utm_source] is thus the empty string, so they inadvertently did the same as this:
MktoForms2.whenReady(function(readyForm){
  readyForm.addHiddenFields({
    "utm_medium__c" : "email",
    "utm_campaign_latest__c" : "2025-09-25-US-Quad-Complex",
    "" : "abc"
  });
});
Now we know how you can get such a field on your form. Not so weird really. The weird part happens next.
Field #20 with an empty name is special
You’re about to join a tiny club. Until last week even I didn’t know about this, and because it depends on a “perfect storm” of bad JS + bad luck, doubt anyone else knew.
To be clear, this isn’t a bug in Marketo Forms. As detailed above, your custom JS must have a bug that lets it add an empty-named field. Since such a field could never exist on the Marketo server side, you definitely screwed up first.😛 (Might be nice if addHiddenFields ignored empty names, but that’d be a belt-and-suspenders thing.)
Here we go.
Marketo form posts automatically include fields named checksum and checksumFields as a protective measure.[1] checksum is a SHA-256 hash of the values of the first 20 fields, joined by | characters. checksumFields is a comma-delimited list of the first 20 field names.
On the server side, checksum verification is easy: split checksumFields to get the names of fields used in the hash; get the values for those names and join with |; SHA-256 the |-delimited string; compare with the hash in checksum.
All good in normal use. But a trailing comma in checksumFields messes it up. It shouldn’t be possible to have a trailing comma, because it shouldn’t be possible to have an empty 20th field name! But indeed, when you have buggy JS, you can end up with:
checksumFields=f1,f2,f3,f4,f5,f6,f7,f8,f9,fA,fB,fC,fD,fE,fF,fG,fH,fI,fJ,
That gets split into 19 field names (f1 through fJ), rather than 20. But the checksum was a SHA-256 of all 20 fields. Therefore the server-side and client-side hashes don’t match: "message" : "checksum invalid".
Yep, multiple things have to go wrong at once
There was code that could potentially add the field "" and the end user did the thing that made "" get added and that field was the 20th field added to the form.
Not sure what the takeaway should be but this was a nightmare to debug!
Notes
[1] Other libraries use checksums/hashes to ensure data integrity (i.e. to detect bit errors) but Forms 2.0 uses checksums chiefly to discard “dumb” form posts, either from sources like 3rd-party webhooks or malicious bots that can’t do SHA-256. Presumably only the first 20 fields are digested to protect server resources; if you were aiming for data integrity, you’d digest all the fields and send the hash in Content-Digest.
[2] PHP’s native parse_str query string parser ignores query params with empty names. JS’s URLSearchParams parses them correctly. Your favorite package/framework/engine may or may not understand them. 


 Every Marketo field has a Friendly name, a Token name, a Form Field name, a REST API name, a SOAP API name, and a Velocity name — and they may all be different 
Sanford Whiteman — Wed, 24 Sep 2025 01:45:11 -0400
 Feels weird to be writing about this at such a late date, but there’s misinformation going around, perhaps AI-influenced.
The spur for this post was the erroneous claim that Marketo Forms 2.0 uses REST API names as Form Field names. That is, if the REST API name is email the corresponding form field is . 
That’s clearly untrue, as you can see by inspecting the HTML of a basic form:   
*
Email Address:
" loading="lazy" width="1080" height="570" srcset="https://blog.teknkl.com/content/images/size/w600/2025/09/image-20.png 600w, https://blog.teknkl.com/content/images/size/w1000/2025/09/image-20.png 1000w, https://blog.teknkl.com/content/images/2025/09/image-20.png 1080w" sizes="(min-width: 720px) 720px">
But even the response I gave on the Nation — No, it uses the SOAP API name — isn’t true 100.00% of the time. Don’t get me wrong: it’s true enough to get you through 99.99% of scenarios, and infinitely true-er than the false claim about the REST API name. It’s certainly true for the system field that holds the lead’s email address, i.e. the one with the default Friendly Name Email.
💡
Knowing all the different names a field can have makes it harder to refer to fields, right? We usually choose the Friendly Name, even if that one can change over time!
The truly-true statement is “Marketo uses the Form Field Name as the Form Field Name.” The tautology illustrates that it’s possible for the  attribute to be completely decoupled from any other metadata about the field.
So how many names can a field have?
Each field has 6 possible names, each for a different context:
the Friendly Name, used in Field Management and in (most) dropdown lists
the Token Name, used to output field values in Emails, LPs, webhooks, or flow steps
the Form Field Name, used as the name attribute on form elements 
the REST API Name, used in the modern REST API
the SOAP API Name, used in the defunct SOAP API
the Velocity Name, used when you pull the field into the Velocity context (i.e. check the field in Script Editor)
💡
Honorable mention goes to List Import Aliases, which allow CSVs to use different header fields if your sources can’t get their act together.😛 We’ll ignore those for now.
Some of those names may be identical for a given field. For example, the built-in Email field has:
Friendly Name Email
Token Name Email Address (i.e. {{lead.Email Address}})
REST API Name email
Form Field Name Email
SOAP API Name Email
Velocity name Email (i.e. $lead.Email)
So there are only 3 unique values across the different types. But sorry to say, you must consider that a coincidence. As noted above, it’s not 100.00% safe to assume the Form Field Name is the SOAP API Name.
Check out this interesting exception, the built-in (and, to be fair, largely unused) field with the Friendly Name Marketo Data.com ID:
Friendly Name Marketo Data.com ID
Token Name Jigsaw Contact ID ({{lead.Jigsaw Contact ID}})
REST API Name jigsawContactId
Form Field Name JigsawContactId
SOAP API Name Marketo Jigsaw Contact Id
Velocity Name: Marketo Jigsaw Contact Id ($lead["Marketo Jigsaw Contact Id"])
Not only does this field have 5 unique values, the Velocity Name is notable because when you drag the field from the tree in Script Editor, Marketo inserts ${lead.Marketo Jigsaw Contact Id}. This is actually invalid VTL because spaces aren’t allowed in dot-property format, just like in JavaScript. You’ll get a ParseException if you leave it like that.[1]
Also notable: the SOAP API Name has spaces. That means the SOAP API Name and Form Field Name must be different. Not that an HTML  can’t have spaces, standards-wise — it certainly can — but an HTML  can’t have spaces and Forms 2.0 uses the same value for name and id. (This is good, by the way.)
Don’t be scared, just treat each one separately
This isn’t a big deal, really. Just give up your assumptions about the connection between names.
When you use the token browser, Marketo always inserts the right Token Name. Don’t copy-and-paste the Friendly Name.
Inspecting the HTML  or running getValues() shows the Form Field Name. Don’t copy-and-paste the SOAP API Name. (Or go ahead and paste it because it’s the same 99.99% of the time, but check there first if anything goes wrong!)
When you drag the field onto the Script Editor canvas, Marketo always inserts the right Velocity Name.
The REST API Name is easy to get from Field Management or the Describe Lead API endpoint. Don’t assume it’s the same as the Friendly Name, even if the Friendly Name has an API-compatible format (no spaces or non-ASCII characters).
Notes
[1] Instead, you need to change it to $lead["Marketo Jigsaw Contact Id"] or $lead.get("Marketo Jigsaw Contact Id"). 


 A global trigger campaign to alert on interesting Program Status changes, with the new Status included in the alert 
Sanford Whiteman — Tue, 23 Sep 2025 14:06:00 -0400
 Marketo recently added a bunch of new {{trigger.tokens}} that can help reduce the number of nearly-redundant trigger campaigns, always a good thing.
Some of the tokens are relatively “raw,” though: they output unique IDs, not friendly names. Massaging those into values suitable for people like sales owners takes a little work.
Going global to avoid local bloat
We had a request the other day for alerts on Program Status is Changed, where the New Status is in a list of interesting statuses and the program is any program in the instance. The alert email also has to include the new status.
Such a campaign can of course be added at the program level:
trigger on Program Status is Changed
constrain on Program [is] , New Status [is] 
include {{member.status}} in the email
The problem is you’d have to do this for every program, forever. Nobody wants that.
Instead, we wanted a single global campaign triggering on Program Status is Changed, Program [is any]:
The goal, then, is to figure out how to get the equivalent of {{member.status}}, since our campaign lives outside the triggering program(s).
Aha! One new token is {{trigger.New Status ID}}, a token that’s available in a Program Status is Changed flow. Sounds perfect, right? But the catch is {{trigger.New Status ID}} returns the unique numeric identifier of the status, not its name. And sales doesn’t understand Program Status 113 or Program Status 221!
Start thinking about Velocity maps 
One ultra-powerful use for Velocity is to map unfriendly names/IDs to friendly names, like so:
#set( $statusNameMap = {
  10  : "Advertising > Filled Form",
  56  : "Advertising > Downloaded",
  224 : "Advertising > Downloaded High-Value Asset",
  168 : "Content > Downloaded",
  221 : "Content > Downloaded High-Value Asset",
  90  : "Content Syndication (PPL) > Downloaded",
  225 : "Content Syndication (PPL) > Downloaded High-Value Asset",
  226 : "Content Syndication (PPL) > Filled Form",
  4   : "Webinar > Registered",
  6   : "Webinar > Attended",
  7   : "Webinar > On-Demand",
  210 : "Website > Filled Form",
  211 : "Website > Downloaded", 
  231 : "Website > Downloaded High-Value Content"
} )
(Some call these as “lookup tables” but I prefer to call them “maps,” since they’re literally Java LinkedHashMaps.)
If we had such a map, we could grab the friendly name with $statusNameMap.get($programStatusId).
There’s no official way to get the Program Status ID that currently[1] corresponds to a given Program Status Name. You can’t get it via the REST API and there isn’t a formal export feature. But you can use Dev Tools to get it from the Marketo UI.[2] Right-click and inspect the  for the Program Status Name:
Then look in the HTML for the adjacent . Its value attribute is the Program Status ID.
OK, great! Now we can build that ID ⮕ Name map in a Velocity token {{my.Program Status Name Map}}. But there’s one more hurdle.
{{trigger.tokens}} aren’t automatically accessible in Velocity
So we have $statusNameMap ready to go. But how do we look up our {{trigger.New Status ID}} in the map, since {{trigger.tokens}} aren’t present in the Velocity context?
Well, they’re actually present, but they’re tricky to get to. Each one is a property of the Velocity $trigger object, but:
it’s converted to upper case
spaces are converted to underscores
it’s prefixed with v
it’s suffixed with _ and an unpredictable number
For example, {{trigger.New Status ID}} can be $trigger.vNEW_STATUS_ID_99 in Velocity. But the 99 can’t be known in advance.
Not to worry. We can’t directly get("vNEW_STATUS_ID_") because we don’t know the suffix, but we can loop over $trigger until a key matches our prefix. 
That happens in the Velocity token {{my.Get Program Status Name}}:
#foreach( $entry in $trigger.entrySet() )
#set( $key = $entry.getKey() )
#set( $value = $entry.getValue() )
#if( $key.startsWith("vNEW_STATUS_ID_") && !$display.alt($value,"").isEmpty() )
#set( $newProgramStatusId = $convert.toInteger($value) )
#break
#end
#end
#set( $newProgramStatusName = $statusNameMap.get($newProgramStatusId) )
The final piece is the one-line Velocity token {{my.New Program Status Name}} to output the value (remember, best practice is separate “calculating” and “output” tokens):
${newProgramStatusName}
Wait, one more thing
The {{trigger.token}} must be used in the email to be accessible in Velocity. Sounds like a Catch-22, but you can drop it inside an HTML comment![3]
Sample alert email
Subject: One of your contacts just had an interesting Program Status Change!
{{my.Program Status Name Map}}{{my.Get Program Status Name}}
Name: {{lead.Full Name}}
Email: {{lead.Email Address}}
Company: {{company.Company Name}}
Title: {{lead.Job Title}}
Phone: {{lead.Phone Number}}
Program Name: {{trigger.name}}
New Program Status: {{my.New Program Status Name}} ({{trigger.New Status ID}})
Salesforce Record Link: https://exampleco.my.salesforce.com/{{lead.SFDC Id}}
The “map” token {{my.Program Status Name Map}} and “calculate” token {{my.Get Program Status Name}} must be included somewhere before the “output” token {{my.New Program Status Name}}.
Notes
[1] Yes, it’s technically possible for the name to change (that’s why the Program Status ID exists). And of course new statuses may be added. You’ll have to modify the $statusNameMap if there’s a relevant change to Admin » Tags » Channels. 
[2] Alternately, look at the POST response for https://app-.marketo.com/marketingEvent/getDescriptorValue. This is left as an exercise for the reader.
[3] Or between two partial Velocity tokens (#* and *#) to wrap it in a block comment. This has the advantage of removing it completely from the rendered email, both HTML and Text versions. 


 Flip a Marketo form field between “Required” and “Not Required” at runtime 
Sanford Whiteman — Thu, 18 Sep 2025 22:27:00 -0400
 Native Visibility Rules and Progressive Profiling pack immense power. But one thing they can’t do is change whether a field is required: if a field is displayed per VR and/or ProgPro rules, it simply picks up the Required setting from Form Editor.
This means you need JS for more advanced behaviors. Say Country should be optional for Home users: 
Country and Company are required for Professional and Enterprise. while Number of Employees is displayed (via native VRs) but optional for Professional:
And finally, Enterprise users must provide Country, Company and Number of Employees:
Enter manageFieldRequirement()
Here’s a little JS function that lets you achieve such special effects:
/**
 * Programmatically require/unrequire a Marketo form field
 * @author Sanford Whiteman
 * @version v1.2 2025-08-25
 * @license Hippocratic 3.0: This license must appear with all reproductions of this software.
 *
 */
function manageFieldRequirement(mktoForm, fieldName, userOptions = {}){    
  const defaultOptions = {
    require: false,
    alsoFlipVisibility: false,
    validationMessage: undefined
  };

  const options = Object.assign(defaultOptions, userOptions);

  const formJq = mktoForm.getFormElem();
  const fieldJq = formJq.find(`[name="${CSS.escape(fieldName)}"]`);

  if(!fieldJq.length) {
    return;
  }

  const rowJq = fieldJq.closest(".mktoFormRow");
  const colJq = fieldJq.closest(".mktoFormCol");
 
  const rowColCount = rowJq.find(".mktoFormCol").length; 
  const flippableJq = rowColCount === 1 ? rowJq : colJq;  
  
  const wrapperJq = fieldJq.closest(".mktoFieldWrap");
  const descriptorJq = fieldJq.closest(".mktoFieldDescriptor");

  if(options.require){
    fieldJq.attr("aria-required","true");
    fieldJq.addClass("mktoRequired");
    wrapperJq.addClass("mktoRequiredField");
    descriptorJq.data("mktoFieldDescriptor").required = true;

    if(options.alsoFlipVisibility){
      flippableJq.show();
    }    
  } else {
    fieldJq.removeAttr("aria-required");
    fieldJq.removeClass("mktoRequired");
    wrapperJq.removeClass("mktoRequiredField");
    descriptorJq.data("mktoFieldDescriptor").required = false;

    if(options.alsoFlipVisibility){
      flippableJq.hide();
    }    
  }
  
  if(options.validationMessage){
    descriptorJq.data("mktoFieldDescriptor").validationMessage = options.validationMessage;
  }    
  
}
(With platform features these days, you don’t need jQuery to manipulate the DOM. But here we specifically need jQuery data, so decided to embrace the beast.)
Usage
manageFieldRequirement() takes 3 params:

mktoForm - a Marketo Forms 2.0 form object, e.g. the argument passed to a whenReady()  listener
fieldName - the form field name, a.k.a. SOAP API name
userOptions - an object with a few properties:

require (Boolean, default false) - require the field or un-require it
alsoFlipVisibility (Boolean, default false) - also show the field if required/hide if unrequired
validationMessage (String, optional) - custom validation message to swap in



Example: Get the behavior shown in the screenshots above
Inside a Forms 2.0 whenReady() listener, add a DOM change listener. Then do advanced management of Country and Company fields:
MktoForms2.whenReady(function(readyForm){
  const formEl = readyForm.getFormElem()[0];
  
  formEl.addEventListener("change",function(e){
    const currentValues = readyForm.getValues();
    const requestedSubscriptionType = currentValues["SubscriptionType"];
    
    if( !requestedSubscriptionType || requestedSubscriptionType === "Home" ) {
      manageFieldRequirement(readyForm, "Country", { require: false });    
      manageFieldRequirement(readyForm, "Company", { require: false });    
    } else {
      manageFieldRequirement(readyForm, "Country", { require: true, validationMessage: "Please provide Country for Pro and Enterprise accounts." });
      manageFieldRequirement(readyForm, "Company", { require: true, validationMessage: "Company is required for Pro and Enterprise accounts." });
    }

    if( !requestedSubscriptionType || requestedSubscriptionType === "Home" || requestedSubscriptionType === "Professional" ) {
      manageFieldRequirement(readyForm, "NumberOfEmployees", { require: false });    
    } else {
      manageFieldRequirement(readyForm, "NumberOfEmployees", { require: true, validationMessage: "Number of employees is required for Enterprise accounts." });
    }

  });
  
  // initialize state
  formEl.dispatchEvent(new Event("change"));
  
});
N.B. The change listener works even when Visibility Rules are also managing the field because new HTML element(s) are injected synchronously by the VR code, before the event bubbles up to the . This is good! 


 NYC MUG in-person talk and meetup: Thursday, 9/25 
Sanford Whiteman — Thu, 18 Sep 2025 22:26:43 -0400
 We’re recommitting to in-person meetups for late 2025 and 2026. First up: Thursday, September 25th from 3-4pm at Adobe’s Union Square office (100 Fifth Avenue).
Webflow’s Guy Yasif will present The Strategic CMO: Driving Personalization and Performance with Marketo and AI-Powered GTM. Just as important, I’ll be around afterward to chat about whatever you like.😀
RSVP here. 


 Extract “Firstname B. Lastname” from “firstname.b.lastname@example.com” using Velocity (with caveats) 
Sanford Whiteman — Sun, 14 Sep 2025 18:15:10 -0400
 Let me start by noting this technique is for addresses @ your email domain, not for lead email addresses. If you forgot to require First Name and Last Name on a lead gen form, complete their profile responsibly. That’s not what this is for!
Sometimes, due to technical gaps, you only have the email address of a sales owner or other internal user, but you need a friendly name for the From: header or signature block.
If your company used 100% predictable logic to generate the address, you can (fairly) safely synthesize a friendly name while waiting for CRM to do a proper field mapping.
That logic is:

Given a display name where (1) all characters are valid in an email address and (2) all words are in title case, convert spaces to dots and append the domain.

For example, the name Sandy-Jo B. O'Shelley is converted to the email address sandy-jo.b.o'shelley@example.com. If an address was generated that way, this Velocity code —
#set( $emailField = $lead.YourEmailField )
## break down left-hand-side@right-hand-side
#set( $lhs = $emailField.substring(0,$emailField.lastIndexOf("@")) )
## split the lhs on the dot
#set( $lhsParts = $lhs.split("\.") )
#set( $displayableParts = [] )
#foreach( $part in $lhsParts )
#set( $displayable = "" )
## split on word break, title case each word, re-join
#foreach( $word in $part.split("\b") )
#set( $displayable = $displayable + $display.capitalize($word.toLowerCase() ) )
#end
## assume single letter is initial
#if( $displayable.length().equals(1) )
#set( $displayable = $displayable + "." )
#end
#set( $void = $displayableParts.add($displayable) )
#end
${display.list( $displayableParts, " " )}
— will extract the original name Sandy-Jo B. O'Shelley. 
Caveats
Repeating the warning above, this isn’t for lead email addresses. Please don’t use it for that purpose.
Some mailservers don’t support — or perhaps are believed to not support — ASCII characters like the quote/apostrophe ' in mailbox names, even though that’s a perfectly valid character in the SMTP standard. In those cases the original O’Shelley would map to oshelley in the email address. You cannot possibly know that happened, so the result will be Oshelley.
You can’t know if accents were removed while transforming the result into an ASCII-only value. Leon and Léon will both map to leon.
You can’t know if someone’s name should use mixed case, as de la Cruz and De La Cruz will both map to de.la.cruz. Same for McCardle mapping to mccardle.
All non-Latin-1 characters and/or anglicized names can’t be recovered. That’s why it’s noted above that all characters must be valid in an email address!
In some contexts, a single letter isn’t an “initial” in the western style. So subramanian.m@example.com should be rendered as Subramanian M. The flipside is some two-letter names are properly rendered as initials, like Ma.. You can’t know what’s right just by looking at the email address.
There’s no substitute for knowing the person’s actual display name! 


 Custom Object tip: create a duplicate field if you’ll need to constrain a Date/DateTime to specific ranges 
Sanford Whiteman — Mon, 25 Aug 2025 00:45:24 -0400
 You have a robust multi-subscription model using Marketo Custom Objects: each Subscription+Person combo has robust metadata about when somebody subscribed/unsubscribed, why, and how.
The boss goes, “Can we get a scheduled report of people who subscribed to any newsletter in the past month?” You know just what to do:
Then they throw in “Can we compare that to the 2 prior months?”
You almost say, “Sure” but decide to play around a bit. Then the uh-oh hits you. First, the between operator won’t work because it requires hard-coded dates, and this is to be a dynamic Smart List:
Next, you try to combine in past before and in past (like you would with person fields): 
But that’s got a fatal flaw: each filter may be looking at a different CO record, i.e. a different newsletter!
This Smart List fetches people who: 
(a) have at least one Subscriber record with Subscribed At earlier than 1 month ago
AND
(b) have at least one Subscriber record with a Subscribed At in the past 3 months
This could include people who subscribed to a newsletter within the last month, as long as they subscribed to another newsletter more than a month ago. Filter 1 and Filter 2 aren’t looking at the same record, they’re looking at the whole CO list. Make sense?
Prepare for this
You can prepare your COs for this kind of query by creating another field, also a DateTime, that holds the exact same value:
Then you can use in past before and in past against the same CO record:
 


 You should probably be checking "isTrusted" in postMessage() listeners 
Sanford Whiteman — Fri, 22 Aug 2025 02:37:05 -0400
 window.postMessage and corresponding window.onmessage listeners enable secure communication between cross-origin windows, including IFRAMEs. The postMessage API is ubiquitous, used by popular JS widgets like media players (YouTube, Spotify), meeting schedulers (Calendly), chat popups, and forms[1].
Code in the main window listens for messages from these widgets and relays data to analytics dashboards, MAPs, and so on. To make the “secure” part a reality, it’s standard to check the origin property of every message to ensure it came from a known child window:[2]
window.addEventListener("message", function(e){
  if( e.origin !== "https://video.example.ly" ) return;

  // do lots of special stuff with e.data, like sending a Munchkin
  // "clickLink" event
});
Browsers guarantee the origin of MessageEvents sent via postMessage will be the document.location.origin of the sending window. Can’t get around it: if an IFRAME at https://pages.example.com/some/lp.html uses window.parent.postMessage, the parent will always see the origin value "https://pages.example.com".
But that’s not the only way to send a MessageEvent
I’ve been choosing my words carefully. 😉
All the above is 100% true if you use postMessage. But if you can directly access a window object — as can non-worker code running on the same origin as the target window — you can also do this:
const me = new MessageEvent("message", { 
  origin: "https://video.example.ly",
  data: { whatever: "you want" }
});
window.dispatchEvent(me);
The listening window will see the same origin as when events truly come from the IFRAME. Which means anything the listener typically does with the e.data, you’ve just silently fooled it into doing with your data.
Yikes? Okay, soft yikes. There are factors that limit the severity of this vulnerability, so while it’s something you should fix (and it’s easy!), no need to panic. 
Limiting factors
(1) Malicious code must be able to access the window object that’s listening for messages. An IFRAME on a different site can’t do this, you’ll get:
Blocked a frame with origin "https://malicious.example.net" from accessing a cross-origin frame.
(2) CSP policies may only allow 3rd-party JS once it’s been thoroughly audited. (But let’s be honest, in the marketing world where anyone can drop code into GTM or Tealium, this isn’t happening.)
(3) If code can access the window, countless other attacks can be mounted as well.[3] (Running untrusted code in anything but a cross-origin worker or sandboxed IFRAME is always risky, though roughly everybody does it!)
What distinguishes this vulnerability is its silence: it’s not overwriting functions or intercepting network requests. It’s just quietly penetrating something you thought was a security measure, in a by-design-but-barely-documented way.   
The fix
Check the isTrusted property in addition to origin:
window.addEventListener("message", function(e){
  if( !e.isTrusted || e.origin !== "https://video.example.ly" ) return;

  // do lots of special stuff with e.data, like sending a Munchkin
  // "clickLink" event
});
isTrusted is false for MessageEvents that were manually constructed and dispatched (unlike the MessageEvents automatically constructed by postMessage).
The side effect, by definition, is you can’t roll + send your own MessageEvents anymore. Not sure why that would ever be critical, but I’m open to suggestions in the comments.
Notes
[1] While Marketo forms technically use postMessage under the hood — they submit via a Marketo-hosted IFRAME for reliable transport — they’re pretty off-topic for this discussion. The visible Marketo form is not an IFRAME, it’s in the top-level DOM (which is good!). 
[2] Technically, this code checks for an origin, not for a unique window. You might have more than one window on the same origin, each sending different messages, in which case you’d check the source property too. But source can also be forged in a manually constructed MessageEvent! So there’s no situation where source alone would fix this vulnerability.
[3] Even though code in global scope can be wildly destructive, that doesn’t mean it’d be easy to exploit the same vulnerability that might be opened here, let alone exploit it silently.
For example, imagine the event listener is added in a 
That’ll take care of it.
The code simply copies each standard utm_ param to a corresponding SQF_UTM_. (The original utm_ param is not removed, so it still works in GA/Clicky/etc.)
Because Squarespace injects your custom code before its default field-filling code, it’ll fill the fields like we want.
I know what you’re thinking, but don’t even bother
Yes, my first thought was also “Just wait for the form to render and set the  values using JS.” 
But that won’t work. It would with a vanilla HTML form, but Squarespace insists on re-filling (in addition to pre-filling) the fields from the querystring when the person clicks submit, so your values will be blanked out. There’s probably a convoluted hack using stopImmediatePropagation(), but it’ll never be easier than the code above.
 


 Is an email address that requires encryption (STARTTLS) a “valid email”? It depends 
Sanford Whiteman — Tue, 15 Apr 2025 03:01:10 -0400
 All email validation services fundamentally do the same thing:
look up the domain to see if it has an MX record
if it has one, connect to the MX and pretend they’re about to send an email
quit after sending RCPT TO, before sending a message body
report whether RCPT TO returned 250 OK or not[1]  
They can — okay, since I’ve built such services myself, we can — dress ’em up with “heuristic analysis” and “suspicious domain databases,” but the foundation is the same.     
Here’s the log of a service hitting our corporate server to validate sandy+test-ssloptional@figureone.com:
94.46.244.65    [1DB4] 20:44:55 Connected, local IP=66.165.231.34:25
94.46.244.65    [1DB4] 20:44:55 >>> 220 icewarp.figureone.com ESMTP IceWarp Epos Update 1 build 17; Sun, 13 Apr 2025 20:44:55 -0400
94.46.244.65    [1DB4] 20:44:55 <<< EHLO douglas.email-validator.com
94.46.244.65    [1DB4] 20:44:55 >>> 250-icewarp.figureone.com Hello douglas.email-validator.com [94.46.244.65], pleased to meet you.
                                    250-ENHANCEDSTATUSCODES
                                    250-SIZE
                                    250-EXPN
                                    250-ETRN
                                    250-ATRN
                                    250-CHECKPOINT
                                    250-8BITMIME
                                    250-SMTPUTF8
                                    250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
                                    250-STARTTLS
                                    250-VRFY
                                    250 HELP
94.46.244.65    [1DB4] 20:44:55 <<< MAIL FROM:
94.46.244.65    [1DB4] 20:44:55 >>> 250 2.1.0 ... Sender ok
94.46.244.65    [1DB4] 20:44:55 <<< RCPT TO:
94.46.244.65    [1DB4] 20:44:56 >>> 250 2.1.5 ... Recipient ok
94.46.244.65    [1DB4] 20:44:56 <<< QUIT
94.46.244.65    [1DB4] 20:44:56 >>> 221 2.0.0 icewarp.figureone.com closing connection
94.46.244.65    [1DB4] 20:44:56 ***   1 0 00:00:00 INCOMPLETE-SESSION 
94.46.244.65    [1DB4] 20:44:56 Disconnected
QUIT without DATA logs an INCOMPLETE-SESSION, but no harm, no foul.
The validator is speaking for itself
Technically, the validator is checking whether it could send mail, not whether any other server could send mail.
There’s still a ton of value to 3rd-party validation, don’t get me wrong! But inevitably you get false positives: the validator says “valid,” while a real send from Marketo or another MAP fails. (The bounce message might even be “Recipient email does not exist.” That’s because mailservers are under no obligation to tell presumptive spammers the truth.)
False positives are typically because (a) the recipient’s mailserver doesn’t accept marketing emails, period, or (b) your IP or domain was blocked due to prior offenses.
Far rarer are false negatives, where the validator says “invalid” but if you try sending anyway, the email goes through. But a client recently validated their whole db and noticed some people had Email Delivered that very same day, so they couldn’t be invalid. Right? 
Well, depends on your point of view. Not even sure which side I’m on yet, but felt like pubbing this post and getting people thinking.😛
It’s about STARTTLS, a form of secure SMTP
SMTP is, or was, a notoriously insecure protocol. If you can tap the network between 2 SMTP servers, or between an SMTP client and server, you can eavesdrop on every message passed between them.
That servers reside in secure datacenters, and the pipes between them are run by (umm, generally) good actors, mitigates the risk somewhat. But if you’re on a coffee shop LAN and the shop owner is in the mood, they can read all submissions from a traditional email client using ol’ school SMTP.[2]
Enter secure SMTP, which comes in 2 flavors:
SMTPS, also known as implicit TLS, which is always encrypted and as secure as HTTPS
SMTP with STARTTLS, also known as opportunistic TLS, which is now actively discouraged because encryption isn’t guaranteed 
STARTTLS offers questionable security, since it’s typically offered but not required: both sides of the SMTP transaction, sender and receiver, need to agree to use it.[3] If the receiver says “Hey, I support STARTTLS,” the sender can still say “Nah, I’m good with plaintext.” And the transaction will still continue.
In contrast, SMTPS won’t allow downgrading to unencrypted traffic.[4] That’s why that RFC linked above is like a cease and desist against STARTTLS.
Nevertheless, STARTTLS is still offered by almost all receivers. But here’s the thing: it’s not 100% supported by senders.
Requiring STARTTLS isn’t whole-internet-safe 
Google publishes a Transparency Report measuring the adoption of STARTTLS across the world, as measured on the Gmail platform. While adoption is highest in the Americas, it’s still hovering at 99%+, not quite reaching 100% for consecutive months. In other areas it’s high-90s: highly successful yet not universal. Here’s a worldwide chart since 2020 showing we’re still not quite there:
So what happens if one of the 1-10% of senders that don’t support STARTTLS connects to a receiver that requires STARTTLS? (We’re not including hackers in this situation, by the way.)
Simple: the connection will end with a permanent failure. The sender will issue an opening EHLO, then the receiver says “OK, you can use STARTTLS.” If the sender doesn’t use STARTLS immediately after that, the receiver says “To be clear, I meant you must use STARTTLS” and sends back a hard 530 error.
And that’s what happened with those leads that came up invalid, even though Marketo could send to them. The validation log looked like this:
94.46.244.65    [2A9C] 20:52:02 Connected, local IP=66.165.231.34:25
94.46.244.65    [2A9C] 20:52:02 >>> 220 icewarp.figureone.com ESMTP IceWarp Epos Update 1 build 17; Sun, 13 Apr 2025 20:52:02 -0400
94.46.244.65    [2A9C] 20:52:02 <<< EHLO douglas.email-validator.com
94.46.244.65    [2A9C] 20:52:02 >>> 250-icewarp.figureone.com Hello email.phone-validator.com [94.46.244.65], pleased to meet you.
                                    250-ENHANCEDSTATUSCODES
                                    250-SIZE
                                    250-EXPN
                                    250-ETRN
                                    250-ATRN
                                    250-CHECKPOINT
                                    250-8BITMIME
                                    250-SMTPUTF8
                                    250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
                                    250-STARTTLS
                                    250-VRFY
                                    250 HELP
94.46.244.65    [2A9C] 20:52:02 <<< MAIL FROM:
94.46.244.65    [2A9C] 20:52:02 >>> 530 5.7.0 Must issue a STARTTLS command first
94.46.244.65    [2A9C] 20:52:02 <<< QUIT
94.46.244.65    [2A9C] 20:52:03 >>> 221 2.0.0 icewarp.figureone.com closing connection
94.46.244.65    [2A9C] 20:52:03 ***   1 0 00:00:00 INCOMPLETE-SESSION 
94.46.244.65    [2A9C] 20:52:03 Disconnected
So the validation service is in the 10% of senders that can’t use STARTTLS. Since it can’t send, it calls the address invalid. Indeed, for any other sender in the 10%, it is invalid — there’s no practical difference between a 530 Missing STARTTLS and a 550 User unknown, they’re both permanent rejections.[5]
Is the validator wrong or right?
Depends. If an email is valid only if every well-behaved/non-blocklisted mailserver in the world can send to it, then the validator is right. If an email is valid if the overwhelming majority of mailservers can send to it — even if your mailserver can’t — then it’s wrong.
This also serves as a reminder: the only way to truly know if your Marketo instance can email someone is by emailing them. Generate enough content and you won’t have uncertainty!
Notes
[1] That’s the extent of what you can check in real time. Validators also have a batch mode which allows them to retry if the initial connection is greylisted.
[2] Note a webmail client, mobile app, or proprietary connection like Outlook ⮕ Exchange is not traditional. I’m talking pure IMAP/SMTP without SSL.
[3] And that’s not all: that initial discussion takes place over plaintext! Which means a hacker in the middle can simply remove the receiver’s original offer, so the sender never knows it could’ve used encryption — and in turn the unencrypted data can be read by the hacker.
[4] SMTPS has its own barriers to global adoption that I won’t get into here, but it can always be used in the coffee shop scenario.
[5] Suppose one difference is the 530 might change over time if the receiver gets the hint that requiring STARTTLS was a bad idea. But as long as the policy is in place, the email address is useless if you don’t support outbound STARTTLS. 


 You’re probably overusing “&” in links 
Sanford Whiteman — Wed, 26 Mar 2025 23:24:40 -0400
 The tl;dr: if a URL’s query params all start with utm_, you don’t need to separate them with &. Use a simple &.
Using & when it’s not required is harmless. But it’s not really best practice, since it makes links harder to build by hand and harder to read.
On the other hand, if you use params other than utm_*, might as well stick with &. Knowing exactly which names/prefixes require & is tricky, as we’ll see below. And if you use a URL builder that automatically spits out & that’s fine.[1]
Why you don’t need it with utm_ params
& is the HTML-encoded form of &. You need in only one case: when the characters that follow the & would otherwise be confused for one of HTML’s named or numeric entities. 
This is not the case with with utm_ params because there’s no named entity &u, &ut, or &utm. (Named entities only contain letters, so once you get to _ you can stop worrying.)
HTML has a standard list of 2200-odd named entities that’s guaranteed to never grow. Follow the link for the full entity list; the important part is here, the last stretch that starts with u:
snippet of HTML named entity list
As you can see, none match any part of utm. So there will never be a case where &utm is interpreted as anything other than the 4 characters &, u, t, and m.  That’s why you don’t need &utm.
When you do need &
When you use & (or, to make things more confusing, just & without the semicolon) the HTML parser treats that 4- or 5-character sequence as an encoded name — like a macro — for the single character &.[2]
That ability to HTML-encode & — to ensure it’s a literal & — can be critical.
Let’s say your website uses a query param current_language, like current_language=en or current_language=fr. That’s very different than utm_, because curren is one of the named entities!
snippet of HTML named entity list
So when you include a querystring-like sequence anywhere in HTML — not just in an , by the way, but anywhere — and current_language isn’t the first query param, you must use &current_language instead of ¤t_language.
If you use the simple &, ¤ will be parsed as the named entity and turned into its underlying character. You’ll send people to bizarre URLs like this:
https://www.example.com/landingpage.html?product=laptops¤t_language=en
See what happened there? ¤ was replaced by the generic currency sign ¤. Now you effectively have a single query param product with the value laptops¤t_language=en. Yikes upon yikes.
So & absolutely has its place. It’s just not needed with the standard marketer’s collection of utm_ params.
Notes
[1] Provided those URLs are used in HTML Text or Attribute data. You must not use HTML-encoding (neither & nor &anythingelse;) in CSS download-circle
Load that file in the  of your Redirector LP:


It’s critical that it load before the Munchkin library, which gets automatically injected at the end of the , so the safe way is to put it in .
Then use this JS instead of the original redirector JS:
redirect: {
   const allowedOrigins = [ // which domains are allowed for redirection
      "https://pages.example.com",
      "https://www.example.com",
      "https://example.com"
   ]; 
         
   const errNoAsset = "Asset URL not found."; // message when no asset in hash
   const errInvalidAsset = "Asset URL not allowed."; // when asset not our domain
   const redirectMs = 2000;
   
   let assetURL;
   try {
     assetURL = new URL(decodeURIComponent(document.location.hash.substring(1)));
   } catch(e){
     document.body.append(errNoAsset);
     break redirect;      
   }
      
   if(!allowedOrigins.includes(assetURL.origin)){
     document.body.append(errInvalidAsset);
     break redirect;
   }
   
   enableMunchkinHitEvent({ forceAfter: redirectMs, debug: true });
   
   document.addEventListener("munchkin.visitWebPage", function(e){
     document.location.href = assetURL.href;
   });
}
The JS is less clunky now as browsers do a lot more stuff natively than they did back in 2017 (!!).
 


 Hooking Conversion Path into HubSpot forms is crazy easy 
Sanford Whiteman — Wed, 18 Dec 2024 14:30:55 -0500
 A long time ago, my friend Joe Fusaro (now at DataChef) and I wrote the still-solid Conversion Path JS attribution library. Conversion Path takes the usually lightweight “UTM-to-cookie” concept and injects it with some kind of superdrug. It has an insane amount of configurability.
When we wrote it, we were adamant about our JS API hooking into any form, including a plain vanilla HTML . (It integrates with Marketo forms automatically.)
Few — or maybe zero — users explored Conversion Path Custom Events back in the day, but recently someone switched to Hubspot and wanted to stick with the script. And it was mind-blowingly simple, thanks to the work put in back then:


Enjoy! 


 Triggering the first time you see a lead domain using FlowBoost 
Sanford Whiteman — Fri, 13 Dec 2024 15:37:00 -0500
 There are so many cool things you can do with FlowBoost’s FBCounter that go beyond the obvious case of counting program members/event registrants.
(As always, mea culpa because the rather meager documentation of FBCounter doesn’t mention these. They mostly come up when a user responds to the onboarding email with a question and I go, “Of course!” ☺)
When you call FBCounter.add(counterName, value) the response has a different shape if the counterName already existed vs. if it’s brand new.
If it’s brand new, it looks like this:
{
  "response": {
    "body": {
      "action": "set",
      "node": {
        "key": "/pub:omuryeoqwuk5vqpw6zpaxtdr/knownDomains/example.com",
        "value": "248832",
        "modifiedIndex": 4453898,
        "createdIndex": 4453898
      }
    }
}
While if the counterName already existed, it looks like this — note the prevNode (“previous node”) object:
{
  "response": {
    "body": {
      "action": "set",
      "node": {
        "key": "/pub:omuryeoqwuk5vqpw6zpaxtdr/knownDomains/example.com",
        "value": "248836",
        "modifiedIndex": 4453902,
        "createdIndex": 4453902
      },
      "prevNode": {
        "key": "/pub:omuryeoqwuk5vqpw6zpaxtdr/knownDomains/example.com",
        "value": "248832",
        "modifiedIndex": 4453901,
        "createdIndex": 4453901
      }
    }
  }
}
Therefore, you can use the presence of prevNode to flag a domain that’s new to your database. Here’s that FlowBoost webhook payload:
let emailParts = FBUtil.string.partsFromEmail({{Lead.Email Address}});
let emailDomain = emailParts.domain;

FBCounter.add(`/knownDomains/${emailDomain}`, {{Lead.Id}})
.then( upserted => {
  success({
    isNetNewDomain : upserted.body.prevNode ? false : true
  });
});
And the response, suitable for mapping to a Person field or just scanning in a Webhook is Called trigger:
{
  "response" {
    "netNewDomain" : true
}
Pretty cool, eh? This is one part of a “poor man’s ABM” solution you can build using FlowBoost’s ability to combine data across multiple leads. 


 Integrations using Marketo’s “Get Folders” API must expect the same Folder ID on multiple pages 
Sanford Whiteman — Wed, 11 Dec 2024 01:54:26 -0500
 On a recent Marketing Nation thread, a developer had questions about the Get Folders API endpoint, one of Marketo’s paginated endpoints that returns folders in batches of (up to) 200:
While paging through /rest/asset/v1/folders.json using the offset parameter, we are seeing duplicate folder ids in later pages that were returned in earlier pages.

e.g. with a maxReturn=200 and offset=0, we get folder id 130 in the results. Then with the same maxReturn=200 and offset=200, we again get folder 130 in the results.
A brief moment of 😵‍ is understandable, but this behavior makes perfect sense.
See, each page is computed upon request. There’s no pre-computed result set containing all pages as of a point in time. (More on this in the notes.) So the underlying database state can easily change while you’re fetching pages.
Take a folder tree like this:
Let’s fetch the root and the first subfolder:
https://123-ABC-456.mktorest.com/rest/asset/v1/folders.json?root=22523&maxReturn=2&offset=0
{
    "result": [
        {
            "name": "Today's Root",
            "description": "",
            "createdAt": "2024-11-28T20:30:17Z+0000",
            "updatedAt": "2024-11-28T20:30:17Z+0000",
            "url": "https://app-us00.marketo.com/#MF5944A1",
            "folderId": {
                "id": 22523,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 13531,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22523
        },
        {
            "name": "Folder 1",
            "description": "",
            "createdAt": "2024-11-28T20:30:33Z+0000",
            "updatedAt": "2024-11-28T20:30:33Z+0000",
            "url": "https://app-us00.marketo.com/#MF5945A1",
            "folderId": {
                "id": 22524,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 22523,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root/Folder 1",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22524
        }
    ]
}
Now get the next 2 subfolders:
https://123-ABC-456.mktorest.com/rest/asset/v1/folders.json?root=22523&maxReturn=2&offset=2
{
    "result": [
        {
            "name": "Folder 2",
            "description": "",
            "createdAt": "2024-11-28T20:30:42Z+0000",
            "updatedAt": "2024-11-28T20:30:42Z+0000",
            "url": "https://app-us00.marketo.com/#MF5946A1",
            "folderId": {
                "id": 22525,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 22523,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root/Folder 2",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22525
        },
        {
            "name": "Folder 3",
            "description": "",
            "createdAt": "2024-11-28T20:30:51Z+0000",
            "updatedAt": "2024-11-28T20:30:51Z+0000",
            "url": "https://app-us00.marketo.com/#MF5947A1",
            "folderId": {
                "id": 22526,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 22523,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root/Folder 3",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22526
        }
    ]
}
Now someone creates a new subfolder, Folder 2.5, while we’re running our job:
And when we get the next 2 subfolders from our last offset, we see Folder 3 again!
https://123-ABC-456.mktorest.com/rest/asset/v1/folders.json?root=22523&maxReturn=2&offset=4
{
    "result": [
        {
            "name": "Folder 3",
            "description": "",
            "createdAt": "2024-11-28T20:30:51Z+0000",
            "updatedAt": "2024-11-28T20:30:51Z+0000",
            "url": "https://app-us00.marketo.com/#MF5947A1",
            "folderId": {
                "id": 22526,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 22523,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root/Folder 3",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22526
        },
        {
            "name": "Folder 4",
            "description": "",
            "createdAt": "2024-11-28T20:31:02Z+0000",
            "updatedAt": "2024-11-28T20:31:02Z+0000",
            "url": "https://app-us00.marketo.com/#MF5948A1",
            "folderId": {
                "id": 22527,
                "type": "Folder"
            },
            "folderType": "Marketing Folder",
            "parent": {
                "id": 22523,
                "type": "Folder"
            },
            "path": "/Marketing Activities/Default/!Universal/Today's Root/Folder 4",
            "isArchive": false,
            "isSystem": false,
            "accessZoneId": 1,
            "workspace": "Default",
            "id": 22527
        }
    ]
}
Similarly, deletes while a paginated job is running can change the overall result if folders slide backward out of view.
These are just things you must expect in order to build a resilient Marketo integration. An ostensibly “full” Get Folders job isn’t guaranteed to include all folder IDs that existed when the job started. Nor is it guaranteed to include a given folder ID only once.
Mitigation tactics
You can mitigate the impact in a few ways:
sync more frequently: this keeps your users happier either way
parallelize: use 2 workers to fetch data — staying under the 100 calls/20 secs rate limit, of course — to speed up the whole job
re-crawl from programs: periodically run Get Programs using a recent date range filter, then crawl backwards from each program to get its ancestor folders (not exactly the same as getting recent folders, but fills many gaps)
acknowledge the possibility in your product docs, but don’t worry about it (far better than nothing!)
Notes
Get Folders uses a basic paginated model akin to OFFSET/LIMIT in SQL. Because it’s stateless, your app doesn’t need to know anything about the next request other than the offset (and in fact that statelessness allows for parallelization, within limits). 
In contrast, stateful models such as keyset pagination ensure consistency across multi-page jobs, but they require server-generated pointers to each page and are more complex to implement. Marketo uses a similar approach for the Activity API, paging tokens.
One rarely used model is where the server fetches the full result set in response to the client requesting a single page. Results can even begin streaming while being cached on disk, like atee; HTTP range lets you fetch file chunks without additional overhead. In theory at least, that’s the best of both worlds! Problem is it doesn’t scale: disk storage quickly grows out of control, and you waste resources generating data that may never be used. 


 A fully customizable “Forward to Friend” using a standard Marketo form + embedded “View as Web Page” 
Sanford Whiteman — Tue, 05 Nov 2024 02:11:26 -0500
 My last post showed how to embed “View as Web Page” (VAWP) as a preview on a fully branded “Forward to Friend” (F2F) page, like so:
Now, let’s learn how to turn a standard Marketo form into a F2F form so we don’t have to use the — let’s face it — pretty ugly popup that comes with the usual F2F link. You know, this one:
The F2F endpoint is just an alternate form listener
The F2F form, like any HTML form, posts to a form listener (that is, HTTP service that expects application/x-www-form-urlencoded payloads). It’s not the same listener used by Forms 2.0 forms, but even simpler. It just expects a GET request with 4 fields:
fname (first name)
lname (last name)
emailAddress (email address)
mkt_tok (the mkt_tok value that identifies the email to forward and from whom)
You can hit the F2F listener from a webhook and it’s exactly the same as if an end user filled out the form. (You probably just had a lightbulb moment!)
Set up a field for the mkt_tok
The mkt_tok is automatically submitted with Forms 2.0 forms, but that system-level field isn’t available as a token or in Smart Lists.[1]
So to expose the mkt_tok in userland, create a custom String field on Person named Last Requested Email mkt_tok:
Set up the webhook
The webhook couldn’t be simpler. Just substitute your LP domain for info.example.com below and that’s your GET payload:
https://info.example.com/index.php/email/forwardToFriend?fname={{lead.First Name}}&lname={{lead.Last Name}}&emailAddress={{lead.Email Address}}&mkt_tok={{lead.Last Requested Email mkt_tok}}
You don’t need any Custom Headers or Response Mappings.
Create a standard form
(This step intentionally left mostly blank. Just make a form with any fields you want to collect.)
Enhance the page JS
The code from the previous post populates the  with an email preview. Add a little more code so the F2F form includes the new Last Requested Email mkt_tok and doesn’t include the typical cookie and mkt_tok fields (you don’t want to send those for a referral-type form):
// same code as in https://blog.teknkl.com/embed-view-as-web-page-vawp-as-thumbnail-iframe/ 
let currentURL = new URL(document.location.href);
let mktTok = currentURL.searchParams.get("mkt_tok") || window.__mktTokVal || sessionStorage.getItem(`${currentURL.pathname}?mkt_tok`);
sessionStorage.setItem(`${currentURL.pathname}?mkt_tok`, mktTok);
        
let emailWebView = document.querySelector("#emailWebView");
let iframeURL = new URL("/index.php/email/emailWebview", currentURL.origin);
iframeURL.searchParams.set("mkt_tok", mktTok);
fetch(iframeURL)
  .then( resp => resp.text() )
  .then( body => emailWebView.srcdoc = Document.parseHTMLUnsafe(body).documentElement.outerHTML );

// new code to add the mkt_tok to the F2F form
MktoForms2.whenReady(function(readyForm){
  readyForm.setValues({
    lastRequestedEmailmkttok: mktTok
  });

  readyForm.addHiddenFields({ 
    _mkt_trk: "",
    mkt_tok: ""
  });
   
  readyForm.onSubmit(function (form) {
    readyForm.setValues({ 
       _mkt_trk: "",
       mkt_tok: ""
    });
  });
});
Create a Smart Campaign to catch form fills
Straightforward form catcher campaign that calls the ’hook:
Create a Smart Campaign to preemptively unsubscribe “friends”
The F2F listener does one interesting thing beyond resending an email. It also sets Unsubscribed to true for net new people. The idea being a person can be referred and get an initial email, but to market to them later you need to get them to fill out a form and officially subscribe. 
So let’s duplicate that feature by flagging people who were created via the Forms 2.0 form:
N.B. Latency between the F2F service and the core platform is unpredictable enough that I’m forced to recommend an arbitrary Wait step. I hate doing it, but we don’t have an event to trigger on. 15 minutes will work fine: if it takes longer than that for Marketo to queue the message, you’ve got far bigger problems!
Detect errors, if you’re feeling thorough
To detect errors calling the F2F listener (which shouldn’t happen, but hey) trigger on webhook responses missing the string Successfully Sent:
Alternate approach
I know what some of you are thinking and yes: you could call the F2F listener on the client side, i.e. in a custom onSuccess function, instead of using the webhook. Or even call the F2F first via some tricky onSubmit stuff. 
But I’m wary of a possible race condition between the Forms 2.0 POST and the F2F GET when they occur < 1s apart and prefer to know the exact order (real form post, then F2F ’hook).
Notes
[1] Also, for F2F purposes, we don’t want to mix up the person who received the original email (the referrer) with the F2F recipient (the referral).
 


 Embedding “View as Web Page” as a thumbnail-like preview on a standard Marketo LP 
Sanford Whiteman — Mon, 21 Oct 2024 14:23:11 -0400
 We’re building out an account-based referral program for a client. The program lets people invite colleagues to in-person events. It’s like “Forward to Friend” on PEDs.
An email preview needs to accompany the referral form, and rather than the huge time suck of manually creating thumbnail images, we realized the standard “View as Web Page” (VAWP) would be perfect if we could get it into an :
Turned out to be net-easy — though, as with many such projects, 10% harder than you might think!
Set up the HTML and CSS 
First, the  and some critical styles and attributes:

The HTML attributes scrolling and tabindex, together with those two CSS “event neutralizing” styles, make the  behave like a static image so it can’t be accidentally clicked or selected.*
Set width and height and other styles to fit your page. In the screenshot I even added filter: grayscale(1) because I thought it looked cool.😊
Populate the  
Here’s where that “10% harder” came in. 
You might think you could just set the  to the VAWP URL (https://landingpages.example.com/index.php/email/emailWebview) with the main document’s mkt_tok copied into its query string, e.g.:
    let currentURL = new URL(document.location.href);
    let mktTok = currentURL.searchParams.get("mkt_tok");

    let emailWebView = document.querySelector("#emailWebView");
    let iframeURL = new URL("/index.php/email/emailWebview", currentURL.origin);
    iframeURL.searchParams.set("mkt_tok", mktTok);

    emailWebView.src = iframeURL;
But this won’t work. Why? Because Marketo sends the HTTP header X-Frame-Options: DENY when you request the VAWP page even if you think you’ve turned that off in Admin. 
That is, this valuable setting.. 
... works for regular LPs under https://landingpages.example.com, but the VAWP service doesn’t pay attention and keeps sending DENY. This is a longstanding bug oddity. Luckily, it’s easy to work around.
’stead of src, fetch into srcdoc
Obvious-when-you-think-about-it fact about X-Frame-Options is it can’t stop you from setting an  (not src but srcdoc) to whatever HTML you want. The HTML might’ve been fetched as-is from a same-origin URL or even a CORS URL, but srcdoc has no idea where it originally came from.
And unless very rare measures (like, “never seen in real life” type of rare) are taken, you can fetch or XMLHttpRequest any public same-origin resource.
So we just need to GET the VAWP URL and then set the srcdoc to the raw response:
    let currentURL = new URL(document.location.href);
    let mktTok = currentURL.searchParams.get("mkt_tok");
        
    let emailWebView = document.querySelector("#emailWebView");
    let iframeURL = new URL("/index.php/email/emailWebview", currentURL.origin);
    iframeURL.searchParams.set("mkt_tok", mktTok);
    fetch(iframeURL)
      .then( resp => resp.text() )
      .then( body => emailWebView.srcdoc = body );
Presto!
Adding resilience
The code above works fine, but it’s a bit fragile. More resilient code is below.
One fragile part: if you inject that code via a tag manager (don’t if you can avoid it, since it just hurts performance!) there’s a race condition with the built-in JS that moves the mkt_tok query param into the __mktTokVal global variable. So better to look for the token in both places.
Another: if the end user refreshes the page, there won’t be a mkt_tok and the VAWP will respond with Cannot get email content (same way it always works). Persisting the mkt_tok in Session Storage takes care of that.
Finally: why not create a real live document (as in Document object) from the fetched HTML and then set the srcdoc from that doc? Helps you think about other modifications you might make to the HTML before populating the .
So let’s use this:
    let currentURL = new URL(document.location.href);
    let mktTok = currentURL.searchParams.get("mkt_tok") || window.__mktTokVal || sessionStorage.getItem(`${currentURL.pathname}?mkt_tok`);
    sessionStorage.setItem(`${currentURL.pathname}?mkt_tok`, mktTok);
        
    let emailWebView = document.querySelector("#emailWebView");
    let iframeURL = new URL("/index.php/email/emailWebview", currentURL.origin);
    iframeURL.searchParams.set("mkt_tok", mktTok);
    fetch(iframeURL)
      .then( resp => resp.text() )
      .then( body => emailWebView.srcdoc = Document.parseHTMLUnsafe(body).documentElement.outerHTML );
Notes
* You could also sandbox it but that disables some cool stuff I’ll show in a future post.
 


 Sending reminders from Marketo when a date falls in the next month 
Sanford Whiteman — Fri, 06 Sep 2024 01:39:18 -0400
 You might’ve just groaned, “A whole post about the [in time frame] = Next Month filter? Ugh.”
Hey, give me a little credit. You might think you merely haven’t used it, but the reality is there is no such [in time frame] option! This is all we’ve got:
Luckily, it’s easy to build work-alike logic.
Assume your current field is called Expiration Date. Create a new Date field named Next Reminder Date.
Keep that new field updated using a daily batch running after midnight. Catch changes to Expiration Date as well as new people: 
And set the Next Reminder Date back 1 month from Expiration Date:
Now, using the built-in [in time frame] = This Month on the new field gives you the desired outcome:
That’s it! 


 Sorry, ▒▒▒▒▒▒, but {{system.tokens}} don’t work in webhook response mappings 
Sanford Whiteman — Wed, 04 Sep 2024 01:15:45 -0400
 On our last MUG Q&A call, a Marketo vet asked about a webhook setup recommended by a certain vendor (who will remain anonymous to save embarrassment).    
The vendor’s setup guide included this striking note:
For items like date, system tokens can be used since the API does not, in most cases, include a timestamp in its response.
And an accompanying screenshot:
This was mind-blowing for everyone on the call. Despite being — I think it’s safe to say! — a Marketo webhooks guru, I’d never seen this attempted before. We extended the Q&A by a half hour just to test it out live.
Problem is it doesn’t actually work. The response mapping does do something to the person record, and if you’re not paying close attention (and/or are not an experienced Marketo user, as was probably the case at the vendor) you might think it works.
Setting up a test
I set up a webhook hitting one of my test servers, which always returns this static JSON:
{
   "car_count" : 123456,
   "item_count" : 117733,
   "item_types" : [
      {
         "item_type" : "Blue Car",
         "item_type_count" : 1115,
         "item_type_ratio" : 12
      },
      {
         "item_type" : "Red Car",
         "item_type_count" : 1225,
         "item_type_ratio" : 14
      },
      {
         "item_type" : "Yellow Car",
         "item_type_count" : 1345,
         "item_type_ratio" : 6
      }
   ],
   "item_types_ratio" : 22
}
And mapped both a real response field car_count and the built-in token {{system.datetime}}: 
Then ran a list of about 15,000 people through the ‘hook (wasn’t messing around with a spot check!). And saw a promising number of people with the same value: 
But therein lay the first clue. It wasn’t just a bunch of people with the same value. It was all 15,000 with the same value. Which meant it couldn’t possibly be stamped when the webhook returns.
See, Marketo’s webhook capacity is very high — which is awesome — but it’s not so high that 15,000 people can start + finish in the same minute. It takes at least a few minutes even with a lightning-fast service on the other end.
Indeed, you can see that some people fired the webhook at 26 after the hour but their value was set to 25 after: 
Then another “Wait, hold on” moment: the webhook fired on September 2nd, but the value was set to September 1st! That ain’t right.
And yet another moment: the webhook fired at 5:26pm US Eastern time but appeared to set the time to 12:25pm US Eastern. That ain’t right, either.
Making matters weirder, per the Activity Log the value being set was 2024-09-01 11:25:04, not 2024-09-01 12:25:04:
This isolated part makes sense, at least. When you set a value to a date-like string in local time, the time zone is assumed to be the server time zone. In this case, that’s US Central time — so 12:25pm displayed in US Eastern. Whew. At least not everything is inexplicable.
But nothing else made sense. We put the setup through a few more tests and saw seemingly random values being written instead of the actual {{system.datetime}}. Sometimes we saw the value of another field from the JSON payload being written.
All in all, we confirmed this setup is not supported and only appeared to work for the vendor because they saw some value being written to the DateTime! Also, because they were using a Date instead of a DateTime, that obscured some of the errors.
Keep using a Smart Campaign
Ignore the vendor’s over-hopeful, under-tested approach.
The correct way to store when a webhook executed is to trigger on Webhook is Called and call Change Data Value to set a DateTime field to {{system.datetime}}. 


 An “Open Marketo Lead in SFDC” button for the Marketo UI 
Sanford Whiteman — Sun, 04 Aug 2024 02:05:00 -0400
 Who among us hasn’t looked up a Lead or Contact in SFDC while checking the corresponding person in Marketo? Ridiculously common for me, and even if it’s not exactly hard, there’s no one-click way to do it. Until now.
Just go to the SFDC Bookmarklet Maker and enter your SFDC “My Domain” in the top field:
The checkbox means each SFDC Lead/Contact opens in a new tab, instead of having a single SFDC tab that gets continually replaced (the default).
You can optionally change the title of the bookmarklet before dragging it. Click the pencil (🖉) to edit and the check (✓) to save:
Then drag the link to your Bookmarks bar:
Presto! Now, whenever you’re viewing a record in the Marketo Lead UI, clicking the bookmarklet takes you to the corresponding SFDC record.
Required: SFDC ID on your custom tab
There is one prerequisite: the SFDC ID field needs to be somewhere on your Custom tab (the exact position doesn’t matter). Check that in Admin » Field Management » Custom Layout Designer:
 


 Don’t worry about having too many Thank You page options 
Sanford Whiteman — Fri, 02 Aug 2024 14:19:03 -0400
 There’s a warning in the forms docs that made an admin skittish the other day: 
For want of a euphemism: this warning is FUD. The number of choices you add in this dialog has no effect on form loading speed at all:
While I’m not privy to the edit history, the error is likely due to a misunderstanding. The Thank You choices can — if you have hundreds of them — slow down that particular page in Form Editor. An engineer might’ve mentioned that to a tech writer in passing.
But the choices are simply not loaded alongside the form. They’re not part of the public form descriptor (i.e. response to a /getForm call) and therefore have no effect on how long the form takes to load and render.
You can see that easily in your browser. Here, for example, are two forms that have one Thank You choice and 200 Thank You choices, respectively:
They have the same size and transfer time.
Thank You choices are only consulted upon form submission — on the server side —where finding the first match is instantaneous.
Thank You choices are private
The fact choices are only used on the server is a powerful differentiator vs. custom Thank You JS in an onSuccess listener.
I love the extended power of onSuccess, but it’s true that since Forms 2.0 JS runs in the browser, a curious end user can see all your possible criteria[1] and destination pages. In contrast, Thank You choices in Form Editor are private, and an end user can only see the one they matched.
Notes
[1] Technically you can hide some criteria by matching hashes instead of plain strings, but you can’t hide the destination URLs.
 


 You can’t delete more than one cookie at a time (and  a couple other cookie bits) 
Sanford Whiteman — Sat, 06 Jul 2024 17:09:00 -0400
 Sometimes you glance at uncommented code and immediately know both what it’s trying to do (good!) and that it’s failing utterly to do it (bad!). Might be existing programmer slang for this, but I’m gonna dub it Error Code UTU8 (i.e. you thought you ate).
Like here in someone’s UTM tracking script:
document.cookie = "utm_campaign=, utm_medium__c=, utm_source__c=, utm_content__c=, utm_adgroup__c=, utm_keyword__c=; gclid__c=;expires=Thu, 01 Jan 1970 00:00:00 UTC;path=/;";
The code above is self-evidently trying to blank out a bunch of cookies that were set individually like so:
document.cookie = "utm_campaign=partner-invite-2024Q2;expires=Sat, 28 Dec 2024 12:34:56 UTC;path=/;"
document.cookie = "utm_medium_c=email;expires=Sat, 28 Dec 2024 12:34:56 UTC;path=/;";
document.cookie = "utm_source_c=blog-newsletter;expires=Sat, 28 Dec 2024 12:34:56 UTC;path=/;";
// etc.
Bad news for the developer: you must run the document.cookie setter separately for each cookie. There are no “batch actions” with cookies.
What the above code is actually doing is setting the cookie named utm_campaign to the value:
, utm_medium__c=, utm_source__c=, utm_content__c=, utm_adgroup__c=, utm_keyword__c=; gclid__c=
then back-dating the value. So the utm_campaign cookie is deleted, but no other cookies are touched.
Here’s the before:
And the after:
 N.B. You delete a cookie by setting its expiration date in the past. The value doesn’t actually matter in this case, so utm_campaign= and utm_campaign=whatever with a past expiration have the same effect. The convention is to set to an empty string when deleting, but that’s kinda misleading because an empty cookie value is valid, as long as it’s not expired! (It’s the expires that deletes it, not the fact that it’s empty.)
More bits
While I have your attention, here are a couple more bits of misguided cookie code found in the wild. (These bits, and many more, need to be wrapped up in a grand Falsehoods Martech Devs Believe About Cookies™ post at some point.)
Bit 2: You don’t need to “wait for” changes via document.cookie to take effect, they’re always immediate (synchronous)
Another groanworthy bit is thinking the browser does some delayed/asynchronous business when you set document.cookie.[1] Nope, any change to document.cookie is committed immediately and the cookie store is up-to-date by the next line.
So you never need anything like this:
document.cookie = "utm_campaign=;expires=Thu, 01 Jan 1970 00:00:00 UTC;path=/;";
setTimeout(function(){
  // something that reads from document.cookie
}, 1000);
Generally, such code exists because of another race condition — not directly related to cookies — and people panic and say “maybe the cookie wasn’t set yet?” Even if the real cause is found and fixed, this code exists for eternity, fixing nothing and just causing confusion.
Bit 3: You can’t set a cookie to HttpOnly from JS, that just deletes it
Some browsers (Safari in particular) trust cookies marked HttpOnly more than script-writeable cookies. This leads devs to think they can remove script-writeability from JavaScript, presumably hiding the cookie from code going forward but giving it elevated trust:
document.cookie = "utm_campaign=partner-invite-2024Q2;HttpOnly;expires=Sat, 28 Dec 2024 12:34:56 UTC;path=/;";
This will not work. When HttpOnly is encountered in JS, the browser just goes, “Well, that’s impossible, you’re in JSland so you can’t tell me what do in HTTPland” and deletes the cookie if it exists.
(Only reason you might think this works is because, well, it does hide the cookie from JS, in a morbid sense!)
Notes
[1] There is a new Cookie Store API (not the document.cookie setter) that’s asynchronous, but it’s not yet widely supported. 


 Verify a Marketo LP domain in Google Search Console  using the “HTML file” method 
Sanford Whiteman — Fri, 28 Jun 2024 02:06:26 -0400
 When you add a property to Google Search Console, you’ve got to prove you own the corresponding domain — or at least that you sufficiently control the webserver bound to https://pages.example.com.
Domain-wide verification requires a ticket opened with IT, which is best avoided. But verification of a Marketo LP domain or domain alias is something you can do yourself. There’s just one a little trick to it.
First, choose the URL Prefix option:
Next, choose the HTML file option (recommended by Google) and they’ll generate a file with the extension .html that you need to serve right under https://pages.example.com:
I purposely wrote “file with the extension .html” instead of writing “HTML document.” That’s because it isn’t a valid HTML document. In fact it’s just a plain text file with one line:
google-site-verification: google9c403852be851234.html
And they really mean that exact file needs to be served.
Problem is, a Marketo LP Template can’t be approved if it doesn’t at least have minimal HTML5 markup. Conversely, you can’t simply surround it with valid markup like so — 


  
    
    Title
  
  
    google-site-verification: google9c403852be851234.html
  
— because Google will barf and say the file is incorrect.
Design Studio to the rescue
The fix is pretty easy. Instead of creating a Marketo LP Template + LP, upload the file to Design Studio » Images and Files:
Then create a Redirect Rule in Admin » Landing Pages so the file appears to hang right off the LP domain root:
Presto:
 


 Never forget UTM params again with this handy email template CSS 
Sanford Whiteman — Wed, 19 Jun 2024 17:29:00 -0400
 As we all know, adding the standard utm_* query params to email links is something Marketo can’t do automatically.
Storing UTM params in a Program-level {{my.token}} and building links from ${mktoString} variables are smart moves. But it’s tough to tokenize every single link. (Users must remember to UTM-ify links in Rich Text areas, for example.)
While there’s no magic hack to add params for you, wouldn’t it be nice to have visual feedback when you forget to add ’em? Check this out:
It’s crazy easy to do this with modern CSS. That CSS won’t work in most email clients, but that doesn’t matter because we only need it to work in Marketo’s Email Preview!
Just add this Velocity {{my.token}} to your template, substituting your LP domain for pages.example.com and your branding (email click tracking) domain for click.example.com:
#if( $mktmail.DefaultTrackingHost.equals("localhost") )


#end
Key points:
For simplicity, we require at least one query param starting with utm_. The code could be expanded to specifically require utm_campaign, utm_medium, etc.
The “ignore” section contains links that aren’t expected to have UTMs.  You’ll likely find more such links. Let me know in the comments if there’s anything non-business-specific. 
You can tag business-specific ignorables with . 
Make sure to check Dynamic Content w/segmentations, Velocity-generated content, etc. not just the Default preview.
Obviously you can restyle the warning any way you want, just keep position: absolute so it doesn’t disrupt the layout.
 


 Marketo Booleans are nullable, but don’t worry about it too much 
Sanford Whiteman — Wed, 19 Jun 2024 17:27:55 -0400
 A user asked about this mysterious-sounding warning in the Trigger Smart Campaign docs:
Sounds scarier than it should because something’s omitted. The missing link? It’s that Boolean fields have 3 possible values: true, false, and null.
null enables more business cases
Nullability lets you distinguish — at least in theory — an unknown or unset value from a value that is known one way or the other.
Among infinite examples:
opt-in fields: responding “No” (false) is different from not having been asked the question (null)
fields like Is Partner before records are linked with external data: knowing somebody is not a partner (false) is different from not yet knowing (null)
In practice, though, only some Marketo features distinguish false and null.
Sometimes true and false are the available options and null doesn’t match either one, which is strict comparison.[1] Other times null is temporarily treated as false, a loose comparison.
Overall, we can say Marketo is always null-preserving, because if you can explicitly set null, the value is stored in the database. But it’s not always null-strict. (Yes, it’s confusing. That’s why your internal Tips ’n’ Tricks doc is so key.😊)
What the warning means
The warning above refers to one specific case: setting a value to null doesn't trigger Data Value Changes to false.
Say you use a Flow step to set null[2] or call the Sync Lead API endpoint like so:
{
  "action" : "updateOnly",
  "lookupField" : "id",
  "input" : [{
    "id" :  123456,
    "isPartner" : null
 }]
}
Regardless of the previous value, this Smart Campaign trigger will not fire:
This trigger also will not fire, despite attempting to compare to null:
Yet — assuming the previous value was true, of course — this trigger will fire:
As you can see, nullability adds vital flexibility to the Marketo database, yet can cause surprises[3] if you don’t test thoroughly.
Notes
[1] It’s not usually possible to compare a field value explicitly to null within Smart List Filters and Flow Choices. But you must prepare for those comparisons in REST API-based apps, which will see the preserved null values in the language of your choice.
[2] You might not realize Change Data Value can set null. Though the dropdown just shows true and false, you can type it manually:
[3] There’s a whole world of interesting behavior with Custom Objects + null fields + Velocity, which I’ve written about before. 


 Velocitip: Find the 𝑿-th 𝒀-day (e.g. 4th Wednesday) of this month 
Sanford Whiteman — Tue, 04 Jun 2024 14:46:00 -0400
 Your developer community meets on the 4th Wednesday of each month. You want to send monthly invites from Marketo without having to hard-code anything. Earlier, we learned how to find the first 𝒀-day of next month, and this is just different enough to get its own post.
As always, start with the standard datetime includes in Velocity:
#set( $defaultTimeZone = $date.getTimeZone().getTimeZone("America/New_York") )
#set( $defaultLocale = $date.getLocale() )
#set( $calNow = $date.getCalendar() )
#set( $ret = $calNow.setTimeZone($defaultTimeZone) )
#set( $calConst = $field.in($calNow) )
#set( $ISO8601DateOnly = "yyyy-MM-dd" )
#set( $ISO8601DateTime = "yyyy-MM-dd'T'HH:mm:ss" )
#set( $ISO8601DateTimeWithSpace = "yyyy-MM-dd HH:mm:ss" )
#set( $ISO8601DateTimeWithMillisUTC = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" )
#set( $ISO8601DateTimeWithMillisTZ = "yyyy-MM-dd'T'HH:mm:ss.SSSZ" )
Then add your campaign-specific settings, i.e. 4th Wednesday is $nth = 4, $day = "WEDNESDAY":
#set( $nth = 4 )
#set( $day = "WEDNESDAY" )
($day must be in all-caps English, since that’s how Java’s Calendar constants are stored.)
Next the hard/weird stuff: 
#set( $dayConst = $calConst.get($day) )
#if( $dayConst < 7  ) 
#set( $nextDayConst = $math.add($dayConst,1) )
#else
#set( $nextDayConst = 1 )
#end
#set( $thisMonth = $date.getCalendar() )
#set( $ret = $thisMonth.setTimeZone($defaultTimeZone) )
#set( $ret = $thisMonth.set($calConst.DAY_OF_MONTH, 1) )
#set( $ret = $thisMonth.setFirstDayOfWeek($nextDayConst) ) ## the day *after* Y-day
#set( $ret = $thisMonth.set($calConst.DAY_OF_WEEK, $dayConst) ) ## Y-day itself
#set( $ret = $thisMonth.add($calConst.WEEK_OF_MONTH, $math.sub($nth,1) ) )
Now output $thisMonth any way you want:
The ${nth}th/nd ${display.capitalize($day.toLowerCase())}
of ${date.format("MMMM yyyy", $thisMonth, $defaultLocale, $defaultTimeZone)}
is ${date.format("MM/dd/yyyy", $thisMonth, $defaultLocale, $defaultTimeZone)}
The 4th/nd Wednesday
of May 2024
is 05/22/2024
Brief code explainer
At the risk of making your head spin:
Find the next day of the week after day 𝑿, using Java’s 1-based week where Sunday = 1, Monday = 2, etc.
Set the current day to 1st day of the month, which is naturally in the 1st week of the month as well.
Shift the calendar (also done in the previous post) so weeks start on the next day from step (1). This ensures we’re in a “World of Wednesdays” if you will.
Set the current day of the the week to day 𝑿.
Jump forward 𝒀-1 weeks. Since we’re already in week 1 of the month, we don’t need to jump the full 𝒀.
Easy, right? 😛 


 An easy-to-make, hard-to-trace mistake with Bulk Import API payloads 
Sanford Whiteman — Mon, 03 Jun 2024 12:59:55 -0400
 Does this look like good multipart/form-data for the Marketo REST API Bulk Import endpoint?
It does, right? Here it is with my text editor (EditPlus) set to show all whitespace, so you can see the CRLFs (represented as ¶) in the right places:
And yet the response from Marketo is:
{
    "requestId": "a571#1831bf14ce3",
    "success": false,
    "errors": [
        {
            "code": "1006",
            "message": "Header field 'email' not found"
        }
    ]
}
Strange, eh? The header email is the all-important system field Email Address, that’s definitely its REST API name. In fact, this particular endpoint is lax about case: you can even send EmAiL and it’ll work... at least usually. So what’s different here?
The direct cause
Now, I’ve been deliberately using text editor screenshots to keep you guessing. I was flummoxed myself until I checked the payload in my hex editor (Hex Editor Neo, highly recommended). Some other apps also show you the way. For example, here’s how it looks in WebStorm:
So there is an extra character: what WebStorm displays, correctly-but-not-ideally, as ZWNBSP, Zero Width No-Break Space.
More generally, this is the Unicode code point U+FEFF. EditPlus doesn't classify it as “whitespace”, so you don’t see it there. (They're thinking you want line breaks, tabs, common things like that as opposed to relatively obscure non-printing characters.)
 That explains the error: the header is actually U+FEFF followed by the characters e m a i l[1], not just the 5 characters e m a i l.
But this isn’t simply a random character where you chalk it up to a random glitch, delete it and go about your day. If you see it in the payload once, you’re sure to see it again and again, so you need to fix your code to deal with it.
ZWNBSP is another name for BOM
To understand how it gets in there, and why you’ll see it again if you don’t do something, you need to think of its other identity: not ZWNBSP but BOM, Byte Order Mark. In fact, in the Unicode spec you aren’t supposed to use it for no-breaky-ness anymore,  but you can still use it for byte order:
Now, I don’t want to dive deeply into byte order today, fascinating as it is. Suffice to say: if (and only if) U+FEFF appears at the very start of a stream of text, it’s called the BOM and determines how the rest of the text is decoded. However, for the type of text that’s supported by the Marketo REST API — that is, UTF-8 text — it’s completely unnecessary (UTF-8 is only ever encoded one way).
Sometimes, if the BOM is present but unnecessary, it’s gracefully ignored (and may be removed when you re-save a file). But in Marketo’s case, sending the BOM when it’s unnecessary breaks everything!
Either outcome is valid, and since you can’t know which one you’ll get with a given app, you should not include the BOM in a UTF-8 payload.
How did the BOM get there?
When you see the BOM within a multipart/form-data part, whoever wrote the code was going for speed over everything. Performance is part of good design, to be sure. But resilience and compatibility need to be covered before you worry about performance.
They likely did something like this, in pseudo-code:
send form-data HTTP headers
send opening MIME data (--boundary,Content-Disposition,Content-Type)
open CSV file from disk
while file chunks remain (
  read chunk
  send chunk
)
send closing MIME data (--boundary--)
They knew the .csv file on disk was already encoded as UTF-8, same encoding they wanted to send to Marketo. So rather than wastefully reading the file into memory and decoding it, only to reencode it into the same sequence of bytes, they just streamed the file as-is to the API.
Now, that’s absolutely the most efficient way to take a file and put it on the wire. It’s silly to peek into file contents where you don’t care about them.
For example, when a webserver delivers a .pdf file, unless it wants to kill its own performance, it doesn’t parse the PDF structure (sections, fonts, embedded images, etc.). It pushes the bytes over the wire, from tip to tail, as fast as possible. It’s up to your device to read and render it, or maybe figure out it isn’t a valid PDF.
But while a PDF is clearly valid or invalid, text files are their own beast. It’s much harder to say what an “invalid text file” would be. In a broad sense (both in and out of Marketo) you’re more likely to end up with mangled text values than, say, a hard error message saying This isn’t a good text file: Import request ignored.[2]
An easy but highly inefficient workaround is to read the entire file, parse it, then put it on the wire again:
send form-data HTTP headers
send opening MIME data (--boundary,Content-Disposition,Content-Type)
open CSV file from disk
parse file, as UTF-8, to one big string
encode and send string as UTF-8
send closing MIME data (--boundary--)
That’ll get rid of the BOM but at the cost of both memory and speed. You don’t need to make a drastic move like that.
Instead, you can still stream chunks, but make sure to check the first chunk for a BOM:
send form-data HTTP headers
send opening MIME data (--boundary,Content-Disposition,Content-Type)
open CSV file from disk
while file chunks remain (
  read chunk
  if chunk is first chunk (
    set chunk = chunk without leading EF BB BF
  )
  send chunk
)
send closing MIME data (--boundary--)
Notes
[1] EF BB BF 65 6D 61 69 6C in UTF-8.
[2] Many text encodings seen in the wild (ASCII, UTF-8, ISO-8859-1, Windows-1252, and more) aren’t sufficiently self-describing. Without firm agreement about the expected encoding — take “auto-detection” claims with a grain of salt — you‘ll end up with X% readable text peppered with Y% gibberish. 


 Beware the 𝚏𝚘𝚛𝚖.𝚜𝚞𝚋𝚖𝚒𝚝𝚝𝚊𝚋𝚕𝚎(𝚝𝚛𝚞𝚎) footgun 
Sanford Whiteman — Wed, 15 May 2024 02:47:00 -0400
 In programming slang, a footgun is a prominent feature that’s so easy to misuse — to shoot yourself in the foot — that everyone should be wary of it, even if it has its uses.
Perhaps a bit strong to describe the form.submittable(true) method of the Forms 2.0 JS API. Yet that method is used incorrectly the majority of the time (including by yours truly!) so let’s see how to use it right.
You typically see form.submittable(true) used like so:
MktoForms2.whenReady(function(readyForm){
   readyForm.onValidate(function(isNativeValid){
      if(!isNativeValid) return;
      
      const currentValues = readyForm.getValues();

      readyForm.submittable(false);
      if( currentValues.FirstName == "Santa" ) {
         readyForm.submittable(true);
      } else {
         readyForm.showErrorMessage("Must Be Santa");      
      }
   });
});
That’s a basic custom validation function: 
if(!isNativeValid) makes sure the native validation rules succeeded (i.e. Form Editor rules like fields marked Required and string/number patterns)if not, exit because you want those rules to pass before running custom stuff
if so, continue
store the current field values: form.getValues()
set the form to not be submittable: form.submittable(false)
check a custom validation ruleif validation succeeds, set the form back to submittable with form.submittable(true)
if validation fails, show an error message
Looks right, right? Indeed, if that’s the only custom onValidate function, anywhere on your page or in external scripts, you’re fine. But in reality, extended validation gets added in different places. There’s a remote 
(I’ve shown the 2 


For (2), check submittability alongside native validity:
That’s it!
Notes
[1] Some form designs require checking all validation rules, regardless of whether form.submittable() was already false. That lets you add a red border around all invalid fields at once, for example. But you still must make sure you don’t set form.submittable(true) unless every rule has passed. (The code for always-check-all-rules is more complex but you can ask about it in the comments.)
[2] Complex load sequences, like using my onMktoForms2Ready pattern, make adding a known-first listener pretty tricky.
[3] On a Marketo Guided LP Template, this means directly after the 
 element (the embed code is automatically injected inside that ).  


 Sorting numeric-string-keyed objects in Velocity (like they would sort in JS) 
Sanford Whiteman — Fri, 10 May 2024 00:32:41 -0400
 One of our clients recently did a big import of JSON-formatted values into a Textarea field. The result in Velocity, after the usual #evaluate trick to rehydrate JSON, is equivalent to this:
#set( $stringKeyedObject = {
  "0": "apples",
  "100": "oranges",
  "2": "pears"
} )
(The data is structured like that for an important reason I’ll explore in a near-future post.)
Here’s the thing: the system that exported this data uses NodeJS. In JS, creating an object literal like
let o = {
  "0": "apples",
  "100": "oranges",
  "2": "pears"
};
and looping over the keys with
Object.entries(o).forEach( ([key,value]) => console.log(key,value) )
uses a specific, standards-defined order. Because the keys are all numeric strings (the term is array indexes in the ES standard), the entries are sorted as numbers, not in insertion order:
0 apples
2 pears
100 oranges
This differs starkly from Velocity. In Velocity, for an identical-looking object literal, the order in a #foreach loop is insertion order:
0 apples
100 oranges
2 pears
That’s because Velocity object literals always create a LinkedHashMap, an object that maintains insertion order, regardless of the type of key.
The problem, then, is the source system thinks the JS order will be used to output values in a Marketo email, regardless of the order of the keys in the JSON. But that’s wrong!
Sorting it out
The solution is kind of clunky, but works fine. First, transform the object into an array of objects where each object has the keys "idx" and "itm":
#set( $numericKeyedEntries = [] )
#foreach( $entry in $stringKeyedObject.entrySet() )
#set( $numericKeyedEntry = {
  "idx" : $convert.toInteger($entry.getKey()), 
  "itm" : $entry.getValue()
})
#set( $void = $numericKeyedEntries.add( $numericKeyedEntry ) )
#end
"idx" is the original numeric string key, cast to an Integer; the "itm" is the original value. So $numericKeyedEntries looks like this:
[
{
  "idx" : 0,
  "itm" : "apples"
}, 
{
  "idx" : 100,
  "itm" : "oranges"
},  
{
  "idx" : 2,
  "itm" : "pears"
}
];
Now, you can use SortTool to sort on the "idx" property, which will be sorted numeric-ascending since it’s an Integer:
#set( $sortedNumericKeyedEntries = $sorter.sort($numericKeyedEntries,"idx") )
And finally, iterate over the objects in the original intended order:
#foreach( $entry in $sortedNumericKeyedEntries ) 
## $entry.idx is the index
## $entry.itm is the value
#end 


 What happens if you leave the protocol (http:// or https://) off email links completely? It’s complicated 
Sanford Whiteman — Thu, 18 Apr 2024 16:04:17 -0400
 Would you believe there’s something only Outlook.com and Outlook Web Access — plus a few lesser known email clients — get right?
Now, by “right” I mean obeying web standards and not covering up your mistakes. Other clients use non-standard guesswork to change what you said into what what they think you meant. And that’s bad, because if your QA happens to skip the Outlook web client that day, you’ll send a load of broken links.
Take this  link in a received email, which was intended to link to https://example.com/my/page?and=query but was messed up on the Marketo side:
what happens?
Such messes happen for a couple of reasons:
typing the whole link directly into the Rich Text editor, but accidentally leaving off the protocol
using a {{my.token}}, {{lead.token}} or mktoString variable to complete the href, but forgetting the template must contain the protocol outside the token/variable for that to work
A link without a protocol doesn’t have a hostname, either
No matter how much it looks like a hostname, the example.com in href="example.com" is not a hostname!  It might as well be abcdef or 123456. When you leave off the protocol completely, you’re in the path part of the URL.
So the URL is in fact path-relative, meaning if you were viewing https://www.example.net/some/thing and clicked that link, the final destination URL would be https://www.example.net/some/example.com/my/page?and=query. That is, the path is modified, while the hostname is untouched.
Mail clients: “¿Qué estándares?”
When I say “not a hostname” above, that’s knowing how the URL standard works. And that describes the behavior on an actual webpage. 
But email clients don’t act like browsers opening a page — they’re different, horrific beasts. Few clients render your HTML as originally sent. Rather, they create their own HTML, merely inspired by your HTML — translating your s to their 
s, your s to their s, and so on. (All that quirky email-specific HTML you have to learn is so it translates effectively.)
So along the way they might decide to “fix up” your URLs to make sure they point to remote locations instead of pointing to a path under https://mail.google.com or https://mail.yahoo.com. They explicitly break the standard to avoid security issues while still presenting a working link. But like I said, not every mail client does this, and you cannot rely on it.
Some examples
Here’s the above link sent to Gmail:
Here’s Gmail’s “fixed up” HTML (i.e. view-source: of the translated email):
As you can see, they prepended http:// even though you messed up, so this link will most likely✱ go to the originally intended URL. (Though notably it’s not a Marketo-tracked link, since Marketo properly didn’t see it as off-page.)
Here’s the same email sent to Outlook.com:
Aha! They also change your original HTML, but instead of “fixing” it, they neutralize it so it’s no longer a link at all. This is what a wide swath of end users will experience, and you don’t want that.
Finally, here’s the same email opened in Outlook 2016:
This one is subtly interesting because Outlook doesn’t change the link to include an explicit protocol. But the app passes links to your default web browser, and the browser then treats the link like you typed it in the Location bar, prepending http:// like it does with user input. (Yet that’s not an official standard either, just a widely adopted convention.)
Bottom line: only use absolute URLs in emails.
Notes
✱ Hedging with “most likely” since it’s technically possible for the fixed-up http://example.com to not redirect to https://example.com. 


 Hitting SMTP rate limits at certain domains? Put leads into fixed-size daily buckets (using FlowBoost) 
Sanford Whiteman — Thu, 18 Apr 2024 16:03:33 -0400
 A client has a pesky problem with a partner: end users are eager to get Marketo emails,  but their mailserver has strict inbound rate limits.
With several thousand Marketo records @ that domain (and growing!) they regularly see Soft Bounce once they exceed the daily rate limit of 1500 emails per day. It’s not tied to particular email addresses, just whoever’s unlucky enough to be person 1501+ for the day.
So we need a way to drop people into 1500-person buckets, starting with Bucket 1. Then we can space out the sends so Bucket 1 goes out on Monday, Bucket 2 on Tuesday, and so on.
And there should be the option to have different size buckets depending on the domain, in case we find another domain with a daily limit of, say, 500 or 3000.
You can’t do this with Marketo alone, but FlowBoost makes it easy. First create an Integer field Staggered Sending Bucket:
The FlowBoost payload is simple:
const knownDomainBucketSizes = new Map;
knownDomainBucketSizes.set("example.com", 1500); // known limit for @example.com
knownDomainBucketSizes.set("anotherexample.com", 500); // another known domain

const defaultBucketSize = 100; // if you call the ‘hook for any other domain

const emailDomain = FBUtil.string.partsFromEmail({{lead.Email Address}}).domain;
const domainBucketSize = knownDomainBucketSizes.get(emailDomain) || defaultBucketSize;

FBCounter.autoAdd(`/domainBuckets/${emailDomain}`)
.then( newEntry => {
  const bucket = Math.ceil( (newEntry.entryIndex + 1) / domainBucketSize );
  return success(bucket);
});
Make sure to add the query param authoringEnv=pro to the end of the FlowBoost URL, as you always do when using FBCounter:
And map the standard response property to the new field:
Then filter your sends by bucket:
A little deeper into the “algorithm” above
It barely rises to the level of computer science, but the code above works like so:
add a record to the counter
get that new record’s index, which gives the current total count 
add 1 to the count so it’s more user-friendly (you probably want Bucket 1, Bucket 2, ... instead of Bucket 0, Bucket 1, ...)
divide the current count by the bucket size, e.g. if the count is 110 and the bucket size is 100, that’s 110/100 = 1.1
get the integral ceiling of the result, e.g. Math.ceil(1.1) is integer 2
the ceiling is the bucket they’re in!
And no, Random Sample can’t do this
Marketo’s Random Sample flow step can only do percentages, not fixed sizes. As the audience is ever-growing, it’s impossible to use it for this case. Random Sample is for when you have a fixed-size list/one-time send and can pre-compute a % that approximates the bucket size. 


 Verifying the mkt_tok was added to Marketo links 
Sanford Whiteman — Tue, 26 Mar 2024 21:19:52 -0400
 These days, anything is up for debate, it seems: there are even mkt_tok denialists!
An IT team claimed the all-important mkt_tok query param✱ wasn’t being attached to Marketo links, even though they redirected from Marketo’s click tracking server (a.k.a. branding domain) to the right page. We knew this was vanishingly unlikely, but how to prove it?
Granted, mkt_tok can be confusing on a Marketo LP because there’s system-managed JavaScript that strips the param when the page loads, moving it to a JS variable for security reasons. The mkt_tok is still in the location bar for an instant, but you might miss it.
However, in the current case the target was their corporate website, where that mkt_tok-stripping code wouldn’t be present.✱✱
So we gotta bring back an old-school technique. Copy the link from the received email, prepend view-source:, and open it. You can see the mkt_tok is there as expected: 
Turned out in this case their webserver was redirecting people again from https://www.example.com/preferencecenter to https://example.com/en/preferences but was stripping all query params except those beginning with utm_! Solved.
Notes
✱ In case you forgot, without the mkt_tok Munchkin can’t associate anonymous web sessions, so Visited Web Page and Clicked Link won’t be logged. Clicked Email doesn’t use Munchkin, so isn’t directly affected.
✱✱ Note if someone has Firefox’s Query Parameter Stripping enabled, that’ll strip mkt_tok at the browser level. However, this is a Chrome-centric shop and that’s a non-default FF setting anyway. 


 Embedding a Marketo form on a Framer LP 
Sanford Whiteman — Tue, 26 Mar 2024 00:46:39 -0400
 Framer LPs support custom code, but — as with other WYSIWYG site builders — the DX is pretty unfriendly. Insert » Utility » Embed gives you a miniature textarea with a proportional font (a pet peeve) and no syntax highlighting:
Pasting a standard Marketo Forms 2.0 embed code into the textarea looks fine in Framer’s Preview mode:
But on the published LP, the form is nowhere to be found:
There’s a very clear clue in the F12 Console:
~60% of the time, this error means you have a persistent error in script load order.✱
Indeed, on the published page, Framer injects the HTML embed asynchronously (I assume for what they think are “performance” reasons). The Forms 2.0 library (the  remote 


Notes
✱ The other 40% of the time, it’s a race condition, which is different because the load order is unpredictable, based on network and browser conditions. A persistent error means the order is predictable and always wrong!
✱✱ As we’ve learned before, a script-injected inline