Complaints - API Reference

Audience: Frontend engineers, panel engineers, backend engineers, QA, and API consumers. Scope: The admin register, workflow and bulk actions, attachments, statistics, configuration (categories, templates, priorities, SLA rules, escalation rules, settings, reminders, notification settings), and the complainant-facing portal at /api/mobile/complaints.

1. Documentation Evidence

2. Module Summary

3. Concepts and Terminology

4. API Surface Map

82 routes, matching structure.baseline.json exactly. "Guards" is always the global JwtAuthGuard followed by RoleGuard.

The portal controllers declare @Controller("complaints") and reach /api/mobile/complaints through MOBILE_CHILDREN. The admin workflow, bulk and attachment controllers share the complaints root with ComplaintsController; no two paths collide.

5. Auth, Identity, and Permissions

5.1 Permission modules

Every module is a separate entry in PERMISSION_MODULES (permission-catalog.ts:524-575).

ComplaintIdentity and ComplaintAudit appear in SUPERADMIN_ONLY_MODULES (permission-catalog.ts:715-716), so no seeded role other than superadmin holds them; a school grants them down to a named role.

5.2 Seeded grants

A staff member or teacher therefore handles only complaints assigned to them. Resolve, close, reject, cancel, reopen, escalate and assign are not seeded onto those roles.

5.3 Validation order on every admin command

ComplaintAccessService.resolveVisible states it and every command follows it: visibility (404), archived (409 COMPLAINT_ARCHIVED), transition (409 COMPLAINT_INVALID_TRANSITION), version (409 COMPLAINT_VERSION_CONFLICT), then input-specific checks.

6. DTO and Model Reference

All responses use the standard envelope { message, data, errorCode: null }. Paginated lists add count, currentPage and totalPage. Errors use the global envelope with message and errorCode.

6.1 Response: ComplaintListItemDto

6.2 Response: ComplaintDetailDto (extends ComplaintListItemDto)

Nested shapes:

Which events a caller sees: public events always; internal_note with ComplaintInternalNotes_READ; identity_viewed with ComplaintIdentity_READ; every other internal event with ComplaintHistory_READ (eventVisibleTo, complaint-detail.mapper.ts:129). An internal attachment is visible only with ComplaintInternalNotes_READ.

6.3 Response: ComplaintEventPageDto

6.4 Response: ComplaintCommandResultDto and ComplaintPortalCommandResultDto

6.5 Response: ComplaintPortalListItemDto and ComplaintPortalDetailDto

ComplaintPortalListItemDto: id, reference (nullable; null for a draft), title, status, priority, category, relatedStudent (nullable), isAnonymous, submittedAt (nullable), lastActivityAt, dueAt (nullable), resolvedAt (nullable), awaitingYourResponse (an information request is waiting for this caller), createdAt, version, schoolTimezone.

ComplaintPortalDetailDto adds description, answers, questionSnapshot, incidentDate, incidentLocation, contactPreference, relatedStaff, gradeName, sectionName, academicSession, templateId, rejectionReason, cancellationReason, duplicateOfReference, infoRequests, resolutions, attachments, timeline, reopenDeadline, allowedActions. duplicateOfReference is always null: the portal never names another complaint.

6.6 Response: ComplaintFormOptionsDto

ComplaintPortalStudentOptionDto is { id, name, studentCode, gradeName, sectionName } (id is students.id). ComplaintPortalStaffOptionDto is { id, name, designation } (id is staff.id).

6.7 Response: statistics, bulk, picker and identity DTOs

6.8 Request: CreateMyComplaintDto and UpdateMyComplaintDto (portal)

Both extend one filing base, so an update sends the full filing again.

6.9 Request: RecordComplaintDto (POST /api/complaints)

A recorded complaint is never anonymous: the DTO has no isAnonymous field. The complainant must have a live profile and a live, unbanned account that can log in, or the request fails with 422 COMPLAINT_COMPLAINANT_INVALID.

6.10 Request: workflow action DTOs

Every class extends ExpectedVersionDto (expectedVersion: integer, required) except RevealIdentityDto.

6.11 Request: bulk DTOs

Every bulk body has items: { id: uuid, expectedVersion: integer }[] with 1-100 items. The service refuses 101 or more with 400 COMPLAINT_BULK_LIMIT_EXCEEDED; the DTO carries a hard ceiling of 1000 (ArrayMaxSize(1000)), above which the body fails validation with 400 VALIDATION_FAILED before any item is validated further. A repeated id answers 400 VALIDATION_FAILED.

6.12 Request: attachment uploads (multipart/form-data)

6.13 Request: query DTOs

ListComplaintsQueryDto (both admin lists) extends QueryDto without search; sending search is refused by forbidNonWhitelisted.

6.14 Request: configuration DTOs

Every update DTO makes its fields optional and requires expectedVersion (integer, at least 0). A stale version answers 409 COMPLAINT_CONFIG_VERSION_CONFLICT.

The {priority}, {kind} and {eventKey} path parameters address closed, seeded sets. A value outside the set answers 400 VALIDATION_FAILED before any query runs.

7. Enum Reference

8. Endpoint Reference

Endpoints are grouped by family. Every family has one fully worked endpoint; the rest of the family differs only where stated. §13.1 lists every route individually.

Status codes: NestJS answers 201 to every POST in this module (no handler sets @HttpCode), except POST /api/complaints, which answers 200 on a replayed submissionId. GET, PATCH and DELETE answer 200.

8.1 GET /api/complaints

Purpose

The office register. The panel calls it for the complaints list with its views (all, unassigned, overdue, urgent, recent, archived), filters and search. It returns every non-draft complaint the caller may see, minus complaints the caller filed and complaints about the caller. Anonymous submitters are masked in every row. Use GET /api/complaints/assigned-to-me for a handler's own queue.

Source Evidence

Auth and Permissions

• Auth: JWT.
• Guard chain: JwtAuthGuard, RoleGuard.
• Permission: Complaints_READ. assigned-to-me needs ComplaintAssignments_READ and returns only rows where assigned_to_user_id is the caller.
• Guest support: None.
• Rate limit: None specific to this module.
• Idempotency: Read-only.

Request

Response

{
  "message": "Complaints fetched.",
  "data": [
    {
      "id": "0192f0c1-6c2e-7a55-9d7e-3f1a2b4c5d6e",
      "reference": "CMP-7K3QX9MB",
      "title": "Broken bench in Room 4",
      "status": "assigned",
      "priority": "medium",
      "category": { "publicId": "0192f0c1-0000-7000-8000-000000000009", "name": "Facilities", "isActive": true, "isDeleted": false },
      "submitter": { "userId": null, "displayName": null, "kind": null, "isAnonymous": true },
      "relatedStudent": null,
      "gradeName": null,
      "sectionName": null,
      "academicSession": { "publicId": "0192f0c1-0000-7000-8000-00000000a001", "name": "2083" },
      "assignee": { "userId": "0192f0c1-0000-7000-8000-00000000b001", "name": "Sita Sharma", "isActive": true },
      "submittedAt": "2026-09-20T04:15:00.000Z",
      "ackDueAt": "2026-09-21T04:15:00.000Z",
      "dueAt": "2026-09-25T04:15:00.000Z",
      "isOverdue": false,
      "lastActivityAt": "2026-09-21T06:02:11.000Z",
      "resolvedAt": null,
      "closedAt": null,
      "hasAttachments": true,
      "escalationLevel": 0,
      "reopenCount": 0,
      "archivedAt": null,
      "version": 4,
      "schoolTimezone": "Asia/Kathmandu"
    }
  ],
  "errorCode": null,
  "count": 1,
  "currentPage": 1,
  "totalPage": 1
}

An empty result is data: [] with count: 0.

Side Effects

None. No cache is read or written.

Error Cases

Edge Cases

• A draft never appears. Neither does a complaint the caller filed or one whose relatedStaffId is the caller's own staff row. A superadmin sees every non-draft complaint.
• q matches the submitter's name only on non-anonymous complaints, so a search cannot find an anonymous complainant by name.
• view=all excludes archived complaints; view=archived returns only them.
• submittedFrom and submittedTo filter submittedAt.

Example Requests

GET /api/complaints?view=overdue&priority=high&priority=urgent&sort=dueDate&page=1&size=20 HTTP/1.1
Authorization: Bearer TOKEN

curl "$API_URL/api/complaints?view=unassigned&q=CMP-7K3QX9MB" \
  -H "Authorization: Bearer TOKEN"

8.2 POST /api/complaints (office record)

Records a complaint the office received on paper, by phone or in person. The complaint is inserted and submitted in one transaction, so it never exists as a draft and the filing rules are the same ones the portal applies. With complainant, the named person becomes the submitter and recordedByUserId names the recorder. Without it, the recorder is the submitter with kind admin.

• Permission: Complaints_CREATE.
• Body: RecordComplaintDto (§6.9).
• Response: ComplaintCommandResultDto, 201 on first write and 200 on a replayed submissionId.
• Side effects: complaints row (with referenceNo from complaint_reference_seq), a submitted event with capacity administrator and metadata recorded: true, and two notifications through the outbox: submitted_complainant and submitted_triage (kind complaint.urgent_submitted when the priority level has alertOnSubmit, otherwise complaint.new_for_triage).

curl -X POST "$API_URL/api/complaints" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "submissionId": "0192f0c1-1111-7000-8000-000000000001",
    "title": "Bus 3 left before pickup time",
    "description": "The guardian reports the bus left the stop five minutes early on Monday.",
    "categoryId": "0192f0c1-0000-7000-8000-00000000000a",
    "priority": "high",
    "incidentDate": "2026-09-21",
    "answers": { "route": "Route 3" },
    "complainant": { "kind": "guardian", "profileId": "0192f0c1-2222-7000-8000-000000000001" }
  }'

When the office records without complainant, the recorder is both submitter and recorder, with submitter kind admin. Nobody complained in person, so the recorder is not treated as a complainant: the register shows the complaint to them like any other handler holding Complaints_READ, and the response carries it. The portal does not list it, because it hides what a caller recorded themselves.

8.3 GET /api/complaints/{id} and GET /api/complaints/{id}/events

findOne returns ComplaintDetailDto. For a caller who is not the complainant (every reader except the submitter, and every reader of an office record with nobody named) it also writes a best-effort ComplaintAudit / READ activity entry for the complaint; a failure to write it is logged and never fails the read.

listEvents pages the visible history newest-to-oldest and returns each page oldest first (ComplaintEventPageDto). limit is 1-200 (default 100). Pass the previous page's nextBefore as before.

• Permission: none declared; allowlisted, with visibility resolved per complaint (§5).
• Errors: 403 AUTH_ACTIVE_ROLE_REQUIRED (no active role), 404 COMPLAINT_NOT_FOUND (missing, draft, or invisible; the three are indistinguishable), 400 COMPLAINT_EVENT_CURSOR_INVALID (before is not an event of this complaint visible to the caller).

curl "$API_URL/api/complaints/$ID/events?limit=50&before=$NEXT_BEFORE" \
  -H "Authorization: Bearer TOKEN"

8.4 POST /api/complaints/{id}/assign (workflow action family)

Purpose

Every lifecycle action is its own POST route under /api/complaints/{id}. Assign gives an unassigned complaint to an eligible handler. The panel renders a button only when assign is in allowedActions, but the server re-checks everything. The same contract applies to acknowledge, reassign, unassign, start, responses, notes, information requests, withdraw, priority, category, due-date, resolve, close, reopen, reject, mark-duplicate, cancel, escalate, archive and unarchive.

Source Evidence

Auth and Permissions

• Auth: JWT.
• Guard chain: JwtAuthGuard, RoleGuard, then visibility inside the transaction.
• Permission: ComplaintAssignments_CREATE, plus visibility.
• Guest support: None.
• Rate limit: None.
• Idempotency: expectedVersion. A retried request after success fails with 409 COMPLAINT_VERSION_CONFLICT because the version moved.

Request

{
  "assigneeUserId": "0192f0c1-0000-7000-8000-00000000b001",
  "reason": "Handles transport issues",
  "expectedVersion": 3
}

Minimal: {"assigneeUserId": "...", "expectedVersion": 3}.

Response

{
  "message": "Complaint assigned.",
  "data": {
    "complaint": { "id": "0192f0c1-6c2e-7a55-9d7e-3f1a2b4c5d6e", "status": "assigned", "version": 4, "allowedActions": ["reassign", "unassign", "add_response", "add_note", "add_attachment", "request_information", "change_priority", "change_category", "set_due_date", "resolve", "reject", "mark_duplicate", "cancel", "escalate"] },
    "eventId": "0192f0c2-9f00-7000-8000-000000000123"
  },
  "errorCode": null
}

The complaint object is the full ComplaintDetailDto, abbreviated here. Each handler sets its own message (for example Complaint assigned., Complaint acknowledged.).

Side Effects

• Locks the complaint row (SELECT ... FOR NO KEY UPDATE inside resolveVisible with lock: true) for the whole transaction.
• If the complaint was never acknowledged, writes acknowledgedAt and an acknowledged event first.
• Inserts a complaint_assignments row, sets assigned_to_user_id and assigned_at, moves the status to assigned, bumps version.
• Appends an assigned event.
• Writes notifications assigned_assignee (to the assignee) and assigned_complainant (seeded disabled) through NotificationService.send, which writes notification_event and outbox rows in the same transaction. The actor is never notified of their own act.
• The deferred consistency triggers check at commit that assigned_to_user_id matches the one active assignment.

Error Cases

Edge Cases

• Every ineligibility reason answers the same code. On an anonymous complaint the submitter check is skipped, so assigning the submitter succeeds rather than refusing, and a refusal cannot reveal who filed it. The submitter still cannot see the complaint on the admin surface, because visibility excludes the submitter.
• Two concurrent assigns: the second waits on the row lock, then fails the version check.
• A reopened complaint can be assigned only after its previous assignment ended; otherwise use reassign, which moves it to assigned.

Example Requests

POST /api/complaints/0192f0c1-6c2e-7a55-9d7e-3f1a2b4c5d6e/assign HTTP/1.1
Authorization: Bearer TOKEN
Content-Type: application/json

curl -X POST "$API_URL/api/complaints/$ID/assign" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"assigneeUserId":"0192f0c1-0000-7000-8000-00000000b001","expectedVersion":3}'

8.5 The other workflow actions

Each row adds to the §8.4 contract (visibility, archived, transition, version). "From" is the status set ACTION_FROM allows; "To" is the result.

mark-duplicate locks both complaints in ascending id order before checking either, so two opposing duplicate marks cannot deadlock.

8.6 POST /api/complaints/{id}/identity-reveal

Returns who filed an anonymous complaint. It is the only route that returns an anonymous submitter's identity, and every call writes an identity_viewed history event with the stated reason. It does not require or bump version.

• Permission: ComplaintIdentity_READ (superadmin-only by default), plus visibility. It is allowed on an archived complaint.
• Body: { "reason": "Safeguarding referral requires the reporter's contact" } (3-1000).
• Response: ComplaintIdentityDto (§6.7), 201.
• Errors: 404 COMPLAINT_NOT_FOUND, 409 COMPLAINT_INVALID_TRANSITION (a draft), 409 COMPLAINT_NOT_ANONYMOUS.
• The identity_viewed event is visible only to holders of ComplaintIdentity_READ.

8.7 POST /api/complaint-bulk/{action}

Runs the same single-complaint command once per item, each in its own transaction, in request order. One item's failure never stops the batch; it is reported in results with its errorCode.

• Permission: the same code as the single action (§4).
• Body: §6.11.
• Response: ComplaintBulkResultDto, 201.

{
  "message": "Bulk acknowledge complete.",
  "data": {
    "results": [
      { "id": "0192f0c1-6c2e-7a55-9d7e-3f1a2b4c5d6e", "ok": true, "version": 3 },
      { "id": "0192f0c1-6c2e-7a55-9d7e-3f1a2b4c5d6f", "ok": false, "errorCode": "COMPLAINT_VERSION_CONFLICT", "message": "..." }
    ],
    "succeeded": 1,
    "failed": 1
  },
  "errorCode": null
}

Whole-request errors: 400 COMPLAINT_BULK_LIMIT_EXCEEDED (101-1000 items: split the batch), 400 VALIDATION_FAILED (more than 1000 items, a repeated id, or another DTO failure).

8.8 POST /api/complaints/{id}/attachments and GET /api/complaints/{id}/attachments/{attachmentId}

Upload

multipart/form-data with file, and visibility or eventId (§6.12). Permission: ComplaintAttachments_CREATE, plus visibility and the add_attachment transition (active statuses and resolved), plus ComplaintResponses_CREATE for a public file or ComplaintInternalNotes_CREATE for an internal one.

The file passes, in order: extension against allowedExtensions and the size limit, a magic-byte sniff that must agree with the extension, a structural scan in a worker pool, and for images a re-encode that strips EXIF (an image whose signature passes but whose bytes do not decode is refused with 400 COMPLAINT_ATTACHMENT_REJECTED and the message "This image could not be read. Save it again or attach a different file."). The service then hashes the stored bytes, records their size (the re-encoded size for an image), with SHA-256 and writes to private storage. Placement then runs inside the upload transaction on the locked complaint row: visibility, the event and visibility rules, the anonymous-type check on the portal, the per-message limit (maxAttachments files on one event, or among loose files) and the lifetime limit (maxTotalAttachments). A loose file writes its own attachment_added event. Response: ComplaintAttachmentDto, 201.

Multer writes each upload to uploads/complaint-attachment/<uuid>/, a fresh uuid per upload that identifies no one, and refuses a destination that resolves outside the upload root. The multer allowlist accepts application/msword and application/vnd.ms-excel for .doc and .xls. Storage keys are never logged beside a complaint id.

curl -X POST "$API_URL/api/complaints/$ID/attachments" \
  -H "Authorization: Bearer TOKEN" \
  -F "file=@bench-photo.jpg" \
  -F "eventId=0192f0c2-9f00-7000-8000-000000000123"

Download

The handler declares no @Permissions(), and its source comment says not to add one: a declared permission would take the handler off the allowlist path and refuse every assignee who lacks that code. role.guard.ts lists it in NO_PERMISSION_ADMIN_HANDLERS as ComplaintAttachmentsController.download, so RoleGuard passes it through. ComplaintAttachmentDownloadService.downloadForAdmin then resolves the owning complaint through ComplaintAccessService.resolveVisible: Complaints_READ, or ComplaintAssignments_READ as the current assignee, never the submitter or the subject. A missing active role answers 403 AUTH_ACTIVE_ROLE_REQUIRED, and an invisible complaint 404 COMPLAINT_NOT_FOUND. The attachment must belong to that complaint, and an internal attachment also needs ComplaintInternalNotes_READ; otherwise the answer is 404 COMPLAINT_ATTACHMENT_NOT_FOUND. The response streams the bytes with the stored MIME type. The file name is masked to attachment-<n>.<ext> for an anonymous complainant's upload. Each download writes a best-effort ComplaintAudit / READ activity entry.

8.9 GET /api/complaint-assignable-users and GET /api/complaint-statistics

complaint-assignable-users feeds the assign, reassign, escalate and escalation-rule pickers. It returns live users holding ComplaintAssignments_READ or Complaints_READ, filtered by q on full name, at most limit (20). It is not filtered by any complaint, so a missing name cannot reveal an anonymous submitter. Access: any of the four codes in §5; 403 AUTH_ACTIVE_ROLE_REQUIRED without an active role.

complaint-statistics returns ComplaintStatisticsDto for the dashboard, optionally scoped to academicSessionId. Every count applies the register's visibility predicate (listVisibilityWhere), so complaints the caller filed, and complaints about the caller, are not counted for them. Permission: ComplaintStatistics_READ. automationLastRunAt reads the Redis key REDIS_KEYS.COMPLAINTS_SWEEP_LAST_SUCCESS.

8.10 Configuration families

Worked example: POST /api/complaint-categories

curl -X POST "$API_URL/api/complaint-categories" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Library",
    "applicableAudiences": ["student", "guardian"],
    "defaultPriority": "low",
    "resolutionTargetMinutes": 4320,
    "questions": [
      { "key": "book", "label": "Book title", "type": "text", "required": false }
    ]
  }'

Response 201: ComplaintCategoryDto with publicId, version: 1 and isSystem: false.

Every update, delete and restore requires expectedVersion and answers 409 COMPLAINT_CONFIG_VERSION_CONFLICT when it is stale. Config deletes take it as a query parameter; restores take it in the body.

8.11 POST /api/mobile/complaints (portal filing family)

Purpose

The complainant starts a complaint. Without submit, it saves a draft the caller can edit, attach files to and submit later. With submit: true it files immediately. The route is idempotent on submissionId, so a client that retries after a timeout gets its own complaint back rather than a duplicate.

Source Evidence

Auth and Permissions

• Auth: JWT with an active role.
• Guard chain: JwtAuthGuard, RoleGuard.
• Permission: MyComplaints_CREATE.
• Guest support: None.
• Rate limit: at most 20 open drafts per submitter; at most dailySubmissionLimit submissions per submitter per school-local day. Both are counted under a per-submitter lock, after the replay check: a replayed submissionId returns the existing complaint before any limit is checked.
• Idempotency: submissionId.

Request

{
  "submissionId": "0192f0c1-3333-7000-8000-000000000001",
  "title": "Bullying at lunch",
  "description": "An older pupil takes my food at lunch most days this week.",
  "categoryId": "0192f0c1-0000-7000-8000-000000000004",
  "isAnonymous": true,
  "incidentDate": "2026-09-19",
  "incidentLocation": "Canteen",
  "submit": true
}

Minimal draft: {"submissionId": "...", "title": "Bus timing", "categoryId": "..."}.

Response

201 with ComplaintPortalCommandResultDto; message is Complaint saved. or Already saved. on a replay. eventId is null.

{
  "message": "Complaint saved.",
  "data": {
    "complaint": {
      "id": "0192f0c1-4444-7000-8000-000000000001",
      "reference": "CMP-D23PQPFK",
      "title": "Bullying at lunch",
      "status": "submitted",
      "priority": "high",
      "isAnonymous": true,
      "relatedStudent": null,
      "awaitingYourResponse": false,
      "version": 2,
      "schoolTimezone": "Asia/Kathmandu",
      "allowedActions": ["cancel"]
    },
    "eventId": null
  },
  "errorCode": null
}

Side Effects

• Inserts the draft row. With submit, also issues the reference, snapshots the category questions and academic context, computes ackDueAt, dueAt and dueSource, appends a submitted event, and sends submitted_complainant and submitted_triage through the outbox.
• A student filing non-anonymously names themselves automatically; an anonymous student complaint names nobody.

Error Cases

Edge Cases

• A replay with submit: true does not submit a second time; it returns the existing complaint, and no draft or daily limit is checked for it.
• A required attachment cannot be satisfied by submit: true on create, because files attach to a draft after it exists. Save a draft, upload, then call /submit.

Example Requests

curl -X POST "$API_URL/api/mobile/complaints" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"submissionId":"0192f0c1-3333-7000-8000-000000000001","title":"Bus timing","categoryId":"0192f0c1-0000-7000-8000-00000000000a"}'

8.12 The rest of the portal

A complaint the office recorded names its recorder in recorded_by_user_id, and the portal never returns it to that recorder, so an office user cannot confirm, cancel or reopen a recording as if it were their own grievance.

9. Flow Diagrams

9.1 Route Ownership

9.2 Request Sequence: workflow command

9.3 Request Sequence: portal filing

9.4 Error Branch

9.5 Auth and permission flow for allowlisted handlers

9.6 Data contract map

10. Pagination, Sorting, Filtering, and Search

The register and portal lists refuse pagination=false because an unpaginated list of grievances is every complainant's account in one response. Search on the register is a case-insensitive ILIKE with the pattern escaped. complaints_title_trgm and complaints_description_trgm are GIN trigram indexes on the two text columns it searches.

11. Caching, Jobs, and External Integrations

13. Mandatory Deep API Documentation Pack

13.1 Route-by-Route Completeness Matrix

Legend. Guards: J+R is JwtAuthGuard then RoleGuard; J+R (A) means the handler is on NO_PERMISSION_ADMIN_HANDLERS. Cache: no route in this module reads or writes a cache. Jobs: Outbox means notification and outbox rows written in the request transaction; no route enqueues a BullMQ job. Errors: B is the base set 404 COMPLAINT_NOT_FOUND, 409 COMPLAINT_ARCHIVED, 409 COMPLAINT_INVALID_TRANSITION, 409 COMPLAINT_VERSION_CONFLICT; every route can also answer 400 VALIDATION_FAILED, 401 and 403. Tests name the file under apps/api/src/modules/complaints/__tests__/ that calls the service method (register, workflow, portal, attachments, config, privacy for complaint-privacy); "None found" means no spec calls it directly.