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. Email and phone are optional on create so reception can record walk-ins and students before sign-in details are known.

Optional email on create

On create, email may be omitted or blank. When provided, it must be a valid email address after trimming. A case-insensitive duplicate check rejects emails already used by another active member in the same tenant (HTTP 400 with an email field message).

Use GET /api/v1/people/members/email-availability/?email=… for debounced client checks before submit.

When neither email nor phone is supplied at create, the API stores a local identity stub and defers Zitadel provisioning until contact details are added (create or PATCH).

Other validation

Field rules (for example at least one of first_name or preferred_name, date of birth not in the future) 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.