Hi,
We have serverless functions running on GCP - Cloud Functions. We’re calling the search company endpoint but it’s returning 403 on production, We have noticed the requests were rejected on 9th November around 9:30 AM onwards.
I have tested on my local machine with the same credentials and I’m able to call the API endpoint without any problem.
Can you please verify if the GCP servers have not been blocked?
Thank you,
Dino Correia
403 is returned when you are exceeding the rate limit - please provide the source ip addresses of the GCP servers.
Steve
Hi Steve,
GCP ip address: 216.239.36.54
I haven’t noticed any unusual large number of requests that could trigger the rate limit from our side. Also, I cannot guarantee this will be the destination IP address because Google used dynamic IP addresses for Cloud Functions
Dino Correia
Hi Dino,
That IP address or 216.239.36.0/24 is allowable to access the service - I assume you are using the API?
Are you seeing any 429 errors prior to the 403?
Steve
Hi Steve,
Yes, we are using API. I only can see 403 errors on our logs.
Dino Correia
So at what rate are you hitting the API?
The max of requests I can verify on the logs before stopping working was about 2-3 requests in less than 1 sec with an average difference in between requests of 200 milliseconds to the GET /search/companies endpoint.
We don’t hit the Companies House API very often - the max of requests per day will be around 20 or even less than that.
The last time we had 200 response code from the search companies endpoint was on 09-11-2021 14:52:28.168 GMT and the next request we made to the endpoint was on 10-11-2021 09:34:43.407 GMT but this time we received the 403. Since then we’re always receiving 403 responses.
Is any way you could check if any IP addresses have been blocked between this range of time? What other information could I provide to trace this issue?
Dino Correia
As stated I cannot find any IP’s in that range. Are you able to test locally to see if you get a different response?
Locally works perfectly fine - no issues found.
Morning, is any update on this issue?
Dino Correia
We cannot find any calls from 216.239.36.54 in the last 7 days.
Once again, I tried to track the IP address from Cloud Functions in a different way and I’m receiving this time: 107.178.231.55
Is possible to trace back using other information - instead of IP address in case not found?
I’m seeing a similar issue, also using Google IPs.
I’ve got a service hosted on Google Appengine and the IP changes frequently, I’m getting 403 using the deployed app but the requests go through fine locally. I’m processing maybe 10-20 calls a day at peak so can’t see why this would have triggered a rate limit.
If I provided the app ID, would you be able to see what’s going on there?
Cheers.
I’m still having the issue with the 403 status code.
@dr0id Are you able to check when you started receiving 403?
I’m using Cloud Function on GCP and I started receiving it on 9th November since then all the requests to Companies House API return 403 on production but locally works fine.
Dino Correia
My app is used fairly infrequently, so I can only say that the last working response was on the 25th of October, then I noticed the 503 errors this morning. That lines up with your date too.
I’ve just tried generating a new key, this also fails once it’s been deployed to GCP.
I’ve got access to another app with a key from a different account, this still appears to work and is also being hosted on GCP so I can’t say with certainty that it’s something to do with GCP’s IPs.
Do you have both apps on different regions or the same?
Also, I cannot say for sure will be problems with IP address. 
My broken app is in europe-west2-3
Working app is in europe-west3-2
By any chance are you having issues with europe-west2?
We have the cloud functions hosted on europe-west2.
I’m on a train at the moment but when I get to a stable internet connection later today, I’ll spin up a VM in eu-west2 and see if I get the same issue there. Hopefully should make it easier for the CH team to diagnose.
I get the same results as @dr0id reported where calls from a cloud function in europe-west2 (London) give a 403 error, e.g. from:
https://europe-west2-projectname.cloudfunctions.net/endpointname
But from other locations, e.g. europe-west3, work as before, e.g.:
https://europe-west3-projectname.cloudfunctions.net/endpointname
A reverse proxy would solve this for us.
But it would be great if the owners of the API could relax the rate limiting or consider the sub-domain+domain instead of just the IP address, which seems to be shared a shared IP pool for GCP Cloud Functions in the europe-west2 region.