DELETE /v3/bidder/favorite/:itemId

DELETE

/v3/bidder/favorite/{itemId}

const url = 'https://api-ha-prod-p8.handbid.dev/v3/bidder/favorite/example';
const options = {method: 'DELETE', headers: {Authorization: 'Bearer <token>'}};

try {
  const response = await fetch(url, options);
  const data = await response.json();
  console.log(data);
} catch (error) {
  console.error(error);
}

curl --request DELETE \
  --url https://api-ha-prod-p8.handbid.dev/v3/bidder/favorite/example \
  --header 'Authorization: Bearer <token>'

NEW (HAN-1864, 2026-05-21). Remove the item from the authenticated user’s favorites. Companion to POST /v3/bidder/favorite/:itemId.

Auth: required.

Response (204 No Content): empty body. Idempotent — deleting a non-favorite (or even a non-existent item) returns 204 with no side-effect. We intentionally do NOT 404 or 403 here:

The user only ever touches their own user_favorite_item_relation row — no cross-user data is at risk.
Treating “you don’t have a favorite for that” as success matches iOS’s fire-and-forget mental model.
Differential error codes would leak item existence in private auctions.

Errors:

429 rate_limited — per-user bidderFavoriteToggle throttle.
400 validation_error — non-positive itemId.

Side-effects (if row existed):

EVENT_AFTER_DELETE → HbNodeUserFavoriteItemsBehavior queues event.favorite to room:{userGuid} with {action: "remove", itemId}.
afterDelete → drops V3CacheTags::userFavorites($userId).

Performance: 2-roundtrip (find + DELETE), 1-roundtrip if no row exists (find returns null, skip DELETE). Target p99 < 150ms.

Hard delete (matches V1 ItemController::actionFavorite at line 324) so the existing behavior triggers fire correctly. Audit trail lives in audit_log, not in this table.

Authorizations

bearer

Parameters

Path Parameters

itemId

required

string

Responses

200

Successful response

application/json