Commune

422not_commune_newsletter

Newsletter not published with Commune

Articles can only be created or edited on a newsletter Commune publishes itself, one whose `esp` is `commune`.

Commune holds two kinds of newsletter, and the esp field on every newsletter (GET /newsletters/{newsletter}) says which. When esp is commune, the newsletter is written in Commune and sent by Commune. Any other value (beehiiv, buttondown, ghost, kit, mailchimp, mailerlite, rss, substack) means it is published by that provider, and Commune mirrors its articles after they go out so readers can discuss them.

Writing an article into a mirrored newsletter would create something that exists in Commune and nowhere else: it could never be sent, and it would not match what subscribers received. So POST /newsletters/{newsletter}/articles and PATCH /articles/{article} refuse it with this code. param is newsletter, and the message names the provider.

It is a 422 like unprocessable, with a code of its own because it cannot be fixed by changing the request at all. The check runs before the body is read, so a request refused this way may also have other problems that will show up later. Everything else about the newsletter keeps working through the API: reading its articles, subscribers, threads and insights.

Why it happens, and how to fix it

  1. The newsletter is published through another provider

    The newsletter you addressed (or the one the article belongs to) has an esp other than commune. Its articles are written in that provider and arrive in Commune after they are sent.

    Fix: Publish through the provider's own tools or API while the newsletter lives there. To write articles through Commune instead, the newsletter's owner moves it onto Commune's own publishing: in the Commune dashboard, with the newsletter selected, open General (or Account & Billing), find Transfer your newsletter to Commune and choose Start migration. The wizard shows the monthly cost first, imports subscribers from Beehiiv, Buttondown, Ghost, Kit, Mailchimp or MailerLite (from Substack, the list is uploaded as a CSV afterwards), sets up a sending address, and then switches the newsletter over. The switch cannot be undone, and only the owner sees the card. Once it is done, esp reads commune and this request succeeds.

  2. The integration picked the wrong newsletter

    The credential reaches several newsletters, some mirrored and some published with Commune, and the request addressed a mirrored one.

    Fix: Call GET /newsletters and choose one whose esp is commune before writing. Branch on esp in your integration rather than on this error. Publish from anywhere walks through writing articles end to end.

  3. The newsletter comes from an RSS feed

    A newsletter with esp: rss is built from a feed and has no subscriber list to bring across, so the transfer wizard cannot move it.

    Fix: Create a new newsletter that is published with Commune, from the Commune app, and write to that one.

Retrying

No: it keeps failing until the newsletter's esp is commune, so write to a different newsletter or move this one onto Commune first.

Example response

HTTP 422
{
  "error": {
    "code": "not_commune_newsletter",
    "message": "Commune can only write articles for a newsletter it publishes itself. This one is published through kit, and Commune mirrors its articles after they go out rather than authoring them, so an article created here would exist in Commune and nowhere else: it could never be sent, and it would not match what subscribers received. To write and send articles through this API, move the newsletter onto Commune's own publishing; how to do that is linked from this error.",
    "param": "newsletter",
    "request_id": "req_01j9c8h1q7m3n4p5r6s7t8u9v0",
    "docs_url": "https://usecommune.dev/errors/not_commune_newsletter"
  }
}

Often confused with unprocessable, payment_required.