---
title: "A cancelling member said why they are leaving."
method: POST
path: "subscription.cancellation_feedback"
tags: ["subscription.* events"]
---

# A cancelling member said why they are leaving.

`POST subscription.cancellation_feedback` (webhook)

### When this fires

A member reached the cancellation screen, on the portal or in a connector chat, and answered the question the project asks on the way out: a reason from the fixed list and, if they wrote one, a sentence of their own. It fires the moment the reason is recorded, before the member sees the offer or confirms, so a member who then takes the offer and stays still appears here. The creator is alerted at the same time. A project that switched the question off asks nothing and fires nothing; its offers are still counted, through `subscription.offer_taken` and the cancellation records.

### Related events

- `subscription.offer_taken`: the member took the offer instead of cancelling.
- `subscription.cancelled`: the member went on and cancelled.

## Headers

- `SB-Signature` string, required
- `SB-Event-Id` string, required
- `SB-Event-Name` string, required
- `Content-Type` string, required
- `User-Agent` string, required

## Payload

- object: The envelope every event is delivered in.
  - `id` string, required: A ULID unique to the event, prefixed `evt_`. Every retry carries the same id, so it is the key to deduplicate on.
  - `type` 'subscription.cancellation_feedback', required: The event name, always `subscription.cancellation_feedback` here.
  - `created_at` string, date-time, required: When the event was emitted, server time, ISO 8601.
  - `api_version` string, required: The contract version of the payload shape, `2026-05-01` today. A breaking change to a shape ships under a new version.
  - `project_id` string, uuid, nullable, required: The project the event belongs to; null for team-scoped and billing events.
  - `data` object, required: The event-specific payload. Keys that do not apply to a given emission are omitted rather than sent as null, so check for presence.
    - `cancellation_id` string, uuid, required: The cancellation record, carried by `subscription.offer_taken` when the member takes the offer.
    - `subscription_id` string, uuid, required: Subscription identifier.
    - `plan_id` string, uuid, required: The plan the subscription is on.
    - `subscriber_id` string, uuid, required: Subscriber's project-scoped user id.
    - `reason` 'too_expensive' | 'not_using_enough' | 'not_enough_content' | 'content_not_expected' | 'found_another_community' | 'not_the_right_fit' | 'taking_a_break' | 'got_what_i_needed' | 'technical_problems' | 'signed_up_by_mistake' | 'other', required: The reason the member picked from the fixed list.
    - `feedback` string, nullable, required: The sentence the member added, up to 500 characters, or `null` when they skipped it.
    - `offer_shown` 'pause' | 'discount' | 'return_coupon' | 'null', nullable, required: The offer the member sees next, or `null` when the owner's plan or the member's rail allows none.
    - `surface` 'portal' | 'bot', required: Where the member answered: the portal, or a connector chat.

## Acknowledgement `2XX`

Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.

## Other responses

- `default`: Any other status, a connection failure, or no answer within 30 seconds counts as a failed attempt. The delivery is retried 8 times, after 10 seconds, 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 1 day, 3 days; the last failure dead-letters it, and it can be retried from the dashboard or `POST /v1/webhook-deliveries/{delivery}/retry`. After 20 consecutive failures the endpoint is paused until it is resumed.

---

[API](https://skmtc.dev/memberpass/apis/subscriby-rest-api.md) · [All operations](https://skmtc.dev/memberpass/apis/subscriby-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/memberpass/apis/subscriby-rest-api/revisions/59c4df91d764?raw)