POST /v1/reseller/services/{siteId}/package

Πισtoποίηση

Στείλτε ένα κλειδί API ως διακριτικό φορέα (bearer token). Το κλειδί πρέπει να διαθέτει το δικαίωμα reseller.provision· ένα κλειδί που δεν το διαθέτει απορρίπτεται με 403, όχι 404.

Δοκιμάστε το

Ατικatastήstε ό,τι βρίskεtai μέσα σe γώniaδeς μe τis δikές sas timές, kai to placeholder klεidioύ μe éna klεidi apó ton pinaka ελέgchou sas.

curl -X POST https://api.zinndigital.com/v1/reseller/services/{siteId}/package \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "plan_code": <string> }'

Συνδεθήκατε; Η κονσόλα API στον πίνακα ελέγχου σας συμπληρώνει το πραγματικό αναγνωριστικό του οργανισμού σας και το δικό σας κλειδί, και εκτελεί το αίτημα στο ζωντανό API, ώστε να μπορείτε να δείτε την πραγματική απόκριση. Ανοίξτε αυτό το τελικό σημείο στην κονσόλα API

Λεπτομέρειες

Performs the upgrade or downgrade your panel just sold. The vendor package is moved, the client's entitlements follow it, and on our own fleet the box is given the new plan's quota. Requires `reseller.provision`. ⛔ **Your client is not charged by us, and cannot be.** Under a reseller programme Zinn® bills *you* — the new plan appears on your next wholesale statement, because that statement is built from your clients' live subscriptions — and you bill your client through your own panel, which has already taken their money for this upgrade. There is no second charge and no card is touched. That is why this operation exists beside `changeSitePlan` rather than instead of it: the customer-facing one mints an order against the client organization, which under a reseller holds no payment instrument at all. Takes a plan **code**, not a version id. A code is what your admin typed into the product's module settings and it stays valid for years; the engine always resolves the newest active version of it, so a plan we have since re-priced cannot be bought at its old price by a panel nobody has updated. Every refusal `listResellerServicePackages` reports is applied again here on fresh numbers, so a downgrade that has become unsafe since the picker was rendered is still refused. Repeating an identical request is safe and is the documented recovery: each step is idempotent, and a service already on the target plan is a `422` saying so rather than a second move. `422` for an unknown plan code, for a plan on a different product line or infrastructure, and for a downgrade the client's usage does not fit. `503` when the hosting platform behind the service cannot change a package type at all. `404` for a service that is not one of your clients'.

Παράμετροι

Σώμα αίτησης

Απάντηση

Σφάλματα που μπορεί να επιστρέψει αυτό το τελικό σημείο

401 · 403 · 404 · 422 · 429 · 503