Skip to main content

​
What happened

The requested plan change would leave the organization over the target plan’s allowance even after applying any add-on adjustments in your request and auto-fill. For example, downgrading from Growth to Starter while seven alerts are active with explicit monitor_pack: 1 only buys 6 alerts of capacity on Starter, leaving the org one alert over. The same applies to seats: a downgrade to a plan whose seat_limit is below the org’s current member count is rejected so members aren’t stranded over the cap. The plan change is rejected so the caller can resolve the overage explicitly — by raising the add-on quantity, reducing usage, removing members, or re-attempting without explicit addons so auto-fill can size the pack correctly.

​
How to fix

In the platform UI, visit your to preview the plan change — the UI surfaces the same blockers, end-state preview, and suggested resolutions and lets you adjust add-ons inline. To resolve programmatically, POST to the feasibility endpoint to discover what blocks the change and preview a fix:
The addons[] array is optional. Omit it to preview the auto-fill defaults; include it to test a specific configuration. The response includes:
  • feasible — true once the previewed end state covers current usage.
  • end_state — full preview of the post-change subscription: tier, allowances, add-on quantities, monthly cost, pricing breakdown.
  • delta — signed differences vs. current state (monthly cost, alert allowance, per-add-on quantity deltas).
  • blockers — hard problems that prevent the plan change. Three types today: monitor_overage (carries current vs. end-state-allowed counts), seat_overage (the target plan’s seat_limit is below the org’s current member count, carrying current members vs. allowed seats — resolve by removing members or choosing a plan with a higher seat limit), and already_on_plan (the request’s target_plan matches the org’s current plan; route through POST /billing/addons if the goal was to adjust add-on quantities rather than change the plan).
  • consequences — non-blocking side-effects to acknowledge (e.g. radar_lost).
  • suggested_resolutions — per-blocker action lists. Largely redundant once you adjust the request addons[] and re-check.
Once the response reports feasible: true, retry the plan change with the same addons[] body via PUT /billing/subscription.