POST /v1/sites/{siteId}/plan

ავტორიზაცია

API გასაღები გაგზავნეთ როგორც მატარებელი ტოკენი (bearer token). გასაღებს უნდა ჰქონდეს sites.view ნებართვა; ამის გარეშე გასაღები უარყოფილი იქნება 403 და არა 404 სტატუსით.

ეს ბოლო წერტილი არ იღებს ორგანიზაციის იდენტიფიკატორს. თქვენი გასაღები უკვე აიდენტიფიცირებს იმ ორგანიზაციას, რომელსაც ის ეკუთვნის, და პასუხი შემოფარგლულია მისით.

სცადეთ

შეSubstituted any value inside angle brackets with your own and the key placeholder with a key from your dashboard.

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/plan \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "plan_version_id": <Uuid> }'

შესული ხართ? თქვენი სამართავ პანელში არსებული API კონსოლი ავტომატურად ამატებს თქვენი რეალური ორგანიზაციის ID-სა და საკუთარ გასაღებს და ატარებს მოთხოვნას ცოცხალ API-ს წინააღმდეგ, რათა იხილოთ რეალური პასუხი. გაAღით ეს ენდპოინტი API კონსოლში

დეტალები

Charges the prorated difference, moves the vendor package to the new type, and moves the subscription — in that order, for the reasons the engine's plan-change module records. The response states what actually happened rather than what was asked for: package_type is read back from the vendor after the move, and charged_minor is what the gateway captured. ⛔ expected_total_minor is a money guard, not a convenience. It is the figure the customer was actually shown, and the change is refused 422 when the freshly-computed quote differs — a price that moved between the page rendering and the button being pressed (an FX recompute, a catalogue edit, the period rolling) must never be charged silently. It is optional only so a script may omit it deliberately. Every other refusal is 422 as well, with nothing charged and nothing changed: an incompatible package type, usage above what the smaller plan allows, a card decline. ⛔⛔ Two usage refusals, checked in this order (#2089). First, this site's vendor-live counts against the target package type — databases, FTP accounts, subdomains — so a customer is told about the thing they can fix on the screen in front of them. Then the whole account against the plan being applied: sites, mailboxes, mailbox storage and disk, anywhere in the org's subtree, from the same check_downgrade the staff tariff endpoint uses. Until #2089 this endpoint ran only the first of those and the staff endpoint only the second, so the owner's ruling held on the path he does not use and failed on the one his customers do. ⛔ There is no override here. The staff tariff endpoint has an audited override_over_limit because staff sometimes genuinely need to move an over-limit account; a customer overriding their own quota check is not an override, it is no check. A customer who cannot proceed must reduce usage or contact support. ⭐ getSitePlanChoices marks an unaffordable plan blocked_reason: "account_over_limit" before the button is pressed, so this refusal should be unreachable from the UI. It is still enforced here: the picker is an affordance, not the control. Serves our own fleet as well as the managed shared range (#2271). The money path is identical on both — prorate, order, charge, credit, supersede — and only the middle step differs: on managed hosting the vendor package moves to another template, on the fleet the box is told the plan's new disk and file allowances. ⛔ On the fleet that happens after the subscription is superseded, because the numbers to apply are read from the governing subscription; a failure there leaves the customer out of sync (their site's Storage card says the new allowance is still being applied) and never out of pocket. 404 for a site whose platform has no plan to change — a VPS or cloud server (the billed unit is the machine) or an edge host (no account at all) — or for a site that is not the caller's. Requires sites.view and billing.payment.manage — it charges a card, so the key that gates paying is the key that gates committing to a payment.

პარამეტრები

მოთხოვნის სხეული

პასუხი

შეცდომები, რომლებიც ამ ენდპოინტს შეუძლია დააბრუნოს

401 · 403 · 404 · 422 · 429 · 503