> ## Documentation Index
> Fetch the complete documentation index at: https://docs.particle.pro/llms.txt
> Use this file to discover all available pages before exploring further.

# plan_change_blocked

> Plan change cannot be applied because current usage exceeds the target plan's allowance

export const BillingLink = ({children}) => {
  return <a href="https://platform.particle.pro/billing">{children}</a>;
};

|                    |                       |
| ------------------ | --------------------- |
| **HTTP status**    | `409 Conflict`        |
| **Error code**     | `plan_change_blocked` |
| **Resolve action** | `check_feasibility`   |

## 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 <BillingLink>organization's billing settings</BillingLink> 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:

```
POST /v1/organizations/{org_id}/billing/plan-change/feasibility

{
  "target_plan": "particle_pro_pay_as_you_go",
  "addons": [
    { "type": "monitor_pack", "quantity": 2 }
  ]
}
```

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`.