Skip to main content

Abuse Reports

The Abuse Reports queue collects the reports of illegal content that people submit on the public form (Art. 16 DSA): a song (copyright, the reported track) or other content identified by a link. Admins triage each report and mark it resolved (the report was valid) or rejected (the report was spurious). Resolving a song report also writes a global block for that track; rejecting it removes any block a prior resolution created. An other report only changes its status — the operator acts on the content itself and tells the reporter the decision by e-mail (Art. 16(5)).

Where to find it​

Admin sidebar → Abuse Reports (/abuse-reports).

Quick start​

  1. Open Admin → Abuse Reports.
  2. Filter by status using the tabs - default is Pending - and by kind (All kinds, Songs, Other content).
  3. Read the Reason text and follow the reported link and the Proof link, if provided.
  4. Click Resolve to accept the report (and block the track globally), or Reject to dismiss it.
  5. Check the All tab to audit past decisions.

Detailed walkthrough​

Filters​

Two tab groups sit at the top. Status toggles between:

  • Pending - default; unreviewed reports.
  • Resolved - reports an admin accepted and acted on.
  • Rejected - reports an admin dismissed as invalid.
  • All - everything.

Kind toggles between All kinds (default), Songs (content_kind=song) and Other content (content_kind=other). Both filters combine.

Report rows​

Reports render as cards, not table rows. The API returns these fields per report:

FieldMeaning
content_kindsong or other.
content_categorycopyright, csam, terrorism, hate_or_violence, privacy, fraud or other; a song report is copyright. Empty on reports from before the any-content form.
content_urlThe reported link (HTTPS; required for other). Untrusted.
location_detailsWhere on the page the content is (timestamp, message), when given.
song_name, artist, spotify_track_idSong reports only.
reporter_name, reporter_emailEmpty only on an anonymous csam report.
reason, proof_urlThe reporter's explanation and optional proof link.
good_faith_confirmed_atWhen the reporter confirmed the report is accurate and made in good faith (empty on older reports).
confirmation_sent_atWhen the receipt e-mail went out; empty = no address or the send failed.

Each card shows:

  • Kind and category badges - Song or Other content, and the category (for example Copyright infringement, Child sexual abuse material). Reports from before the any-content form carry no category badge.
  • Song – Artist - the reported track, as the card headline of a song report.
  • URL - the reported link, when present. Rendered as a link only when it is http/https (URL sanitiser), with rel="noopener noreferrer nofollow"; anything else shows as plain text.
  • Reported by - the reporter's name and email address, or Anonymous for an anonymous csam report.
  • Location details - where on the page the content is, when given.
  • Reason - free-text field the user submitted.
  • Proof - optional URL (YouTube link, screenshot host, etc.), sanitised and linked the same way as the reported URL.
  • A status pill (Pending / Resolved / Rejected).
  • A line with Received (submission time), Good faith confirmed (the time of the reporter's statement, or not recorded (older report)) and Receipt email (sent with its time, or not sent - no address was given or the send failed).

Resolve and Reject buttons appear only on cards whose status is pending. Resolved and rejected cards are read-only - the resolving admin (resolved_by) and the resolved_at timestamp are stored but not rendered.

Decision actions​

Both Resolve and Reject call the same PATCH endpoint with a different status value, then refetch the list so the card moves to the matching tab.

Beyond flipping the status, the backend acts on the verdict:

  • Resolve inserts a global block for the reported song / artist / Spotify track ID.
  • Reject deletes the block again when the report carries a Spotify track ID, undoing a prior resolution.

Common scenarios​

  • Receipt not sent - the reporter gave an address but the card says not sent: the receipt email failed. Confirm receipt to the reporter by hand before you decide.
  • Copyright false-positive - user reports a song flagged as unsafe that they believe is actually safe; investigate on the Copyright Review page, then resolve the abuse report.
  • Coordinated report spam - if multiple users submit near-identical reports against the same track, cross-reference with the song in the Copyright Reports queue before acting.
  • Bad-faith report - reject with no action and the row moves to the Rejected tab for later audit.

Permissions​

ActionPermission
View reports (all statuses)support:read
Resolve / reject a reportsupport:edit

Dashboard entry requires admin:access. System admins (is_system: true) get every admin permission implicitly.

API​

UI actionGraphQLREST
List abuse reports (filtered)adminAbuseReports(status, contentKind, page, limit)GET /v1/admin/abuse-reports?status={pending|resolved|rejected}&content_kind={song|other} (omit a filter for all)
Submit an abuse report (user side; public, Turnstile abuse, 5 per IP and 100 in total per hour)submitAbuseReportPOST /v1/abuse-reports
Resolve / reject a report- (REST only)PATCH /v1/admin/abuse-reports/\{id\} with { status: "resolved" | "rejected" }

Both list twins use the admin-scope support:read guard and return the same fields. Resolving is REST-only.

Tips & gotchas​

  • There is no "undo" button - once resolved or rejected, the buttons disappear from the card. Flipping a resolved report back to rejected (or the reverse) requires a direct PATCH against the endpoint.
  • The Proof and content links are user-supplied and untrusted. Open it in an incognito window, never paste it into an authenticated tab.
  • The UI does not surface how many times the reported entity has been reported previously. Cross-reference manually using Copyright Reports.
  • Closed reports are deleted automatically three years after they were resolved or rejected (abuse_reports.retention_years, see Installation → Abuse report retention). Pending reports are never deleted, however old.
  • The list endpoint pages at 25 items by default (max 100 via limit); the UI reads only the first page and renders no pagination controls.