Article like added or removed Webhook

Add MCP server to your AI tool

Allow AI tools and LLMs to interact with the API documentation portal through MCP.

MCP server URL

https://api-reference.usecommune.dev/mcp

Standard setup for AI tools providing an mcp.json file

mcp.json
{
  "REST API MCP server": {
    "url": "https://api-reference.usecommune.dev/mcp"
  }
}

Close
POST https://webhook.example.com

A reader liked an article, or took the like back. data.direction says which: added when the like was given, removed when it was withdrawn.

One topic carries both directions, so subscribing once is enough to mirror the whole association. A consumer that heard a named person liked an article and never heard them take it back would keep acting on a claim the person withdrew.

data.reader names the person. The same actions are readable as engagement records at GET /newsletters/{newsletter}/events?event_type=like. A reader with no Commune account cannot like an article, so unlike article.read this field is null only for a deleted account.

data.like_count is the whole tally after the change, counted in the same transaction that made it, and is the number GET /articles/{article} reports on stats.likes. It is on the removal as well as the addition, so a consumer that stores it never has to add anything up and a consumer that missed a message is corrected by the next one.

Fires on a real row change only. Liking an article this person already liked is silent, and so is unliking one they had not liked. Liking, unliking and liking again fires three times.

Delivered as a single HTTPS POST to the consumer's registered endpoint, with the message as the JSON request body. Respond 2xx to acknowledge. Anything else, or a timeout, is retried with backoff, so acknowledge fast and do the work afterwards.

Headers

  • Commune-Version string Required

    API version the payload conforms to. Same value as api_version in the envelope.

  • Commune-Event-Id string(uuid) Required

    Same value as id in the envelope. The dedupe key.

  • Commune-Event-Type string Required

    Same value as type in the envelope. The topic name.

  • Commune-Signature string Required

    HMAC-SHA256 over Commune-Timestamp as Unix seconds, a literal ., then the raw request body, keyed by the endpoint's signing secret. Lowercase hex, carried as v0= followed by one or more comma separated digests (more than one while a secret is being rotated). The header's timestamp is an RFC 3339 instant, so convert it to Unix seconds before signing. Verify against the raw bytes before parsing the JSON. The webhooks guide has the full procedure.

  • Commune-Timestamp string(date-time) Required

    When this delivery attempt was made, as an RFC 3339 instant in UTC. It differs on every retry, and it IS covered by the signature, in Unix seconds, so a stale or altered one can be rejected. Enforce a tolerance window of a few minutes and dedupe on the event id as well, since a retry inside that window is legitimate.

  • Commune-Delivery-Attempt integer

    1 on the first attempt, incremented on each retry. Not sent today: do not rely on it, and be idempotent regardless. The same number is readable after the fact as attempt on a DeliveryAttempt, so a consumer that needs to tell a retry from a first delivery can ask instead of being told.

    Minimum value is 1.

application/json

Body Required

A reader liked an article, or took the like back.

  • id string(uuid) Required

    Unique id for this event. Stable across redeliveries, so it is the dedupe key. Assigned when the state change is recorded rather than when the message is dispatched.

  • type string Required

    The topic name, identical to the channel address. Route on this.

    Value is article.liked.

  • api_version string Required

    The Commune-Version value this payload conforms to. Present on the message itself, not only on the request header, so an event persisted to a consumer's own store stays self-describing.

  • occurred_at string(date-time) Required

    RFC 3339 timestamp of the state change, not of the delivery attempt. Use it to order events, since delivery order is not guaranteed.

  • newsletter_id string(uuid) | null Required

    The newsletter the change belongs to. This is the tenant boundary: a consumer only ever receives events for newsletters its credential can read. Null only for events that are genuinely not newsletter-scoped, which none of the topics Commune publishes currently are.

  • actor object | null Required

    Who caused the change, and null when nobody outside Commune did.

    Populated on a change made through this API's write operations, and null on every other change: an edit a creator made in the product, an import arriving from a provider, a scheduled job, a delivery result reported by the sending provider. Null is therefore the common case and stays a legitimate value. Read it as "this change came in through the API under this credential", never as "nothing caused this".

    It never names a person, only the credential.

    It answers "did this change come in through the API, and under which credential". It is not the field to drop the echo of your own write with: use idempotency_key, which you chose and therefore already know, whereas id here is Commune's own identifier for your credential and no operation reports it back to you. A creator can read that identifier in Commune, but it changes when the credential is replaced, so matching on it puts the loop back silently after a rotation.

    Additional properties are NOT allowed.

    Hide actor attributes Show actor attributes object | null
    • type string Required

      api_key for a change made through this API, which is the only value emitted today. user is reserved for a change a named person made through an authenticated session and system for an unattended job; neither is emitted.

      An OAuth access token reports as api_key as well. The two credentials are interchangeable everywhere else in this API, and a separate value here would be a distinction a consumer cannot act on.

      Values are user, api_key, or system.

    • id string Required

      Identifier of the actor within its type. For api_key it is the credential's own id and never its secret, and it is the same value that appears in a creator's list of credentials, so an event can be traced back to the integration that caused it.

    • label string | null

      Human-readable name for display. Best effort, may be null.

  • idempotency_key string | null Required

    The Idempotency-Key of the API write that caused this change, so a consumer can tie an event back to its own request and collapse the duplicates a retried write would otherwise produce.

    This is how a consumer that writes recognises its own work. Keep the keys you send, and skip any event carrying one of them. You chose the value, so you know it before the event arrives. actor cannot do this job, because Commune's id for your credential is not something this API reports to you.

    Null for every change that did not come in through this API, which is most of them: an edit made in Commune, an import, a scheduled job and a delivery result all have no originating request to key on.

    It reaches every endpoint registered for the newsletter, not only the one that made the write, so choose opaque keys such as UUIDs rather than keys carrying your own business identifiers.

    Maximum length is 255.

  • data object Required

    Event-specific body. Narrowed by each concrete event schema below.

    Hide data attributes Show data attributes object
    • article_id string(uuid) Required
    • title string Required
    • url string(uri) | null

      Canonical public URL. Follows the newsletter's custom website domain when it has an active one, otherwise the Commune-hosted path.

    • reader object | null Required

      The person who gave or withdrew the like. A like requires a Commune account, so this is null only in the case UserRef describes, an account that has since been deleted.

      Hide reader attributes Show reader attributes object | null
      • user_id string Required
      • username string | null
      • display_name string | null
      • avatar_url string(uri) | null
    • direction string Required

      added when the like was given, removed when it was taken back.

      Values are added or removed.

    • like_count integer Required

      The article's whole like tally after this change, counted in the same transaction that made it. The same number Article.stats.likes reports. Carried on both directions, so a consumer never has to add or subtract to stay correct.

      Minimum value is 0.

    • changed_at string(date-time) Required

      When the like was given or withdrawn. Equal to occurred_at.

Responses

  • 200

    The consumer accepted the delivery. Any 2xx acknowledges the message and it is not sent again.

  • 4XX

    The consumer rejected the delivery. Handled exactly like a 5xx: the message is retried with backoff, because a rejection cannot be told apart from a consumer that is briefly misconfigured.

  • 5XX

    The consumer failed to handle the delivery. Retried with backoff. A timeout is the same case and is retried too.

POST article.liked
Request examples
{
  "id": "018f2a93-1010-7000-8000-000000000041",
  "type": "article.liked",
  "api_version": "2026-08-26",
  "occurred_at": "2026-08-26T20:02:14Z",
  "newsletter_id": "7d3f1c02-58a1-4a4e-9a0b-2f6d1c9e4411",
  "actor": null,
  "idempotency_key": null,
  "data": {
    "article_id": "4c9e2f81-0b7a-4d13-8e55-1a2b3c4d5e6f",
    "title": "What newsletters get wrong about community",
    "url": "https://example.com/p/what-newsletters-get-wrong-about-community",
    "reader": {
      "user_id": "9f8e7d6c-5b4a-4392-8180-7f6e5d4c3b2a",
      "username": "mara",
      "display_name": "Mara Iversen",
      "avatar_url": "https://example.com/avatars/mara.png"
    },
    "direction": "added",
    "like_count": 18,
    "changed_at": "2026-08-26T20:02:14Z"
  }
}
{
  "id": "018f2a93-2020-7000-8000-000000000042",
  "type": "article.liked",
  "api_version": "2026-08-26",
  "occurred_at": "2026-08-26T20:41:55Z",
  "newsletter_id": "7d3f1c02-58a1-4a4e-9a0b-2f6d1c9e4411",
  "actor": null,
  "idempotency_key": null,
  "data": {
    "article_id": "4c9e2f81-0b7a-4d13-8e55-1a2b3c4d5e6f",
    "title": "What newsletters get wrong about community",
    "url": "https://example.com/p/what-newsletters-get-wrong-about-community",
    "reader": {
      "user_id": "9f8e7d6c-5b4a-4392-8180-7f6e5d4c3b2a",
      "username": "mara",
      "display_name": "Mara Iversen",
      "avatar_url": "https://example.com/avatars/mara.png"
    },
    "direction": "removed",
    "like_count": 17,
    "changed_at": "2026-08-26T20:41:55Z"
  }
}