Increasing the size of contact record IDs

[Dadams]

Beginning in March 2024, we'll be updating the system that generates contact record IDs. This will affect the id for the v3 Contacts API, the vid for the legacy Contacts API, and the hs_object_id property returned with either API.

What's changing?

Once this change goes into effect, the numbers generated for contact record IDs may be significantly higher than currently generated IDs. The new ID values will require 64 bit data types to store the ID as an integer value.

This update will bring contacts in line with all other CRM objects that already use the new system for generating IDs.

The IDs for existing contact records will not be changing. This will only affect the IDs for newly created contact records.

When is this happening?

The new system will start being used to generate IDs for new contact records on March 11, 2024.

Please let us know if you have any questions by replying below.

[JasonFF]

What you guys did without any notice to users is very, very messed up; we lost a week of customers till we noticed the issue and had to spend hours to diagnose the issue.

[PalSivertsen]

Clients using the associations API is currently breaking due to the use of 64 bit record ids where the spec says int32:

https://api.hubspot.com/api-catalog-public/v1/apis/crm/v4/associations

[notthebuilder]

"The new ID values will require 64 bit data types to store the ID as an integer value."

How or where can I check if I already have the required data types in my portal? Is this something I need my IT/developer team to do? Thanks in advance.

[TimMunro]

@Dadams - the marketing events subscriber update API here:
https://developers.hubspot.com/docs/api/marketing/marketing-events

Declares that parameter "vid" is of type int32
On this endpoint:
/marketing/v3/marketing-events/events/{externalEventId}/{subscriberState}/upsert

Is that also becoming an int64? Thanks.

[TimMunro]

@Dadams JavaScript's native JSON.parse/stringify do not natively handle full 64 bit integers so for users of the legacy (v1) API, where IDs are returned as numbers rather than strings, this will require some non-trivial adjustments. With that in mind - as implied by the title - can you confirm that this change ONLY apply to contact IDs?

[TimMunro]

@Dadams I am still after an update here?

[SteveHTM]

@Dadams - I presume that there wont be a big transition if we are treating these IDs (Contacts and everything else) as string values?

Steve