Health Scores

Every operation in your API gets a health score from 0 to 100. The score reflects how well-tested, documented, and maintained the operation is, regardless of whether it’s GraphQL or REST.

What gets scored

Each quality module contributes to the score:

Module	What it measures	Impact
Input Fuzzer	How well the operation handles malformed input	High
Response Validator	Whether GraphQL responses match the SDL	High
RBAC Matrix	Permission boundary correctness	High (if auth enabled)
Rate Limit Validator	Whether rate limiting is enforced	Medium
Error Code Validator	Error response consistency and safety	Medium
Deprecation Tracker	Deprecation lifecycle compliance	Low
REST Fuzzer	Transport, header, and schema-level acceptance of malicious or edge-case REST requests	High (REST operations only)

OpenAPI response shape validation (validateResponseAgainstSpec in @dino/agents) is available for integrations; default dino scan health scoring for REST leans on rest-fuzzer (and shared modules like error-code-validator when REST calls are made), not a separate CLI module today.

Score breakdown

100  — All modules pass, no findings
80+  — Minor issues (missing rate limits, non-critical error format)
50-79 — Significant issues (schema mismatches, missing auth checks)
<50  — Critical issues (injection vulnerabilities, broken responses)
0    — Operation unreachable or all modules failed

Per-operation vs aggregate

Per-operation score: Each GraphQL query/mutation or REST path/method gets its own score based on which modules reported issues. Aggregate score: The API-level score is the weighted average across all operations. Operations with more findings pull the average down.

Reading the catalog

When you run dino scanThe output includes scores:

{
  "operations": [
    {
      "name": "createUser",
      "type": "mutation",
      "health": 72,
      "findings": [
        { "agent": "rbac-matrix", "severity": "high", "message": "No auth check on mutation" },
        { "agent": "error-code-validator", "severity": "medium", "message": "Error leaks stack trace" }
      ]
    }
  ],
  "summary": {
    "total_operations": 312,
    "average_health": 84,
    "critical_findings": 3
  }
}

What do scores mean for your team

Score Range	What it means	Action
90-100	Excellent. Your API is well-tested and documented.	Monitor for regressions with `dino watch`.
70-89	Good. Some gaps to address.	Review findings, prioritise high-severity items.
50-69	Needs attention. Significant quality gaps.	Create tickets for critical findings. Run `dino lint` to check the docs.
<50	Critical. Major issues detected.	Address security findings immediately. Enable RBAC testing if auth exists.

Don’t aim for 100 on day one. Use observe mode to establish a baseline, then improve incrementally. Scores that go up over time matter.

False positives

Dino’s deterministic engine minimises false positives, but they can happen — especially with unconventional API patterns. If you see an incorrect finding:

Check if the API behaviour is intentional (e.g., an endpoint that should reject all input)
Use --tools to exclude specific modules for that run
File an issue, false positives are our #1 bug priority

Health scores are deterministic. Same API state = same scores. If your score changes, something in your API changed.

Get Started

CLI Reference

Configuration

How Dino Works

Security & Compliance

Reference

Health Scores

Health Scores

What gets scored

Score breakdown

Per-operation vs aggregate

Reading the catalog

What do scores mean for your team

False positives

​Health Scores

​What gets scored

​Score breakdown

​Per-operation vs aggregate

​Reading the catalog

​What do scores mean for your team

​False positives

Health Scores

What gets scored

Score breakdown

Per-operation vs aggregate

Reading the catalog

What do scores mean for your team

False positives