Exchange valt buiten deze API/CLI-release. Eventuele historische Exchange-voorbeelden in deze gids zijn niet beschikbaar; dit zegt niets over bestaande portaalfuncties. Zie het [actuele releasebereik](/developers/guides/release-scope?lang=nl).

# Hosting-pakketten en onveranderlijke Plesk-abonnementsplannen

Een platformbeheerder kan Hosting-pakketten beheren via **Hosting → Pakketten** of de beheer-API binnen een bedrijfscontext. Beheer vereist de juiste scope `admin:read` / `admin:write`, een actuele interne beheerder, recente passkeyverificatie en ingeschakelde beheer-/beveiligingsfuncties. Een gewone bedrijfseigenaar of servicekoppeling kan deze bewerkingen niet gebruiken.

## Wat verandert

Een pakket aanmaken of bewerken maakt op elke momenteel geconfigureerde Hosting-server een afzonderlijk onveranderlijk Plesk-abonnementsplan aan. Het portaal verifieert het exacte ID, de GUID, externe referentie, resourcelimieten en het spamfilterrecht van het leveranciersplan voordat het voor nieuwe bestellingen wordt gepubliceerd. De commerciële prijs en facturatieperiode worden tegelijk met de bevestigde planversies van kracht.

Wijzigingen gelden voor **toekomstige bestellingen**. Bestaande abonnementen behouden hun quota en commerciële afspraak. Een al betaalde taak behoudt zijn exact goedgekeurde historische plan, ook nadat de pakketnaam of nieuwste versie verandert. Oude planversies blijven beschikbaar om dat terug te lezen; ze worden niet stilzwijgend gewijzigd of verwijderd. Vóór de eerste omzetting van een oud pakket moet openstaande oude levering worden afgerond of afgestemd.

Deze procedure verstuurt bewust geen Plesk `service-plan/set`: die bewerking kan bestaande niet-vergrendelde abonnementen wijzigen. Een afzonderlijke expliciete migratie van bestaande quota en contracten maakt geen deel uit van deze pakketwijziging. Uitfaseren verwijdert een pakket uit het aanbod en behoudt het lokale Product, bestaande abonnementen en leveranciersplannen.

## API-procedure

Alle onderstaande paden zijn relatief aan `/api/v1/accounts/{account}`. Vraag vóór een schrijfactie de actuele mogelijkheden op en lees het actuele OpenAPI-contract.

| Bewerking | Verzoek |
|---|---|
| Pakketten tonen | `GET admin/hosting/packages?limit=50` |
| Pakket en ETag lezen | `GET admin/hosting/packages/{package}` |
| Een geverifieerd pakket aanmaken | `POST admin/hosting/packages` |
| Een toekomstige versie publiceren | `PUT admin/hosting/packages/{package}` |
| Een pakket uitfaseren | `DELETE admin/hosting/packages/{package}` |
| Uitsluitend lezende leveranciersafstemming | `POST admin/hosting/packages/{package}/actions/reconcile` |
| Nog niet geprobeerde stappen voortzetten | `POST admin/hosting/packages/{package}/actions/continue` |

Stuur `Idempotency-Key` voor schrijfacties en de actuele `If-Match` voor wijzigen, uitfaseren en acties. Een metadata-proefuitvoering valideert lokale configuratie en actuele autorisatie zonder een Product, journaalregel of leveranciersplan aan te maken. Prijzen zijn decimale EUR-teksten exclusief belasting. Facturatieperioden zijn maanden. Resourcewaarden zijn gehele getallen: `-1` betekent onbeperkt; schijfruimte, dataverkeer en mailboxquota gebruiken bytes en de overige velden aantallen.

```json
{
  "name": "Hosting Plus",
  "sell_price": "14.95",
  "exceed_price": "0.00",
  "period_months": 12,
  "overuse": "block",
  "spamfilter": false,
  "limits": {
    "maxSites": 1,
    "maxSubdomains": 10,
    "maxDomainAliases": 10,
    "diskSpace": 1073741824,
    "traffic": -1,
    "maxWebUsers": 0,
    "maxSubFTPUsers": 0,
    "maxDatabases": 5,
    "maxMailboxes": 0,
    "mailboxQuota": 0,
    "maxMaillists": 0,
    "maxWebApps": 5
  }
}
```

De ondersteunde overschrijdingsregels zijn `block`, `not_suspend` en `normal`. Ze komen overeen met de portaalkeuzes blokkeren, dataverkeer/opslag voortzetten en toestaan. Andere Plesk-regels worden bij het importeren van oude configuratie niet stilzwijgend omgezet.

## CLI-procedure

De geavanceerde API-opdracht gebruikt dezelfde gepubliceerde mogelijkheden, bedrijfsbevestiging, ETags en intentieafhandeling. Authenticeer als interne beheerder en vraag expliciet beheerscopes aan:

```sh
binadit login --scope account:read --scope admin:read --scope admin:write
binadit api /admin/hosting/packages --account 123 --output json
binadit api /admin/hosting/packages/7 --account 123 --output json
binadit api /admin/hosting/packages --method POST --from-file package.json \
  --account 123 --dry-run
binadit api /admin/hosting/packages/7 --method PUT --from-file package.json \
  --version CURRENT_ETAG --account 123
binadit api /admin/hosting/packages/7/actions/reconcile --method POST \
  --version CURRENT_ETAG --account 123
```

Gebruik de `meta.etag` / HTTP-ETag uit de actuele leesactie. Verouderd of ontbrekend menselijk passkey-bewijs vereist nieuwe browserverificatie; een service-identiteit kan dat niet vervangen. Pakketinvoer bevat gewone configuratie, nooit het Plesk-wachtwoord. Verzin na een onzekere uitkomst geen nieuwe intentie: lees en stem de oorspronkelijke wijziging af.

## Een onzeker leveranciersantwoord

Het portaal slaat een blijvende pogingmarkering op **vóór** het versturen van een verzoek om een plan aan te maken. Een time-out of ongeldig gevormd antwoord retourneert `requires_reconciliation: true`, een veilig `change_id` en de pakketversie. Een nieuw pakket blijft niet bestelbaar; bij een wijziging blijft de laatst gepubliceerde commerciële configuratie behouden.

Open het pakket en kies **Alleen status opnieuw lezen**, of roep `actions/reconcile` aan met de actuele ETag en een nieuwe intentiesleutel. Dit haalt uitsluitend de exact eerder gegenereerde leveranciersreferentie op; het verstuurt nooit ADD, SET of DEL. Als Plesk het oorspronkelijke verzoek wel heeft geaccepteerd, rondt geverifieerd teruglezen dezelfde wijziging af. Kan het plan niet worden aangetoond, bewaar dan de bestaande wijziging voor onderzoek door ondersteuning.

**Nog niet geprobeerde stappen voortzetten** mag een versie aanmaken op een andere server die zijn ADD nog nooit heeft ontvangen. Dit kan een onduidelijke poging niet opnieuw versturen. Maak nooit nog een Product aan en zet de pogingmarkering niet terug om onzekerheid te omzeilen. Gewijzigde serverroutering of ingetrokken beheerrechten stoppen de procedure en vereisen expliciete beoordeling. Een geldige wachtwoordrotatie behoudt de server-/planidentiteit; de actuele inloggegevens moeten nog steeds authenticeren en exact het goedgekeurde plancontract teruggeven. Serverbeheer blokkeert sleutelrotatie zolang een pakketwijziging openstaat.

Het contract en lokale automatische controles bewijzen geen daadwerkelijke levering via Plesk. Werkelijke publicatie vereist geconfigureerde, bereikbare leveranciersservers; er is geen terugval die nagebootst succes meldt.

## Leveranciersbron

De implementatie volgt Plesks [service-plan ADD](https://docs.plesk.com/en-US/obsidian/api-rpc/about-xml-api/reference/managing-service-plans/creating-a-service-plan.32908/), [GET](https://docs.plesk.com/en-US/obsidian/api-rpc/about-xml-api/reference/managing-service-plans/getting-information-on-service-plans.32915/) en [limietstructuur](https://docs.plesk.com/en-US/obsidian/api-rpc/about-xml-api/reference/managing-service-plans/service-plan-settings/limits.66453/). Plesk beschrijft het doorvoeren van SET naar bestaande niet-vergrendelde abonnementen in [abonnementsplaninstellingen configureren](https://docs.plesk.com/en-US/obsidian/api-rpc/about-xml-api/reference/managing-service-plans/configuring-service-plan-settings.32929/).