In addition to the standard properties of a Stripe object, metadata offers a flexible and powerful means of storing additional information. This information can be anything from a unique identifier to additional data that you want to track.
For businesses using HubSpot that want a more automated payment processing experience, using saas•hapily with Stripe is the way to go.
No matter the reason for storing metadata in Stripe, this information can often help enrich your HubSpot data. saas•hapily makes it easy to sync metadata associated with customers, subscriptions, and transactions to your HubSpot records.
In this article, we will cover how to separate (parse) Stripe metadata in HubSpot.
Because metadata fields can vary greatly between object types, individual records, and use cases, saas•hapily does not create a property for each possible metadata field.
Instead, saas•hapily syncs all metadata fields on stripe Customers, Subscriptions, and Transactions to a HubSpot property on the relevant record.
Giving you full control to determine which properties and values are placed where.
Since saas•hapily syncs all Stripe metadata fields to a single property, you will need to utilize a HubSpot Custom Coded Workflow Action to parse the values.
Metadata will enter the workflow in this format:
{"domain_name":"saas•hapily.com","account_id":"123"}
And the values will leave nicely nested in a HubSpot Property!
Depending on the type of object you are parsing metadata for, you will need to create a workflow based on that object. In this example, we will be creating a saas•hapily Subscription based workflow
Set the workflow enrollment trigger to " Subscription Metadata is Known" if you want the metadata to parse when the object is created.
Set "Subscription Metadata has been updated in the last 1 day" and turn on re-enrollments if you want subscription metadata to update anytime it's updated in Stripe.
Set the following fields:
CODE:
Add a Copy Property Value action for each data output.
In this example, I have added 2 outputs. One for the "fieldOne" output and another for the "fieldTwo" output.
And that's all folks! If you run into any issues in building this or would be interested in us building it for you, do not hesitate to get in touch!