Docs

Run the prebuilt binary

After downloading the compiled artifact, make it executable and start the service with the config file.

chmod +x anonymix_linux_amd64-v1.0.0
./anonymix_linux_amd64-v1.0.0 -config config.yaml

The binary will listen on the address configured by `server.listen_addr` in the YAML file or via environment overrides.

Run with a license

Set the license key before starting the binary so anonymix runs in commercial mode.

# Set the license key and deploymentId in config.yml
./anonymix_linux_amd64-v1.0.0 -config config.yaml

Set the license key and deploymentId in config.yml with the values provided by your license issuer.

Example config.yaml

server:
  listen_addr: "0.0.0.0:8080"
  max_body_bytes: 10485760       # 10 MiB
  max_batch_items: 100
  read_timeout_ms: 5000
  write_timeout_ms: 10000
  idle_timeout_ms: 60000
  allowed_origins: ["http://localhost:8080"]
  # tls_cert_file: "/etc/anonymix/tls.crt"
  # tls_key_file: "/etc/anonymix/tls.key"

anonymix:
  redaction_token: "[REDACTED]"
  field_rules:
    - pattern: "firstName"
      action: redact
    - pattern: "lastName"
      action: redact
    - pattern: "fullName"
      action: redact
    - pattern: "name"
      action: redact
    - pattern: "email"
      action: redact
    - pattern: "*.password"
      action: redact
    - pattern: "UserData.ssn"
      action: redact
    - pattern: "*_token"
      action: redact
  regex_rules:
    - id: "custom_employee_id"
      pattern: "EMP-\d{6}"
      priority: 1
      full_value: false
  built_in_patterns:
    # Ids cover both the Tier 1 regex rules (R01-R15) and the Tier 1.5
    # contextual detectors (C01-C09).
    # Leave "enabled" empty to activate all built-ins except those disabled.
    # Setting it makes it an allow-list over BOTH tiers, so name the C0x ids
    # explicitly if you use it.
    enabled: []
    disabled:
      - R07  # IPv6

  # Tier 1.5 -- contextual detection. Finds PII that carries no formatting of
  # its own, such as a bare "5551234567" rather than "555-123-4567", which the
  # Tier 1 regexes cannot match without also matching every order number.
  #
  # A candidate is redacted only when a structural validator accepts it (Luhn
  # for cards, the issuing rules for SSNs, the numbering plan for phones) AND a
  # cue word sits nearby or in the enclosing key. A Luhn-valid card number is
  # the one exception: the checksum is evidence enough on its own.
  #
  # Detectors, toggled through built_in_patterns above:
  #   C01 payment card       C04 international phone   C07 bank routing number
  #   C02 US SSN             C05 7-digit local phone   C08 device / ad UUID
  #   C03 NANP phone         C06 non-ISO date of birth C09 driver's licence
  contextual:
    enabled: true
    # How far from a candidate a cue word may sit, in bytes. The search always
    # stops at a line break.
    cue_window_before: 48
    cue_window_after: 24
    # Additional cue words per detector, for non-English or domain-specific
    # deployments. Purely additive: built-in cues are never removed.
    extra_cues: {}
      # C02: ["numero de securite sociale", "amka"]

ner:
  # When enabled, uses the built-in pure-Go NER recognizer (no model files
  # required). It redacts contextual PII such as person names and locations in
  # free-text values whose length is at least min_text_length.
  enabled: true
  min_text_length: 20
  entity_types:
    - "PER"
    - "LOC"
  batch_window_ms: 5
  max_batch_size: 16
  max_tokens: 512

rate_limit:
  enabled: true
  requests_per_second: 1000
  burst: 200

logging:
  level: "info"          # debug | info | warn | error
  format: "json"

license:
  # Paste your commercial or trial license token here to activate the
  # software.
  key: ""
  # Alternatively, point at a file containing the token (mutually exclusive
  # with "key").
  key_file: ""
  # Must match the deployment ID your license is bound to. Both commercial and
  # trial licenses are bound to the email you used to obtain them — use that
  # same email here.
  deployment_id: ""

How to use the REST API with JSON payloads

The REST API is available at the root of the service. You can send a POST request to the `/anonymize` endpoint with a JSON payload containing the data you want to anonymize.

POST /v1/anonymize
Content-Type: application/json

{
  "email": "john@example.com",
  "ssn": "123-45-6789",
  "text": "Contact john@example.com or call 555-123-4567. SSN on file: 123-45-6789."
}

→ 200 OK
{
  "email": "[REDACTED]",
  "ssn": "[REDACTED]",
  "text": "Contact [REDACTED] or call [REDACTED]. SSN on file: [REDACTED]."
}

How to use the REST API with XML payloads

The REST API is available at the root of the service. You can send a POST request to the `/anonymize` endpoint with an XML payload containing the data you want to anonymize.

POST /v1/anonymize?type=xml
Content-Type: application/xml

<person><email>john@example.com</email><name>Jane</name></person>

→ 200 OK
<person><email>[REDACTED]</email><name>[REDACTED]</name></person>

How to use the REST API with batch JSON payloads

The REST API is available at the root of the service. You can send a POST request to the `/anonymize` endpoint with a JSON payload containing an array of the JSON the data you want to anonymize.

POST /v1/anonymize/batch
Content-Type: application/json

[
  {"email":"a@b.com"},
  {"ssn":"123-45-6789"},
  {"note":"call 555-123-4567"}
]

→ 200 OK
[
  {"email":"[REDACTED]"},
  {"ssn":"[REDACTED]"},
  {"note":"call [REDACTED]"}
]

How to use the REST API with batch XML payloads

The REST API is available at the root of the service. You can send a POST request to the `/anonymize` endpoint with an XML payload containing a root element with the data you want to anonymize.

POST /v1/anonymize/batch?type=xml
Content-Type: application/xml

<batch>
  <item><email>john@example.com</email></item>
  <item><ssn>123-45-6789</ssn></item>
  <item><note>call 555-123-4567</note></item>
</batch>

→ 200 OK
<batch>
  <item><email>[REDACTED]</email></item>
  <item><ssn>[REDACTED]</ssn></item>
  <item><note>call [REDACTED]</note></item>
</batch>