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

Develop, Build & Integrate APIs & Integrations
1

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().

2

Hey, @Jna935 :waving_hand: 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

3

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.

4

Hi @Jna935

get_all() should return the properties for the specified object type; HubSpot does not document caching or internal indexing as a reason for properties to be omitted, so a property returned by get_by_name() but missing from get_all() should be treated as unexpected behavior.

(Properties API - HubSpot docs )

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:

(Create and edit properties )

Hope this helps.

Moderator Note: this post was reviewed for relevancy and optimized for clarity on September 30, 2026. Thank you for your contributions to the HubSpot Community!