Have you tried passing the username as a query param as well? (aka. adding ?username=<username> to the URL)
Looks like we were not being quite consistent with how we allowed the API to fall-back to the Api-Username username when no username query param was being provided.
That should be fixed with
main ← fetch-target-user-helper
opened 10:29AM - 22 Apr 26 UTC
Admin callers using the API to `DELETE /drafts/:id.json` or `DELETE /review/:id.… json` received a `not_found` error when the `username` param was omitted, even though the resource existed and was owned by the API user (`Api-Username`). The destroy actions always called `fetch_user_from_params` on the API path, which raises `Discourse::NotFound` when neither `username` nor `external_id` is provided — forcing callers to redundantly pass `username=<self>` to delete their own resources.
Extract the target-user resolution into a shared `fetch_target_user` helper in `ApplicationController` that mirrors the pattern already used by `topics#set_notifications`: for API requests, an admin can target another user via `username`/`external_id`; otherwise the action operates on `current_user`. This also aligns API capabilities with the UI — non-admin API callers can now manage their own drafts/reviewables, matching what they can already do via the web.
Migrated call sites:
- `DraftsController#destroy` and `#bulk_destroy`
- `ReviewablesController#destroy`
- `TopicsController#set_notifications` (now uses the helper instead of its inline version)
https://meta.discourse.org/t/401220