Contacts properties


#1

Hi,

We have found that some of our contacts are not synched properly to Hubspot, could you send me the list of API calls requests received sorted by date for a specific user, so we can idenfity the problem?

Thanks


#2

Hi @juanramoncg,

We’re not able to store comprehensive logs for every request that comes into the HubSpot API. If you have specific examples of requests that have failed, or at least a specific portal you’re referring to, I can help investigate the issue.


#3

Hi Derek,

I can give you the portal ID, and some other information needed with a better description of our problem. Is it possible to jump into a 1:1, so i don’t expose the information in this public Forum.

Thanks.
Juan Ramon Cañizares Gomez.


#4

HI @juanramoncg,

Sure thing, you can direct message my by clicking on my profile and clicking the ‘Message’ button that appears in the modal window.


#5

Hi Derek,

I have found the reason why our users are not being created properly in Hubspot:

{\"isValid\":false,\"message\":\"n/a was not a valid long.\",\"error\":\"INVALID_LONG\",\"name\":\"access_end\"}
{\"isValid\":false,\"message\":\"n/a was not a valid long.\",\"error\":\"INVALID_LONG\",\"name\":\"trial_start\"},
{\"isValid\":false,\"message\":\"n/a was not a valid long.\",\"error\":\"INVALID_LONG\",\"name\":\"trial_end\"}

We haven’t had any problems using n/a for our date picker properties access_end, trial_start and trial_end before, it was just setting - value to this property, but it returns a 400 http status now and the contact is not created properly. Do you know when have you introduced this breaking change? Is there any documentation about this? And the most important question, is it possible for us to still use n/a for an empty date in this property?

Thanks.
Juan Ramon Cañizares Gomez.


#6

Hi @juanramoncg,

The Contacts API has had this date property validation for roughly a year now. Strings/non-timestamp values were never supported, and the validation was added to bring the API behavior more in line with this. There aren’t any plans to allow strings/non-timestamp values for date properties in the future.


#7

Hi Derek,

Ok, thanks for the clarification.
Juan Ramon Cañizares Gomez.