Properties API Inconsistency - get_all() missing properties that exist via get_by_name()

[Jna935]

We've discovered a critical inconsistency in the HubSpot Properties API v3 endpoints where custom properties that exist and are accessible via get_by_name() are not returned by the get_all() method for the same object type.

Technical Details:

Affected Endpoints:

• /crm/v3/properties/{objectType} (get_all method)

• /crm/v3/properties/{objectType}/{propertyName} (get_by_name method)

Object Type: Companies (likely affects other object types as well)

Expected Behavior:
Both API methods should return consistent results. If a property exists and is accessible via get_by_name(), it should also appear in the get_all() response.

Actual Behavior:

• get_by_name() successfully retrieves custom property definitions

• get_all() excludes the same properties from its response

• This occurs regardless of the archived parameter value (tested with false, true, and no parameter)

Reproduction Steps:

1. Create a custom property for the Companies object in HubSpot UI

2. Call get_all() with object_type="companies" and archived=false

3. Verify the custom property is missing from results

4. Call get_by_name() with the same object type and property name

5. Observe that the property is successfully retrieved

Code Pattern (Generic):

# This works - property found
single_prop = client.crm.properties.core_api.get_by_name(
    object_type="companies", 
    property_name="custom_property_name"
)

# This fails - same property not in results
all_props = client.crm.properties.core_api.get_all(
    object_type="companies", 
    archived=False
)
# custom_property_name not found in results
​

Environment:

• HubSpot Properties API v3

• Using official HubSpot Python SDK

• Private app with appropriate CRM scopes (crm.objects.companies.read)

Business Impact:
This inconsistency forces developers to implement workarounds using multiple API calls to get complete property lists, increasing API usage and complexity. It also creates confusion about which properties actually exist in the system.

Workaround Currently Used:
Hybrid approach combining get_all() with individual get_by_name() calls for known custom properties that are missing from the bulk response.

Request:
Please investigate and resolve this API inconsistency so that get_all() returns complete and accurate property lists that match what's accessible via get_by_name().

[RubenBurdin · Accepted solution]

Hi @Jna935 

The get_all() endpoint can lag behind or exclude fields because of caching and internal indexing. HubSpot’s own docs mention that archived and caching can affect property visibility

(https://developers.hubspot.com/docs/guides/api/crm/properties )

Sometimes a new property takes a while before it surfaces in get_all() even if get_by_name() returns it right away. Clearing caches or waiting a bit usually fixes itt

If you need consistency immediately, the workaround you described combining get_all() with targeted get_by_name() calls—is about the only safe path for now. Also, worth checking the archived flag carefully: HubSpot’s Knowledge Base explains the behavior in more detail here:

(https://knowledge.hubspot.com/properties/create-and-edit-properties )

On a side note, some teams sidestep these odd API gaps by using a sync layer that keeps HubSpot properties mirrored in a database in real time. That way you don’t depend on quirks of get_all() at all platforms like Stacksync handle that automatically

Hope this helps.

[Jaycee_Lewis]

Hey, @Jna935 👋 I ran a quick test using Postman and was able to return my custom properties without issue. I wonder if this is an SDK-specific issue. I'm going to set up a quick test using the SDK and follow up here.

Talk soon! — Jaycee

[Jna935]

Hi @Jaycee_Lewis ,
Thanks for testing that out

I believe thats an API caching issue.

Added another column and that didn't happen now.

Not sure if this will be consistent.