Skip to main content

Identifier Hashing and Normalization

When automatic hashing is enabled for a reverse ETL field mapping, Extract handles the required normalization methods before hashing the raw identifier.

How Extract decides whether to hash​

In the field-mapping editor, any destination field with a hash property gives you two options:

  • Apply hashing (SHA256): the source column can contain raw customer data, and Extract will run the destination-specific normalization and hashing step before sending it.
  • Source values are already hashed: Extract treats the incoming value as already hashed and does not hash it again.

apply_hashing defaults to true, and static-value mappings are never hashed.

Exact normalization is still destination-specific. Each destination page documents the behavior for that connector in its own Hashing and normalization section.

Execution order​

When Apply hashing (SHA256) is enabled, the flow is:

  1. Extract maps the source field into the data-contract field.
  2. The destination connector applies its identifier normalization rules.
  3. Extract hashes the normalized value with SHA-256 and sends the lowercase hex digest.

When Source values are already hashed is selected, Extract forwards the value as-is, aside from any connector-specific field renaming needed by the partner API.

Common normalization methods​

Extract can apply one or more of these normalization steps before hashing, depending on the destination connector:

  • trim(): remove leading and trailing whitespace before hashing.
  • Lowercasing: convert values such as emails to lowercase before hashing.
  • E.164 phone normalization: canonicalize phone numbers into the +[country code][number] format before hashing.

What the shared E.164 helper does​

For the destinations that use normalize_phone_e164, Extract:

  • Accepts numbers already in E.164 form such as +15551234567.
  • Accepts some formatted inputs such as +1 (415) 555-2671 or (+1)2133734253.
  • Requires an explicit country code.
  • Rejects values without a country code, such as (415) 555-2671.

Examples​

For destinations that lowercase and trim email before hashing:

  • Input: ALICE_abc@gmail.com
  • Normalized email: alice_abc@gmail.com
  • SHA-256: 848a771458438fc2ec420560d769fb9b9b86851ee338ec56517baabd79d3bb4f

For destinations that normalize phone numbers with the shared E.164 helper:

  • Input: (+1)2133734253
  • Normalized phone: +12133734253
  • SHA-256: 9f7ec22d72092cd3c0b58726ed9c2d91b92e51a3f29837508fb2948bb22dd2fd

Practical guidance​

  • If the customer sends raw email or phone values, leave Apply hashing (SHA256) enabled when the destination page says the connector applies the normalization you need.
  • If the customer already hashes upstream, choose Source values are already hashed.
  • If the partner requires a stricter normalization step than the connector currently performs, normalize and hash upstream, then pass the pre-hashed value through unchanged.
warning

Several partner APIs document their own normalization requirements. Treat the destination-specific docs and the partner specification as the source of truth for that connector.