Anytime you have massive updates to do, interns everywhere quiver at the thought of manual labour. Fortunately for the interns at our client, Salytics was approached to automate the process of updating the links in their Marketo instance to ensure a smooth transition with their upgraded Security Certificate (SSL). To do this of course means every link must update from http to https. A painful manual process, that only got more difficult the further it was investigated. Below, we offer some tips and tricks that we discovered to make this as painless as possible. Our client is a dedicated and long time user of Marketo and as such has hundreds of templates and thousands of pages that needed to make the switch.


  1. The client had many hard-coded links/scripts that would cause browser warnings and break javascript functionality once switched over to https
  2. No automated way to discover what pages/templates required updates
  3. Client’s backend was disorganized and didn’t have clear way to determine total number of pages/templates
  4. While some pages could be fixed at the template level, many pages had html elements inside the page, requiring them to be fixed manually.
  5. Marketo’s REST and SOAP API do not support landing page updates.


First we had to figure out what we didn’t know. We had no idea how many pages were broken, how many were ok, or what was even broken. Ideally, we would have a way to grab each page by the html, analyze it, and then make the appropriate updates. We would also ideally have a way to know how many pages we were dealing with, who their template’s were, and any other necessary data.

We began looking around Marketo using network debuggers, and discovered a series of endpoints that would help us solve a lot of our questions. These end points included, ones that would allow us to find the total number of pages in a workspace, the html content of these pages (which we could analyze) and landing page information (such as the program it belonged to and it’s template). Working with these endpoints, allowed to to solve 3 of the 5 problems we were facing in the browser console as opposed to any APIs. With the cap on calls using the API and the heavy number of calls required for this task, this proved to be very helpful.

Code Snippets using Endpoints

  1. Get the number of pages in the Marketo workspace (eg. Global, Default etc…):
    var xsrfId = jQuery("#xsrfId").val(); //security parameter  
    	dataType: "json",  
    	type: "POST",  
    	url: "",  
    	data: {   
    		ajaxHandler: "MktCanvas",  
    		xsrfId: xsrfId   
  2. Get the Landing Page Metadata:
    var xsrfId = jQuery("#xsrfId").val(); //security parameter  
    	dataType: "json",  
    	type: "POST",  
    	url: "/landingPage/showPages",  
    	data: {   
    		pageSize: size,  
    		start: 0,  
    		xsrfId: xsrfId  
    	success: function(response) {  
     /*data returned as:  
     [lpid,id,lpName,lpType,lpProgram,lpTemplate,lpTemplateType,lpStatus,lpStatus,lpUrl,lpMobileEnabled,lpEditingMode,lpUpdated,marketingProgramId] */  
  3. Get the Individual Pages HTML:
               type: "GET",  
               url: "/lpeditor/preview",  
               data: {  
                         pageId: lpId,  
                         deployedLatest: 1  
     /*returns landing page html*/  

Testing our work:

As we completed our work we discovered 1 last problem. Our test environment does not use SSL, meaning we wouldn’t be able to test the changes we were making. The only options were to go live, or make our test environment secure causing our other projects to be placed on hold as we would no longer be able to test them. After further investigation, we discovered a 3rd option that worked perfectly. When you preview a page in Marketo, you will notice that your page is embedded in an iframe. That iframe is secure, meaning we can test our pages using https.

Using the endpoints above, we were now in a position to build a script in javascript to pull all landing page information and analyze landing page html to see if any of the scripts/sources it used were using http. If they were, we would mark these pages:

  • For these marked pages, we migrated everything at the template level to use relative urls (some scripts had different locations for their https counterparts, so using code like document.location.protocol == “https” was done for these cases)
  • We take note of any special cases that a page may have just in case we are wrong

Once the above was done, we realized that many pages had offending javascript urls in them such as < script src=”http://…”/>. Thankfully, many of them were similar, but we had no way to change these pages programmatically…

  • Using the network tools in firefox/chrome, we made simple changes to test pages, and saw what endpoints were being called (similar to the above section). There is one for retrieving landing page fragments, and one for updating a single landing page fragment
  • Once we found the endpoints (see above, they work in a similar way) and necessary information required to hit these, we built a script to:
    • Find all landing page fragments of a given landing page using one of our new endpoints
    • Analyze the landing page fragments to see if they contained bad html
    • Use our other endpoint to send these updates to the proper fragment


Overall, we were able to address the five points that were standing in the way of migrating our client’s Marketo instance to https. We managed to find a way to automate much of the process without using any SOAP or REST API calls. We also had a way of testing our code before initiating our SSL certificate. Lastly, we had a way of checking/tracking our work since our data was gathered in javascript and the landing page info was gathered automatically.

Products Involved: Marketo;