> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Exception routing
> Understand automatic severity classification and use explicit assignment, bulk actions, caller-directed dispatch, and callbacks.
Matcher automatically classifies unmatched transactions by severity. Assignment, bulk operations, and dispatch are explicit API actions; Matcher does not automatically route or escalate exceptions.
## Severity classification
***
Matcher classifies exceptions automatically from base amount, age, and source signals to support review prioritization.
### Default severity rules
| Severity | Default amount or age criteria |
| ------------ | ---------------------------------------- |
| **Critical** | Base amount ≥ 100,000 OR age ≥ 120 hours |
| **High** | Base amount ≥ 10,000 OR age ≥ 72 hours |
| **Medium** | Base amount ≥ 1,000 OR age ≥ 24 hours |
| **Low** | All other cases |
Source signals can also influence classification. Exceptions with reason `FEE_DATA_MISSING` are capped at `MEDIUM`, even when amount or age thresholds would otherwise classify them as `HIGH` or `CRITICAL`.
## Assignment
***
Assignment is explicit. For an `OPEN` exception, the assignment API accepts one opaque `assignee` string and changes the exception to `ASSIGNED`.
Matcher has no user-group model and does not implement automatic assignment, round-robin routing, or least-loaded routing. If you use a user or group identifier, encode it in the `assignee` string and resolve its meaning in your own identity system.
## SLA behavior
***
Matcher contains domain helpers that can calculate SLA due dates, but the production exception flow does not call them. Matcher does not currently set SLA deadlines, emit SLA warnings, escalate exceptions, or route them automatically. Track and enforce operational SLAs outside Matcher.
## Additional exception endpoints
***
Beyond the basic exception CRUD, Matcher provides endpoints for advanced exception workflows:
| Endpoint | Method | Description |
| -------------------------------------------------------------------- | -------- | ------------------------------------------------------------------ |
| [Dispatch exception](/en/reference/matcher/dispatch-exception) | `POST` | Attempt caller-selected dispatch without changing exception status |
| [Process callback](/en/reference/matcher/process-exception-callback) | `POST` | Apply a token-authenticated, idempotent external update |
| [Bulk assign](/en/reference/matcher/bulk-assign-exceptions) | `POST` | Assign exceptions to one `assignee` string |
| [Bulk resolve](/en/reference/matcher/bulk-resolve-exceptions) | `POST` | Resolve multiple exceptions independently |
| [Bulk dispatch](/en/reference/matcher/bulk-dispatch-exceptions) | `POST` | Dispatch multiple exceptions independently |
| [List comments](/en/reference/matcher/list-exception-comments) | `GET` | Retrieve all comments on an exception |
| [Add comment](/en/reference/matcher/add-exception-comment) | `POST` | Add a comment to an exception for audit and collaboration |
| [Delete comment](/en/reference/matcher/delete-exception-comment) | `DELETE` | Remove a comment from an exception |
| [List disputes](/en/reference/matcher/list-disputes) | `GET` | Retrieve all disputes with filtering |
| [Get dispute](/en/reference/matcher/retrieve-dispute) | `GET` | Retrieve details of a specific dispute |
| [Open dispute](/en/reference/matcher/open-dispute) | `POST` | Flag an exception as disputed for escalated review |
| [Close dispute](/en/reference/matcher/close-dispute) | `POST` | Close a dispute with a resolution |
| [Submit evidence ](/en/reference/matcher/submit-evidence) | `POST` | Add evidence to support a dispute case |
Bulk assign, resolve, and dispatch accept 1–100 exception IDs. Matcher processes each ID independently, so partial success is expected. Bulk assignment accepts a single `assignee` string, not a user or group object.
## Dispatch and callbacks
***
Dispatch is caller-directed: each request names the target. Dispatch records an audit event but does not change the exception status. Do not treat the accepted target names as preconfigured integrations.
### Dispatch targets
When dispatching an exception, the `targetSystem` field must be one of the following values:
| Target | Description |
| ------------ | ------------------------------------------------------------------------------------------- |
| `JIRA` | Attempts caller-directed JIRA dispatch; runtime connector configuration is required. |
| `SERVICENOW` | Not supported; it reaches the generic unsupported-target failure path and returns HTTP 500. |
| `WEBHOOK` | Attempts caller-directed webhook dispatch; runtime connector configuration is required. |
| `MANUAL` | Acknowledges the dispatch locally without sending to an external system. |
Inbound callbacks are a separate token-authenticated, idempotent flow. A callback can set an exception to `ASSIGNED` when it includes an assignee, or to `RESOLVED`; it is not bidirectional synchronization performed by dispatch.
### Filtering by external system
When listing exceptions, the `external_system` query parameter accepts any string value for filtering. This allows you to filter exceptions dispatched to any system, including custom identifiers that may have been set through callbacks.
### Dispatch error handling
Request validation and connector failures use API problem responses. In particular, `SERVICENOW` does not return `MTCH-0508`; it currently returns the generic HTTP 500 unsupported-target failure. A successful dispatch acknowledges the target operation but still leaves the exception status unchanged.
## Queue summaries and observability
***
The exception list exposes queue-scoped summary counts. Matcher does not expose SLA breach rates, routing-rule distribution, or integration success and failure analytics. Use your external observability stack for those operational signals.
## Best practices
***
Use the classified severity to prioritize review, and account for the `FEE_DATA_MISSING` cap at `MEDIUM`.
Pass a stable identifier in the opaque `assignee` string and resolve ownership in your identity system.
Define deadlines, warnings, and escalation in your workflow system because Matcher does not enforce them.
Confirm the selected connector is configured before relying on caller-directed JIRA or webhook dispatch.
Treat bulk operations as independent per ID and handle partial success explicitly.
Protect callback tokens and use stable idempotency keys when external systems update exception status.
## Next steps
***
Resolve exceptions through the API or external systems.
Advanced event delivery and callback handling.