AnsweredAssumed Answered

Rate limiting in the REST API

Question asked by 944305f82a3d29af645a1f0dd997d502eecbf9e5 on Jun 12, 2014
Latest reply on Jul 2, 2014 by 2039
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).