Worker assignments API — child case-carrying create, list, show, delete; nested child endpoint
POST /api/v1/worker_assignments (child case-carrying)
You can now assign a case-carrying agency worker to a child using the same endpoint as application worker assignments, with a mutually exclusive payload shape.
Request (child)
Send POST /api/v1/worker_assignments with:
data.type:"worker-assignments"data.attributes.role:"case-carrying"(hyphenated in the request body)data.relationships.child: link to the child (type: "children")data.relationships.worker: link to the agency worker (type: "agency-workers")- Do not send
data.relationships.applicationin the same request; including both returns 422.
Optional data.meta["send-notification"] (boolean): when true or omitted, an email notification is sent for a new assignment. Set to false to suppress notifications.
Validation: The request body is validated before processing. Invalid payloads (e.g. wrong role, missing relationships, data: null for a required relationship) return 422 with source.pointer under /data/.... Business rules (worker eligibility, agency match, row limits) also return 422.
Responses: 201 when a new assignment is created; 200 when the worker was already assigned (no-op). The response body is a paginated collection of that child's case-carrying assignments.
Note: the role value in response payloads uses underscores (e.g. case_carrying), while the create request uses the hyphenated form case-carrying.
GET /api/v1/children/:child_id/relationships/worker_assignments (new)
List case-carrying worker assignments for a specific child. The caller must have read access to the child. Supports created_start_date, created_end_date, and role query filters, as well as standard pagination and sorting.
POST /api/v1/children/:child_id/relationships/worker_assignments (new)
Create a case-carrying worker assignment on a child using the nested route. The child is identified by the URL path rather than a relationship in the payload. Request body:
data.type:"worker-assignments"data.attributes.role:"case-carrying"data.relationships.worker: link to the agency worker (type: "agency-workers")- Optional
data.meta["send-notification"](boolean)
The request body is validated before processing. The caller must have update access to the child. Responses match the top-level endpoint: 201 on create, 200 if already assigned.
POST /api/v1/applications/:application_id/relationships/worker_assignments
This endpoint now performs request body validation. Invalid payloads (missing worker, unpermitted role) return 422.
GET /api/v1/worker_assignments and GET …/:id
Results now include case-carrying worker assignments tied to a child the caller has access to, in addition to existing application-scoped assignments.
Query filters (index): Optional application_id and child_id parameters narrow the collection to assignments for that application or child. Typical use: list assignments for one application or one child without paging through the full set.
DELETE /api/v1/worker_assignments/:id
Deleting a child case-carrying assignment requires update access to the child. Application-backed assignments are unchanged.
POST /api/v1/worker_assignments (application path)
Unchanged behavior for application + approvals / support roles. Create requests are now validated (including relationship id types, non-null data for application and worker, and allowed application type values such as applications, initial-applications, renewal-applications). Invalid payloads return 422.