Skip to main content
Solved

Tips to avoid API rate limiting

  • February 23, 2022
  • 5 replies
  • 2171 views

Forum|alt.badge.img+2

Hi! We’ve been getting some rate limiting errors in our logs. We’re using the node-klaviyo package in NPM. The volume of usage of our service is pretty small, but we do envision scaling in the future. We are hitting the lists endpoint as well as the events endpoint each time we have a trigger event.

 

What I saw in the documentation about this issue is to utilize exponential backoff -- while a great suggestion, the necessity of this while our volume is still small would suggest that we are already bumping up against performance limits, that we would have to find some solution to this -- which could look like paying more money to increase the rate limits, optimize our usage of the API/avoid duplicative requests, or something else. 

 

Would love to discuss the following:

  1. Are there pricing options offered that would increase our rate-limits?
  2. Are there some tips/best practices on any particular kinds of API requests to avoid (because the rate-limit on that resource is smaller than the others)?
  3. Are there any optimizations to our flows that we could try?

Best answer by David To

Hey @henry_mcdonald,

Thanks for those additional details!

From your explanation, it certainly doesn’t sound like you should be hitting the API rate limit. Klaviyo’s rate limits are in line with industry standard limits similar to those of Google (2-20 calls per second) or Shopify (2-4 calls per second). 

In my experience, instead of hitting our API rate limit, I suspect you may actually be hitting Klaviyo’s list bomb limits since you’re hitting the list endpoint multiple times. 

When Klaviyo detects a large number of calls originating from the same IP address attempting to hit our list endpoint, the system will prevent these calls from fully going through. I’ve seen this happen when users are self testing in an attempt to simulate live traffic through their own system. Although the API can handle these limits, Klaviyo is suspect of these calls as they all originate from the same source. This is to prevent malicious actors or bots from bloating and inflating your email lists. 

One of the differences you’ll see between your calls being rate limited and hitting the list bombing limit is that you’ll actually receive an appropriate response code for the rate limit. When you hit the rate limit, you’ll receive a response code for a 429 error. Whereas you won’t receive any errors with our list bomb limit. The call to the list endpoint will return a 200 code indicating the call was made successfully as it was understood correctly. However in the backend, it would be blocked and you’ll notice the user was not actually subscribed to the list. 

To test this, I would suggest using a different network to make these calls such as through a VPN. In addition, I suggest including a one or two second pause made between each call as making these quick calls in succession can at times be known to cause a similar issue where these calls are being bunched together and potentially run into a race condition. 

I’ve also included some additional Community posts below that sound similar to the situation you are facing and hoping the discussions in them could help shed some additional light on your issue!

David

View original
Did this topic or the replies in the thread help you find an answer to your question?

5 replies

David To
Klaviyo Employee
Forum|alt.badge.img+60
  • Klaviyo Employee
  • 2456 replies
  • February 24, 2022

Hello @henry_mcdonald,

Welcome to the Klaviyo Community!

Typically, Klaviyo’s rate limit for API calls is fairly generous. However this would depend entirely on what it is you were trying to do and the volume. Can you share with us more details on what is you were trying to do to understand the situation a bit more? 

At present, Klaviyo doesn’t offer any addition plans that would increase the threshold on the rate limits of our API. 

David


Forum|alt.badge.img+2
  • Author
  • Contributor I
  • 1 reply
  • February 28, 2022

Thanks David.

For some more context, here is the flow of API requests:

  1. A users clicks on our service -- we add them to a list. If the relevant list does not exist, then we create the list and add them to it. Because of the find-or-create pattern here, this involves 2 or 3 API calls to the list endpoint.
  2. We send an event with a small(maybe 200 characters in total) JSON payload -- per usage of the service to the events endpoint. 

So in total, there are perhaps 4 requests to the Klaviyo API per “usage”. When I am testing, I might use the service 5 times  in 5 seconds, something like that -- it’s a little more load than we would expect to receive from our organic traffic, but it only happens as fast as I can open links -- there’s no bot that is running up hundreds of requests per second, or something like that.

Does it seem plausible to you that I would run up against the rate limits sending volume like this, which might amount to a handful of request per second? If not, then I guess we have a bug in our application and are sending many more than we realize.

 

Thanks so much. 


David To
Klaviyo Employee
Forum|alt.badge.img+60
  • Klaviyo Employee
  • 2456 replies
  • Answer
  • March 1, 2022

Hey @henry_mcdonald,

Thanks for those additional details!

From your explanation, it certainly doesn’t sound like you should be hitting the API rate limit. Klaviyo’s rate limits are in line with industry standard limits similar to those of Google (2-20 calls per second) or Shopify (2-4 calls per second). 

In my experience, instead of hitting our API rate limit, I suspect you may actually be hitting Klaviyo’s list bomb limits since you’re hitting the list endpoint multiple times. 

When Klaviyo detects a large number of calls originating from the same IP address attempting to hit our list endpoint, the system will prevent these calls from fully going through. I’ve seen this happen when users are self testing in an attempt to simulate live traffic through their own system. Although the API can handle these limits, Klaviyo is suspect of these calls as they all originate from the same source. This is to prevent malicious actors or bots from bloating and inflating your email lists. 

One of the differences you’ll see between your calls being rate limited and hitting the list bombing limit is that you’ll actually receive an appropriate response code for the rate limit. When you hit the rate limit, you’ll receive a response code for a 429 error. Whereas you won’t receive any errors with our list bomb limit. The call to the list endpoint will return a 200 code indicating the call was made successfully as it was understood correctly. However in the backend, it would be blocked and you’ll notice the user was not actually subscribed to the list. 

To test this, I would suggest using a different network to make these calls such as through a VPN. In addition, I suggest including a one or two second pause made between each call as making these quick calls in succession can at times be known to cause a similar issue where these calls are being bunched together and potentially run into a race condition. 

I’ve also included some additional Community posts below that sound similar to the situation you are facing and hoping the discussions in them could help shed some additional light on your issue!

David


Forum|alt.badge.img+1
  • Contributor I
  • 1 reply
  • April 16, 2022

I’m trying to download the full content of a list containing about 50K profiles, using the “Get List Members” endpoint: https://a.klaviyo.com/api/v2/group/<list_id>/members/all

 

While I’m iterating on the chunks of 1000 profiles (using the `marker` parameter) I find that if I don’t rate limit my requests at all, I get a 429 (request throttled) after about 45 requests (out of the 50 I need). With a 1 second sleep between requests, I can however complete the task.

 

My questions: is this limit specific to this endpoint, as you seem to explain above? Can I expect to NOT be throttled as severely when I will use the “Get Profile” endpoint, on every single profile ID I have in my list, to retrieve their full data? 50K sequential requests with a 1 second delay between them would be prohibitive for my application. I would ideally need to be able to launch as many concurrent “get profile” requests as possible, to complete the 50K profile data download as quickly as possible. Is this possible within the API usage rules and constraints?


David To
Klaviyo Employee
Forum|alt.badge.img+60
  • Klaviyo Employee
  • 2456 replies
  • April 18, 2022

Hey @cjauvin,

Depending on the endpoint you’re hitting, they’ll all have a rate limit. Some endpoints may have more bandwidth than others, but they would all fall within the industry standard rate limits of 2-20 calls per second as mentioned prior. The Get Profile endpoint would be no exception to this. 

David