← all problem types

invalid_settings

422 Unprocessable Content   A value inside settings is not valid for this monitor type.

When you get it

A value inside settings is not valid for this monitor type. 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:

pointer

RFC 6901 JSON Pointer to the offending value in the request body.

value

The value the request sent, echoed back so the caller can see what was read.

allowed

The complete set of values this field accepts. Send one of these.

reason

The machine-readable sub-case, when one code covers several. Branch on it.

expected

What this member should have been. On `wrong_type` it is the JSON type the member must have - `string`, `number`, `integer`, `boolean`, `object`, `array` or `null` - and an array of those names when more than one is accepted (`["string", "null"]` means the member is nullable). On a selection mismatch it is instead the count YOUR preview reported while `actual` is what the server counts NOW - the drift is the point. Where the refusal is about a token or a flag, it is the value the server required.

min

The smallest value this field accepts, inclusive.

max

The largest value this field accepts, inclusive.

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/invalid-settings",
  "title":  "A value inside settings is not valid for this monitor type.",
  "status": 422,
  "code":   "invalid_settings",
  "errors": [
    { "pointer": …, "value": …, "allowed": …, "reason": …, "expected": …, "min": …, "max": …, "detail": … }
  ]
}