Skip to content

Feedback and Reports

Jump to bottom
leanwrldd edited this page Sep 10, 2026 · 1 revision

← Back to Home

Feedback & Reports

Play Tracking

Record a listen event, no auth required. Call when a track starts (or after e.g. 30 s).

POST /juicewrld/plays/

Field Required Notes
song_id No
public_id No
title Conditional Required if the song can't be resolved from song_id/public_id
era_name No
category No
album_name No
file_path No
source No

201 response is just { "id": 0 }.

GET /juicewrld/plays/stats/

Site-wide play stats, cached 5 minutes: totals, category breakdown, top songs/albums/eras, and a recent-plays log.

{
  "total_plays": 0,
  "total_songs_with_plays": 0,
  "total_albums_with_plays": 0,
  "total_eras_with_plays": 0,
  "category_breakdown": [{ "category": "", "count": 0 }],
  "top_songs": [{
    "id": 0, "public_id": 0, "name": "", "era_name": "",
    "category": "", "play_count": 0
  }],
  "top_albums": [{ "id": 0, "title": "", "artist_name": "", "play_count": 0 }],
  "top_eras": [{ "id": 0, "name": "", "play_count": 0 }],
  "recent_plays": [{
    "id": 0, "song_id": 0, "public_id": 0, "title": "", "era_name": "",
    "category": "", "album_name": "", "source": "", "played_at": "ISO8601"
  }]
}

Feedback

POST /juicewrld/feedback/

General API/app feedback. No auth required. Forwards to a webhook + the mod server.

{
  "message": "required",
  "contact": "optional",
  "automated": "optional — true for a crash report the client sent on its own"
}

Throttled at 10/min.

GET /juicewrld/feedback/

List submitted feedback. Requires auth.

Song Reports

Public-facing way to flag wrong/missing info on a specific song. Submissions go to the DB and are forwarded to the mod server via webhook; editors triage them from the queue.

Method Path Access Description
POST /juicewrld/reports/ No auth Submit a report
GET /juicewrld/reports/ Editor+ List reports — filter: ?status=pending|resolved
PATCH /juicewrld/reports/{id}/ Editor+ Set status/review_notes (records reviewer + time)

Create:

POST /juicewrld/reports/

{
  "song_id": 94086,     // or "public_id": 163 — one of the two, not both
  "message": "required — what's wrong",
  "contact": "optional"
}

Throttled at 10/min.

Report row (from the editor list):

{
  "id": 31,
  "song": 94086,
  "song_name": "Maze",
  "message": "Issues: Wrong era\n\nSong: Maze\n\n(Unreleased v1.18.0)",
  "contact": "someuser",
  "status": "pending",
  "review_notes": "",
  "reviewer_username": null,
  "created_at": "...",
  "reviewed_at": null
}

Read the list defensively: it may come back as a bare array or a DRF { results: [...] } envelope, and the song id has been seen under song, song_id, and public_id depending on the serializer. Only status, review_notes, and the reviewer/timestamp fields are guaranteed.

There's no structured category/issue field on submit — clients fold those into the message text, which is why the messages above look pre-formatted.

Review:

PATCH /juicewrld/reports/{id}/
Authorization: Token <token>

{
  "status": "resolved",     // "pending" | "resolved"
  "review_notes": "optional"
}

The server records the reviewer and review time itself — don't send those. Note there is no idempotency key on submit, so a client retrying a queued report can double-post.

Beta App (installer gating)

Gates access to in-development desktop builds behind a beta code, separate from the public token/role system — auth here is the X-Beta-Code header, not Authorization: Token.

Method Path Auth Description
GET /beta/unlock?code=X None Check a code — returns `{ "valid": true
GET /beta/versions X-Beta-Code List active beta builds (401 if the code is invalid)
GET /beta/download?version=X X-Beta-Code Stream the installer for that build (401/404) 
GET /beta/versions
X-Beta-Code: YOUR_CODE

Clone this wiki locally