KINDI can detect 23 canonical entity types, but most integrations only want a subset masked. Entity toggles let you choose exactly which types are detected on your text requests: per account, and optionally overridden per API key.

A disabled type is filtered after detection, before anything is tokenized: it never appears in masked_text, spans, or pii_count.

Defaults: new accounts vs existing accounts

Account	Effective set
Created after toggles shipped	The core 10: `PERSON`, `NATIONAL_ID`, `RESIDENCE_PERMIT`, `PHONE_NUMBER`, `EMAIL_ADDRESS`, `DATE_TIME`, `IBAN`, `CREDIT_CARD`, `PASSPORT`, `ADDRESS`. The 13 extended types are off, one toggle away.
Created before toggles shipped (never customized)	Grandfathered to the full set: every canonical type stays on until you save a selection, so nothing that used to be masked silently stops being masked.

The is_default field on GET /me/entities tells you which case you are in: true means you have never saved a selection (the response then shows the core-10 shipped default as the effective set).

The single most common "KINDI missed my ORGANIZATION / MRN / MONETARY_AMOUNT" report is an extended type that is simply switched off. Check your toggles before filing a detection bug.

Read and set your account-level toggles

Both endpoints accept a browser session or a Bearer key.

1GET /me/entities

12345678910{
  "enabled": ["PERSON", "NATIONAL_ID", "RESIDENCE_PERMIT", "PHONE_NUMBER",
              "EMAIL_ADDRESS", "DATE_TIME", "IBAN", "CREDIT_CARD",
              "PASSPORT", "ADDRESS"],
  "is_default": true,
  "catalog": [
    {"type": "PERSON", "group": "core", "default_on": true},
    {"type": "ORGANIZATION", "group": "extended", "default_on": false}
  ]
}

PUT /me/entities replaces the whole enabled set at once (there is no per-type PATCH):

1{ "enabled": ["PERSON", "NATIONAL_ID", "PHONE_NUMBER", "ORGANIZATION"] }

An unknown type name returns 422. The saved set is de-duplicated and returned in the catalog's display order. In the dashboard the same controls live under Settings → Entities.

Per-key overrides

A single key can carry its own enabled set, overriding the account set for requests authenticated with that key:

12GET /v1/keys/{key_id}/entities
PUT /v1/keys/{key_id}/entities

The PUT body is {"override": [...]}. Passing "override": null clears the override so the key inherits the account set again; the GET response's override field is null in that inherited state. A key id you don't own returns 404.

Resolution order per request: per-key override → account set → grandfathered full set (when neither is configured).

Typical use: a broad account set for internal tooling, plus one locked-down key for a pipeline that must only mask identifiers, or a wider key that also masks ORGANIZATION for a document workflow.

What the toggles never filter

CUSTOM_TERM (your glossary terms) always masks, regardless of toggles. An explicit user-defined term is treated as intent, not a preference.
Toggles use canonical names only. You toggle NATIONAL_ID, never the retired legacy alias SAUDI_NATIONAL_ID. See legacy alias spans.

Scope: text endpoints only

Toggles govern POST /api/v1/mask and POST /api/v1/redact only.

File redaction always runs the full entity set. A shared document is permanent in a way an API response is not, so the file path errs toward redacting more.
The LLM Proxy also runs the full set today; toggle honoring on the proxy is planned.

Changes propagate immediately: the enabled set is read per request, not cached with your key's auth context.