DEV Community: Michele

Choosing a PII anonymization strategy: when mask, redact, replace, hash, or substitute wins

Michele — Mon, 03 Aug 2026 06:00:00 +0000

Any tool that anonymizes PII from free text gives you roughly five levers:
mask, redact, replace, hash, and substitute. They all
answer one question — how much of the original value do you keep, and in what
form? The choice is rarely global. A support screen needs the last four of a
card to be recognisable; a log aggregator needs a stable join key that is not
the original email; a screenshot fixture for a compliance deck needs one
canonical placeholder, not a different synthetic value every run. Pick the
strategy per field, not per codebase. This article walks through each
strategy, what it does to the value, and a decision matrix for picking the
right one per use case.

The diagram shows the same input — the email jane.doe@example.com — fed
through each of the five strategies. The rest of this article explains why
you would pick one over another and how to combine them in a single call.

Why the choice matters

The strategy you pick is the privacy/utility knob for that field. Strip
everything and you lose the diagnostic value of a log line; preserve
everything and you have not anonymized anything. A default that is right for
one team is rarely right for every team. A production log aggregator, a
development seed dataset, and a screenshot fixture for a compliance training
deck want three different things from the same email address. The rest of
this article is about recognising which case you are in and choosing the
strategy to match.

Mask

Mask keeps the structure of the value and hides part of it. You usually
pick it when the value still has to look like itself, just less complete.

anonymize(text, {
  EMAIL_ADDRESS: {
    type: "mask",
    char: "*",
    count: 5,
    fromEnd: false
  }
})

A common default for credit cards is to keep the last four digits,
for IP addresses to keep the first three octets, and for MAC
addresses to keep the OUI while hiding the rest.

Best for: support screens where an agent still needs the last four of a
card or a recognisable email shape to find a record; logs that must stay
greppable; and any UI that benefits from the user seeing a value is there
without showing the whole value.

Operational note: residual plaintext is still sensitive. Masking is a
usability tool, not a privacy boundary.

Redact

Redact is the simplest strategy: the detected value is removed entirely.
The configuration object is just { type: "redact" }.

anonymize("Alice Smith can be reached at asmith@mygoogle.com", {
  EMAIL_ADDRESS: { type: "redact" }
})
// → "Alice Smith can be reached at "

It is a common default for URLs when you want to keep the base address
but drop query strings and other tracking material.

Best for: free-text fields where the PII carries no diagnostic value —
error messages, exception payloads, customer-support copy pasted into a
ticket. It is the minimum-friction option when you genuinely do not need the
value downstream.

Operational note: redact destroys all signal. If a downstream parser expects the
entity to be a non-empty string, redact will hand it an empty slot and may
crash on whitespace. Wrap it with a sentinel if your pipeline needs one.

Replace

Replace substitutes every occurrence of the detected entity with one
fixed value that you provide.

anonymize(text, {
  EMAIL_ADDRESS: {
    type: "replace",
    value: "dummy@example.com"
  }
})

Replace is rarely the default for any entity. The value you supply is
global: every email in the request becomes dummy@example.com, every phone
number becomes +1-555-0100, and so on.

Best for: seed data for screenshots and compliance training decks;
demo fixtures that have to look like real data but must not be real;
synthetic test inputs where you want a single canonical placeholder rather
than a different synthetic value per occurrence.

Operational note: every detected entity collapses to one value. If your dataset
has a hundred email addresses, they all become dummy@example.com — so
uniqueness is destroyed by construction, and any downstream check that
relies on distinctness (duplicate detection, per-user correlation, group-by)
will produce nonsense. Replace is for display, not analysis.

Hash

Hash turns the detected value into a fixed-length token. Most
implementations use SHA-256 and, when a salt is provided, produce the same
token for the same input across calls.

anonymize(text, {
  salt: "0123456789abcdef",
  overrides: { IP_ADDRESS: { type: "hash" } }
})

Hash is the common choice for crypto addresses and, in practice, a very
common choice for IP addresses in log sanitisation. Without a salt, each
request hashes independently and the same value can produce a different token
on every call; with a salt, the output is deterministic across calls and
across services.

Best for: cross-record correlation. If you need to trace one user
across dozens of log lines without storing the original value, hash with a
stable salt gives you the join key. The token is a stable handle for the
record — every log line that mentions the same email produces the same
token, so you can join records across services without ever seeing the
original.

Operational note: hash is a pseudonymisation technique. The salt is a
separate secret you must govern alongside the data — rotate it like any
other credential, restrict who can read it, and never log it next to the
hashes. If the link to the original is no longer needed, delete or rotate
the salt so the records can no longer be re-derived.

Substitute

Substitute swaps the detected value for realistic synthetic data of the
same type. Configuration is type and an optional attribute that hints
what flavour of synthetic data to produce.

anonymize(text, {
  salt: "0123456789abcdef",
  overrides: {
    EMAIL_ADDRESS: { type: "substitute", attribute: "email" }
  }
})

When a salt is provided, the same input always produces the same synthetic
output across calls — every endpoint, every region, every CI run. With the
salt, substitute becomes a join key: the same jane.doe@example.com will
appear in every record that originally referenced that user, without
revealing anything about the original address. Without the salt, synthetic
values vary by request, so substitute is only useful when you don't need to
re-identify the same record later.

Substitute is the common default for person names (a fake name from the
same locale), locations (a synthetic address or state), phone
numbers (a fake number in the same format), and email addresses (a
fake address with a plausible domain). It is the closest strategy to a
"functional but not real" copy of the original.

Best for: analytics pipelines that still need to group by user; dev
and staging environments seeded with realistic-looking data; datasets
shared with third parties where the receiving system has to keep working
but the subjects have to stay anonymous. Substitute preserves the
shape of the data, so downstream code, regexes, and validators all
behave as they would with real values.

Operational note: synthetic is not original. Substitute does not preserve
uniqueness, does not preserve relationships between fields (a substituted
name and a substituted email will not belong to the same fake person),
and on low-cardinality entity types (countries, currencies, states) the
synthetic value can collide with the real one in the same dataset. For
correlating records, use hash. For preserving function, use substitute.

Decision matrix — what each strategy does

Strategy	Output shape	Reversible to original?	Format kept?	Length kept?	Joinable across records?
`mask`	Partially redacted original	n/a (partial plaintext remains)	Yes (character class preserved)	Configurable (`char`, `count`, `fromEnd`)	Weak (the unmasked tail varies)
`redact`	Empty (entity removed)	No	n/a	n/a	No
`replace`	One fixed caller value	No	Yes (you choose)	Yes	No — every entity collapses to one value
`hash`	Fixed-length hex (SHA-256, salted if a salt is set)	Pseudonymisation — the salt is a separate secret you govern	No (hex)	Fixed (64 hex chars for SHA-256)	Yes, with a salt
`substitute`	Realistic synthetic value of the same type	No (synthetic, not derivable)	Yes (same type and locale)	Approximately	With a salt: same input → same synthetic output. Without: no.

Decision matrix — pick by use case

If you need to…	Pick	Why
Show a human the last four of a card, or a recognisable email shape	`mask`	Preserves the part of the value that humans use to recognise the record
Remove PII from a free-text log line and never need the value again	`redact`	Lowest-friction default; the entity disappears entirely
Trace one user across dozens of log lines without storing the original	`hash` with a salt	Deterministic token gives you a join key without keeping the value
Seed a dev environment or share a dataset with a third party without re-identification risk	`substitute`	Synthetic data keeps the pipeline functional, but the subject is fictional
Build a screenshot fixture for a compliance training deck	`replace`	One global placeholder is easier to read in a static image than a hash
Sanitise web-hook payloads from a payment provider before they reach your APM	`mask` (card) + `redact` (everything else)	Card last-four stays useful for support; everything else is noise
Default a new service to "no PII in logs" without bespoke per-entity config	`redact` for free-text + `mask` for cards	Two overrides cover most cases; expand from there as you find needs

Combining all five in one call

A real integration rarely uses one strategy. Most APIs let you key overrides
by entity type, so you can mix strategies per entity in a single call:

anonymize(
  "User Jane Doe (jane.doe@example.com) called from 203.0.113.42 about order #4711",
  {
    locale: "en_US",
    salt: "0123456789abcdef",
    overrides: {
      PERSON: { type: "substitute" },
      EMAIL_ADDRESS: { type: "mask", char: "*", count: 4, fromEnd: false },
      IP_ADDRESS: { type: "hash" },
      URL: { type: "redact" },
      PHONE_NUMBER: { type: "replace", value: "+1-555-0100" }
    }
  }
)

That single call replaces the person with a synthetic name, masks the local
part of the email, hashes the IP, redacts the URL, and collapses any phone
number to a fixed placeholder. The five strategies compose per entity
because they live in the same overrides map — the call itself does not pick
a global mode.

FAQ

How does hash relate to GDPR?

Hash is a pseudonymisation technique — exactly the kind of risk-reduction
measure GDPR encourages for systems that hold personal data. A salted hash
gives you the best of both worlds: the log aggregator no longer holds the
original value (a meaningful improvement over plaintext), and the salt is a
separate secret you can govern independently of the data — rotate it, scope
it, audit access. If your goal is to correlate records across services
while keeping the original out of your logs, a salted hash is the right
tool. If your goal is to break the link to the original entirely
(irreversible anonymisation in the strict GDPR sense), that is a different
problem solved by deletion, aggregation, or noise injection, not by
hashing. The same framework also supports redaction, replacement, and
substitution when you want to remove the original outright.

Can I get the original back from substitute or replace?

No. substitute generates a synthetic value with no relationship to the
original that can be inverted; replace substitutes one fixed value you
supplied. Both are irreversible by design. If you need reversibility, the
anonymisation tool is the wrong choice — you want encryption, not
anonymisation, and you should think carefully about who holds the key and
under what lawful basis.

Is mask GDPR-compliant?

It depends on how much of the value you keep. Masking the first eight of
sixteen card digits still leaves eight digits, which is enough to
re-identify the cardholder against a known-card database. Mask is a
usability tool, not a privacy boundary. For a privacy boundary you want
redact, replace, substitute, or hash — in roughly that order of strength.

Does substitute preserve uniqueness?

No. The synthetic name Jane Doe may be produced for a hundred different
original subjects, and a substituted email may collide with a real email
elsewhere in the dataset. If you need a join key, use hash with a salt.
If you need realistic shape, use substitute. If you need both, apply them to
different entity types in the same overrides block.

Can I combine strategies per entity in one call?

Yes — that is the normal mode. The overrides map is keyed by entity type
(PERSON, EMAIL_ADDRESS, IP_ADDRESS, and so on), and each value is its
own strategy object. You can mix mask, redact, replace, hash, and
substitute freely across entity types in the same call. The one rule is
that one entity type gets one strategy per call; if you want to apply two
transformations to the same entity, you run the call twice or chain a
second one.

If you are mapping this to a real API

Use the same decision matrix, then swap in your provider’s exact entity names
and field names from the docs. The trade-offs stay the same even when the
syntax changes.

If you want a concrete implementation to compare against,
Veramask is the product behind the canonical examples on veramask.com.

The Hidden Cost of Logging PII

Michele — Tue, 21 Jul 2026 08:55:11 +0000

Logging personally identifiable information (PII) is the breach you have
already created but may not have found yet. Every console.log(user), every
audit row with a plaintext email, every error payload forwarded to a third-party
APM tool — each one is another copy of regulated data outside your intended
boundary. The cost is not the log line itself. It is the compliance exposure,
the breach response, the trust hit, and the engineering time spent cleaning up
something that should never have been written in the first place.

This article breaks down why PII in logs gets expensive fast, why after-the-fact
cleanup rarely solves the problem, and how to make the boundary safe by default.

The bill shows up in audit season

If logs contain personal data, you are processing personal data. That means the
usual privacy rules still apply: lawful basis, purpose limitation, data
minimization, retention control, access management, and security by design.
When those logs are compromised, GDPR notification duties can apply under
Articles 33 and 34, and CCPA / CPRA can expose certain breaches to private
actions and statutory damages. US state privacy laws add more notification
timelines and remedies on top.

The uncomfortable part is the blast radius. A single compromised database is
one incident. The same PII replicated into application logs, nightly backups,
and a SaaS APM dashboard is the same incident multiplied across every copy —
and every copy brings its own retention clock, access path, and vendor risk.

Asked another way:

Is logging PII illegal?
Not categorically. But it is processing, and it needs a lawful basis, a
documented purpose, retention limits, and appropriate safeguards. Logs kept
"for debugging" with no retention cap and no access control rarely meet that
bar. The real question is whether your logging would survive a
data-protection audit.

Why logs are the soft underbelly

Application teams usually model threats around the request path: the API
boundary, the database, the session store. Logs sit beside that path, written
as a side effect and rarely reviewed with the same rigour. Four patterns cover
most PII-in-logs incidents:

console.log(user) and friends. Dumping the user object is the fastest way to debug auth flows — and the fastest way to land email, phone, and sometimes address into stdout, which then ships to a log aggregator.
Audit and history tables. "Log everything to the database for compliance" sounds safe until compliance officers ask who can read the table, how long rows live, and whether they're encrypted at rest.
Error and webhook payloads. Unhandled exceptions are often logged verbatim. Webhook bodies from payment providers can carry customer names, emails, and billing addresses.
CI fixtures and test artifacts. Production-shaped fixtures exported for local testing, or stack traces uploaded as build artifacts, quietly move PII outside the production trust boundary.

The common thread: the point of exposure is the write, not the read. By
the time anyone notices, the log aggregator, the backups, and the third-party
APM tenant all hold copies — and each copy is a separate retention clock.

The four cost categories

Cost category	What it covers	Why logs make it worse
Regulatory fines	GDPR penalties, CCPA / CPRA remedies, state-law penalties	Logs expand breach scope; copies in third-party systems count separately
Breach remediation	Forensics, notification, credit monitoring, legal review	Every log sink (APM, SIEM, backups) must be scrubbed individually
Reputational / trust	Churn, lost deals, public reporting obligations	"We leaked data through our own logs" reads as negligence, not a sophisticated attack
Engineering toil	Log scrub projects, retroactive redaction, audit responses	Months of work; often blocks new features; recurs every time a new sink is added

The engineering-toil row is the one teams underestimate. A single
PII-in-logs incident can spawn a quarter-long remediation programme covering
every service, every environment, and every third-party destination — and if
the root cause is still unregulated log writes, the same project repeats when
the next sink appears.

Why redaction-after-the-fact fails

The instinctive fix is a log scraper: run a job over cold logs, find PII,
redact it, move on. It's seductive and almost always wrong.

Scrapers miss unstructured text. Regex for emails is easy; regex for names, addresses, and clinical notes inside free-text error messages is not. Coverage gaps are the rule, not the exception.
Retention clocks start at write-time. Under GDPR, the deletion deadline is not fixed by when you finally clean the log. After-the-fact redaction does not undo the period when the data was exposed.
Third-party tenants aren't yours to clean. You can scrub your own Elasticsearch cluster. You generally cannot run a delete job against your APM vendor's hosted storage — you can request deletion, and you can wait.
Regex is locale-fragile. Phone formats, address layouts, and ID-number conventions vary across regions. A US-only pattern misses EU IBANs and Japanese phone numbers.

The conclusion is structural: you cannot reliably clean logs after the fact,
so you have to avoid writing the PII in the first place. That shifts the
intervention to the boundary — before the log line exists.

A default-safe path

The reliable pattern is to anonymize PII at the boundary, before it ever
reaches a console.log, an audit table, or an exception handler. Veramask
exists to make that boundary anonymization a one-line call instead of a bespoke
regex pipeline. It is stateless and zero-retention: you send text or JSON, it
returns anonymized text or JSON, and it keeps nothing — which matters for logs
specifically, because the last thing you want while fixing a logging problem is
a second system holding the same PII.

A typical call looks like this:

curl -X POST https://api.veramask.com/v1/anonymizeText \
  -H "x-api-key: $VERAMASK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": "User Jane Doe (jane.doe@example.com) failed checkout from 203.0.113.42",
    "settings": {
      "locale": "en_US",
      "confidence_threshold": 0.8,
      "consistency_salt": "0123456789abcdef"
    },
    "overrides": {
      "PERSON": {
        "type": "substitute",
        "attribute": "name"
      },
      "EMAIL_ADDRESS": {
        "type": "mask",
        "masking_char": "*",
        "chars_to_mask": 10,
        "from_end": false
      },
      "IP_ADDRESS": {
        "type": "hash"
      }
    }
  }'

{
  "masked_data": "User Jane Doe (**********e@example.com) failed checkout from 9f2c1a..."
}

The response is the only thing you should ever let near a log. The strategy
choices map directly to what good log hygiene needs:

mask preserves structure and length, which is useful when logs must stay greppable and you still need correlation.
redact removes the entity entirely, the right default for free-text error messages where the value has no diagnostic value.
hash with a consistency_salt produces a deterministic, non-reversible token — the same value always hashes to the same string, so you can trace a user across log lines without storing the original.
replace and substitute cover synthetic-value and locale-preserving cases, such as swapping a real name for a generic one while keeping the surrounding sentence readable.

That boundary matters because you stop guessing which patterns to chase.
Veramask detects the common log-risk entities in one pass, including email
addresses, phone numbers, credit cards, IP addresses, IBANs, locations, URLs,
dates, names, medical licenses, NRP, crypto addresses, and MAC addresses. The
full strategy reference lives in the
transformation strategies docs, and the endpoint
contracts are in the API specifications.

A practical checklist

Do	Don't
Anonymize at the boundary, before the log write	Rely on a weekly log-scraper to clean up later
Treat logs as data stores: retention, access control, encryption	Assume `console.log` is throwaway and unread
Hash with a stable salt when you need cross-line correlation	Log the raw value "just this once" for debugging
Review every third-party log destination in your DPIA	Forward raw error payloads to APM by default
Default new services to "no PII in logs" from day one	Add redaction retroactively, service by service

FAQ

Does hashing count as anonymization?
Hashing with a secret salt is pseudonymization, not anonymization — given the
salt and the hash, a value can still be checked. It is a strong improvement
over plaintext, because logs become uncorrelatable without the salt, but it is
still regulated data. For logs, deterministic hashing is usually the right
practical answer because it gives you correlation without storing the original.

What if I only log PII internally?
"Internal" is a control, not an exemption. GDPR and CCPA scope processing, not
exposure — writing PII to an internal-only log is still processing and still
needs a lawful basis, purpose limitation, and retention controls. Internal logs
also do not stay internal for long: they are backed up, indexed, and queried by
operators who do not need the original data for their job.

How does a stateless, zero-retention API help with logs?
It removes the second-copy problem. A redaction service that keeps your PII to
learn from it is a new data store you now have to govern. Veramask processes
the request in volatile memory and returns the anonymized result — no
persistence, no training, no retention. The only copy of the PII that existed
was the one you sent, and the only thing that should hit your logs is the
anonymized response.

Connect with us

Follow @veramaskapi on X
Try the API at veramask.com
Read the transformation strategies and API specifications docs

How to Anonymize PII in Text with an API

Michele — Thu, 09 Jul 2026 21:48:22 +0000

What Is Data Masking?

Data masking is a technique that replaces sensitive information with realistic but fictitious data, preserving the format and structure of the original while removing its identifiable meaning. The goal is to keep data usable for development, testing, analytics, or sharing — without exposing real personally identifiable information (PII).

Common masking techniques include:

Substitution — Replace a real value with a plausible fake (e.g., Alice Smith → Jane Doe).
Masking (partial obscuring) — Show only a portion of the value (e.g., 4111-1111-1111-1234 → ****-****-****-1234).
Redaction — Remove the value entirely.
Hashing — Replace with a cryptographic hash. Irreversible, but deterministic when salted.

Data masking is widely used in non-production environments, analytics pipelines, data marketplaces, and any scenario where real PII is not needed but structural fidelity is.

What Is Dynamic Data Masking?

Static data masking (SDM) applies transformations to data at rest — you clone a production database, mask it, and ship the masked copy to a lower environment. The masking happens once, and the result is a permanent dataset.

Dynamic data masking (DDM) applies transformations on the fly, at query or API time, based on who is asking. The original data stays untouched; the masking rules are applied in the response layer. This means:

Different roles see different levels of detail (e.g., support agents see the last 4 digits of a credit card; auditors see the full number).
No masked copies to maintain — one source of truth, many views.
Masking policies are centralized and enforceable without application changes.

Veramask implements a DDM-style model over an API: you send a request with payload and settings, and receive back the transformed result in real time. No data is persisted on the server — each call is independent and stateless.

Anonymizing PII with the Veramask API

Veramask exposes two endpoints for dynamic PII masking:

Endpoint	Input	Use Case
`POST /v1/anonymizeText`	Raw string	Free-text fields, log lines, chat messages, documents
`POST /v1/anonymizeJSON`	JSON object	Structured payloads, API responses, database records

Both accept a common set of controls: settings for global behavior (locale, confidence threshold, consistency salt) and overrides for per-entity-type strategy selection.

Step 1: Get an API Key

Sign up through the Veramask Developer Portal to obtain an API key. You will include this key in the x-api-key header of every request.

Step 2: Make Your First Anonymization Request

The simplest call sends raw text and relies on default strategies for each detected entity type.

curl -X POST https://veramask-gateway-3irxmt23.uc.gateway.dev/v1/anonymizeText \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "data": "Alice Smith can be reached at alice@example.com or +1 555 123 9999"
  }'

Response:

{
  "masked_data": "Jane Doe can be reached at fake_user@example.com or +1 555 482 7714"
}

Notice that PERSON, EMAIL_ADDRESS, and PHONE_NUMBER were all detected and replaced with synthetic substitutes — the names are swapped, the email faked, and the phone number replaced — while the sentence structure is preserved.

Step 3: Choose Your Anonymization Strategy Per Entity Type

You can override the default behavior for any entity type using the overrides object. Five strategies are available:

Strategy	Behavior
`mask`	Partially obscures the value (configurable character, count, direction)
`redact`	Removes the value entirely
`replace`	Substitutes with a fixed caller-provided value
`hash`	Replaces with a SHA-256 digest (salted when `consistency_salt` is set)
`substitute`	Replaces with realistic synthetic data via the Faker library

Example — Mask email addresses, hash phone numbers, substitute person names:

curl -X POST https://veramask-gateway-3irxmt23.uc.gateway.dev/v1/anonymizeText \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "data": "Alice Smith can be reached at alice@example.com or +1 555 123 9999",
    "overrides": {
      "PERSON": { "type": "substitute", "attribute": "name" },
      "EMAIL_ADDRESS": {
        "type": "mask",
        "masking_char": "*",
        "chars_to_mask": 10,
        "from_end": false
      },
      "PHONE_NUMBER": { "type": "hash" }
    }
  }'

Response:

{
  "masked_data": "Christopher Taylor can be reached at **********@example.com or a1b2c3d4e5f6..."
}

Step 4: Enable Deterministic (Repeatable) Output

By default, Veramask produces different synthetic values on each call. If you need consistent anonymization — for example, to join datasets across time without leaking identity — provide a consistency_salt.

curl -X POST https://veramask-gateway-3irxmt23.uc.gateway.dev/v1/anonymizeText \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "data": "Alice Smith can be reached at alice@example.com",
    "settings": {
      "consistency_salt": "0123456789abcdef"
    }
  }'

The same input with the same salt always produces the same output. This is deterministic pseudonymization — the transformation is repeatable without maintaining a lookup table.

Step 5: Anonymize Structured JSON

For JSON payloads, use /v1/anonymizeJSON. Veramask traverses all string values recursively.

curl -X POST https://veramask-gateway-3irxmt23.uc.gateway.dev/v1/anonymizeJSON \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "data": {
      "customer": {
        "name": "Alice Smith",
        "email": "alice@example.com"
      },
      "notes": [
        "Home address: 7211 Jewel Lake Rd, Anchorage, Alaska"
      ]
    },
    "settings": {
      "confidence_threshold": 0.7
    },
    "overrides": {
      "EMAIL_ADDRESS": { "type": "substitute", "attribute": "email" }
    }
  }'

Response:

{
  "masked_data": {
    "customer": {
      "name": "Christopher Taylor",
      "email": "pespinoza@example.com"
    },
    "notes": [
      "Home address: 7211 Lake Brentland, Kathymouth, Rowehaven"
    ]
  }
}

The JSON structure is preserved exactly — keys, nesting, and non-string types are untouched. Only string values containing PII are transformed.

Step 6: Tune Detection Sensitivity

The confidence_threshold (range 0.0–1.0, default 0.4) controls how aggressively Veramask flags tokens as PII:

Lower values (e.g., 0.2) — more aggressive; catches borderline cases but may over-mask.
Higher values (e.g., 0.8) — conservative; only masks high-confidence detections, reducing false positives.

"settings": {
  "confidence_threshold": 0.8
}

End-to-End Workflow Summary

Client App                  Veramask Gateway              Anonymization Engine
    │                             │                              │
    │  POST /v1/anonymizeText     │                              │
    │  x-api-key: ...             │                              │
    │  { data, settings, ... }    │                              │
    │────────────────────────────>│                              │
    │                             │  1. Authenticate API key     │
    │                             │  2. Check subscription       │
    │                             │  3. Validate features        │
    │                             │  4. Attach GCP key           │
    │                             │                              │
    │                             │  POST /anonymizeText         │
    │                             │  { data, settings, ... }     │
    │                             │─────────────────────────────>│
    │                             │                              │
    │                             │    NER → strategy → mask     │
    │                             │                              │
    │                             │  { masked_data }             │
    │                             │<─────────────────────────────│
    │                             │                              │
    │                             │  5. Strip internal fields    │
    │  { masked_data }            │                              │
    │<────────────────────────────│                              │

Default Entity Strategies (No Overrides)

When you don't specify overrides, Veramask applies sensible defaults per entity type:

Entity Type	Default	Example Output
`CREDIT_CARD`	Mask (last 4)	`****1234`
`CRYPTO`	Hash	`e3b0c442...`
`DATE_TIME`	Jitter (±7 days)	Date shifted deterministically
`EMAIL_ADDRESS`	Substitute	`fake_user@example.com`
`IBAN_CODE`	Partial hash	`DE******9999`
`IP_ADDRESS`	Mask (last octet)	`192.168.1.0`
`MAC_ADDRESS`	Mask (last 3 octets)	`AD:F3:7A:00:00:00`
`PERSON`	Substitute	Synthetic name
`LOCATION`	Substitute	Synthetic state/region
`PHONE_NUMBER`	Substitute	Synthetic phone number
`URL`	Redact (query strings)	Keeps base domain

Error Handling

Status	Meaning
`400`	Malformed request or validation failure
`403`	Feature not in subscription plan
`413`	Payload exceeds size limit
`422`	Request model validation errors
`500`	Internal server error

Key Takeaways

Data masking obscures PII while preserving structure; dynamic data masking does this at request time with no persistent copy.
Veramask gives you an API-first DDM layer: send data, get it back anonymized, no storage involved.
Five strategies (mask, redact, replace, hash, substitute) give per-entity-type control.
A consistency_salt enables deterministic pseudonymization for referential integrity.
The /v1/anonymizeText endpoint handles free text; /v1/anonymizeJSON handles structured objects.
Zero retention means no long-term PII liability on the service side.