Feedback Admin API Reference

Audience: Admin/frontend developers, API consumers Scope: Admin feedback contracts currently implemented.

Admin APIs

List Feedback

Endpoint

GET /api/admin/feedback

Auth

• Authorization: Bearer <admin-jwt>
• Requires admin permission: Feedback_READ

Query params

Get Feedback Detail

Endpoint

GET /api/admin/feedback/{id}

Mark Feedback Reviewed

Endpoint

PATCH /api/admin/feedback/{id}/review

Auth

• Requires admin permission: Feedback_UPDATE

Behavior:

• sets status = reviewed
• stores reviewedByAdminId
• stores reviewedAt

Guest submissions — customerId is now nullable

A signed-out visitor can submit through POST /api/mobile/feedback/public (see Feedback Mobile API Reference). Rows from that path land in the same feedback_submissions table and appear in this same list — there is no separate guest inbox and no separate review workflow.

FeedbackSubmissionResponseDto.customerId is string | null. On a guest row, customerId is null and the sender is carried instead in guestName / guestEmail / guestPhone. A consumer that reads customerId for display or lookup and does not check for null first will render a blank sender for every guest submission, not an error — nothing in the response shape signals the distinction except the null itself.

The schema enforces exactly one identity per row: migration 0032_feedback_guest_submitter.sql adds the CHECK feedback_submissions_submitter_identity_ck —

(customer_id IS NOT NULL AND guest_name IS NULL AND guest_email IS NULL AND guest_phone IS NULL)
OR
(customer_id IS NULL AND guest_name IS NOT NULL AND guest_email IS NOT NULL)

— so a row is either fully authenticated (customer set, all guest columns null) or fully guest (customer null, name and email required, phone optional). The FK on customer_id stays CASCADE on delete, not SET NULL: SET NULL would leave a deleted customer's row matching neither arm of the CHECK, which would make account deletion fail on any customer with feedback history.