Deals Endpoint Returning 414

[krhsiung]

For the past week, we've been having a fairly urgent issue with our data pipeline due to the length of our requests to HubSpot. I believe this is because the Deal Properties API has started returning extra auto-generated properties. We use Stitch to get data from HubSpot into our data warehouse and, looking through Stitch's logs, it does not seem to be able to talk to HubSpot anymore.

Stitch fetches data from HubSpot in the following order:

1) It grabs all deal properties from HubSpot's deal properties endpoint.

I believe that last week this endpoint may have started returning autogenerated properties that it did not use to - I am seeing ~300 properties that we don't have in our data warehouse. They all start with the prefix 'hs_' and mostly correspond to timestamps for when a deal entered a particular dealstage. For example:

- 'hs_date_entered_STAGEID'

- 'hs_date_exited_STAGID'

- 'hs_time_in_STAGEID'

2) It then hits HubSpot's deals endpoint with those properties.

This creates a very long url because all the properties are listed as query params in the URL. The properties endpoint returns 512 properties and serializing all of these properties to the deals endpoint creates a URL over 26,000 characters long.

This second request fails. The Stitch script receives a "HTTPError: 414 Client Error: Request-URI Too Large" error. I did some poking around and it appears that this HubSpot endpoint is capped at around 2^14 = ~16000 characters. On average, a serialized property adds around 50 characters to the URL which means we would have had to add ~200 properties to our deal object in the past week to have broken this limit on our own - I've confirmed we did not do that. Especially given that we've never replicated any of these 'hs_*' properties in our data warehouse before, my suspicion is that the properties endpoint has started returning more properties. 

This seems to make it impossible for us to use the HubSpot API to grab all of a deal's properties, as by default the API does not return all of the properties.

We'd love to get to a world where Stitch can use the API like before. Unfortunately, we don't control Stitch's script - would it be possible to just set the URL-length limit to 2^16? (Or if it's not intended that the endpoint surface these properties, could they stop getting sent?)

Any help moving this forward would be greatly appreciated as we have several experiments in flight that we'd like to evaluate.

[WendyGoh]

Hey @krhsiung,

This issue has been raised on this community thread - https://community.hubspot.com/t5/APIs-Integrations/Deals-API-not-working/m-p/318845/highlight/true#M... and for this case, I have reached out to our internal team and I'll keep you posted on this thread as soon as I have more information on this. 

[stitch_data]

Hi @WendyGoh -- I work for Stitch and we are seeing a lot of customers hitting this error.  Is there additional context you can provide about what changes were made that caused the increase in returned properties?  Also, is there any action our affected customers can take to raise the priority of this issue?  

[WendyGoh · Accepted solution]

Hey @stitch_data @krhsiung and other community users,

Context

It came to our attention that since last week, some customers are receiving 414 errors when fetching HubSpot deals data using Stitch.

This specific issue occurred because many new properties were added by HubSpot, and Stitch includes all properties in the URL of their "Get all deals" requests. This resulted in the URI being too long, causing an error.

Latest update

Our internal team has reached out to Stitch and they will implement a short term fix of requesting all properties via the `includeAllProperties` and `allPropertiesFetchMode` params. This will allows the endpoint to get all deals properties without including them individually in the request URI (which resulted in error 414).

Longer term, we will be working closely with Stitch to artichitect their integration with us in a more efficient way. 

Please do let me know if there's any further questions on this.

[krhsiung]

Thanks @WendyGoh. Is it possible to also set the URL length limit to 2^16 while Stitch works on this please? These sort of analytics are imperative to our business and we would very much like to get access to that data as soon as possible.

[WendyGoh]

Hey @krhsiung,

I believe Emily kept you posted that we have checked in with our team and while increasing of the URL length isn't possible, I'll definitely keep you updated once we received updates from Stitch end. 

[stitch_data]

Hey @WendyGoh ,

We (Stitch) implemented this fix and it seems to have resolved the issue.  Thanks for the quick response!

[WendyGoh]

Hey @stitch_data,

Awesome! Thanks for the update, Stitch team!

[Wendy3288]

Anyone else running into a new issue due to Stitch flattening Hubspot nested JSON structures?  This was to make the data compatible with Redshift, and is resulting in tables with columns that exceed Amazon Redshift’s 1,600 column limit...

[billwmartinez]

@Wendy3288 Im experiencing the same exact issue.  Account and Contact data does work fine but our Deal data wont import into our Redshift Database. It makes no sense becasue we have a lot more properties on our Contact object than we do on our Deals.  

I worked with our BI vendor to try a recommended solution and it did not work.  I would like to hear if you were able to resolve the issue.

[PowerMyAnalytic]

@WendyGoh 

Following up on your "Latest Update" - We have the same issue with fetching contacts.

Can you please anable this fix (`includeAllProperties` and `allPropertiesFetchMode` params)

for the endpoint 

contacts/v1/lists/all/contacts/all/

?

also possible fix is to make this endpoint as POST request and send the properties threw the body.

[WendyGoh]

Hey @PowerMyAnalytic , @stitch_data responded on 24th Feb that they have already updated their integration to use the includeAllProperties=true and allPropertiesFetchMode=latest_version in combination instead of each property that they want. 

In this case, are you still getting the 414 error?

[PowerMyAnalytic]

Hey @WendyGoh 

We want this feature to contacts endpoint -

contacts/v1/lists/all/contacts/all/

and BTW we are not using stitch, using REST API calls directly.

[WendyGoh]

Hey @PowerMyAnalytic ,

Thanks for the clarification!

In this case, if you haven't already, I'd recommend jumping over to the HubSpot Ideas Forum and posting this idea there so that it's visible to the HubSpot product team and other HubSpot customers and developers. Hopefully this will gather more interest.

[PowerMyAnalytic]

@WendyGoh 

I don't understand. It is the same case, other object. Please apply the solution there too...

[geraldgwarp]

This problem might be caused by the Apache limits the set a size of a client’s HTTP request-line and the HTTP request header field size. Extremely long URLs are usually a mistake. If you keep URLs under 2000 characters , they'll work in virtually any combination of client and server software. URI actually have a character limit depending on several things. Chrome limits url length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication. On most platforms, Chrome's omnibox limits URL display to 32kB ( kMaxURLDisplayChars ) although a 1kB limit is used on VR platforms. IE - 2083 characters, Firefox - 2047 characters, Safari 80000 characters and Opera 190,000 characters.

To resolve the problem :

• By POST request: Convert query string to json object and sent to API request with POST
• By GET request: Max length of request is depend on sever side as well as client side. Most webserver have limit 8k which is configurable. On the client side the different browser has different limit. The browser IE and Safari limit to 2k, Opera 4k and Firefox 8k. means the max length for the GET request is 8k and min request length is 2k.
•  

If exceed the request max length then the request truncated outside the limit by web server or browser without any warning. Some server truncated request data but the some server reject it because of data lose and they will return with response code 414.