DEV Community: Veramask API Team

Passing a data protection audit with a stateless API

Veramask API Team — Mon, 12 Oct 2026 07:00:00 +0000

Data protection audits rarely fail on the database you secured. They fail on
the copies you forgot: the log aggregator, the nightly backup, the APM
tenant, the CRM sync, the export someone made for a migration and never
deleted. An audit is a walk through every place personal data lives, and
every copy that isn't on your map — with a retention period, an access
policy, and an owner — is a finding. The stronger your core system looks, the
more these side copies stick out.

This article covers what a data protection audit actually asks for, the
copy-multiplication pattern that fails them, and how placing a stateless
anonymization boundary in front of your writes changes the conversation:
what it removes from audit scope, what it deliberately does not remove, and
the evidence you should have in the room when the auditor arrives.

What a data protection audit actually covers

The material is predictable. Under GDPR — and mirrored by CCPA/CPRA and the
US state privacy laws in slightly different vocabulary — an audit walks
seven areas:

Area	What the auditor asks for	Where it comes from
Records of processing (Art 30)	A per-purpose inventory: what data, why, where it flows, how long	Your RoPA
Data-flow maps	Every system and copy a record touches, including processors	Architecture diagrams
Lawful basis per activity	Each processing purpose mapped to a basis (contract, consent, legitimate interest)	Privacy policy + RoPA
Retention evidence	Concrete periods per store and the mechanism that enforces deletion	Retention schedule
DSAR readiness	How access, erasure, and portability requests execute end-to-end, with timings	Runbook + endpoints
Breach readiness	The 72-hour notification process (Art 33), roles, decision trees, templates	Incident response plan
Processor terms (Art 28)	A DPA per processor and a disclosed sub-processor list	Contracts + privacy policy

None of this is exotic. The failure mode is not ignorance of the list — it is
that the honest answers to it sprawl faster than the documentation tracks
them. Every new log sink, SaaS integration, and backup tier adds rows to
three of those seven areas at once.

The pattern of failure: unmapped copies

The typical finding sequence looks like this. The auditor asks to see every
system holding customer personal data. You show the application database —
encrypted, access-controlled, retention-timed, documented. Then they ask
about logs, and the room gets quieter. The application writes request bodies
to stdout; the aggregator holds them for 30 days; the nightly backup holds
them for a year; the error tracker holds the payloads that crashed the
webhook handler, sometimes with looser access than production. Four stores,
four retention clocks, four access paths — and one of them is a third party
whose storage you don't control.

Copy	Why it exists	Why it's a finding
Log aggregator	Debugging and observability	Plaintext PII with a retention period set by ops convention, not policy
Nightly backups	Disaster recovery	Deletion requests don't reach backups; the retention clock is the backup cycle
APM / error tracker	Exception triage	Error payloads carry request context; hosted tenant you can't scrub
CRM / analytics sync	Business tooling	A processor copy governed by a DPA you may not have signed

The deeper problem is that none of these copies was a decision. Nobody
chose to put PII in the aggregator — the aggregator ingests whatever the app
writes, and the app writes what it logs. As
the hidden cost of logging PII
argues, the point of exposure is the write, not the read. After-the-fact
scraping can't reliably fix it, and you generally cannot run a delete job
against a vendor's hosted storage. The control that works is upstream of the
write.

The subtractive move: anonymize at the boundary

Most privacy controls are additive: encryption at rest, access control,
retention timers, audit logging. Each layers on top of a system that still
holds the data — each reduces risk, none reduces it to zero, because the data
is still there.

Boundary anonymization is subtractive. Sanitize the payload before the
write and the copy never contains the personal data — so it never needs its
own retention clock, its own DSAR procedure, or its own line in the breach
analysis. The copy drops off the audit's map entirely.

The mechanism in this stack is a stateless anonymization API: you send text
or JSON, it returns the same structure with sensitive entities replaced, and
it retains nothing — no payload store, no input logging, no training corpus.
The five-clause contract behind that claim (no persistent store, no input
logging, no training on customer traffic, no cross-tenant state, memory as
the only medium) is laid out in
why stateless anonymization reduces exposure.
Here, the question is what that contract does to an audit.

What a stateless boundary removes from audit scope

The anonymization step never appears as a data store. Your data-flow map gains a transformer, not a box holding regulated data. Diagrams stay small; the RoPA entry for the redaction leg is one line.
No retention clock on the redaction leg. A store that retains nothing has no retention period to document, no deletion job to demonstrate, and no backup tier to explain.
No vendor-storage DSAR dependency. Erasure requests don't generate a ticket to a redaction vendor's warehouse, because there is no warehouse. Your DSAR runbook stays inside systems you control.
No vendor-storage breach scenario. The blast radius of a vendor incident ends at non-content operational metadata — timestamps, request sizes, processing durations, detected entity types. Painful for the vendor, but not a personal-data breach on your side of the contract.
The DPIA stays proportionate. A processing leg with no storage, no profiling, and no persistence is a low-risk leg. Your assessment effort concentrates where the originals actually live.

What it does not remove

This section is the one to read twice, because over-claiming is how
subtractive controls get written up as findings themselves:

The processor still goes in your sub-processor list and RoPA. Zero retention changes the description of the processing, not the obligation to disclose it. "Anonymization API, zero-retention, volatile-memory processing" is the entry — not silence.
The Art 28 DPA is still required. A processor acting on your behalf needs a data processing agreement whether it keeps data for three years or three hundred milliseconds. Retention length is a term inside the DPA, not an exemption from having one.
You still need a lawful basis for sending the data through. The call itself is processing: personal data in transit is personal data. The basis that lets you process the payload in the first place covers the call.
Pseudonymized output is still regulated. Salted hashes and stable synthetic mappings are pseudonymisation — re-linkable with additional information you hold (the salt), so still personal data under Recital 26. Truly irreversible output can exit scope, but know which transformation produced each field before you claim it. The deterministic anonymization guide covers where that line sits.
Operational metadata still gets a line. Non-content metrics are not the payload, but "timestamps, sizes, durations, entity types" is still a sentence in your RoPA entry. Disclose it precisely and it's unremarkable.
Everything upstream keeps its Article 32 measures. Your database of originals still needs encryption, access control, and breach detection — all of it. The subtractive control is for the copies; the system of record keeps every layer it always had.

The auditor checklist

The core deliverable: map each standard question to the evidence, and note
where the boundary changes the answer.

Auditor asks	Evidence to have ready	Where the stateless boundary helps
"Show me every system holding customer PII"	Data-flow map + RoPA	Sinks written post-boundary hold tokens, not PII — the map stays small and true
"How long is data retained in each store?"	Retention schedule per store	The anonymization leg adds no clock; each sink's own policy still applies to its tokenized content
"Walk me through a DSAR end-to-end"	Runbook + export/erasure endpoints	Fewer copies to search and purge; no dependency on a redaction vendor's storage
"What happens in a breach?"	Incident plan, Art 33 timeline, comms templates	Copies that were never written can't be breached — the notification analysis for those legs is empty
"Who processes data on your behalf?"	Sub-processor list + DPAs	The anonymization API is listed as a zero-retention processor; describe exactly that
"Where do logs fit?"	Log retention policy + scrubbing evidence	Logs written post-boundary contain tokens; the evidence is the anonymization configuration on the write path
"Show me your DPIA"	DPIA or documented low-risk assessment	The redaction leg has no storage to assess; risk concentrates where originals live

A before-and-after: one webhook, four copies

Take a payment webhook. The provider posts a payload with the customer's
name and email; your handler writes it to the audit table, the log
aggregator picks up the structured log line, the error tracker captures
failures, and the nightly backup sweeps the database. One event, four
stores.

Without a boundary:

Dimension	State
Stores holding the email	4 (audit table, aggregator, error tracker, backup)
Retention clocks	4, set by four different policies
DSAR effort	Search and purge 4 systems; file a deletion request with the tracker vendor
Breach analysis	All 4 copies in scope; each needs its own notification assessment

With a boundary at ingestion — one call to anonymizeJSON before
anything is written:

curl -X POST https://api.veramask.com/v1/anonymizeJSON \
  -H "x-api-key: $VERAMASK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data": {
      "event": "subscription.updated",
      "customer": { "name": "Jane Doe", "email": "jane.doe@example.com" },
      "note": "Called from 203.0.113.42 about invoice 4711"
    },
    "settings": {
      "locale": "en_US",
      "consistency_salt": "0123456789abcdef"
    },
    "overrides": {
      "PERSON": { "type": "substitute", "attribute": "name" },
      "EMAIL_ADDRESS": { "type": "hash" },
      "IP_ADDRESS": { "type": "hash" }
    }
  }'

{
  "masked_data": {
    "event": "subscription.updated",
    "customer": { "name": "Christopher Taylor", "email": "9f2c1a..." },
    "note": "Called from 8f223fc... about invoice 4711"
  }
}

The structure is preserved — non-string fields pass through, arrays and
objects are traversed, downstream parsers keep working — but the four stores
now hold a synthetic name and a stable hash token instead of the original.
The consistency_salt keeps the token deterministic, so support can still
correlate a ticket to a subscription without the email existing in any copy;
that mechanism is covered in
deterministic anonymization: join keys without storing PII.

Dimension	State
Stores holding the email	0 — the email exists only in transit and in the system of record
Retention clocks	The four stores' policies still apply, but to non-personal data
DSAR effort	Those four legs are one line: "no personal data retained"
Breach analysis	Nothing personal on that path to notify about; the salt is the only secret, and it lives in your secret manager

FAQ

Do I still need a DPA with a zero-retention vendor?

Yes. GDPR Article 28 governs any processor acting on your behalf; retention
length is negotiated inside that agreement, not a pass on signing it. A
stateless anonymization vendor is the easiest DPA you'll sign — the
processing description is short and the sub-processor list is short — but
sign it, file it, and list the vendor in your privacy policy.

Is anonymized output outside GDPR scope?

It depends which transformation produced it. redact and replace remove
the original outright, and unsalted substitute emits fictional values with
no derivable link — candidates for true anonymization under Recital 26's
"reasonably likely means" test. Salted hash and salted substitute are
pseudonymisation: you hold the salt, so the link to the original exists, and
the output remains personal data. Audit your overrides field by field and
document each one's classification.

What evidence should I keep for the anonymization control?

Four artifacts: the anonymization configuration (which entity types get which
strategies, on which write paths), the salt governance policy if you
pseudonymize, the processor list entry plus signed DPA, and the one-line RoPA
description of the zero-retention processing. That packet answers every
question in the checklist above.

Does a stateless API replace encryption and access controls?

No. It is subtractive for the copies; the systems that still hold originals —
your database, your backups of it — keep every Article 32 measure they always
had. The pattern is: subtract where the data need not exist, layer security
where it must.

Does this help with CCPA and US state privacy laws too?

The mechanics map directly. Right-to-know and right-to-delete get easier with
fewer copies to search; "reasonable security" is easier to demonstrate when
the side copies hold tokens; and breach notification scope shrinks along with
the copies. Different statutes, same arithmetic: less data stored, less to
answer for.

Originally published at
veramask.com.

How to anonymize data without breaking your analytics

Veramask API Team — Mon, 05 Oct 2026 07:00:00 +0000

Your privacy team ships anonymization. A week later, your analytics team
files a ticket: daily active users dropped 90%, the conversion funnel leaks
at every step, and duplicate detection stopped firing. Nobody did anything
wrong — anonymization did its privacy job, and in the same pass it destroyed
every join key in the dataset. The same person now looks like a different
person on every request, because each call generated a fresh fake value.

The fix is a pattern, not a product: make the anonymization deterministic
with a salt you keep. Same input plus same salt equals same output — every
call, every service, every environment. The masked value becomes a stable
handle for the record it came from, so you can group, join, and trace exactly
as you did before, without storing any original value and without running a
tokenization vault. This article walks the pattern, the pseudocode, the salt
governance, and the cases where you should not use it.

Why anonymization breaks analytics

What you were doing	What happens with random anonymization
`GROUP BY user`	One real user fragments into N synthetic users — counts inflate, averages smear
Sessionization and funnels	Steps can't be linked to one subject; funnels leak at every stage
Cross-service tracing	Service A's log and service B's event carry different fake values for the same person
Duplicate detection	Every copy of a record looks unique; dedupe never fires
Joining logs to a warehouse	No shared key on either side
"Top users by activity"	Rankings become noise; heavy users never concentrate on one token

The underlying issue: the anonymized value was carrying the identity.
Destroying identity is anonymization's privacy job — the mistake is
applying it where identity was also the analytical key. Determinism
restores the key while never emitting the original value. The token is a
handle to the record, not the record.

The pattern: salted determinism

No memory, no vault, no coordination service. You pick a secret salt, keep
it in your configuration, and pass it to the anonymization function. The
function mixes the salt into the transformation:

hash computes a salted SHA-256 of the value. Same input + same salt → the same 64-hex-character token, every time.
substitute picks the synthetic value as a deterministic function of the input and the salt. Same input + same salt → the same fake name, email, or phone number, every time.

// The whole pattern in one call:
anonymize(text, {
  salt: "0123456789abcdef", // >= 16 bytes, from your secret manager
  overrides: { EMAIL_ADDRESS: { type: "hash" } }
})

The salt is the only cross-request link, and it is yours. Two services that
share nothing else — no shared database, no token service, no coordination
calls — derive the same token for the same value, because both run the same
function with the same salt. Correlation without a vault.

Hash tokens as join keys

The classic use: sanitize logs for PII while keeping them traceable.

anonymize("User Jane Doe (jane.doe@example.com) failed checkout from 203.0.113.42", {
  salt: "0123456789abcdef",
  overrides: {
    EMAIL_ADDRESS: { type: "hash" },
    IP_ADDRESS: { type: "hash" }
  }
})
// → "User Jane Doe (9f2c1a...) failed checkout from 8f223fc..."

Every log line that mentions that email now carries the same 9f2c1a...
token. Grep for the token and you have the user's complete trail — without
the email existing in any line. Put the same salt in another service's
config and it computes the same token independently: cross-service joins
with zero infrastructure between them.

Stable synthetic values

Hashes are ugly in datasets humans read. Salted substitute gives you the
same determinism in realistic shape:

anonymize("Alice Smith can be reached at alice@example.com", {
  salt: "0123456789abcdef",
  overrides: {
    PERSON: { type: "substitute", attribute: "name" },
    EMAIL_ADDRESS: { type: "substitute", attribute: "email" }
  }
})
// → "Christopher Taylor can be reached at pespinoza@example.com"

Every occurrence of Alice Smith in the salted corpus becomes
Christopher Taylor; every occurrence of her email becomes
pespinoza@example.com. A staging database seeded this way keeps working:
group-bys return stable per-user rows, and the data still looks like data.

One caveat: substitution does not preserve relationships between fields.
The fake name and the fake email are each individually stable, but they do
not describe the same fictional person. If you need referential integrity
across entity types, use the hash as the join key and substitute only for
human-readable surfaces.

Salt governance: the salt is a credential

Determinism moves the secret from a database into the salt. Treat it like
one:

Generate it randomly, store it in a secret manager — never in the repo, never in code.
Never log it next to the tokens it produces. A salt published beside its hashes turns every pseudonym into a verifiable guess target.
Scope it per purpose. One salt for log sanitization, a different one for the dataset you share externally. Tokens from one scope can't be correlated with the other, and one leak doesn't compromise everything.
Rotate it knowing the cost. A new salt re-baselines every token; new values stop matching historical ones. Version the generation (a token_epoch column) so consumers know which era a token belongs to, and destroy the old salt once the migration is done.
Deleting the salt is the off switch. With it gone, tokens can no longer be verified against candidate values — the pseudonymization link you created is severed, which is exactly what you want when the analytical purpose expires.

When not to salt

Determinism is a default for pipelines, not a law of nature:

Small populations. A stable token per subject preserves cardinality and frequency. In a five-user dataset, the token is the user — context alone re-identifies them. If a recurring fake value would itself be a leak, you want per-request randomness.
Low-cardinality fields. Fifty states map to fifty tokens; frequency analysis matches them in minutes. Deterministic substitution of location fields buys nothing analytically and confirms structure to an attacker.
One-shot jobs. A single log line that will never be joined to anything gains nothing from a salt — and every salt you manage is a credential with a rotation cost.
Freshness is the point. Demo screenshots, red-team fixtures, and load-test payloads often want different fake data every run. That is what unsalted anonymization gives you.

A token vault, minus the vault

The enterprise alternative is a tokenization vault: an encrypted store
mapping originals to tokens, with a detokenization API for authorized
callers. Vaults work — and they are a concentrated database of originals you
must run, secure, back up, and audit forever. The salt gets you the same
correlation property with a different architecture:

	Tokenization vault	Salted determinism
What it is	A database of original ↔ token mappings	A secret plus a pure function
Server-side store	Yes — the vault holds every original	None — nothing to store, nothing to breach
Reversible	Yes, by design (detokenization)	hash: not decryptable — with the salt you can verify a guess, never recover the value. substitute: not derivable at all
Operational cost	Run, secure, back up, audit, scale the vault	Keep one secret in the secret manager
Breach impact	The vault is a single point of total PII compromise	A leaked salt is a rotated credential; no data store sits behind it
GDPR posture	Pseudonymisation with added attack surface	Pseudonymisation with subtractive storage

If you need the original back later — support workflows that must
re-identify a customer — you want a vault or encryption, not anonymization.
If you need correlation without recovery, the salt is the whole answer.

FAQ

Is a salted hash anonymous data?

No — it is pseudonymisation. Because the salt plus the token lets you verify
candidate values, GDPR treats the output as personal data; the regulation
recognizes the technique, under Article 32(1)(a), as a security measure
rather than an exemption. If your goal is true anonymization — data that
exits GDPR scope — the tools are deletion, aggregation, and noise, not
hashing.

What happens when I rotate the salt?

Every token changes. Treat rotation as a re-baseline: version the token
generation so both eras stay queryable, or accept the cliff and reprocess
what you can. Keep the old salt only for the migration window, then destroy
it — a retired salt has no analytical value and nonzero risk.

Can I use one salt for everything?

Technically yes; hygienically, scope per purpose. One salt means one leak
compromises every dataset's linkability, and internal-log tokens could be
correlated with tokens in a dataset you shared externally. Separate salts
per purpose are free — more entries in the secret manager — and they cap the
blast radius of any disclosure.

Why do I get different outputs for the same input?

Usual causes: no salt passed at all (unsalted substitutions and hashes vary
by request — that is normal behavior); a different salt between calls; or
the two calls ran with different strategy overrides. Confirm the exact same
salt string and the same overrides are being sent every time before
debugging anything else.

If you want a concrete implementation of this pattern to compare against,
Veramask — the PII anonymization API behind the canonical examples on
veramask.com — implements it as the consistency_salt
setting on its hash and substitute strategies, with the stateless
contract that keeps the salt and the payloads out of any server-side store.

Why stateless anonymization reduces exposure

Veramask API Team — Mon, 17 Aug 2026 05:02:00 +0000

Anonymization has to lower your risk, not move it. The moment a redaction
service stores the text you sent it — for training, for caching, for "insights"
— it becomes a second system holding the same regulated data you were trying to
remove. You have not closed the boundary; you have widened it. Stateless
anonymization is the architectural choice that prevents that drift: the service
reads your payload in volatile memory, returns the masked version, and keeps
nothing. The reduction in exposure is structural, not contractual.

This article walks through why statelessness is the property that makes an
anonymization tool safe to put in the critical path, where the failure mode of a
stateful service sits, and how to reason about the trust boundary when you
evaluate any redaction vendor.

Direct answer

Why does stateless anonymization reduce exposure? Because it removes the
second copy of the data. Every stateful redaction service — one that logs
inputs, caches payloads, builds models, or keeps a "training set" — creates a
new data store you now have to govern with the same retention controls, access
policy, and breach response as the system you were trying to protect. A
stateless service holds the data only for the duration of the request, in memory
that is overwritten on the next call. There is no persistent copy to breach, to
subpoena, to retroactively delete, or to forget to delete.

Where the exposure actually lives

When you send PII to a redaction service, two questions decide your residual
risk: how long the service keeps the input, and who can reach what it kept.
A surprisingly large share of "anonymization" products fail the first question
by design.

Data the service holds	New exposure it creates
Input payloads written to a request log	A second breach surface, with the original — not anonymized — values
Cached payloads for "performance"	A hot store governed by the cache's TTL, not your retention policy
A training corpus built from customer traffic	Personal data harvested for a purpose the data subject never consented to
Error payloads captured for debugging	Untreated PII sitting next to stack traces, often with looser access than prod
Repromised inputs in an analytics warehouse	A copy that survives your deletion request because it lives outside your tenant

Each row is a new retention clock. Under GDPR, the deletion deadline and breach
notification timeline are reckoned from when the data was collected, not from
when you eventually delete it. A stateful redaction service that "forgets
later" does not reset that clock — it just hands you a second one to track.

The structural problem is not that stateful services are malicious. Most are
not. The problem is that keeping data is the path of least resistance for any
product team: logging inputs makes debugging easier, caching makes latency
lower, and a training corpus makes the model better. Each is a reasonable
engineering choice in isolation. Aggregated, they turn an anonymity tool into a
PII aggregator, and the privacy posture of the aggregator is now part of your
own posture.

The stateless contract

Statelessness is not a marketing claim; it is a property you can verify. A
service is stateless with respect to your data if all of the following hold:

No persistent store. Input payloads are not written to disk, object storage, a database, or an append-only log. Memory used during a request is released at the end of the request, not pooled for reuse against the next tenant.
No input logging. Request bodies are excluded from application, access, and error logs. If an error payload must be captured for diagnostics, the PII-bearing fields are stripped or hashed before the line is written — never after.
No training on customer data. Models are trained on licensed or synthetic corpora, not on traffic flowing through the production API. This is the one clause most easily violated silently; ask for it in writing and check the data processing terms.
No shared request-scoped state across tenants. What one customer sends cannot be observed by, or influence the processing of, another customer's request. A deterministic salt supplied by the caller is the cross-request link — not server-side session state.
Memory is the only medium. Where intermediate buffers are needed (say, to stream a large JSON payload), they live in RAM for the lifetime of the request and are not persisted to a temp file or swap.

The first three are the ones that matter for compliance. The last two matter
for correctness and multi-tenant isolation. Together, they collapse the trust
boundary to a single request: what you send is what gets processed, and what
gets processed is what you get back. Nothing accumulates.

Why this is the cheapest privacy control you can ship

Most privacy controls are additive — they layer on top of a system that
already holds data: encryption at rest, access controls, retention timers,
audit logging, DPIAs. Each is a new surface you must operate and audit. Each
reduces risk but never to zero, because the data is still there.

Statelessness is subtractive. It removes a class of risk rather than managing
it. Concretely:

No breach surface to defend. You cannot exfiltrate a database that does not exist. The most secure data store is the one you never built.
No retention clock to forget. Data that is never stored cannot be forgotten late. There is no DSAR hole, no stale backup to chase, no "we deleted the row but the warehouse copy survived" incident.
No DPIA for the redaction path. A stateless service that processes and forgets does not appear as a data store in your data flow maps. You still need a lawful basis for sending the data, but you no longer need to defend the vendor's storage.
No vendor-lock risk in the data. A stateless service holds nothing, so there is nothing to export, nothing to migrate, and nothing the vendor can hold if you switch.

The control is cheap because the architecture is cheap. The same property that
protects your users protects the vendor: less state means less to operate, less
to back up, less to audit, less to explain to regulators.

How to evaluate a redaction vendor's actual surface

When the sales deck says "we don't store your data," the architectural
questions that disambiguate are narrow and worth asking directly:

Question	What you are really asking
Do request bodies appear in your application logs in plaintext?	Whether the access log is a second breach surface
How long do cached payloads live, and where?	Whether "performance" extends your retention though a back door
Is customer traffic used to train your models?	Whether the product improves itself on data you sent it
Where do error payloads — including the raw input — get written?	Whether debugging infrastructure is a quiet PII sink
Is data partitioned per tenant at rest, or is it a shared store?	Whether a tenant boundary breach exposes every customer

A vendor that can answer all five with "no" or "nowhere" and back it with a
contracts clause and an audit report is stateless in the sense that matters. A
vendor that hedges on any one — "we keep a cache for performance," "we may use
anonymized samples to improve the model," "errors are logged with the request
context" — is stateful by another name, and the retention clock is running on
your data inside their boundary.

The failure mode of a stateful redaction service

The worst outcome is not a vendor that mishandles data; it is a vendor that was
designed to handle data safely and drifts. Stateful redaction services tend
to add retention surfaces over time in three predictable ways:

Latency wins. A cache for "warm" payloads gets added to reduce p99, and suddenly inputs live for an hour at the edge.
Quality wins. A model fine-tuning pipeline starts sampling production traffic because retraining on synthetic data is not improving recall.
Support wins. A debug capture job, scoped to one noisy tenant, starts keeping raw request bodies "for a week, with access limited to engineering" — and stays on.

Each is a reasonable local decision. None violates the original "we don't store
your data" promise as the vendor remembers it. But the boundary you agreed to
no longer matches the boundary that exists. A stateless architecture makes
these drifts structurally harder to add — there is no store to extend, no
schema to migrate, no cache tier to plumb in. The friction is not a bug; it is
the control.

A mental model: shrinking the trust boundary

You can draw any privacy architecture as a set of trust boundaries. Each
boundary is a place where regulated data lives and a set of principals who can
reach it. The smaller the set of boundaries that hold the original data, the
smaller your exposure. A stateful redaction service adds a boundary — and
extends the perimeter of any breach that hits you into that vendor's
infrastructure.

A stateless service is a boundaryless transformer. It accepts data, mutates
it, returns it. The regulated data still flows through it, but it does not
dwell in it. From a data-flow perspective, it is closer to a pure function
than to a database. When you choose tools for the critical path — the path
between "your user types something" and "the value reaches your log line, your
warehouse, or a third party" — a boundaryless transformer is what you want,
because every durable store you avoid is a store you do not have to defend.

FAQ

Does "stateless" mean the service keeps nothing whatsoever?

No. A stateless redaction service keeps your data for no longer than the
request. It still keeps operational metadata that any service keeps — request
counts, latency metrics, error rates — because those are necessary to run and
observe the service. The statelessness guarantee is specifically about the
input payload and the masked output: neither is persisted, logged, or repromised
beyond the lifetime of the request that produced it.

Can a stateless service still leak data?

Yes — via the operator, the network, and the in-memory window. Statelessness
reduces the persistent surface to zero, but the request still exists in
volatile memory for some milliseconds, traverses the network, and is produced by
code you do not control. The mitigations are the standard ones: TLS in transit,
memory that is overwritten between requests, no shared process memory across
tenants, and a vendor you have a real contract with. Statelessness is not the
only control you need; it is the one that makes the storage surface
evaporate.

If a stateless service forgets everything, how can it be deterministic?

Determinism comes from the output, not from remembering the input. When you
supply a salt, the service applies a deterministic function (typically a salted
hash) to each detected value — the same input plus the same salt always yields
the same masked output on every call. The reproducibility lives in the
function and in the salt you keep, not in any server-side state. This is what
lets the same value produce the same join key across log lines and services
without the redaction service ever storing the original.

Is a stateful redaction service ever the right choice?

Sometimes. A large-batch job that has to replay the same corpus many times —
for re-processing, for backfill, for multiple downstream consumers — may
benefit from a service that holds intermediate state so callers do not
re-upload. In those cases the right pattern is to keep the corpus under your
boundary, anonymize it in a stateless pass, and never send the raw data to a
third party that retains it. Statefulness is acceptable inside your own
perimeter; it is a liability when it lives in a third party's.

If you want a concrete implementation to compare against

The stateless, zero-retention model described here is the architecture
Veramask is built on: payloads are processed in volatile memory, nothing is
persisted, and no customer traffic is used for model training. If you want to
see how that contract is expressed in the API surface — entity types,
override strategies, the consistency-salt mechanism that makes output
deterministic without server-side state — the
architecture and API docs walk through it end to end.

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

Veramask API Team — 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

Veramask API Team — 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

Veramask API Team — 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.