4 Replies Latest reply on Jul 2, 2014 4:31 PM by 2039

    Rate limiting in the REST API

      As a third-party developer, I find the approach to rate limiting taken in the SOAP APIs straightforward and easy to understand. There, rate limits pertain to my users, so it's pretty easy for me to explain to them what's going on in ways that give them control over their experience. The primary complicating factor is the fact that results may be paginated and that paginated results will result in using additional API calls against their quota; that's a complication but it's not too bad.

      The first version of the Early Access REST API seems to be a place where Marketo is experimenting with a number of other approaches to rate limiting. These include:
      •           Total results -- Get Multiple Leads by Filter Type. If the filter matches 300 or fewer leads, all of those leads are returned. If it matches 301-1000 leads, 300 leads are returned, along with a warning that "more results are available". It doesn't appear that there's a way to access those additional leads directly, and the doc doesn't (yet) address how that warning is delivered. If the filter matches more than 1000 leads, no lead info at all is returned and an error comes back (somehow) saying that too many results match the filter.
      •           Pagination -- Get Multiple Leads by List Id. This works pretty much like pagination in the SOAP API. (Seems likely that an upcoming version of the doc will document a maximum batch size, at which point "pretty much" will give way to "exactly".)
      •           App-based usage limits -- Get Multiple Leads by List Id (and others?). If my third-party app, operating on behalf of a potentially large number of users, makes more than 100 api calls in a 20-second window, those requests may start failing, so my app will need retry logic.
      •           User-based usage limits? Not visible in the current doc but I know the current doc is definitely not the final doc.
      Of these approaches, I guess it's not terribly surprising that I find the pagination and user-based approaches more congenial (as a third-party developer) than the total results and app-based approaches.
      •           The total results approach doesn't seem too bad for an interactive application (like maybe an analytics front-end) -- put up a dialog, user chooses a filter, api call is made immediately, user can respond to the results immediately by either using them or narrowing the filter. But for an automation app, intended to be specified once and then run autonomously at regular intervals, it works less well. Even if the app can efficiently notify the user that the limits are being exceeded, what the user really wants is to set up their automation once and not have to worry about it, much less have to fiddle with it on an ongoing basis.
      •           The app-based approach, as presented in the doc, seems fairly innocuous to start with -- if you exceed the limit, you just wait a bit and retry. But in the context of an app intended to be used by a large number of users, it becomes kind of difficult.           
        •                     The problem being encountered may not be the fault of any individual user and certainly can't be "fixed" by any individual user.
        •                     A paginated API like Get Multiple Leads by List Id is relatively likely to cause a number of API calls to be issued and there's no way to discover this in advance.
        •                     The existence of the approach makes me wonder if my app could wind up being blacklisted if it issues too many calls in too short a time? That would transform my requirement from "be ready to retry" to "make sure this never ever happens". (Which would not be unique to Marketo.)
        •                     But really, the biggest problem is that the more successful my app is in attracting users, the more likely it is that the app will run afoul of this problem. That seems like a strange way to build an ecosystem (speaking as one who has never built an ecosystem, so take it for what it's worth).
             
      Now that at least part of the REST API has been officially announced, I'm hoping that at least some of this will be considered and more fully documented (or maybe even alleviated).
        • Re: Rate limiting in the REST API
          Hi Edward,

          Long comment, so let me slice this up for a bit and talk about each:
          •           Total Results - The reason we have this cap in place is that fetching leads by a value in a field is designed for that value to be mostly unique. If we get a ton of leads back, it's clear it wasn't unique enough. We'll be providing other mechanisms (like the List option) for getting large chunks of leads
          •           Docs - The beta documention is a work in progress, so we'll be more precise with the GA version, and I want that to continue to improve over time as well
          •           Concurrent Request Throttling - That is the 100 per 20 second piece. This isn't rare in APIs, basically we don't want too many calls in a very short period of time
          •           Total Calls - This is the same as SOAP, but we will actually enforce it from the beginning
          Now, the other thing to keep in mind is that these caps are per integrated subscription not per app. So, if your application takes off, you'll have more calls because you'll be working with mroe customers.
          • Re: Rate limiting in the REST API
            Erik, thank you! Having those caps be per integrated subscription answers my biggest worry with respect to concurrent request throttling (which I agree is common) and is a great relief in general.
            • Re: Rate limiting in the REST API
              Hi Erik,
              In my cenario I need to be updated for all the leads that created or modified and I can't see a way to do it via the REST API.
              Query by list id is not helping me since I don't know what are the user lists and their semantic.
              What I expected in the first place is query by a filter (using created or modified fields using <>=) of course with paging.
              What do you think?
              • Re: Rate limiting in the REST API
                We'll add in support for querying leads by date of last change. That's targeted to come out in the next few months. In SOAP, you can do this with the getMultipleLeads or getLeadChanges APIs.