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	POST	Attempt caller-selected dispatch without changing exception status
Process callback	POST	Apply a token-authenticated, idempotent external update
Bulk assign	POST	Assign exceptions to one assignee string
Bulk resolve	POST	Resolve multiple exceptions independently
Bulk dispatch	POST	Dispatch multiple exceptions independently
List comments	GET	Retrieve all comments on an exception
Add comment	POST	Add a comment to an exception for audit and collaboration
Delete comment	DELETE	Remove a comment from an exception
List disputes	GET	Retrieve all disputes with filtering
Get dispute	GET	Retrieve details of a specific dispute
Open dispute	POST	Flag an exception as disputed for escalated review
Close dispute	POST	Close a dispute with a resolution
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

---

Review automatic severity

Use the classified severity to prioritize review, and account for the FEE_DATA_MISSING cap at MEDIUM.

Use stable assignee values

Pass a stable identifier in the opaque assignee string and resolve ownership in your identity system.

Track SLAs externally

Define deadlines, warnings, and escalation in your workflow system because Matcher does not enforce them.

Validate dispatch availability

Confirm the selected connector is configured before relying on caller-directed JIRA or webhook dispatch.

Inspect every bulk result

Treat bulk operations as independent per ID and handle partial success explicitly.

Secure callbacks

Protect callback tokens and use stable idempotency keys when external systems update exception status.

Next steps

---

Resolving exceptions

Resolve exceptions through the API or external systems.

Webhooks & callbacks

Advanced event delivery and callback handling.