Skip to main content

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.

HTTP status409 Conflict
Error codeplan_change_blocked
Resolve actioncheck_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 monitors are active with explicit monitor_pack: 1 only buys 6 monitors of capacity on Starter, leaving the org one monitor over. The plan change is rejected so the caller can resolve the overage explicitly — either by raising the add-on quantity, by reducing usage, or by 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: 
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, monitor allowance, per-add-on quantity deltas).
  • blockers — hard problems that prevent the plan change. Two types today: monitor_overage (carries current vs. end-state-allowed counts) 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.