Validation errors

The errors member of a request_validation_failed problem document, in full. Every other code this API returns is in the error reference.

A request_validation_failed document carries one further member, errors, holding every constraint the request body broke. There is one item per violation, so a body with three problems is fixed from one response.

{
  "type": "https://developer.carepatron.com/docs/errors#request_validation_failed",
  "title": "Request body validation failed",
  "status": 400,
  "instance": "urn:trace:0af7651916cd43dd8448eb211c80319c",
  "timestamp": "2026-01-15T10:30:00.0000000Z",
  "errors": [
    { "pointer": "/personalDetails/firstName", "code": "pattern", "detail": "Must match the pattern the schema declares." },
    { "pointer": "/personalDetails/lastName", "code": "max_length", "detail": "Character count must be at most 100." }
  ]
}

• pointer - an RFC 6901 JSON Pointer into the request body as sent, so a nested member is addressed by its path (/personalDetails/lastName) and an entry of a set by its position (/customFields/0/value). The empty string addresses the whole body.
• code - the constraint that was broken, named as the JSON Schema validation keyword in snake_case: required, min_length, max_length, pattern, format, enum, minimum, maximum, exclusive_minimum, exclusive_maximum, min_items, max_items, unique_items. A constraint the schema cannot express takes a code of its own, and it addresses the set rather than one entry: duplicate_identifier, where no two entries may name the same stored row. JSON Schema can bound a collection and constrain each entry, but cannot state a rule spanning entries - and unique_items is not the same question, since two entries can differ in every other member while still naming one row. A collection whose entries carry isPrimary takes one more at the set, exactly_one_primary, when a non-empty set designates none of its entries or more than one. A custom field's value takes five further codes of the same kind, because what it may hold is decided by a definition the workspace owns and no schema can state: custom_field_unknown for a key the workspace has not defined, custom_field_type_unsupported for a field whose type this version does not serve, custom_field_type_mismatch for a value of the wrong JSON type, custom_field_option_unknown for a choice the field does not list, and custom_field_value_invalid for a value of the right type that the field still cannot hold. The whole-map write takes one more, custom_field_missing, at /customFields for each field the workspace defines that the body leaves out: a null under the key is how a value is cleared, so leaving the key out is refused rather than read as one. A country takes one more, because the codes it may hold are ISO 3166-1's rather than the schema's: country_unknown, for a pair of uppercase letters the standard does not assign. Branch on code, not on detail.
• detail - what the constraint requires, worded for an end user and safe to show beside the field.

An item never contains the rejected value or anything derived from it, its length included. A custom_field_missing item names the workspace's own key for the field the body left out: the key is the workspace's configuration, not a value the request sent. Resolve pointer plus code against the operation's request schema for the constraint's exact terms.