I keep getting this error on Keap when I make a single api key. It worked a few times running it as a script but when I run it on my local server it gives me this error:
{‘code’: ‘429’, ‘message’: ‘Quota Exceeded’, ‘status’: ‘Request Throttled’, ‘details’: None}
Can someone please help this is quite urgent because my new customers need a reliable system to receive emails & updates
I am using Keap Max Classic
Thank you.
Good morning!
That message indicates that you are sending requests too quickly to our APIs. If you are using a Service Account Key or Personal Access Token for your requests do note that the limits are lower than if you follow our OAuth2 Access Code flow.
https://developer.infusionsoft.com/faqs/how-does-throttling-work/
Hi @TomScott ,
We’re using the service token to write a form to the leads area. We have a sleep(1) before every call and we still get intermittent 429s. We’re trying to understand if we have 5 queries per second, why this would happen?
For transparency into the precise mechanism the throttle is controlled by a SpikeArrest policy in our proxy.
We are using a configuration property of UseEffectiveCount=true that allows for “bursty” traffic, with the Rate=5ps for Service Account Keys.
@TomScott Still doesn’t understand why we would hit 5 requests per second when we are not. Maybe it queues on your end?
We are rebuilding everything to log our form into a local DB, and then every minute do our API work, with 5 seconds between every call, and wait another minute to do the next one.
If you could help me further clarify what we may be missing, that would be great.
I’m not sure why you would be seeing any performance below the 5ps mark that we have configured, unless you are consuming the same key via multiple threads simultaneously. I would recommend logging the headers that are returned on each call to see exactly how fast you are consuming call quotas.
https://developer.keap.com/api-token-quota-and-usage-measurements/
nope, we dont have any services using the same key via multiple thread simultaneously.
since we kept getting the 429 errors, we finally use queue and sleep(5) between each requests.
its been working great so far but then we caught 429 errors at least 5 times. since we kept getting it, we finally build another logger to log just the keap response to observe the header. its attached as CSV.
we also for whatever reason caught 405 error (method not allowed) for a working endpoint – might just be a glitch on keap end.
please see attached pdf to see the keap headers between 5 requests that has 5 seconds gap per request.
keap-429-errors.pdf (48.6 KB)
We’ve encountered the same issue. The support’s response was, in essence (I hope they don’t mind I post it here, since this should seemingly be a common knowledge):
“these 429 throttle responses are in error - you are not actually hitting any limit, spike or otherwise. There’s apparently an issue known to the public API development team that they’ve been working to resolve with Google, where spike arrests are triggering improperly. They were able to confirm that this issue was the cause for this 429 response. The quotas shown are not incorrect; the error message was incorrect.”
“HTTP/2 429 will show in the response headers for both the unexpected Google-side errors as well as legitimate spike limits. Unfortunately, legitimate spike arrests and false alarms will show exactly the same. The reason why we can’t provide more information on spike arrests in the header, such as -available or -used, is because no such values are provided by Google Cloud for us to use.”
As a solution, we’ve added a handler for these 429 error responses. In general, it catches the error, sleeps for a second if it happens, then tries repeating the request, but does so not more than twice. This approach is working fine for us so far.
For further clarity, we have observed that 429 issue to only occur inconsistently on the very first call in a 24h period for PAT/SAKs. Retrying the call with exponential backoff for a limited number of times will handle this error transparently and is good practice regardless, and can be configured in many libraries.
axios-retry - npm is a common one that we use internally for our JS projects which allows a simple configure like that.