Subscriptions¶
A subscription links a subscriber to a plan. It is the commercial assignment entitlements resolve through.
Why not a field on subscriber?¶
An explicit subscription object leaves room for:
- Status (
active,canceled, …) - Start / end
- History (later)
- Clear audit of plan changes
A subscriber has at most one active subscription at a time.
Properties¶
| Field | Description |
|---|---|
id |
Subscription id |
subscriber_id |
Subscriber |
plan_id |
Plan |
status |
At least active / canceled |
started_at |
When access under this plan begins |
ended_at |
Set when canceled or replaced (optional) |
created_at / updated_at |
Timestamps |
Lifecycle¶
| Action | Effect |
|---|---|
| Create | Subscriber entitled via plan grants (status active) |
| Change plan | Cancel or end current; create new active subscription (or dedicated change API) |
| Cancel | Status → canceled; plan grants no longer apply (overrides may still apply) |
Exact change-plan shape is defined in the API docs; the invariant is one clear active subscription for resolution.
Interaction with overrides¶
Overrides apply on top of (or instead of) the plan for specific features. Canceling a subscription does not automatically clear overrides unless you delete them.