`too_many_items`

422 Unprocessable Content The request carries more items than this operation accepts.

When you get it

The request carries more items than this operation accepts. It is always answered with HTTP 422 - one code means one status, so a client may key its handling on either.

Fields it carries

Inside each errors[] entry, beside pointer:

limit: The cap this operation enforces.
actual: The value the server actually observed.
pointer: RFC 6901 JSON Pointer to the offending value in the request body.
parameter: The query parameter the failure is about - the query-side twin of `pointer`.
count: How many items the request carried - the same fact as `actual`, under the spelling this endpoint uses.
max: The largest value this field accepts, inclusive.
maxItems: The most items this operation accepts in one request - the same fact as `limit`, under the spelling this endpoint uses.
monitors: How many monitors the request named.
buckets: How many time buckets the requested window and bucket size produce over the requested range.
cells: The monitors x buckets product the request would materialise - the value the `max` limit is measured against on `getResultSummary`.
reason: The machine-readable sub-case, when one code covers several. Branch on it.
detail: Human-readable detail for this one occurrence. Never the only place remediation appears.

A field is omitted when the server genuinely does not know it - an absent member is never the same as an empty one.

How to fix it

The request was well-formed but a value is not acceptable. The fields above name the offending value and what would be accepted - fix the request and retry.

Shape

{
  "type":   "https://api2.host-tracker.com/problems/too-many-items",
  "title":  "The request carries more items than this operation accepts.",
  "status": 422,
  "code":   "too_many_items",
  "errors": [
    { "limit": …, "actual": …, "pointer": …, "parameter": …, "count": …, "max": …, "maxItems": …, "monitors": …, "buckets": …, "cells": …, "reason": …, "detail": … }
  ]
}