Member create validation (HTTP 400)

Staff and integrators use POST /api/v1/people/members/ to add a person when they are not linking an existing identity. The server creates sign-in credentials for that person, so the request must include contact details the product can use for that flow.

Required email on create

On create, email must be a non-empty string after trimming. If it is missing or blank, the API responds with HTTP 400 and a JSON object that includes an email key (list of human-readable strings), matching the default Django REST framework validation error shape.

Other field rules (for example at least one of first_name or preferred_name, date of birth not in the future, email format) use the same pattern: 400 with field names as top-level keys where applicable.

Note

This endpoint does not use application/problem+json for these serializer checks. RFC 9457-style problem details are reserved for gated workflows (such as enrolment or checkout) where the client needs a stable errors[] contract. See the troubleshooting status-code pages for those types.

For developers and integrators

• Normative request and response shapes: OpenAPI / Scalar (Member write schema and POST /api/v1/people/members/).
• Parse validation responses as typical DRF JSON (field keys plus optional detail), not as RFC 9457 documents, unless a future release explicitly documents a problem type for this route.