CRM Search API – email search does not distinguish accented vs non‑accented characters in local part

Smart CRM & Sales Hub CRM
1

We’re seeing unexpected behaviour when searching contacts by email, where the only difference is an accented character in the local part of the email address.

We have two different contacts:

Contact 1: sudipè@testuser.com

Contact 2: sudipe@testuser.com

When we search using the Search API, the results don’t reliably distinguish between these two emails. Depending on the query, we can get both contacts when we expect only one, or we can’t reliably target just one of them.

Example request:

http

Copy code

POST https://api.hubapi.com/crm/v3/objects/contacts/search

Content-Type: application/json

Authorization: Bearer <REDACTED>

{

“filterGroups”: [

{

“filters”: [

{

“propertyName”: “email”,

“operator”: “EQ”,

“value”: “sudipè@testuser.com”

}

]

}

],

“properties”: [“email”]

}

Observed behavior:

The search may return both contacts (sudipè@testuser.com and sudipe@testuser.com) or otherwise treat them as not clearly distinct when we expect an exact match on the full email address.

In general, the search API does not appear to clearly distinguish between accented (è) and non‑accented (e) characters in the local part for our use case.

Expected behavior:

sudipè@testuser.com and sudipe@testuser.com should be treated as two distinct email values.

A search with operator: “EQ” and value: “sudipè@testuser.com” should only return the contact whose email is exactly sudipè@testuser.com.

Questions:

Is this behavior expected for the CRM Search API (e.g., any Unicode normalization or tokenization being applied to the email field)?

Is there a supported way to enforce strict, accent‑sensitive, exact matching on the email property via the Search API?

If this is not expected, can you log this as a bug/defect with the search service?

2

This looks like diacritic-insensitive indexing / Unicode normalization in the Search API (accent folding), so é may be treated the same as e. That would explain why operator: “EQ” doesn’t behave like a strict byte-for-byte match.

Also: Unicode email addresses can be valid (EAI / SMTPUTF8), but a lot of systems don’t handle them consistently.

If you need a reliable workaround:

  • A “copied” text property may still behave the same if it’s indexed the same way.
  • If you need strict distinction, store a separate key like email_strict_hash (e.g. SHA-256 of the raw email in UTF-8). Hashes are ASCII-only, so they won’t be affected by accent folding and remain unique.
  • If you want to prevent duplicates, store an email_normalized version (lowercase + remove accents) and use that as your dedupe key.

I’d also raise this with HubSpot support/docs to confirm whether the email field is indexed as diacritic-insensitive and whether strict matching is supported at all via Search.