Error condition

`invalid-operand`

The operator is supported but the operand is not usable.

Type URI: https://openpredicate.tech/problems/invalid-operand
HTTP status: 400 Bad Request
Defined in: Specification §8

What it means

The shape is right and the operator is served, but the value cannot be used: a regular expression that will not compile, a malformed $like escape, or a value outside the field's domain — "Available" where the field admits only "available".

What a client does about it

Check the field's domain in the capability document — its values, type or format. A generated filter schema encodes these as enums and formats, which turns this class of error into a validation failure.

What a server should send

Carry an accepted member describing the domain whenever the operand was rejected for falling outside it.

application/problem+json

{
  "type": "https://openpredicate.tech/problems/invalid-operand",
  "title": "Invalid operand",
  "status": 400,
  "detail": "'Available' is outside the domain of 'status'.",
  "pointer": "/filter/status/$eq",
  "accepted": {
    "values": [
      "available",
      "pending",
      "sold"
    ]
  }
}

The wire format is the API's own. The specification mandates the condition, not this envelope: an API with an established error format should express the condition in it rather than carry a second format for one endpoint. The member names above are the recommended ones.

The other conditions

malformed-query — The body does not conform to the grammar.
unknown-field — The path is well-formed but this endpoint does not expose it.
unsupported-operator — The operator is part of the language but not of this endpoint's profiles.
query-too-complex — A safety limit was exceeded.