Is there a way to know if a lead exists in a specific smart list by API call?

[Anonymous]

Hello,

    I wish to implement an API that gets lead identifier (id, cookie, mail) and a smart list id and returns a boolean response of whether the given lead resides in the given smart list.

   Is there any way to implement this logic by API?

Thanks

[SanfordWhiteman]

Nope.  Only if you duplicate the membership conditions of the Smart List in application code.

[Robb_Barrett]

leads don't "exist" in smart lists. They either qualify for the conditions or don't. It's like saying "Raise your hand if you're hungry." Right now, you're hungry. After lunch, you're not hungry. You don't "exist" as hungry, you just meet the qualifications at that time based on data you're reporting. If your logic says "If JUST ATE then NOT HUNGRY" then after lunch you don't qualify, but two hours later you do.

[Grégoire_Miche2]

Hi Robb,

I'll reuse the comparison. Thx

-Greg

[Anonymous]

Good explanation Robb.

Rajesh

[Dan_Stevens_]

Classic analogy, Robb! 🙂

[SanfordWhiteman]

As you've learned, Smart List membership is not a fixed boolean value. Nevertheless there's no theoretical reason why membership in a Smart List cannot be queried via an API -- after all, membership in a SL is a point-in-time boolean value in Marketo.

However, for theory to become reality, the server resources necessary to check an individual lead's membership would have to be cheap. That's far from the case: computing a complex SL is a resource-intensive operation.  To allow that operation to be triggered by API calls would just give another avenue for slowing down an instance.

[Robb_Barrett]

On the more useful end of the spectrum is the static list. You can use static lists as impromptu boolean fields. You can use them to show that, at some point in time, the person met that criteria without putting in a field.

To further my analogy: A smart list could say "Is currently eating lunch." Well, right now it's 9:00am in my timezone so no, I'm not currently eating lunch. However, let's say I put in a Static List called "Ate Lunch Today" and used it in a smart campaign. Now, as we all eat lunch, we get written to that static list. Some of us will skip lunch today and not get written to that static list.

The smart list will only show those of us who are actually nibbling on a sandwich as we speak. For me, that's probably some of my friends in Greenland. As they open up their lunchbox I write them to a list.

At the end of the day I have a static list of everyone who has eaten lunch today. This will remain forever. This is queryable. You can make a call to it and see if your friends are on there and invite them to lunch tomorrow since you know they're the kind of people who don't work through their lunch.  Lazy slackers.

[Anonymous]

Hi,

    First, thanks a lot for the response and explanation.

    Just few clarifications:

    The scenario i'm currently handling is accessing a customer's Marketo account only(!!) through the available API.

    One of the features we want to implement is to return a boolean answer, relevant only to the specific time the question was asked, which is: "is the given lead assigned (meaning, completed the rules that currently assign him/her) to the given smart list?

   The difference between a static and smart list is clear, the real question is:

   Can I, with API calls, track the rules and past activities of the lead and decide if right now he/she applies to be assigned for the given smart list.

    If I can do it, which APIs should I use?

Again, thanks for the help.

[SanfordWhiteman]

One of the features we want to implement is to return a boolean answer, relevant only to the specific time the question was asked, which is: "is the given lead assigned (meaning, completed the rules that currently assign him/her) to the given smart list?

If I can do it, which APIs should I use?

The only way to do this is to archive every single activity or dimension that could result in membership in the Smart List, every day.  Then (as I said above) reproduce the SL conditions in application code.  You will not have access to the Smart List definition itself but will have to keep it up-to-date.

I am hopeful that you will reconsider delivering such a project to the customer. It's a pretty unreasonable expectation to build an entire DW just for this.