Pass Windows

Cancel a pass window

curl -X POST https://api.subscriby.net/v1/projects/$PROJECT_ID/pass-windows/$WINDOW_ID/cancel \
  -H "Authorization: Bearer $SUBSCRIBY_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)"

By the time the response arrives every holder has been resettled, and meta says how:

TallyWhat happened to those holders
reboundMoved to the plan's next window on sale, and told so. Their invite links are re-issued when the new window opens.
refund_dueThe schedule had nothing left to offer, so their pass was ended and they were told to ask the creator for a refund.
legs_droppedSeason-ticket holders who lost this one date and keep the rest of their series. Their message states what the date was worth of what they paid.

Subscriby never moves the refunds. refund_due and legs_dropped are statements, not actions. The money stays where it is until the creator refunds it at the gateway. An integration that wants to act on them should subscribe to pass.holder_stranded and pass_series.leg_dropped, which carry the amount per holder.

Cancelling is a POST verb and not a DELETE on purpose: it resettles every holder, moving them on or ending their pass, which is far too consequential to read as removing a row. It also cannot be undone: the window keeps its start permanently, so the same instant can never be re-created on that plan.

Raises pass.window_cancelled carrying the tallies, plus one event per holder: pass.holder_moved or pass.holder_stranded for ordinary passes, pass_series.leg_substituted or pass_series.leg_dropped for season-ticket holders. A window that is already cancelled is answered 200 with every tally at zero, so a retry after a lost response changes nothing.

post/v1/projects/{project}/pass-windows/{window}/cancel

Request

  • Base URL: https://api.subscriby.net
  • URL: https://api.subscriby.net/v1/projects/{project}/pass-windows/{window}/cancel
  • Auth: HTTP bearer

Path parameters

projectstring uuid required

The project, resolved by the route binder.

windowstring uuid required

The window, resolved within the project.

Headers

Idempotency-Keystring uuid required

A key unique to this operation, such as a fresh UUID. The same key replays the original 2xx response for 24 hours (with Idempotent-Replay: true), so a retry after a timeout never repeats the write; the same key with a different body is refused with 409.

Response

The window, cancelled, with meta.rebound, meta.refund_due and meta.legs_dropped.

Example response

{
  "data": {
    "id": "3d5a8c72-b016-4e94-8fa7-61c209d4e738",
    "plan_id": "c4e82f16-93a7-4d5b-b81c-6e0f27a94d3b",
    "plan_name": "Match Day Pass",
    "starts_at": "2026-09-20T13:00:00+00:00",
    "ends_at": "2026-09-20T16:00:00+00:00",
    "timezone": "America/New_York",
    "local_range": "Sun 20 Sep 2026, 09:00 – 12:00 EDT",
    "duration_minutes": 180,
    "status": "scheduled",
    "source": "generated",
    "sellable": true,
    "holders": 38
  },
  "meta": {
    "rebound": 38,
    "refund_due": 3,
    "legs_dropped": 4
  }
}

Changes

No recorded changes to this operation across all 1 revision of this API.