---
title: "Unsubscribe By Token"
method: POST
path: "/api/subscribe/unsubscribe"
tags: ["Subscriptions"]
---

# Unsubscribe By Token

`POST /api/subscribe/unsubscribe`

## Request

- Base URL: `https://warnfirehose.com` (the document declares no server; this is the origin it was published from)
- URL: `https://warnfirehose.com/api/subscribe/unsubscribe`
- Auth: none declared

One-click unsubscribe via token or email (no login required).

POST is required, not optional: every message carries
`List-Unsubscribe-Post: List-Unsubscribe=One-Click` (RFC 8058), and Gmail
and Outlook honour that by POSTing to this URL. While this route was
GET-only they got 405, so the mailbox told the reader they were
unsubscribed and nothing here ever ran. The next newsletter arriving after
that is what turns an unsubscribe into a spam complaint.

GET is kept because it is what the visible body link uses, and links in
already-delivered mail must keep working. The token carries the identity in
both cases, and repeating either verb is idempotent.

A bare `?email=` with no token proves nothing about the caller. It used to
HARD-DELETE that address's subscription, and the 200-vs-404 answer told
anyone whether an address was subscribed (security scan 2026-10-15,
finding 12). It now changes nothing and returns the same page whatever the
address, pointing at the token link in the mail and the signed-in route
(DELETE /api/subscribe), which still work. No current mailer emits a
tokenless link (tests/test_newsletter_unsubscribe_token.py).

## Query parameters

- `token` string
- `email` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/warnfirehose/apis/laborcurrent-api.md) · [All operations](https://skmtc.dev/warnfirehose/apis/laborcurrent-api/llms.txt) · [OpenAPI document](https://skmtc.dev/warnfirehose/apis/laborcurrent-api/revisions/0040897972b8?raw)