Skip navigation
All Places > Products > Blog > Authors James Laughlin

Products

2 Posts authored by: James Laughlin Employee

I recently received a request from a customer who was trying to update a person's email address via the API. He was trying to use the Create and Update Lead API, and because the lead had a new email address, he was getting a duplicate person record created with the new email address. What he wanted was to update the existing Person record with the new email address instead.

 

 Since I have had this question a few times, I thought it would be helpful to write a blog post about it.  The steps to follow are below, but...spoiler alert....the answer is to use the Sync Leads Using Post endpoint instead.

 

 In order to update the right Person record, I'll need the Marketo Person ID for that person.  I can get that using the Get Leads By Filter Type endpoint like this: 

 

 

Once I have the id of the Person record, I can call the Sync Leads Using Post endpoint to update that record. As you can see from the screenshot below, I’m passing in an action of “updateOnly” and  “id” for the “lookupField” value. Then I can pass the information in the “input” that I want to be updated; namely email in this case.

 

To verify that the email address was changed, I can make the  Get Leads By Filter Type call again and pass the new email address. 

 

Finally, there are several ways to get the person id that you’ll need to do this with.  You can either do a Bulk Lead Export if there are a lot of them or you can call Get Leads by Filter Type if it's a one-off, and you need to look it up by email address. 

 

Many of our customers have complex business requirements that require more than what the baseline Marketo data model can support. That's why we have Custom Objects in Marketo. Custom Objects allow the customer to support more advanced data models in Marketo, but there are some best practices to follow when using them.

 

Measure Twice. Cut Once

 

When you first design your Custom Object, we advise to take your time and get all of the fields correctly defined before you approve the object. The reason for this is data contiguity. When you approve the custom object, Marketo creates a table in the database for that object definition.

 

If, at a later time, you decide that you need another one or more columns, and you simply add them and approve the object again, the additional columns will not be stored in the same table as was created in the original object definition. Going forward, you'll have data in two different tables for that object, which will require Marketo to use a join whenever it access that object. This can have an adverse effect on the speed of data retrieval from Marketo instance, impacting script execution, data access via the API, and even the user experience in the Marketo web UI.

 

As an alternative, you could always drop and recreate the Custom Object with the correct columns, but then you would have to migrate the data from the old Custom Object to the new one which adds a level of complexity that most of our customers don't want to get into. The best option is to get it right the first time; like woodworkers say: "Measure twice. Cut Once."

 

Recreating a Custom Object

Just in case you find yourself in a position to need to rebuild your Custom Object, here are the steps you'll need to follow to do it correctly: 

  • Stop any third-party integrations that are using the Custom Object via the API.
    • This will prevent any third-party systems from trying to access the Custom Object via its API while you're rebuilding the object.
  • Remove all references to that object in filters, flow steps, smart lists etc. 
    • This will prevent any trigger campaigns from executing based on your work.
  • Write down the exact spelling of the Custom Object.
    • So you can recreate it later
  • Delete the Custom Object 
    • Depending on how many rows of data are in the Custom Object, you may have to ask support to do this.
  • Wait for about 15-30 minutes to allow Marketo to confirm that the Custom Object is fully deleted
    • This ensures you can recreate the object with the same API name.
    • If you just delete and recreate the object with the same API name, the recreate can fail.

 

Don't Use Custom Objects as a Data Land Fill

Many of our customers do regular bulk exports of their data for storage in a data warehouse of some other third-party analytic system. If your Marketo instance is full of Custom Object data that is not, and never will be useful for that analysis, your exports will take longer and have a more significant effect on your API rate limits. 

 

To avoid allowing your Marketo instance to fill up over time with useless data, it's best to make sure to use your Custom Objects to store only data that is useful now, or in the future. Things you should not store in a Custom Object include:

  • Transient information  - Activity data should be stored in a Custom Activity instead
  • Order history - Consider purging old data from time to time
  • Any data that will not be used for marketing activities

 

Deletion of Custom Object Data

If, after following the steps above, you still need to purge data from your Custom Objects you can do this through the API. Use the Delete Custom Objects endpoint, and remember to batch your calls in order to do up to 300 rows at a time. This will save you from using up your API rate limit.

Filter Blog

By date: By tag: