IOError during CRM Extension data-fetch



I have a CRM Extension trying to load when a contact page is being opened in a test hub, and I'm not seeing my data-fetch uri being requested. In the monitoring section of my developer account, I see an IOError. I can copy paste the request in my browser and I see the request.

Any help would be appreciated.

Webhook Subscription Test 403

Hi @cameroncollective, happy to help! Taking a look at your App Monitoring section in your dev portal, I'm able to see the request here: for this contact (and all others) is failing. When I go to that URL, I'm unable to get to any data as there's a 502 Bad Gateway error.

In order to fix this error, there needs to be an object returned back from your servers, otherwise you'll get this IO Error.


Since I'm still developing I don't leave the server running so I don't expose any security holes, that's why you get the 502.

When it is up and I load a contact page, I don't see the data-fetch request from Hubspot. If it helps I can leave a static object up to be returned for you to investigate. I will try and get this done over the holiday.

Thanks for your quick response.


Hey @Connor_Barley I left the server running and it will return a fairly static object to the data-fetch request.

After poking around a bit, I still don't see the request hitting nginx, However with tcpdump, I see traffic from you guys trying to open a SSL/TLS connection. My guess is that you guys don't like my SSL certificate signed by Let's Encrypt CA?


I switched my cert to Comodo, and I'm still getting the same IOError, so I still must be doing something dumb.


I have this extact issue.

Is it appropriate to address here, or should I create a new issue?

As a side note, when I copy the URL from the Monitoring > CRM Extensions tab, and invoke via curl/browser/postman - I get json.

	"results": [
		"objectId": 245,
		"title": "testages",
		"reported_by": "",
		"reporter_type": "Account Manager",
		"ticket_type": "Bug"
	  "settingsAction": {
		"type": "IFRAME",
		"width": 890,
		"height": 748,
		"uri": "",
		"label": "Settings"
	  "primaryAction": {
		"type": "IFRAME",
		"width": 890,
		"height": 748,
		"uri": "",
		"label": "Create Ticket"

I set my object type up to contain properties for reported_by/reporter_type/ticket_type.

Is there any other documentation on the structure/required properties of "object types"?

Is there any other resource to debug the integration? or a way to get a more detailed failure?


Hi @cameroncollective, I'm still looking into this to see what's going on. I don't think this has to do with your SSL cert. I'm looking to see if there's something with the format of your JSON data, but I'm still checking. @Kevin_Griffin, what is your App id so I can take a look?


This is my app ID 184159


Hi @Kevin_Griffin can you try changing the URIs of the data that comes back to be one of your baseURI's to see if this fixes your issue?

@cameroncollective, it looks like your data is stringified when I go to your fetch URL, can you make the data that gets returned just be JSON, rather than the stringified version of your JSON object?


@Connor_Barley I still receive IOError.


Do those actions need to map to valid endpoints?
I can remove them, I was just using the sample.

I updated the endpoint to omit actions entirely, just returning

	"results": [
		"objectId": 245,
		"title": "testages",
		"reported_by": "",
		"reporter_type": "Account Manager",
		"ticket_type": "Bug"

Still IOError


Hey @Connor_Barley My test app is now returning a JSON object with the correct mime type etc. and not a JSON-like string.

Here is why I think it's a cert\CA issue.

This is a packet capture on my server when I open a contact's detail page triggering the data-fetch call.

I would have guess that was the issue with the Let's Encrypt cert, but this is a legit Comodo cert.


Hi @Kevin_Griffin, taking a closer look at your fetch URL, there's definitely something strange going on. When I make a GET request to in Postman, I don't get any response back. I deployed a simple app to mirror yours up to Heroku and was able to get 200 responses on all object types in HubSpot. You can find the app here:

The only difference I can see between your app and mine is that if you check the Network on your webpage and look at the response, your JSON is formatted like this:

Whereas mine looks like this:

I also made your app have the same base URI structure as mine. Here's what my HubSpot app looks like:

could it be something as simple as some sort of typo on your end? Here's my simple app in Github as well:

I can keep digging in with my team, but thought I'd share my findings with you first.

@cameroncollective, I'm still investigating your issue


@Connor_Barley looks like it's the let's encrypt certs for us.

I had SSL verification off in postman, if I turn it on - it fails.
If I turn it off, it works, Chrome etc think the cert is valid though.

Also greatly appreciate you digging in :slight_smile:


Got it @Kevin_Griffin, so you're all set now? Glad I could help. If I could now flip the tables on you, how were you able to disable the SSL verification in Postman? I'm not aware of where to find that setting!


Nevermind, I found it :stuck_out_tongue_closed_eyes:. Should've googled a bit more


@cameroncollective, I was able to make a successful GET request to your URL ( here when SSL certificate verification was turned off as @Kevin_Griffin mentioned, so your hunch about the certificate is probably right. I'm going to get clarification from the CRM extensions team so that I can provide more details on what we require for SSL certs.


Turn SSL verification off:

Settings > General > SSL verification

Sadly though, no, not sorted.

We're thinking maybe something is wrong with the cert chain. Not sure you guys can help us, we're investigating on our side. I follow up if we resolve it, hopefully it will help others in the future with cert issues.


Got it. I included more details on the info i gave to our developers so I hope they can clarify what the restrictions are on the certs we accept, if there are any restrictions. Hope to get back to you as soon as possible


@Connor_Barley, we got it.

So, the way we automatically provision certs was missing the addition of intermediate certs, so the cert chain was not "complete" enough for postman / curl (but apparently for chrome ?). pointed out that deficiency.

we manually re-provisioned the certs (in gcloud for us) and all is well.

As you'll see if you check our monitoring page, we got our first 200.

Greatly appreciate the help.