Knowledgebase

Featured article

(Article Updated - August 2024) Overview A blocklist is a database of IP addresses or domains that have been associated with the sending of unsolicited commercial email or spam. Internet Service Providers (ISPs) and business email networks use information from blocklists to filter out unwanted email. As a result there can be a drop to inbox delivery rates if the IPs or domains involved with sending email are listed on a blocklist. Marketo’s Email Delivery and Compliance team monitors blocklist activity on our IPs and domains daily. When an impactful listing occurs, we reach out to the blocklist, attempt to identify the sender that triggered it, and work with the blocklist organization to get the listing resolved. There are thousands of blocklists, most will not have a significant impact on your delivery rates. Below, we have compiled a list of the blocklists that commonly appear across our sender ecosystem. Each blocklist has been grouped into a top tier (Tier I) by most impactful, to the bottom least impactful tier (Tier III). These may have little to no impact across our sender network. Tier I Blocklist Spamhaus (SBL) Impact: Spamhaus is the only blocklist that we categorize as a Tier I for a reason: it has by far the greatest impact on delivery. It is the most well-respected and widely used blocklist in the world. A listing at Spamhaus will have a negative effect on your ability to deliver emails to your customer’s inbox and can cause bounce rates of over 50%. Evidence suggests that most of the top North American ISPs use Spamhaus to inform blocking decisions. How it works: Unlike many blocklists, Spamhaus lists senders manually. This means they are proactively watching sender activity, collecting data, and base listings on a number of variables. Most commonly senders are listed for mailing to spam trap addresses that Spamhaus owns. Sometimes Spamhaus will list senders based on recipient feedback as well. Next Steps: Please note that every Spamhaus email can be quite different depending on the information provided and the nature of the listing . Because Spamhaus has multiple types of listings, the remediation steps are based on which type of blocklisting has occurred. We have listed the most common types to affect Marketo customers, from most to least impactful. Impact can range from a full block of top severity, to a partial block that is less severe (CSS Data, DBL). If remediation isn’t performed and the problem not addressed, these listings can increase in severity and turn into a full blocklisting. Spamhaus Blocklistings Types SBL (full blocklisting) Considered the most impactful. Remediation steps: Our team monitors closely for Spamhaus listings. Once alerted to the listing, we send an email notifying the customer, and reach out to the Spamhaus contact to start the remediation process. Only a Marketo delivery team member should be in direct correspondence with the Spamhaus contact, to speak on behalf of the customer, and to relay their questions and instructions, ensuring quick resolution and reduced impact. Senders that trigger this listing on a shared IP range will be moved to a more isolated, penalty range (IPB), so as not to impact the other shared senders. Those affected on a Dedicated IP, only impact their own sending and will not be moved. However, depending on the severity of the issue, our team may need to revoke a customer’s ability to send any emails until full resolution. The listing will last until Spamhaus is satisfied that the offending sender has taken the appropriate steps to mitigate the problem. SBL CSS Customers are alerted of the listing with an email containing all the information needed to immediately begin the remediation process. This is part of an automated trigger listing, that allows for a customer to delist directly on the Spamhaus website, after they’ve completed remediation. Remediation steps: Customers will go to the Spamhaus IP lookup website, at https://check.spamhaus.org, where they can check on the status of their IP and continue to monitor it in real time, until it is no longer listed there. Follow the remediation and delisting instructions provided, and check for specific details in the blocklist notification email. DBL (Domain blocklisting) Customers will receive an email notification alerting of the company domain being listed. The email will contain specific information to help narrow down and identify which email source likely triggered it within Marketo. It’s important to note that any email sent from outside of Marketo, that contained the company domain, is suspect. This means, if the sender uses multiple IPs and/multiple email platforms, then any of those could be the source. Remediation steps: Follow the detailed instructions in the email, which will also provide a link to the Spamhaus Domain reputation checker webpage, to check the real time listing status of the affected domain. Once the email source is identified and cause addressed, this customer will follow the online instructions to request to be delisted. Tier II Blocklist SpamCop Impact: SpamCop is not used by any of the major North American ISPs to inform blocking decisions, but it makes it to the Tier II list because it can have a significant impact on B2B email campaigns. SpamCop is considered a Tier I one blocklist for B2B marketers but a Tier II for B2C marketers. SpamCop is a dynamic IP blocklist, that can affect a single IP or a subset of IPs Typically, the block will automatically lift within one business day, but can take longer for relisted IPs. To have triggered a SpamCop listing likely means the sender has a list management problem that should be addressed. How it works: SpamCop lists IPs for one of two reasons: Either the email hit SpamCop spam trap addresses OR A SpamCop user has reported the email unwanted. Most of SpamCop’s spam traps are previously valid addresses that have not been active for 12 months or longer. Remediation steps: If you are seeing a significant number of bouncing emails caused by a SpamCop blocked IP but aren’t sure if your email activity triggered the listing, first identify whether you are sending on a shared sender network or not. If sending from a shared IP range when this occurs, you or any other customer sending from the same network may have contributed to the IP block. This IP block will automatically get dropped within a business day. For those on a Dedicated IP that trigger a listing, refer to the above remediation steps and resources, to address the list management issue. Tier III Blocklist (Low/ No impact ) These are considered the lowest tier and therefore cause the least impact across the Marketo sender ecosystem. Some of these blocklists were more impactful at one time, while others are only impactful based on the sender region (Manitu). Others still can suddenly flare up (Lashback). There are also many blocklists that are ignored (0spam), and are not taken seriously because they do not provide any means to delist once on the list (NoSolicitado) or that they charge money to have the listing removed ( UCEPROTECT ). The pay-to-delist model is not well respected in the email industry. When using blocklist tool checkers, such as MXToolBox, many blocklists will appear, but very few are relevant. Here is our selection of Blocklists you may come across that are least impactful: Project Honey Pot SpamAssassin URIBL/SURBL DrMX PSBL 0spam HostKarma Ascams ZapBL Barracuda Trendmicro Inc. Cloudmark Proofpoint Invaluement ISP Blocklists Some ISPs use internal blocklists to make blocking decisions. Examples include AOL, Yahoo, Gmail, Outlook and Hotmail. If your IP is being blocked by one of these networks, and those networks have a large presence in your lists, a block of this kind could have a noticeable negative impact on delivery. Marketo monitors for significant ISP blocks. Those experiencing deliverability issues with emails not making it to the Inbox and bulking in the spam folder may benefit from additional services with our Email Delivery Consultants. Remediation Steps: Email Delivery Compliance Team works to resolve any ISP blocks. ISP blocks are are usually resolved or lifted within less than 24 hours of a delisting request. Customers experiencing significant blocks for Microsoft domains (outlook.com, live.com, microsoft.com), can submit a request to the delivery team to seek mitigation on their behalf. Additional Resources: Blocklist Deep Dive Abuse Report Deep Dive What is a spamtrap, or spam trap, and why does it matter? Blocklist remediation Blocklist resolution flowchart Successful lead reconfirmation What is a blocklist?

What is the Email API? What is the Email API used for? What is Email 2.0? Does the Email API Work on Email 2.0 Assets? Will the Email API Break when Enabling Email Experience 2.0? How Are 1.0 Assets Upgraded to 2.0 Assets? What to Do When an Email Was Accidentally Converted to Email 2.0 format? What is the Email API? API stands for Application Programming Interface and the Email API allows an automated process to create and edit emails in Marketo. There are also other API calls that involve emails, such as Approve Snippet (assuming the Snippet is used in an Email) and Clone Program (assuming the Program contains Emails). There are also API calls to create and update Email Templates. Essentially, the API can do many things that you can also do through the Marketo user interface, but then in an automated fashion. What is the Email API used for? There are many scenarios: an external system could create Emails in Marketo using data that lives outside of Marketo. A translation service provider could clone a master Email, translate it to many languages, then save them back into Marketo as localized Emails. A reporting system could extract Emails from Marketo to use in reports that are generated outside of Marketo. An external system could Clone a Program that contains Emails, then populate the Program Tokens and schedule the Email to be sent out at a specific time. There could be an external email template creation system that creates new Email templates in Marketo through the API. What is Email 2.0? “Email Experience 2.0” is the new Marketo product feature with the enhanced email editor, documented here: https://docs.marketo.com/display/public/DOCS/Email+Editor+v2.0+Overview. It can be switched on in Admin > Email > Edit Email Editor Settings. All Emails and Email Templates also have a version number, either 1.0 (the old version) or 2.0 (the new version). If we refer to “Email 2.0 asset” we mean an email or email template in the new upgraded 2.0 format. Does the Email API Work on Email 2.0 Assets? Yes. Will the Email API Break when Enabling Email Experience 2.0? No. Enabling Email 2.0 will not automatically upgrade Emails or Email Templates to the new 2.0 format. The Email API can still create new Emails and Email Templates in the 1.0 format. However – after enabling Email 2.0 – any Email or Email Template that is created or edited and approved through the Marketo User Interface will automatically be upgraded to the 2.0 format. How Are 1.0 Assets Upgraded to 2.0 Assets? If you edit an “Approved" or “Approved with Draft” 1.0 Email with Email 2.0 enabled, the draft is converted to the 2.0 format. You can still discard the draft to go back to the approved 1.0 format. Once you approve the email and it becomes 2.0, the Email cannot be converted back to 1.0. If you edit a “Draft” 1.0 Email (never been approved), this will automatically be converted to 2.0 with no option to revert back to the 1.0 format. The same applies to Email Templates. What to Do When an Email Was Accidentally Converted to Email 2.0 format? If an Email or Email Template was accidentally converted to the 2.0 format, you’d have to copy the asset contents to a text editor, disable Email 2.0, then create a new 1.0 asset using the content that you copied.

Using the Marketo SOAP API, you can check whether or not your website visitors have filled out a form and present them content accordingly. The following code below is unsupported and is intended to help you develop your own solution. In the resources section of the Marketo website, we use this method for our premium content. For leads who have already registered, their links go directly to the resource. Leads who haven't registered are given links to a landing page. In both cases, the link appears the same. Behind the scenes, a cookie is used to store whether or not this lead has registered: If the user has the premium registration cookie, the premium links are shown. If the user does not have that cookie, the lead's record is retrieved via the SOAP API. Based on the lead's record: If the lead has a valid email address, the premium content links are shown and the premium registration cookie is set. If not, the premium content links are not shown. Instead, they take leads to a landing page to fill out a form. First, you'll need to develop a SOAP API connection to Marketo. The attached ZIP file has a sample connection PHP file. You'll need to make the following changes in this file: ... $this->access_key = 'Your API Access Key Goes Here'; $this->secret_key = 'Your Secret API Key Goes Here'; // // The endpoint is in the "SOAP API Setup" page in the Marketo Admin section // ex. $soap_end_point = 'https://xx-1.marketo.com/soap/mktows/'; // $soap_end_point = 'Your SOAP API End Point URL Goes Here'; // // Errors are sent to this email address. Your web server // must be configured to send email for this to work correctly. // // ex. $this->error_email_address = 'example@example.com'; // $this->error_email_address = 'Put your debug email address here'; ... After creating your SOAP API connection, the next step is to implement the logic that determines which content to show if the user is logged in or not. The get_premium_url_status() function returns true if the lead has the premium cookie or if they've filled out a form. Otherwise, it returns false. You can use that result to determine what content the lead should see. The attached ZIP file has a PHP file that contains an example of this check.

Issue Description The Get Lead Activities REST API is not returning any activities even though the lead referenced definitely has multiple activities of the type being called. REQUEST: https://[munchkinID].mktorest.com/rest/v1/activities.json?access_token=x&leadIds=123&nextPageToken=ABC&activityTypeIds=46 RESPONSE: { "requestId": "xyz123", "success": true, "nextPageToken": "ABC", "moreResult": true } Issue Resolution The Get Lead Activity REST API are reliant on timestamps for their nextPageToken. Each Get Lead Activity call will go through 300 activities of ALL types from the timestamp placed on the nextPageToken. This is supported by the article http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#/Activities/getLeadActivitiesUsingGET "By default, the endpoints mentioned in this section will return 300 activity items at a time. If the moreResult attribute is true, this means that more results are available. Continue to call the endpoint until the moreResult attribute returns false, which means that there are no more results available." Based on that, the reason why the API call does not return any activities is that it does not find any activities of type 46 in the 300 activities it checks from the timestamp placed on the nextPageToken So when making a Get Lead Activity call for a specific activity type, ensure that nextPageToken is as close as to the timestamp of the specific activities Is this article helpful ? YesNo

Marketo Champions are customers who have demonstrated outstanding leadership in the Marketo Community, are experts in Marketo products, are avid contributors in the social world, and are loyal advocates of the Marketo brand. Benefits and perks our Champions receive include: Access: Meetings with our product and marketing teams to give exclusive feedback Previews: Given early previews to products, features, and releases when available Publicity: Exclusive speaking opportunities at our annual Marketo Summit and other events Networking: Special networking events with Marketo executives and fellow Champions and semi-annual conference calls Ownership: Ownership of content and exclusive activities at our annual Marketo Summit that showcase your expertise and thought leadership Credibility: Special Champion badge on Marketo Community profiles, and profiled on Marketo's corporate website Sweet Swag: Champion-exclusive swag To find out more information and apply, click here. To view a complete list of current Champions, click here. Join the Marketo Elite Today!

Issue: I am looking for the ID to one of my campaigns for a SOAP API project I am working on. Solution: The ID can be found in the URL of the campaign. 1.1 Log into Marketo, under Marketing Activities, find and select the campaign in question. This is a article attached image 1.2 The URL to the campaign will look something like: This is a article attached image The Campaign ID is between "SC" and "A", in the above example it's "1150". This is a article attached image

Included in this article Note: This post will be updated to reflect changes made to activity records returned by the API due to migration to new infrastructure. Overview With the rollout of Marketo’s next-generation Activity Service beginning in May 2017, we will be unable to enforce the uniqueness or presence of the integer “id” field in activities, data value changes, or lead deletion records returned by Marketo’s APIs. This change will begin rolling out to all subscriptions over the remaining first half of 2017. To avoid service disruptions for integrations which retrieve activity records, the id field should be treated as optional. Cutover of this change will begin to affect subscriptions with the September (Q3) 2017 release. This change will affect the following endpoints: REST API Get Lead Activities Get Lead Changes Get Deleted Leads Add Custom Activities SOAP API getLeadActivity getLeadChanges The affected SOAP types are ActivityRecord and LeadChangeRecord. Examples The following examples show record types which will be affected. In both examples, the effected field is called “id.” Example REST Field: id Example SOAP Field: id FAQs Do I need to update my WSDL version if I'm using SOAP integration? Yes. The marketoGUID field will only be returned in activities when using the WSDL version 3.1 or later. The new URI will follow this pattern: https://{munchkinId}.mktoapi.com/soap/mktows/3_1 It may also be obtained through the Admin->Web Services menu in your subscription When can I expect to see each change? Beginning with our Q1 Minor Release on April 7th, activity records retrieved via Marketo’s SOAP or REST APIs will include a new field called “marketoGUID”. The value of this field will match the value of the “id” field, but will be a string type field. Some time after the Q2 release beginning May 17th 2017, the “id” field will stop being returned as part of these records, and the value of marketoGUID will become a 128-bit string. What do I need to do? If you are responsible for code that deals with Marketo activities, you should determine whether your code relies on the presence or uniqueness of “id” field for Marketo activities, and then remove that requirement. In an upcoming release, an additional string field called “marketoGUID” will be added. “marketoGUID” should be considered the unique ID for retrieved activities when it becomes available. If you are not, you should consult with your team and relay this message to the appropriate stakeholders. Who will this change affect? This change should only affect client and partner integrations which retrieve activity records from Marketo, and only if the integrations rely on either the presence and/or type of the “id” field in the response, or rely on the uniqueness of the field. After the rollout of Orion AS, and the disabling of activity writes to MySQL, the “id” field will no longer be available and will be supplanted by a unique string id field. Check out our documentation on the Marketo Developers Site here: https://developers.marketo.com/blog/important-change-activity-records-marketo-apis/

Issue Description You need to revert a data value change for a field on multiple leads. Issue Resolution There is no way through the UI to "undo" a data value change (unless it was a boolean field, in which case there are only two possible values.) You can certainly use a Smart List to identify whose values have changed, but there no way to go back to the old value (unless it's stored elsewhere in another field or through another data store, along with the API). However, you can use the API to extract the data value change activity from the activity log, which would include the old and new values, extract the original values, then use the API to rewrite the old values back to the lead record. http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#!/Activities/getLeadChangesU… Is this article helpful ? YesNo

Issue You are experiencing slow processing of campaigns, smart lists, and reports. Solution There are three key components that can slow down an instance: Number of trigger campaigns: Trigger campaigns are always on, always listening. If there are 50 campaigns triggering at the same time, all the 50 triggers will be in queue, slowing down your processing and routing inside Marketo. Solution: Reduce the number of Triggers. Convert some of the triggers to batches: Batches also run all the flow steps for every lead at once, instead of serially, which reduces total processing time. Complexity of smart lists: The more complex a smart list, the harder it is for the system to figure it out, which increases backend processing and even creates campaign failures from timeouts. Solution: Reduce the number of nested smart lists called in a smart list. Whenever you ask Marketo to call another Smart List, it has to wait until all of the other smart lists finish, before putting together the final counts. Instead of Marketo looking for the list and running it, just put the filters in the trigger itself. Volume of Leads: With regular cleaning and good systems design, it is fairly easy to keep your system running fast. Reduce the number of leads that can flow through with filters. Clean up the inactive leads at regular intervals.

This is a article attached image Upon signing a contract with Marketo you are provisioned a Marketo instance and a Support Service. There are four different types of Support Services which are available to meet different customer support needs: Online (Legacy) Business or PREMIER SUPPORT BUSINESS (Legacy) Premier or PREMIER SUPPORT ENTERPRISE (Legacy) Elite or PREMIER SUPPORT ELITE Each Support Service has a different Service Level Target (SLT). An SLT is the amount of time Marketo Support targets to make first contact with you after a support case has been submitted. SLTs differ for each Support Service and priority level. Priority levels range from Priority P1 to Priority P4. Here are the SLTs and priority levels for each Support Service: Priority Online (Legacy) Business PREMIER SUPPORT BUSINESS (Legacy) Premier PREMIER SUPPORT ENTERPRISE (Legacy) Elite PREMIER SUPPORT ELITE P1 1 hour 1 hour 1 hour 30 minutes 30 minutes 30 minutes 15 minutes P2 4 hours 3 hours 2 hours 2 hours 1 hour 2 hours 30 minutes P3 6 hours 5 hours 4 hours 4 hours 2 hours 2 hours 1 hour P4 3 days 1 day 1 day 1 day 1 day 1 day 1 day Here are the descriptions for each priority level: Priority Description P1 Mission Critical: Core business function down or potential loss of mission critical data P2 Urgent: Major feature or workflow is not functioning. Mission critical workflow and majority of user community is not blocked P3 Important: Normal usability or task completion is impacted but functional, or workaround is available P4 Minor: Minor issue requiring a correction. Normal workflow is not impacted Find more information About Support here!

Note: Please ensure that you have access to an experienced Web developer. Marketo Technical Support is not set up to assist with troubleshooting code. The listOperation SOAP API call allows for the ability to interact with static lists (My Lists) in the Lead Database. The supported operations are adding a lead to list (ADDTOLIST), checking if a lead is a member of the list (ISMEMBEROFLIST), and removing a lead from a list (REMOVEFROMLIST) Note, there is no operation to create a new list (or delete) via the SOAP API. The list must be created beforehand in the Lead Database. In the examples, the list is named "Static List". Example 1 - Request: Adding multiple leads into the list <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt = "http://www.marketo.com/mktows/"> <soapenv:Header> <mkt:AuthenticationHeader> <mktowsUserId>[User Id]</mktowsUserId> <requestSignature>[Signature]</requestSignature> <requestTimestamp>[yyyy-mm-ddThh:mm:ss-00:00]</requestTimestamp> </mkt:AuthenticationHeader> </soapenv:Header> <soapenv:Body> <mkt:paramsListOperation> <listOperation>ADDTOLIST</listOperation> <listKey> <keyType>MKTOLISTNAME</keyType> <keyValue>Static List</keyValue> </listKey> <listMemberList> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <leadKey> <keyType>IDNUM</keyType> <keyValue>215</keyValue> </leadKey> </listMemberList> </mkt:paramsListOperation> </soapenv:Body> </soapenv:Envelope> Example 1 - Response: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns1="http://www.marketo.com/mktows/"> <SOAP-ENV:Body> <ns1:successListOperation> <result> <success>true</success> <statusList xsi:nil="true"/> </result> </ns1:successListOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Example 2 - Request: Check to see if leads are a part of list. One lead (Lead ID #213) is and the other (Lead ID #70) is not <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt = "http://www.marketo.com/mktows/"> <soapenv:Header> <mkt:AuthenticationHeader> <mktowsUserId>[User Id]</mktowsUserId> <requestSignature>[Signature]</requestSignature> <requestTimestamp>[yyyy-mm-ddThh:mm:ss-00:00]</requestTimestamp> </mkt:AuthenticationHeader> </soapenv:Header> <soapenv:Body> <mkt:paramsListOperation> <listOperation>ISMEMBEROFLIST</listOperation> <listKey> <keyType>MKTOLISTNAME</keyType> <keyValue>Static List</keyValue> </listKey> <listMemberList> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <leadKey> <keyType>IDNUM</keyType> <keyValue>70</keyValue> </leadKey> </listMemberList> </mkt:paramsListOperation> </soapenv:Body> </soapenv:Envelope> Example 2 - Response: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.marketo.com/mktows/"> <SOAP-ENV:Body> <ns1:successListOperation> <result> <success>false</success> <statusList> <leadStatus> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <status>true</status> </leadStatus> <leadStatus> <leadKey> <keyType>IDNUM</keyType> <keyValue>70</keyValue> </leadKey> <status>false</status> </leadStatus> </statusList> </result> </ns1:successListOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Example 3 - Request: Similar to Example 2, but all leads are valid <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt = "http://www.marketo.com/mktows/"> <soapenv:Header> <mkt:AuthenticationHeader> <mktowsUserId>[User Id]</mktowsUserId> <requestSignature>[Signature]</requestSignature> <requestTimestamp>[yyyy-mm-ddThh:mm:ss-00:00]</requestTimestamp> </mkt:AuthenticationHeader> </soapenv:Header> <soapenv:Body> <mkt:paramsListOperation> <listOperation>ISMEMBEROFLIST</listOperation> <listKey> <keyType>MKTOLISTNAME</keyType> <keyValue>Static List</keyValue> </listKey> <listMemberList> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <leadKey> <keyType>IDNUM</keyType> <keyValue>215</keyValue> </leadKey> </listMemberList> </mkt:paramsListOperation> </soapenv:Body> </soapenv:Envelope> Example 3 - Response: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns1="http://www.marketo.com/mktows/"> <SOAP-ENV:Body> <ns1:successListOperation> <result> <success>true</success> <statusList xsi:nil="true"/> </result> </ns1:successListOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Example 4 - Request: Remove leads from the list. One lead (Lead ID #213) is a member of the list, the other (Lead ID #70) is not <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt = "http://www.marketo.com/mktows/"> <soapenv:Header> <mkt:AuthenticationHeader> <mktowsUserId>[User Id]</mktowsUserId> <requestSignature>[Signature]</requestSignature> <requestTimestamp>[yyyy-mm-ddThh:mm:ss-00:00]</requestTimestamp> </mkt:AuthenticationHeader> </soapenv:Header> <soapenv:Body> <mkt:paramsListOperation> <listOperation>REMOVEFROMLIST</listOperation> <listKey> <keyType>MKTOLISTNAME</keyType> <keyValue>Static List</keyValue> </listKey> <listMemberList> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <leadKey> <keyType>IDNUM</keyType> <keyValue>70</keyValue> </leadKey> </listMemberList> </mkt:paramsListOperation> </soapenv:Body> </soapenv:Envelope> Request 4 - Response: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://www.marketo.com/mktows/"> <SOAP-ENV:Body> <ns1:successListOperation> <result> <success>false</success> <statusList> <leadStatus> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <status>true</status> </leadStatus> <leadStatus> <leadKey> <keyType>IDNUM</keyType> <keyValue>70</keyValue> </leadKey> <status>false</status> </leadStatus> </statusList> </result> </ns1:successListOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Example 5 - Request: Similar to Example 4, but all leads are valid <soapenv:Envelope xmlns:soapenv = "http://schemas.xmlsoap.org/soap/envelope/" xmlns:mkt = "http://www.marketo.com/mktows/"> <soapenv:Header> <mkt:AuthenticationHeader> <mktowsUserId>[User Id]</mktowsUserId> <requestSignature>[Signature]</requestSignature> <requestTimestamp>[yyyy-mm-ddThh:mm:ss-00:00]</requestTimestamp> </mkt:AuthenticationHeader> </soapenv:Header> <soapenv:Body> <mkt:paramsListOperation> <listOperation>REMOVEFROMLIST</listOperation> <listKey> <keyType>MKTOLISTNAME</keyType> <keyValue>Static List</keyValue> </listKey> <listMemberList> <leadKey> <keyType>IDNUM</keyType> <keyValue>213</keyValue> </leadKey> <leadKey> <keyType>IDNUM</keyType> <keyValue>215</keyValue> </leadKey> </listMemberList> </mkt:paramsListOperation> </soapenv:Body> </soapenv:Envelope> Example 5 - Response: <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns1="http://www.marketo.com/mktows/"> <SOAP-ENV:Body> <ns1:successListOperation> <result> <success>true</success> <statusList xsi:nil="true"/> </result> </ns1:successListOperation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Related Learning Resources Marketo SOAP API Reference

Issue When retrieving result sets from the /rest/v1/activities.json end-point using a Paging Token, the result set returned by the API appears to be less data than what is in the Marketo UI. In this scenario, we're going to explore how and why Paging Tokens work when utilizing them in REST API calls. SCENARIO Say we wanted to grab all 'Send Email' activities (activityType = 6) that have occurred since 2024-04-12T12:00:00Z, and we're planning to pull these activities every two hours, and increment our paging token every two hours prior to making the /activities.json call to obtain the latest data. Current Time Apr 12, 2024, 8:00:00 AM (MST) == 2024-04-12T14:00:00Z What We Want 1. Retrieve all Send Email activities SINCE Apr 12, 2024, 6:00:00 AM (MST) == 2024-04-12T12:00:00Z We would start by retrieving our Paging Token with the sinceDateTime parameter = 2024-04-12T12:00:00Z: /rest/v1/activities/pagingtoken.json?sinceDatetime=2024-04-12T12:00:00Z Our response would contain the nextPageToken representing the sinceDateTime: { "requestId": "1607c#14884f3e74e", "success": true, "nextPageToken": "RW6ZK46LKV36BMJ2QARX3BFZHQNHRVPPEW4IZVEELI45V2OH6RCA====" } We would then pass that nextPageToken into our GET /rest/v1/activities.json end-point, as well as our activityTypeId = 6 to target all 'Send Email' activities that have occurred since 2024-04-12T12:00:00Z. /rest/v1/activities.json?nextPageToken=RW6ZK46LKV36BMJ2QARX3BFZHQNHRVPPEW4IZVEELI45V2OH6RCA====&activityTypeIds=6 After paging through all of the results (now leveraging the returned nextPageToken from the /activities.json end-point to page through all results), we've returned 15,000 Send Email activities. PROBLEM We know that, from our Marketing team, that we were expecting ~20,000 email sends since 2024-04-12T12:00:00Z. So why does the result set appear to be missing 5,000 records? Let's examine this further. 'Send Email' activities aren't committed to the Marketo database until the message has successfully been sent from our mail servers. Prior to that, the email is queued, awaiting it's launch to it's receiving mail server. This can present a delay from the time the email is sent, to when the activity is recorded to the Marketo database. For example, say there were two campaigns sending 10K emails each: First Campaign Send: 2024-04-12T12:30:00Z (30 minutes after our sinceDateTime token) Second Campaign Send: 2024-04-12T13:45:00Z (110 minutes after our sinceDateTime token, 10 minutes prior to when the call was made) While the first campaign send is most likely accounted for in the database (Send Email activities have been committed), Campaign #2 is still processing and sending out all 10K emails in the background. For this scenario, Marketo has only committed 5K out of 10K email sends to the database at the time the call was made. Without noticing the missing data, you repeat this process two hours from now, incrementing your sinceDateTime token by two hours as well, assuming you'll get all the new Send Email activities for the past two hours. This would now lead to you missing the 5K Send Email activities that were still being processed, but not yet committed to the database. SOLUTION The nextPagingToken returned in the /activities.json end-point is position based, and can only pull data that has been committed to the Marketo database, which inherently changes as records are being processed. If, for instance, you made the original /activities.json call at (Apr 12, 2024, 8:00:00 AM (MST) == 2024-04-12T14:00:00Z), and used the same sinceDateTime token 5-10 minutes later (Apr 12, 2024, 8:10:00 AM (MST)), you would now notice that campaign #2 has fully finished it's processing AND committed the 'Send Email' activities to the Marketo database with dateTime stamps less than Apr 12, 2024, 8:00:00 AM (MST). So, what's the best way to ensure you're retrieving all the data? Solution #1 Increment your sinceDateTime token based on the MAX(created_at) dateTime returned in the latest result set, rather than incrementing it based on an interval (every two hours). This would help ensure you're not missing records that were processing, but not yet committed to the Marketo database. Solution #2 If the data you're retrieving does not need to be live, we would recommend using the Bulk Extract API to pull this data at a lower frequency (such as twice per day 12AM & 12PM). This would greatly decrease the chances of missing records that weren't committed to the database.

Summary This article explains why certain Company fields show up on the Person/Lead Object when you do a describe API call to Marketo. Issue When making the Describe call on the Lead object in Marketo (/rest/v1/leads/describe.json), several Company object fields are returned along with the Lead object fields. Environment Marketo REST API Solution This is expected behavior. Users can utilize the Describe Leads call to retrieve a full list of the fields available for interaction via the REST API. Several areas within Marketo treat custom Company fields as though they were on the Person/Lead object. For example if you were doing a Bulk Import, you can target the Company and Person/Lead fields and you have the ability to update Company field values as if you were changing it manually on a Person record in the UI. Root Cause This is expected behavior, due to how the Describe call retrieves all

Issue Customers may run into limitations with Webhook providers or other third party REST services that require their fields are an integer type field. This may present issues with those values being inputted to Marketo (and other systems) accurately if a record has a value outside of the integer value limitation range: -2147483647 to 2147483647 Environment Marketo/Third Party REST/Webhook Providers Solution There is no way to increase/modify the integer value limitations on the Marketo side. This is not a Marketo product limitation, it's the defined constraints of Integer data types. If you're running into issues with values from a third party/webhook provider falling outside of the limitation range, this will present issues with the field value being accurately logged in Marketo. In this scenario, it's worth checking with the third party/webhook provider to see if they have any flexibility around which field types they can allow (for example, String or Float type fields have less limitations and will allow for larger or smaller numbers outside of the -2147483647 to 2147483647 range). For a full overview of Marketo field limitations, you can visit the below article: Marketo Field Limits by Field Type

Issue When using the [mktorest.com/rest/asset/v1/emailTemplates.json] end-point to pull all Email templates, the COUNT is much less than what is shown in Marketo's Design Studio Global Search. Solution This is the expected behavior. When viewing the total count of Email templates in the Design Studio UI, it will count EACH shared template that is shared across other workspaces, counting the same template multiple times depending on how many workspaces it's shared to. However, when retrieving the Email Templates from the REST API, it will only return DISTINCT Email Template ID's from the originating shared workspace where the template resides. It will not return the templates from the shared workspaces. Root Cause REST API Expected Behavior

Issue Executing a GET API call to retrieve a list of available activity types in the target instance using the '/rest/v1/activities/types.json' endpoint, resolves with an unexpected attribute name for a field with the display name ID in the context of Marketo Custom Objects. An example of that may be a Marketo Custom Object with the following name: '3 to be', as can be shown in the image below: One of the '3 to be' Marketo custom object fields name is 'ID'. (highlighted in red). When performing a GET API call using the '/rest/v1/activities/types.json' endpoint, you will be getting a list of available activity types in the target instance, along with associated metadata of each type, however for a Marketo custom object with an ID field name, you may see it returns back with a slightly different name, in this case, it would be returning the following output for my test Marketo Custom Object activity: { "id": 100019, "name": "Add to 3 to be", "primaryAttribute": { "name": "3 to be ObjRef", "dataType": "integer" }, "attributes": [ { "name": "3 To Be Person Id", "dataType": "integer" }, { "name": "ID (3)", "dataType": "string" }, { "name": "Linkfield4", "dataType": "string" } ] } ], Here's an image of what it may look like when making the call using POSTMAN: In fact, the character in the brackets next to the ID field represents the very first character of your Marketo Custom Object name. Environment Customers who have Marketo Custom Objects where one of the custom object fields is named 'ID'. Solution If this is interrupting your business, you may want to select a different name for the ID field under your Marketo Custom Object. (ie. ID number, Transaction ID etc.) Root Cause This behavior is expected and is a result of the 'ID' field being a unique field in the context of Marketo custom objects world and while it may be possible to create a Marketo Custom Object field with the name 'ID', it may be better to give it a distinct name that will be better describing what kind of ID field it is.

Issue Per our developer page: https://developers.marketo.com/rest-api/assets/programs/#update, it is possible to update tags on your existing program When updating a program tag within an existing program, you may encounter an error below given the tag and its values are correct. {"code": "709","message": "Required tags are mandatory"}]} Environment Any API clients when performing the Web Service API Solution The workaround is to have the tag updated via the UI. Root Cause "Updating tags is a destructive operation." Any attempt to update the tags of a program must include valid values for all of the required tags for a program. Unless the 'specific' tag type you are working on is the only required tag type in the instance, then that is possible to update it using the API. Otherwise, you'll encounter the error above as it is a system behaviour.

Summary Estimating the external storage requirements for your Marketo Engage Database Issue I want to extract all of my data from Marketo Engage and store it. How much storage space will I need? Environment Marketo Engage and External Systems Solution Summary There is no repeatable method to accurately estimate the amount of storage you will need to extract and store your Marketo Engage database. Standing in the way of good estimation is data availability, field selection, and storage method. Any accurate estimate will take into account the potential sizes of each type of data and their quantities (known to data scientists as "facts and dimensions"). Determining ranges for these values takes a lot of preparation and may require a high level of skill. IMPORTANT NOTE: Estimating Database size is hard so any estimate used to make business decisions should be made in cooperation with a database or application architect or other qualified professional. Scope Some information won't be extracted. Information about anonymous leads, for example, cannot be extracted. Some of the data that can be extracted may not be needed at all. Selecting the right data for your needs is the best practice as it reduces the required storage and leads to a more efficient extraction process. Field Definitions How the fields are defined in the target system will affect how big the stored data is. Depending on your storage format, padding may play a role in the size of your extracted database. As an example, the "Country" field in Marketo is a string of up to 255 characters. You could chose to store 255 characters for every country value. Or you may choose a format that uses a variable amount of space. You might also know that the longest country name is "the United Kingdom of Great Britain and Northern Ireland" meaning that 199 of those characters will always be extra so you truncate the value from Marketo storing the first 56 characters only. Each choice will have an impact on the size of your extracted database. Estimating 199 unnecessary characters per lead and making similar decisions for other fields will add up to increased storage requirements and slower extraction time. Format Once the desired data is identified, the next step is to extract, transform and load (ETL) the data from Marketo Engage into your storage system. The data returned by Marketo's API is plain old text which is usually formatted as JSON or CSV. For the information to be useful, you will transform it from JSON into the format necessary for your storage system. That format could be an Excel spreadsheet, Microsoft SQL database or a schema-agnostic database like Azure Cosmos DB. How the data is formatted and encoded will make a big difference in the amount of storage needed. Take this simple example: a Microsoft Excel spreadsheet with "Marketo Engage" in cell A1. I saved that same file in four different formats which resulted in files ranging from 1 KB to 25 KB. The format you store you information in may have a bigger impact on your final storage requirement than the data itself. This is a article attached image To help illustrate the impact of the storage system, take a look at this guide for Microsoft SQL Database size estimation: https://docs.microsoft.com/en-us/sql/relational-databases/databases/estimate-the-size-of-a-database Functionalization Once you've extracted your data, what are you going to do with it? Archiving your data (simply storing it) is easiest and comes with the fewest contraints. A compressed archive (Zip file) will save dramatically on storage space at the cost of functionality and ease of use. Functionalizing your data (using it in an application) requires more: at least better speed and searchability: typically a relational database. An application will often require additional data and that will need to be accounted for too. Facts and Dimensions: Do the Math It's a lot of work to get to this stage. Once you've determined how your extracted data will be stored, you can set upper and lower bounds on the sizes for each object type extracted (lead, email, activity, etc). These are your facts. Then multiply those values by the number of each type of record. These are your dimensions. Add to that the overhead of your target storage system and its functional requirements to generate your final estimates.

Summary Creating many-to-many relationships with Marketo custom objects requires an intermediary object with one link to a Lead or Company and another link to a secondary custom object. Here's how to solve the problem of the secondary custom object not showing up to be selected as the linked object. Issue Creating a many-to-many or N:N custom object structure such that a lead or company can be associated with multiple custom objects and a custom object can be associated with multiple leads or companies at the same time. When adding a link to the secondary custom object, that secondary object is not list as an available linked object. Solution If you find that the custom object you'd like to link to is not list in the "Link Object" list, there are two things two check: The secondary CO must be approved. The secondary CO must not have any link type fields. Since it's not possible to change a link field once a custom object is approved, if you already have link fields, the only solution is discard the secondary custom object and create a new one. Recreate the custom object without link fields. Then, in the intermediary object, the target object will show up as an available link object. More detail can be found at: Understanding Marketo Custom Objects Add Marketo Custom Object Link Fields - Create a Link Field for a Many-to-Many Structure Root Cause The secondary custom object type is not approved. - or - The secondary custom object type is approved type and has link fields. Environment Marketo Custom Objects Many to Many Relationship - N:N Link Fields

Note: Once you have migrated to Admin Console, you can manage your support cases through the feature provided in the Admin Console Platform. To learn more, visit: https://experienceleague.adobe.com/docs/customer-one/using/home.html. Once you have submitted a case to Marketo support, we provide a simple way of staying connected to your case and the cases submitted from your company through the Marketo Support Portal. You can access the support portal through your Marketo instance by selecting Community in the top right corner: This is a article attached image You can also access the support portal directly at https://support.marketo.com and login with your Marketo credentials (login and password). This will not work for users with SSO. Once you are in the support portal you can Create a Case for Marketo Support or you can also review any cases that are open and being worked on by support or review your case history. Navigate to My Case management: This is a article attached image From the My Cases navigation you can access the following case views: This is a article attached image My Recent Cases* - Cases that you have opened in the past 30 days All Company Recent Cases* - Cases that any authorized support contact has opened in the past 30 days My Open Cases – Cases created by you that are being triaged by Support and pending Support’s response and are more than 30 days old My Closed Cases – Cases that were created by you and are now closed My Awaiting Fix Cases – Cases that were created by you where Marketo is developing a fix which will be implemented at a later date All Company Closed Cases – Cases that were created by you or your colleagues that are now closed All Company Open Cases - All open cases submitted for the account Company Awaiting Fix Cases – Cases that were created by you or your colleagues where Marketo is developing a fix which will be implemented at a later date Management Escalations - Escalations opened by you or your colleagues Survey Cases - Surveys that are available for you to fill out after a case is closed *Cases that have been opened for more than 30 days will move from Recent cases to Open cases To view specific case details, click a case number. This is a article attached image From the Case Details, you can perform the following: Close your Case - Select the "My Case is Resolved" button to close your case Add Comments - Provide additional comments to support or respond to a Support question Add Attachment - Provide any screenshots or documents that will help illustrate the issue you are reporting If your case has been closed there are two options available to you. Reopen - You can reopen your case if you are not satisfied with the case resolution by adding a comment in the case. Case Survey - Once your case has closed, please consider offering feedback on the level of Support you received.

Knowledgebase

Maintaining a Directory of Leads Bouncing Emails

Top Blocklists - What You Need to Know

Email 2.0 and Email API FAQ's

Checking for User Registration Via SOAP API

Get Lead Activities REST API is not returning any activities

Marketo Champion Program

Find A Marketo Campaign ID

Customer User Guide - Marketo Customer Support Links

Important Change to Activity Records in Marketo APIs

How to revert Data Value Changes

Marketo Running Slow

Service Level Targets (SLT)

Example SOAP API Call - listOperation

REST API Paging Tokens Use Case

Company Fields Appear in Lead Object "Describe" API Call

Can Marketo Increase The Max Integer Value Limit of 2147483647?

Email Template Count Different in UI When Compared to REST API Count

Get Activity Types via API returns a character wrapped in brackets for a Marketo Custom Object field named ID

API Error 709 When Updating Tags of an Existing Marketo Program

How Much Storage is Required to Extract My Entire Marketo Engage Database?

I can't add a link from one custom object to another.

Managing your Support Cases