> For the complete documentation index, see [llms.txt](https://ask.birdie.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ask.birdie.ai/integrations-and-data-ingestion/field-hashing.md). # Field Hashing Birdie supports protecting sensitive attributes before storage using cryptographic hashing. When enabled, specific fields (e.g., national ID numbers, email, phone number, account identifiers) are transformed into irreversible hashes before being stored. Hashing is **not enabled by default**. Clients must explicitly request which fields should be protected. No key generation or key management is required from the client. *** ### How It Works When field hashing is enabled, Birdie applies a one-way cryptographic hash (**HMAC-SHA-512**) to the configured field before storage. The original value is permanently replaced and is not stored anywhere. The transformation is **deterministic** — the same input always produces the same output. This allows the hashed value to function as a stable identifier for: * Joins * Segmentation * Deduplication * Equality comparisons Because hashing is one-way, there is **no decryption process**. *** ### Irreversibility Field hashing is irreversible by design. Birdie does not store any information that would allow recovery of the original value. If you need to identify the original value behind a hashed record, you must correlate it against your own database. For example, if an account identifier was hashed, you can match the hashed value with your internal records to determine which account generated a given ticket. *** ### Enabling Field Hashing To enable hashing, contact the Birdie team and specify which fields should be protected. No additional setup is required from your side. *** ### Input Formatting Field values are hashed exactly as received. Different representations of the same logical value will produce different hashes. For example: * `12345678900` and `123.456.789-00` produce different hashes * `Email@domain.com` and `email@domain.com` produce different hashes * Trailing or leading whitespace changes the result To ensure consistent matching and deduplication, normalize formatting before ingestion. Recommended practices include: * Removing punctuation when applicable * Standardizing casing (e.g., lowercase emails) * Trimming whitespace * Ensuring consistent encoding (UTF-8) *** ### Security Hashing uses **HMAC-SHA-512**, a standard cryptographic construction defined in: * [RFC 2104 (HMAC)](https://datatracker.ietf.org/doc/html/rfc2104) * [FIPS 180-4 (SHA-512)](https://csrc.nist.gov/publications/detail/fips/180/4/final) A secret, organization-specific **pepper** is used as the HMAC key. This ensures: * Protection against brute-force enumeration attacks * Isolation between organizations * Strong resistance even for low-entropy fields (such as national ID numbers) The pepper is securely managed by Birdie and is never exposed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ask.birdie.ai/integrations-and-data-ingestion/field-hashing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.