Third-party APIs require the data you send to be of a specific data type. Unless otherwise specified, Hightouch takes the data from your source and leaves the data type unchanged to send to your destination.
You'll see these icons in the Hightouch UI to distinguish various data types:
Hightouch intentionallly stringfies the field you designate as the 'primary
key' in your model for enhanced record matching performance. If you also need
to sync the primary key as a non-string value, use SQL aliasing in your model
to create a new field specifically for syncing.
In order for your data to reach its destination without error, its data type must match the data type required by the destination. You can use 'casting' to turn of value of one data type into another data type.
If your model's primary key is not already a string, Hightouch will intentionallly stringfy it for enhanced record matching performance.
If the casting of the primary key makes it incompatible with the data type your destination is expecting, we recommend you use SQL aliasing to create an additional field for mapping.
For example, if you use a field called id as your primary key, Hightouch will stringify that number to perform the matching and diffing operations.
Many destinations actually expect a field called id to be a string. Some destinations, however, expect id to be an integer. This will cause a data type conflict if you need to map your primary key in addition to using it for matching.
Using SQL aliasing and casting can solve for this issue. In this example query of a customers table, we select the customer_id - the primary key - which will be stringified and used for matching in Hightouch. Then, we select the customer_id again but alias it as id_for_mapping and cast it is an int so that id_for_mapping can be mapped to a destination field:
SELECT customer_id, CAST(customer_id ASint) AS id_for_mapping
Our team is relentlessly focused on your success. We're ready to jump on a call to help unblock you.
Connection issues with your data warehouse?
Confusing API responses from destination systems?
Unsupported destination objects or modes?
Help with complex SQL queries?
If you see something that's missing from our app, let us know and we'll work with you to build it!
We want to hear your suggestions for new sources, destinations, and other features that would help you activate your data.