Skip to main content

Hi,

 

We’re using v1.4 of the API to query and update users in our (Google) cloud services. However all of a sudden the requests are return a 403 status code with a HTML body - also there are no other usual Intercom response headers (x-request-id, x-ratelimit-limit, etc.) present so I can’t even provide a request ID trace to debug with.

 

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>

Headers:

connection: keep-alive
content-length: 118
content-type: text/html
date: Thu, 22 Jun 2023 15:54:21 GMT
server: awselb/2.0

 

It’s not an issue with the authentication or request as if I run curl with the same request it succeeds with a 200 status code.

Has Intercom blocked our cloud services (Google Cloud Run) IP or something?

 

A simple request such as the below fails when run in the cloud:

curl -i -H 'accept: application/json' -H 'intercom-version: 1.4' -H 'authorization: Bearer <access-token>' 'https://api.intercom.io/users?user_id=X'

 

Hi @Rich Hodgkins - Cam from the Intercom Support Engineering team here 👋

The fact that this call is returning a 403 error suggests that the request being made may simply not be allowed (as mentioned in our Dev Docs here).

From the details you’ve provided I can’t see any immediate indication for why the request would be ‘not allowed’ but one thing I will just confirm with you - are you using a POST method when making this request?

Hi @cameron.gumley,


It’s happening for GETs (user querying) and POSTs (user updates) and not just for api.intercom.io/users but for api.intercom.io/tags (POST) too.

 

And as I previously mentioned all these requests work locally with curl.

Just to add a bit more information, it is intermittent in the sense that it was fine for the past year or so (ie. from when we started the calls) till the 21-06 when around 0337 it stopped working and then started again after redeploying intfra at 1418. It happened again on the 22-06 @ 0030 the issue reoccured until 0207 (no fix was attempted, it just started working), then the same day from 0352 until 1704. A redeploy was again attempted at 1647 but this time didn’t immediately fix the issue this time.
All times BST.

Hi @Rich Hodgkins !

I’m actually not seeing these call come into Intercom in our logs. That 403 error makes me think that maybe you’re not using the correct Access Token. That is the error that would display in these situations and the fact that I’m not seeing the calls come through also indicates that the Access Token isn’t connected to your workspace.

That said, I think this will require more back and forth with a member of our support team to dig into since we will need to grab more details from you around your calls. I’m sending this conversation over to the team and they will reach back out to you over email in the next few days to continue the investigation!

>That 403 error makes me think that maybe you’re not using the correct Access Token

I’d normally agree but its starts working by itself without any redeployments or changes. Also in my debugging I noticed the following:

If you send a request without an access token you get:

curl -H 'accept: application/json' -H 'intercom-version: 1.4' -i 'https://api.intercom.io/users?email=email@domain.com'

401 status code:

{"type":"error.list","request_id":"003u09gbnd6qmlfuk3e0","errors":r{"code":"missing_authorization","message":"No authorization was provided"}]}

And with an invalid access token:

curl -i -H 'accept: application/json' -H 'intercom-version: 1.4' -H 'authorization: Bearer A' 'https://api.intercom.io/users?email=email@domain.com'

401 status code:

{"type":"error.list","request_id":"003u8gs5f21r3jvbskjg","errors":r{"code":"unauthorized","message":"Access Token Invalid"}]}

All these responses are JSON with the usual Intercom response headers (x-ratelimit-limit, etc.) as I’ve previously mentioned.

The 403 I'm getting is HTML without any of these response headers.

 

The reason I mention IP blocking is that a bit after a redeploy things start to work and this possibly maybe because the services have finished turning over the and the backing infra has changed the IP of the service - this is just a guess obviously...

Just to update this thread, the marked answer is not the answer. It has been fixed however.

More info from another member of the support team:

it looks like there's a Web App Firewall (WAF) in AWS that triggered here. It would appear the instance you were connected to was in a block list in AWS resulting in recieving the 403 http request. The team adjusted some rules for this on June 23rd, which resolved the issue. There's still some retrospective work to be done, but everything should be working fine 

@Jacob Cox we’re getting this issue again, I spoke to Seán last time who said it had been resolved, can we get this sorted please.

Hi @Rich Hodgkins !

I’m going to re-open the Support conversation that you previously had with Sean and reach out to you. That way you can send me the details around this newest situation!.

Reply


Terms & ConditionsCookie settings