Inconsistency in calculation_rollup property types from /crm/v3/properties/{objectType}

Developer Support APIs & Integrations
,
1

Hello,

I am working on a system that uses the
https://api.hubapi.com/crm/v3/properties/{objectType} endpoint to retrieve and expose the schema for each object (table) to end users.

As part of this, we rely on the type and fieldType attributes to map fields to our supported SQL types (for example: INTEGER, DECIMAL, DOUBLE, VARCHAR, BINARY, etc.).

I am running into an inconsistency specifically with properties of fieldType = calculation_rollup, which makes it difficult to reliably determine the correct datatype.

Problem Description

There appears to be inconsistent behavior for calculation_rollup properties when interpreting the type attribute.

Below is a practical example with two properties that both have:

  • fieldType = calculation_rollup
  • type = number

However, their actual returned values differ significantly.

Example Properties Response

[
 {
 "updatedAt": "2025-05-28T20:42:26.976Z",
 "createdAt": "2025-03-12T20:25:44.943Z",
 "name": "hs_hd_ticket_ids",
 "label": "hd_ticket_ids",
 "type": "number",
 "fieldType": "calculation_rollup",
 "description": "All Helpdesk ticketIds associated with the Note",
 "groupName": "note",
 "displayOrder": -1,
 "calculated": true,
 "externalOptions": false,
 "hasUniqueValue": false,
 "hidden": true,
 "hubspotDefined": true,
 "modificationMetadata": {
 "archivable": true,
 "readOnlyDefinition": true,
 "readOnlyValue": true
 },
 "formField": false,
 "dataSensitivity": "non_sensitive"
 },
 {
 "updatedAt": "2025-12-22T08:42:02.492Z",
 "createdAt": "2025-12-22T08:42:02.492Z",
 "name": "rollup_fieldtype",
 "label": "rollup_fieldtype",
 "type": "number",
 "fieldType": "calculation_rollup",
 "description": "rollup_fieldtype",
 "groupName": "contactinformation",
 "displayOrder": -1,
 "calculated": true,
 "externalOptions": false,
 "archived": false,
 "hasUniqueValue": false,
 "hidden": false,
 "showCurrencySymbol": false,
 "modificationMetadata": {
 "archivable": true,
 "readOnlyDefinition": false,
 "readOnlyValue": true
 },
 "formField": false,
 "dataSensitivity": "non_sensitive"
 }
]

Example Values Response

[
 {
 "id": "88262553254",
 "properties": {
 "hs_hd_ticket_ids": "24039996340;29553990175;29609291889;29612232290;29653594195;29971242580"
 }
 },
 {
 "id": "153970383798",
 "properties": {
 "rollup_fieldtype": "520"
 }
 }
]

Observations

  1. hs_hd_ticket_ids

    • HubSpot-defined property
    • Declared as type = number
    • Returns multiple numeric values concatenated as a semicolon-separated string
    • Cannot be safely mapped to a numeric SQL type
    • Treating it as numeric causes parsing errors in our platform

  2. rollup_fieldtype

    • Custom property
    • Declared as type = number
    • Returns a single numeric value
    • Datatype can be reliably inferred from the type attribute

Proposed Approach

Would the following logic be considered safe and future-proof?

  • If fieldType = calculation_rollup and hubspotDefined = true
    → Treat the field as string, since it may return multiple values separated by ;
  • If fieldType = calculation_rollup and hubspotDefined = false
    → Determine the datatype based on the type attribute from the properties response

Questions

  1. Is this assumption correct and safe to rely on?
  2. Is this a known issue or limitation of calculation_rollup properties?
  3. Are there plans to introduce additional metadata (for example, something like isMultiValue) in the properties response to make this distinction explicit?

Any guidance on the recommended way to handle this would be greatly appreciated.

Thank you in advance.

2

Hello @skerdi,

Thanks for posting in the community!

I see that you’re looking for some assistance or clarity around calculation/rollup properties.

I’d like to tag a few of our community experts who may some experience with this!

@RubenBurdin, @GRajput, @sylvain_tirreau

Do you have any tips for @skerdi regarding that proposed approach?
Thank you!

Sam, Community Manager

3

@skerdi - It seems to me that there is part of the context missing in this question. The rollup functionality is performing differently of course in the two cases, but the unstated aspect of the rollup is the property that you are referencing as the source of the calculation and the rollup function applied. It seems reasonable that the rollup of a string property value (example associated ticket ids) would be a concatenated list of such IDs. But the rollup of a numeric property value (example count of associated contacts) would give you a count/average/min/max or whatever expressed as a numeric value as youu have outlined. I wonder if his missing detail is key to the behavior you are reporting?

Hope this is helpful.

Steve

4

Hi @SteveHTM, thank you for the response.

I think there may still be a key mismatch between the property metadata and the actual values returned, which is the core of the issue I’m trying to highlight.

If you look closely at the properties definition I shared, the hs_hd_ticket_ids property is explicitly defined as:

  • type = number
  • fieldType = calculation_rollup
  • hubspotDefined = true

Based on the properties metadata alone, this indicates that the rollup is being performed on a numeric property, not a string property. From a client/API consumer perspective, this strongly suggests that the returned value should be safely treated as numeric.

However, the actual value returned by the records endpoint is:

"24039996340;29553990175;29609291889;29612232290;29653594195;29971242580"

This is a semicolon-separated string of multiple numeric IDs, which cannot be parsed or treated as a numeric type. In my client application, this causes parsing errors if I rely on the type = number metadata.

To further illustrate the inconsistency, I created a custom rollup property using:

  • Field type: Rollup
  • Rollup type: Sum
  • Associated record property: Record ID

skerdi_0-1766480469924.png
skerdi_0-1766480469924.png1087×925 72.9 KB

In this case, HubSpot sums the numeric IDs of the associated records and returns a single numeric value, which aligns with:

  • type = number
  • fieldType = calculation_rollup

So we have two calculation_rollup properties, both with type = number, but with fundamentally different runtime behavior:

  • One returns a multi-value string
  • One returns a single numeric value

This is why I believe the issue is not the rollup logic itself, but rather an inconsistency between the metadata and the actual value shape returned by the API, particularly for HubSpot-defined rollup fields.

Clarification I’m Seeking

Given this behavior, I want to confirm whether the following approach is safe and future-proof:

  • If fieldType = calculation_rollup and hubspotDefined = true
    → Treat the value as string, since it may return multiple values separated by ;
  • If fieldType = calculation_rollup and hubspotDefined = false
    → Determine the datatype based on the type attribute from /crm/v3/properties/{objectType}

Questions

  1. Is this assumption correct and safe to rely on?
  2. Is this a known limitation or special case for HubSpot-defined calculation_rollup properties?
  3. Are there any plans to introduce additional metadata (for example, an isMultiValue or similar attribute) to make this distinction explicit in the properties response?

Any guidance on the recommended way to handle this scenario would be greatly appreciated. Thank you again for taking the time to look into this.

5

@skerdi - I applaud your sleuthing of these properties. It set me off doing a scan of related properties and types to try and confirm my understanding on the logic.

Based on what I can see, the HubSpot defined property that you are referencing ‘hs_hd_ticket_ids’ on the ‘note’ object is an anomaly where - as you observe - the type = number does not accurately indicate the values that are contained in the property.

In all other examples of HubSpot properties that I have looked at that contain dynamic concatenated lists of object IDs (example ‘hs_merged_object_ids’ on a Contact record) the type is set to enumeration and the fieldType to checkbox - which is what you see when definiing a property of your own of this sort.

The UI for property definition seems to only support the defintion of a rollup calculated property as a number type - even when the property being “rolled” is potentially more normally interpreted as a string (Record IDs are a bit ambiguous like this). I have not tried the API definition of a rollup properry, but I suspect that would have similar behavior.

Bottom line - bearing in mind I do not speak on behalf of HubSpot here - I think you would be very safe in interpreting type=number as a safe mapping for your SQL integration for all non-HubSpot defined properties. The tangled history of some internal HubSpot object defintions may have left some wreckage that don’t 100% conform here - but I imagine that this would be pretty rare and not exposed at the UI level.

I hope this is helpful.

Steve

6

Hey @skerdi
This is a great find and something we’ve had to deal with extensively. You’ve basically uncovered one of those legacy inconsistencies in HubSpot’s internal property definitions that makes building reliable sync systems tricky.
SteveHTM is right that hs_hd_ticket_ids is an anomaly. We’ve seen a handful of these HubSpot defined properties where the metadata says type = number but the actual value is a semicolon delimited string. The hs_merged_object_ids pattern (type = enumeration, fieldType = checkbox) is what HubSpot uses consistently for newer multi value fields, but some older internal properties didnt follow that convention.
Your proposed approach is reasonable but I’d add a small refinement:
For fieldType = calculation_rollup with hubspotDefined = true, I’d actually check the value shape at runtime on first sync rather than blanket treating as string. Most HubSpot defined rollups do return proper numbers. The problematic ones like hs_hd_ticket_ids are edge cases. You could maintain a small allowlist of known problematic properties if you want to avoid runtime type detection.
For custom rollups (hubspotDefined = false), yes the type attribute is reliable since users can only create rollups through the UI which enforces proper typing.
Regarding your question about isMultiValue metadata, I’d suggest posting this in the HubSpot Ideas forum or the developer feedback channel. Its a legitimate gap in the API contract.

At Stacksync we’ve built up handling for these exact edge cases when syncing HubSpot to Postgres and other databases, including automatic type coercion and schema detection that accounts for these inconsistencies. Happy to compare notes if you want to dig deeper into how we approached the mapping logic. Disclosure: This answer comes from my own experience and was lightly rephrased with AI to improve readability. Disclosure: This answer comes from my own experience and was lightly rephrased with AI to improve readability.

Good luck with your integration!