search

HubSpot / HubSpot-public-api-spec-collection

8 stars 7 forks source link

specs are not met by v3 CMS pages api #21

Open pieterdt opened 1 month ago

pieterdt commented 1 month ago

When creating a page I get the following error:

Invalid input JSON on line 1, column 21135: Cannot deserialize value of type long from String \"1970-01-01T00:00:00+00:00\": not a valid long value

however the date is matching the API specifications. Leaving out the property makes the call work, even if the property in question (archivedAt) is listed as a required property.

hseligson1 commented 1 month ago

Hey @pieterdt - thanks for sharing this! It looks as though the API expects a long value (likely a timestamp in milliseconds since the epoch), but you're passing a date-time string in ISO 8601 format. You could try converting the ISO 8601 date-time string to a long timestamp in milliseconds and use that value in the archivedAt field. I recognize this contradicts the example in our API docs: "2024-08-22T14:56:58.138Z", but my assumption is that it was formatted this way for readability since the response is requesting a long value.

I'd suggest testing this out and see what outcome you receive!

pieterdt commented 4 weeks ago

hi @hseligson1 , thx for looking into it.

If the API endpoint expects a timestamp in milliseconds, then I would expect the SDK's (i checked the nodejs sdk and the php sdk) should transform the value to that format. It is the SDK that formats it into this ISO 8601 representation. Also, the ISO8601 representation is what you receive on a GET. So it would make sense that the value type of the property would be the same for POST and GET, no?

The documentation mentions both formats are allowed in the API's: https://developers.hubspot.com/docs/api/faq#timestamps and the examples here for page creation: https://developers.hubspot.com/docs/api/cms/pages also use the ISO 8601 notation.

So if HS documents it like this, it is surprising that the actual endpoint does not accept this kind of input. Also all other timestamps like createdAt and updatedAt perfectly accept this dateformat. Hence I think it is a bug in the enpoint rather than an issue with the documentation.