Accept hashed Email + Phone in requests - #65
Open
mosherBT wants to merge 5 commits into
Open
Conversation
Adds an OptableIdentifier.raw case for identifiers that are already type-prefixed and encoded, such as a hashed Email obtained from a backend or a newsletter link. The value is sent as-is. This also fixes tryIdentifyFromURL, which pulled the SHA256 oeid out of the URL and then passed it through .emailAddress, hashing it a second time and sending an EID that could never match. The Objective-C identifierWithString: factory had the same problem. Mirrors OptableIdentifier.Raw in the Android SDK.
Adds .hashedEmailAddress and .hashedPhoneNumber for callers that already hold a SHA256 of the value, such as a HEM supplied by a backend or CRM. The value is normalized (whitespace removed, lowercased) and prefixed, but not hashed a second time. Also fixes init?(extendedIdentifier:), which mapped an encoded 'e:'/'p:' value back onto .emailAddress/.phoneNumber and therefore hashed it again. This is what made tryIdentifyFromURL send sha256(sha256(email)) for the oeid in newsletter links.
mosherBT
changed the title
Swift imports all-caps NS_ENUM tokens verbatim, so OptableSDKIdentifierType_HEM is .HEM, matching the existing .ID5 and .UTIQ cases rather than the lowerCamelCase ones.
mosherBT
force-pushed
the
feature/accept-hashed-identifiers
branch
from
August 13, 2026 19:21
dfb14ca to
a961e07
Compare
mosherBT
force-pushed
the
feature/accept-hashed-identifiers
branch
from
August 13, 2026 19:47
59e1854 to
6d7bcc2
Compare
etiennelatendresse-optable
approved these changes
Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
.hemfor callers that already hold a SHA256 of an Email address, so a HEM can be passed toidentify/targetingwithout the SDK hashing it again. Previously.emailAddressalways hashed its input and there was no way in for HEM values. Also adding the same function for phone numbers.Bug Fix
In the newsletter path there
tryIdentifyFromURL(url)we were double hashing ex.SHA256(SHA256(email@test.com))so any newsletter path was silently ignoring emails. The double hash would look normal but would never match HEM(email).Introduced here due to
OptableEncoderabstraction. Before (HEM into identify call) versus after where we apply the hash to the HEM, since it comes through withe:prefix