Why Custom Patterns?
Standard entities cover names, emails, etc. Custom patterns let you detect org-specific data like employee IDs (EMP-123456), project codes, internal account numbers, or any custom identifier.
Request Body
| Field | Type | Required | Description |
|---|---|---|---|
name | string | Yes | Pattern name (e.g., “EMPLOYEE_ID”) |
pattern | string | Yes | Regex pattern to match |
description | string | No | Human-readable description |
examples | array | No | Example matches for validation |
Example Request
Response
| Field | Type | Description |
|---|---|---|
pattern_id | string | Unique pattern identifier |
name | string | Pattern name |
status | string | Pattern status ("active") |
analysis | object|null | Overlap and quality analysis (see below) |
conflict | object|null | Conflict details if overlaps are detected |
Example Response
Response with Conflict
If the new pattern overlaps with existing entity detections, the response includes aconflict block:
When a conflict is detected, an insight is automatically created. Use the Insights API to resolve it.
Using Custom Patterns
Once created, custom patterns are automatically included in sanitization whenconfig.custom_patterns is set to true in the request body:
List Patterns
GET /v1/patterns returns all patterns for your organization.
Delete Patterns
DELETE /v1/patterns/{pattern_id} removes a pattern.
