HubSpot Cloud Mode Integration (New API v3)
4 minute read
RudderStack supports the following API calls while sending data to Hubspot via cloud mode using the new API v3.
RudderStack does not support the new datetime data type introduced by HubSpot.
Identify
RudderStack sends the identify call to check if a contact exists, if it does, RudderStack updates the contact with new information. Otherwise, it creates a new contact.
A sample identify call is as shown:
rudderanalytics.identify({
firstName: "Alex",
city: "New Orleans",
country: "USA",
phone: "+1-202-555-0146",
email: "alex@example.com",
custom_flavor: "chocolate",
custom_date: 1574769933368,
custom_date1: new Date("2019-10-14T11:15:53.296Z"),
})Make sure to specify the HubSpot property you set in HubSpot property to be used for upsert dashboard setting in the traits object of the identify call — RudderStack sends this property to HubSpot for matching contacts.
For best performance, choose a HubSpot contact property that is unique in your account. Unique properties let RudderStack call HubSpot’s batch upsert contacts API for
identifyevents, which significantly increases throughput.Non-unique properties will still work, but RudderStack uses a slower search-based flow.
rudderanalytics.identify({
name: "Alex Keener",
phone: "+1-202-555-0146",
uniqueId: "user-12345"
})If you configure HubSpot property to be used for upsert in the dashboard but omit that property in theidentifytraits, RudderStack uses
Trait mappings
The following table lists the mappings between the RudderStack properties and the HubSpot properties:
| RudderStack property | HubSpot property |
|---|---|
traits.emailcontext.traits.emailproperties.email | email |
traits.firstNametraits.firstnametraits.first_namecontext.traits.firstNamecontext.traits.firstnamecontext.traits.first_nameproperties.firstname | firstname |
traits.lastNametraits.lastnametraits.last_namecontext.traits.lastNamecontext.traits.lastnamecontext.traits.last_nameproperties.lastname | lastname |
phone | phone |
traits.address.streetcontext.traits.address.streetproperties.address.street | address |
traits.address.citycontext.traits.address.cityproperties.address.city | city |
traits.address.countrycontext.traits.address.countryproperties.address.country | country |
traits.address.statecontext.traits.address.stateproperties.address.state | state |
traits.address.postalcodecontext.traits.address.postalcodeproperties.address.postalcode | zip |
traits.company.namecontext.traits.company.nameproperties.company.name | company |
Handle null and empty property values
The following table explains how specific trait values are handled when you update HubSpot properties from Event Stream or a Reverse ETL source connected to this destination:
| Trait value | Event Stream | Reverse ETL |
|---|---|---|
null | Clears the property | Leaves the property unchanged |
"" (empty string) | Clears the property | Clears the property |
undefined | Leaves the property unchanged | Leaves the property unchanged |
false or 0 | Sent unchanged | Sent unchanged |
- In an Event Stream connection,
nulltrait values are converted to""before the request is sent. HubSpot treats""as a clear signal and removes the property value. - In a Reverse ETL connection,
nullvalues are omitted from the update payload, so the existing HubSpot value is not modified.
To clear a HubSpot property from a Reverse ETL sync, map an empty string ("") for that field.
The HubSpot API clears properties only when you send "" — it does not accept null.
See the following HubSpot references for more information:
Track
A track call lets you record various user actions and any properties associated with them.
To associate a track call with a user, you need to specify the user’s email under context.traits.
RudderStack associates thetrackevents with the same user only after you make a successfulidentifycall. However, if you send atrackcall without making anyidentifycall first and there is no contact present in HubSpot, RudderStack will not associate the events as there is no identifier.
A sample track event is as shown:
rudderanalytics.track(
"Order Completed", {
value: 30,
}, {
context: {
traits: {
firstname: "Alex",
city: "New Orleans",
country: "USA",
phone: "+1-202-555-0146",
email: "alex@example.com",
},
},
}
)Property mappings
The following table lists the properties and their mappings between RudderStack and HubSpot for the track call:
| RudderStack property | HubSpot property |
|---|---|
traits.utkcontext.traits.utkproperties.utk | utk |
traits.emailcontext.traits.email | email |
traits.objectIdcontext.traits.objectIdproperties.objectId | objectId |
properties.occurred_attimestamporiginalTimestamp | occurredAt |
You must send either of theutk,objectId(can becontact_idorvisitor_ id) properties to make atrackcall successfully.
Custom behavioral events
The custom behavorial events can be used for both the authentication types. However, they must have theanalytics.behavioral_events.sendpermission to be used for private apps.
Custom behavioral events are account-defined events in HubSpot that store event details in the event properties. You can create custom behavioral events and their associated properties in the RudderStack dashboard as explained in the New API section.
The following parameters are sent in the custom behavorial events:
- Identifier: Either the contact ID, email, or utk (user token) of the contact associated with the event. The utk is the user token stored in the visitor’s
hubspotutkbrowser cookie. - Event name: The internal name of the event which can be found in HubSpot.
- Properties object: When you create a custom behavioral event in HubSpot, some default properties are provided with those events, explained in the below section.
Behavioral events property mappings
The following table lists the optional and default property mappings between RudderStack and HubSpot for custom behavioral events:
| RudderStack property | HubSpot property |
|---|---|
properties.assetDescriptionproperties.hsAssetDescription | hs_asset_description |
properties.assetTypeproperties.hsAssetType | hs_asset_type |
properties.campaignId | hs_campaign_id |
traits.address.citycontext.traits.address.cityproperties.address.city | hs_city |
traits.address.countrycontext.traits.address.countryproperties.address.country | hs_country |
context.device.name | hs_device_name |
properties.elementClassproperties.hsElementClass | hs_element_class |
properties.elementIdproperties.hsElementId | hs_element_id |