export leads that have not unsubscribed using rest api | Community
Skip to main content
A
Anonymous
January 16, 2017
Solved

export leads that have not unsubscribed using rest api

  • January 16, 2017
  • 1 reply
  • 2901 views

I'm unable to export leads using /rest/v1/leads.json that have unsubscribed.

I keep receiving an error message that filtertype of Unsubscribe is not supported.

Can someone help explain how to go about performing a REST API export of non-unsubscribed leads please, or point out what I might be doing wrong?

As far as code I have been using existing examples, and can poll the interface.  However I find the use of the leads export functions very limiting at the moment.

Thanks.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

Great way of dealing with the issue (the epoch integer column).

Doesn't this approach still have the issue of too many results returned (based on the 1k limit)?

Arent these approaches limited to Static Lists vs Smart Lists?

Thanks for taking time to respond.


Doesn't this approach still have the issue of too many results returned (based on the 1k limit)?

Depends on your volume. You can use epoch hour if epoch day returns too many (store both values). The point is to get granular enough to still be able to do bulk queries and conserve API calls, but no more granular than necessary.

Arent these approaches limited to Static Lists vs Smart Lists?

When you're pulling based on the filter, this doesn't relate to either kind of list.

1 reply

Jim_Thao7
Jim_Thao7
New Participant
January 20, 2017

It's because the unsubscribe field is a boolean field.  I would recommend to review this page: http://developers.marketo.com/rest-api/lead-database/leads/#describe

Here's a copypasta for the section that refers to your questions:

Get Leads by Filter Type will return the same type of records, but may return up to 300 per page.  It requires the filterType and filterValues query parameters.

filterType will accept any non-boolean field to filter on, which you can list using the aforementioned Describe method.  When searching by custom field, only the following data types are supported: string, email, integer.

filterValues will accept up to 300 values in comma-separated format. The call will search for records where the lead’s field matches one of the included filterValues.  If the number of leads matching the lead filter is greater than 1,000 an error is returned: “1003, Too many results match the filter”.

One way to go about it is to create a string field and have it populated via a smart campaign by referencing the unsubscribe field.  EG. If Unsubscribe = True then CDV for said field with "Unsubscribed" or some variation of that.   Then, field on that field in your REST call.  You're going to need to build in logic to manage this smart campaign too because if some records subscribes again, you're going to want to update that field.

    SanfordWhiteman
    SanfordWhiteman
    New Participant
    January 20, 2017

    Prob is another string field that still is implicitly boolean is going to return too many results.

    We do this by storing the epoch day (i.e. epoch time at 00:00) of the last unsubscribe in an integer field unsubscribedAsOfDay. This is an integer field with the right cardinality for the filter (you can iterate day-by-day, get yesterday's only, etc.)  For example, today, 2017-01-20, is 1484870400. The value is empty when Unsubscribed is false.

    You could also use the epoch week if you don't have a lot of traffic. Key is to use a filter-compatible field with a semantic relationship to the unsubscribe action and obvs. the day they became unsubscribed is a good fit.

    A
    Anonymous
    February 16, 2017

    Great way of dealing with the issue (the epoch integer column).

    Doesn't this approach still have the issue of too many results returned (based on the 1k limit)?

    Arent these approaches limited to Static Lists vs Smart Lists?

    Thanks for taking time to respond.

    Terms & ConditionsAccessibility statement

    Loading footer...