When calling the API, I get a 403 back with the message “Sorry, you have been blocked”.
Cloudflare Ray ID: 923cd07c1d8c5690
I’m forced to use a Cato VPN, but my IP is still located in Denmark.
I have just tried using https://trakt.docs.apiary.io/ from my phone, which is not on a VPN, and I still get the Cloudflare error when using the Try button on the examples.
A 403 indicates a bad api key.
I can confirm that the same happens (Cloudflare gateway) with something that I’ve been playing around with to keep track of my collection “offline”, and can asure you that it was working before without an issue.
Can be used without any sort of api key as far as I can see, and it still fails.
The API requires a key for all methods, a 403 means you’re sending no key or an invalid key.
I just run a simple call using Apiary, with a valid key, and Cloudflare still steps in erroring out the call.
If it helps, the Cloudflare Ray ID is 923f212bfbcd4d20.
What’s also “really funny” is that the page mentions that my IP address is 147.154.29.227, which doesn’t even come close to my real IP address.
Is there some other way we can provide more information to help understand what the issue might be? Thanks in advance.
I wouldn’t rely on running stuff through the API docs. I’m sure they proxy and do other stuff. It would be more helpful to have raw curls that you’re using.
After doing some more search around, according to a discussion on Github (Getting 403 status code when trying to get the access_token · trakt/trakt-api · Discussion #507 · GitHub), that the team is “experimenting with some firewall rules to block bot traffic”.
The proposed workaround, which I just tried and seems to work, is to set the User-Agent header. Maybe that should have been communicated… 
1 Like
I’m not sure what changed, but today my API calls are working again, and requests sent from Insomnia is also working again.
My requests are scheduled to run every night, and started failing on marts 21 4:10 AM GMT+1.
I also tried multiple times from Insmonia on the 21 with a similar Cloudflare related error.
The same error happend when the schedule ran on the 22 and 23, but today marts 24 4:22 AM GMT+1 everything worked again.
I actually didn’t look at my logs before trying to fix the problem, so I started by sending my saved requests from Insomnia, thad had failed on the 21, and to my surprise they worked, so I requested a new access token as I thought that was the problem for my scheduled requests, but after updating them in my application I noticed that the schedule has completed during the night without any problems.