Residency and redaction

Pinning data to a jurisdiction, and removing what should never have been sent.

Residency

A dataset's region is fixed at creation and determines where blocks rest — see regions. Pin the datasets that carry regulated data and leave the rest on the default.

Redaction at ingest

Redaction rules run before the event is written, so redacted values never touch storage. This is the only kind of redaction that helps you in a breach.

cURL

curl -X POST https://api.logstreem.com/v1/datasets/api-gateway-prod/redactions \
  -H "Authorization: Bearer $LOGSTREEM_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rules": [
      { "field": "user.email",     "action": "hash" },
      { "field": "request.headers.authorization", "action": "drop" },
      { "field": "message", "action": "mask",
        "pattern": "\\b\\d{13,16}\\b", "replacement": "[card]" }
    ]
  }'

Action	Result	Still useful for
`drop`	The field is never stored	Nothing — it is gone
`hash`	Replaced with a stable SHA-256	Grouping and counting distinct users
`mask`	Regex matches replaced inside the value	Keeping a readable message

Redaction is not retroactive

A rule added today does nothing to events written yesterday. If secrets have already been ingested, trim the dataset or delete it — there is no selective erase.

hash beats drop for user ids

A hashed email still answers "how many distinct users hit this error" and still joins across datasets, without storing the address. Dropping it answers nothing.

PreviousUsage and billing NextMCP server