What's the meaning of createdat vs. createdate vs. hs_createdate properties?

Developer Support APIs & Integrations
1

When fetching an object like deals via a GET, there are multiple “created”-type fields in the response. They are all hubspot-defined, but they often do not match.
Take the below real request and response.

GET https://api.hubapi.com/crm/v3/objects/deals/XXX?properties=hs_createdate

200
{
 "id": "XXX",
 "properties": {
 "createdate": "2022-11-27T21:51:23.417Z",
 "hs_createdate": "2022-10-18T22:29:01.649Z",
 "hs_lastmodifieddate": "2025-01-14T23:04:36.946Z",
 "hs_object_id": "XXX"
 },
 "createdAt": "2022-11-27T21:51:23.417Z",
 "updatedAt": "2025-01-14T23:04:36.946Z",
 "archived": false
}

The `createdate` and `createdAt` datetimes are more than a month different than `hs_createdate`.
Worse, a GET /deals/XXX?propertiesWithHistory request returns changes going back to 2022-05-18, long before any of the create dates. That property history includes changes to the `createdate` and `hs_createdate` values themselves.
Does anyone know which property is actually reliable as a creation timestamp? How can that timestamp be later than the property history of the same object?

2

Hi @Hogan :waving_hand:

Based on the property information supplied by HubSpot (specifically for Deals, but I imagine it’d be the same for other object types):

  1. createdate
    • Label: Create Date
    • Description: Date the deal was created. This property is set automatically by HubSpot.
    • Read Only: False (i.e. you can set and update this property’s value)
    • Notes: The description should actually read something like, “If not explicitly set by the user, this property is set automatically by HubSpot relevant to the datetime the record is created in HubSpot.”
  2. hs_createdate
    • Label: HubSpot Create Date
    • Description: The date the deal was created. This property is set automatically by HubSpot.
    • Read Only: True (i.e. you cannot set or update this property’s value)
    • Notes: This property’s value will always represent the datetime the record is created in the relevant HubSpot Portal.

createdAt is not a CRM “property”, rather it can be considered a CRM record “attribute”. Based on some quick testing, it looks like createdAt will always match createdate.

Finally, it’s also interesting to note that all relevant calculation properties reference the createdate property.

I hope that proves helpful. Please let me know if you have any follow-up questions.

3

Hi Zach, I appreciate your quick response, but that doesn’t really address the question.

As I mentioned, `hs_createdate` DOES have a property history. And that history spans to before the current value itself, showing edits from users:

"hs_createdate": [
{
"value": "2022-10-18T22:29:01.649Z",
"timestamp": "2022-11-02T00:02:50.074Z",
"sourceType": "MERGE_OBJECTS",
"sourceId": "userId:46072309",
"updatedByUserId": 46072309
},
{
"value": "2022-10-18T22:29:01.649Z",
"timestamp": "2022-10-18T22:29:01.649Z",
"sourceType": "CRM_UI",
"sourceId": "userId:46072309",
"updatedByUserId": 46072309
},
{
"value": "2022-05-18T05:41:50.905Z",
"timestamp": "2022-05-18T05:41:50.905Z",
"sourceType": "CONTACTS",
"sourceId": "userId:25629599",
"updatedByUserId": 25629599
}
]

I’m aware of the property information returned by the properties endpoints, but that description doesn’t line up with the behavior of the record. What am I missing?

4

Thanks for clarifying @Hogan

I can understand the “hs_createdate” property being updated in the case of a “MERGE_OBJECTS” operation (i.e. it would be updated to reflect the value of the oldest record, as per this doc).

However, the second update in your example is definitely confusing, as the sourceType is “CRM_UI”, which goes against the assumed “read only” nature of this property. Are you in a position to ask the HubSpot user who’s credited with this update (User ID 46072309) if they have any insight? I’d also like to invite @Jaycee_Lewis and @BérangèreL into the conversation to see if they have any insight.

5

Thanks for flagging @zach_threadint :waving_hand: — Jaycee

6

Hey, @zach_threadint

How is it possible than that hs_createdate can be null while createdate is not?
Deal seems to be the only one object type where it’s set. Others have “null” which shoud not be possible according to the description you provided

MYermolayev_0-1768391020385.png
MYermolayev_0-1768391020385.png1198×842 157 KB

MYermolayev_1-1768391050529.png
MYermolayev_1-1768391050529.png1288×854 166 KB

MYermolayev_3-1768391082736.png
MYermolayev_3-1768391082736.png1494×812 178 KB

7

Hi @MYermolayev and thanks for reaching out to the HubSpot Community!
I’d love to put you in touch with our Top Experts: Hi @Anton, @SteveHTM and @evaldas have you already seen the hs_createdate that might be null for some object types while the createdate has a value? Do you have any insights to share with @MYermolayev, please?
Thanks so much and have a great day!
Bérangère

8

Hi @MYermolayev, just following up to share that the hs_createdate property is usually set automatically by HubSpot when new records are created.
However, it seems there can be some differences in how this property is handled for various CRM object types, for example, Deals often have hs_createdate filled in, while other object types might show it as null. I’ve passed this along internally so our team can review.

To ensure consistency, I recommend using the createdate field from the top-level response as your go-to timestamp for all object types.
I hope this helps and thanks for bringing up this great question!
Bérangère
This post was created with the assistance of AI tools