Breaking Change: Removed Support for Referencing Custom Object Types by Base Name

Develop, Build & Integrate Developer Announcements
1

We are removing the undocumented support for requesting custom object types by their base name (GET/crm/v3/objects/{baseName}) in HubSpot public APIs. All custom object types must be referenced by their unique identifier (object type ID, fully qualified name, or short-hand custom object type name) to ensure clarity and consistency in API interactions.

What’s changing?

Previously, referring to custom object types by their base name in API requests was possible. For instance, if both a HubSpot-defined object type and a custom object type were named “vendor,” using the base name would cause confusion and result in unexpected behavior in API responses.

As a result, the base name format will no longer be supported after June 24th, 2025. Here is an example using the base name “vendor.”

// Example

GET /crm/v3/objects/vendor
Instead, you must use one of the following formats for your request:
  • Using the short-hand custom object type name, aka GET /crm/v3/objects/p_{object_name}
// Example

GET /crm/v3/objects/p_vendor
  • Using the GET /crm/v3/objects/objectTypeId
// Example

GET /crm/v3/objects/2-123
  • Using the GET /crm/v3/objects/fullyQualifiedName
// Example

GET /crm/v3/objects/p345_vendor

What does this mean for developers?

Failing to update your custom object type API calls that refer to their base name instead of their unique identifier (object type ID, fully qualified name, or short-hand custom object type name) will result in unexpected errors or a failed request, returning a 400 error response:

{
status:"error",
message:"Unable to infer object type from: vendor",
correlationId:"cfb4f7d2-c7dc-4b91-a5f1-b0fa417ae2e8"
}

We recommend the following next steps:

  • Review and update your API integrations to ensure that all API requests to custom object types comply with the documented requirements and no longer refer to a custom object type by its base name.
  • Please refer to our API Documentation for more information on retrieving custom object type data and understanding the available reference formats.

When is it happening?

The implementation of this change will begin on June 18th, 2025, for existing portals currently referencing the path (GET/crm/v3/objects/{baseName}), and will be completely disabled for all end users by June 24th, 2025.

**Important Update (Date Change):

The release date for removing the undocumented support for requesting custom object types by their base name has been changed. The original date of April 29th, 2025, has moved to June 24th, 2025. Please update your systems and plans accordingly.**

Questions or comments? Join the forum below for a peer-to-peer discussion.

2

Does this change also apply to references to custom objects in HubL? (e.g., the crm_object function)

3

@BRVNARISHIGE - This is a great question, and I’ll follow up with our product team for confirmation.

4

There used to be an issue with using the base name if the custom object contained multiple words (i.e. “basketball_teams”). Will the short-hand custom object type name (i.e. “p_basketball_teams”) address the multiple word issue?

5

Hey @evaldas - thank you for your comment! Would you mind telling me more about what sort of issues you would face when leveraging multiple words? I’d love to know more!

6

Hey @hseligson - sure!

If a custom object was simply named “Vendors” and you used the base name in the request it worked fine because it’s a single word:

// Example

GET /crm/v3/objects/vendor

However, if the custom object is multiple words, i.e. “Food Vendors”, then it would return an error:

// Example

GET /crm/v3/objects/food_vendor

“status”:“error”,

“messages”:“Unable to infer object type from: food_vendor”

7

@evaldas - thank you for the additional context and for sharing the error message!
I tested this with the example “food_vendor” and received the same error when requesting crm/v3/objects/food_vendors.
However, when I modified the request to the formats we documented in our docs, I received a 200 with the following requests:

  • crm/v3/objects/p_food_vendors
  • crm/v3/objects/{objectTypeId}
  • crm/v3/objects/p{portalId}_food_vendors

I suggest leveraging the formats we have documented to avoid errors. Please feel free to let me know if you have any additional concerns.

8

Hi

Can I clarify if any calls to quote_template will also be affected?
Also is this specific to v3 or v4 as well?

Kind regards

9

Hi! This update affect also custom code in Worfklows?
I’ve something like this:

hubspotClient.crm.objects.searchApi.doSearch('seriali', searchBody);

Need I to update in something like this?

hubspotClient.crm.objects.searchApi.doSearch('p_seriali', searchBody);

thanks

10

Hi @Pietro-Poli- Thank you for your question!
Yes, this will affect any usage of the base name. Your example is precisely correct.

  • Using the shorthand custom object type name, or GET /crm/v3/objects/p_{object_name}
    You can also take a look at the API documentation for any additional details about the accepted formats.
11

Thanks @hseligson

12

Hi @hseligson i also have a similar question in regards to associations.

Will i need to replace code like

return await this.hubspotClient.crm.associations.typesApi.getAll(
 fromObjectType,
 toObjectType,
 );

with:

return await this.hubspotClient.crm.associations.typesApi.getAll(
 CustomObjectTypes.includes(fromObjectType)
 ? `p_${fromObjectType}`
 : fromObjectType,
 CustomObjectTypes.includes(toObjectType)
 ? `p_${toObjectType}`
 : toObjectType,
 );

where i have the custom object types defined in an array?

13

Similar question for

return await this.hubspotClient.crm.properties.coreApi.getByName(
 CustomObjectTypes.includes(objectType) ? `p_${objectType}` : objectType,
 propertyName,
 );
14

I have a question. We’re using GitHub - HubSpot/hubspot-api-python: HubSpot API Python Client Libraries for V3 version of the API · GitHub. Are you going to update it? I believe this change will affect this library.

Thanks.

15

Dear Community,
I would like to extend my heartfelt thanks for all your questions and engagement. I’d like to clarify an important update regarding our HubSpot public APIs. Going forward, any usage that requests custom object types by their base name (GET/crm/v3/objects/{baseName}) will no longer be accessible. This change applies universally, whether the base name is utilized through an association, workflow, or any other means.
Thank you for your understanding!
Best,
HubSpot Developer Relations

16

I am using short-hand for my custom object from factura to p_factura and time response is very long in search, create and associations:

(.venv) mojicamarcumplo@Marcos-MacBook-Air migraciones % /Users/mojicamarcumplo/Documents/migraciones/.venv/bin/python /Users/moj
icamarcumplo/Documents/migraciones/custom_object_huspot.py
:stopwatch: Tiempo total de ejecución: 150.38 segundos

Using for search : url = “https://api.hubapi.com/crm/v3/objects/p_factura/search”

with body = {
“filterGroups”: [
{
“filters”: [
{
“propertyName”: “rut_proveedor”,
“operator”: “EQ”,
“value”: “xxxxxxxx”
},
{
“propertyName”: “numero”,
“operator”: “EQ”,
“value”: “2344”
}
]
}
],
“properties”: [“id”], # propiedades a traer
“limit”: 10
}