---
title: "Read Rule Coverage"
method: GET
path: "/notifications/rules/coverage"
tags: ["notification-rules"]
---

# Read Rule Coverage

`GET /notifications/rules/coverage`

## Request

- Base URL: `https://api-docs.upsmith.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api-docs.upsmith.com/notifications/rules/coverage`
- Auth: one of:
  - API key in header `x-api-key`
  - HTTP bearer

What this organization's live rules leave uncovered.

A read, open to any member: it reports on the organization's own configuration and names no
document. Changing routing is what needs an admin.

## Headers

- `organization-id` string, nullable
- `x-user-id` string, nullable
- `timezone` string
- `x-actor-email` string, nullable
- `x-request-source` string, nullable
- `x-operation-id` string, nullable
- `x-commit-message` string, nullable
- `x-confirmation-id` string, nullable
- `x-chat-id` string, nullable

## Response `200`

Successful Response

- RuleCoverageResponse: What this organization's live rules leave uncovered. **What ``covered`` claims, and what it does not.** It claims an active rule is keyed to the event type, can notify somebody, and is one this build can evaluate — which is what dispatch requires before it routes at all. It does **not** claim the rule's gate matches any particular event: deciding whether a condition could match is not reliably answerable, so previewing against recent real events is how an author checks that, and this report links the two by naming the rules covering each type. **What the report cannot see.** Its denominator is the organization's ``notification`` rows, so a type with no module row at all — not merely an inactive one — is absent rather than uncovered. A dispatch seeds that row lazily and retries, so such a type can appear in a later run of this report having never been reported before.
  - `organization_id` string, required
  - `entries` RuleCoverageEntry[], required
    - `notification_type` string, required
    - `module_title` string, required
    - `rule_event_type` string, nullable, required
    - `status` string, required
    - `reason_code` string, nullable
    - `reason` string, nullable
    - `rules` RuleCoverageRule[]
      - `rule_key` string, required
      - `name` string, nullable, required
      - `version` integer, required
    - `invalid_rules` RuleCoverageInvalidRule[]
      - `rule_key` string, required
      - `name` string, nullable, required
      - `version` integer, required
      - `issues` RuleIssue[]
        - `path` string, required
        - `message` string, required
  - `summary` RuleCoverageSummary, required: The three states partition the entries; ``types_with_invalid_rules`` cuts across them.
    - `covered` integer, required
    - `uncovered` integer, required
    - `not_expressible` integer, required
    - `types_with_invalid_rules` integer

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/upsmith/apis/upsmith-api.md) - [All operations](https://skmtc.dev/upsmith/apis/upsmith-api/llms.txt) - [OpenAPI document](https://skmtc.dev/upsmith/apis/upsmith-api/revisions/86e2c2bd93af?raw)