Hi there@alexoanea,

Welcome to the Community,

A relatively common reason for this is if you have a firewall or other security measures in place that may be rate-limiting or blocking Klaviyo after detecting large transfers of data. The solution to this is to whitelist Klaviyo. As Klaviyo uses dynamic IPs, we do not provide a range of IPs to customers. Instead, we recommend whitelisting our user agent, which is: Klaviyo/1.0

This could also be due to a bad API key, syntax error, or due to be running from javascript. See "group memberships" in the API documentation.

If not, it could be that you're using our server side endpoint for a client side call. If this is the case, I would recommend switching this as I don't think we will allow cross origin requests.
Here is an example ajax call that you should be able to utilize if you're sending from the client side:
 

var settings = {
  "async": true,
  "crossDomain": true,
  "url": "https://manage.kmail-lists.com/ajax/subscriptions/subscribe",
  "method": "POST",
  "headers": {
    "content-type": "application/x-www-form-urlencoded",
    "cache-control": "no-cache"
  },
  "data": {
    "g": “{{LIST_ID}}",
    "$fields": "vote",
    "email": “{{email}}",
    "vote": "vote"
  }
}

$.ajax(settings).done(function (response) {
  console.log(response);
});

Additional info can be found here.

Thanks!
Alex

Hi Alex,

Thank you for the reply.

I’m getting the error on the following endpoint: https://a.klaviyo.com/api/v1/person/{person_id}

I’m using Tray.io ((https://tray.io/) ) for this integration and I’m pretty sure there is no rate limiting on their side as I’ve had projects that dealt with a lot more request/data and if there was ever a rate limiting issue it was always on the API side and not on the client (Tray.io).

I’m also ruling out the bad API key, syntax error, or due to be running from javascript as these integrations have been running OK for months and they keep running OK most of the time but in recent weeks (starting 15th March we’ve seen periods (particularly during night) where request fail this way across all Klaviyo Clients (we have around 40 clients live with this integration).

Is Klaviyo using Cloudflare? could it be an issue with Cloudflare blocking the Tray.io IP on the Klaviyo side? If so, would it be possible to whitelist Tray.io on the Klaviyo Cloudflare?

Kind regards,

Alex

Hi there @alexoanea,

To start, I will say that although we use Cloudflare, I cannot request for one-off IPs to be whitelisted as there is a much more detailed process behind that.

I'm slightly confused what it is that you are trying to do. It sounds like you are using a third party tool to integrate a different software with Klaviyo but when making that v1/person request its being denied/blocked with a 403 aka a server/authentication issue. I think there is something more systematic than Klaviyo's cloudflare blocking these accounts. If you could further explain your goals and how you want the data to interact between Klaviyo, MentionMe, and tray.io that could help.

Additional note, the time of day should not be a variable.

All the best,

Alex

Hi Alex,

We have a integration between Mention Me and Klaviyo based on the Mention Me webhooks. We send the webhooks to Tray.io where they get processed and depending on webhook type and payload values we make various calls to the Klaviyo API to create/update profiles, track profile activity, subscribe profiles to lists using the Tray.io Klaviyo connector 

We’ve been running this integration for about 1 year now and have about 50 clients using it. Only in recent weeks we started seeing these 403 errors which seem Klaviyo’s Cloudflare blocking the requests rather than the Klaviyo API rejecting the calls. I only mentioned the time of day because every time it happened was out of office hours.

This issue occurred for only a small number of requests reported to the total number of requests: 59/27343 on 2rd April and and 128/30382 on 6th April.

Hi Alex and Alex

I’m experiencing the same problem...

I’m calling the metrics API (https://a.klaviyo.com/api/v1/metrics) from Google Sheets using AppScript for reporting purposes.

Looking at my error logs, I can see that the problem started suddenly on 29th March. Seven error 403s were reported on that day compared to none in the previous month… Now I get error notifications every day with up to 50% of daily calls failing in some cases (I’m calling the API every 6 hours).

Look forward to your thoughts Alex H…

Thanks, Iain

Hi there @IainD,

Just a few questions for you. Are all these calls coming from the same IP address? Do you have any retry logic implemented in your integration to retry requests that fail?

All the best,

Alex

Hi @alex.hong 

All fixed now - no errors over the last 2 days having had multiple errors per day over the previous 2 weeks. Please thank your developers ;-)

To answer your questions, though, I think AppScript uses multiple IPs - see https://stackoverflow.com/questions/66919433/how-to-know-ip-of-urlfetchapp-in-google-apps-script

It would be easy to add retry requests but the data is not mission critical so I can afford a few fails per day.

Many thanks

Iain

After a long period of no issues this seems to have come back since 21/09/2022 04:55:23 BST. Since around that time all the requests from our integration seem to be blocked by Cloudflare again as we get this as the response. See attached screenshot of response.

This is valid across tens of Klaviyo accounts, each with their out API Authentications. As mentioned before, it seems that Cloudflare is blocking calls from certain IPs  (requests from Tray.io would come from 1 or 2 IPs only. Any way we can fix this/ prevent it from happening in the future?

Hey @alexoanea,

I would suggest trying again to see if those requests were still getting block. 

We recently noticed an incident regarding a partial API outage causing an elevation in 403 errors. You can find more details and subscribe to the public incident report here. 

David

Hi @David To,

Thanks for the update! I had checked the Klaviyo Status page when I saw this started happening and there was nothing yet reported. Guess the incident was reported a bit later. We’ve replayed all the failed requests soon after the outage was resolved.

Regards

Alex

Hi community! I’m on magento2 with direct api connection. fastly/cloudflare. The 403 errors are still coming up for us seemingly randomly/intermittently and blocking email traffic. Should I create new api keys to clear up the issue?

Hi @lsamuels ,

I would try that first and if the problems seem to persist, then contact our Support team to see if there are any errors and the disconnects aren’t just random.

Tips to fix-

Check the . htaccess File. 
Reset File and Directory Permissions. 
Disable WordPress Plugins. 
Upload an Index Page. 
Edit File Ownership. 
Verify the A Record. 
Scan for Malware. 
Clear Your Web History/Cache.

Regards,

Rachel Gomez