Naar de documentatie

Exchange wordt later opnieuw gebouwd en is niet beschikbaar via de API of CLI. Beschikbaarheid van deze release

Praktische werkwijzen

Markdown

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.

Product- en prijsbeheer

Een interne beheerder beheert verkoopkeuzes en toekomstige catalogusprijzen voor domeinen, Exchange en spamfilters met dezelfde productrecords die het portal gebruikt. Dit vereist expliciet admin:read/admin:write, de afzonderlijke beheer- en gevoelige featureflags en recente passkeyverificatie. Een bedrijfseigenaar, reseller of serviceverbinding krijgt hiermee geen interne beheerrechten.

Producten lezen en wijzigen

binadit login --scope account:read --scope admin:read --scope admin:write
binadit admin domains products list --account 123 --output json
binadit admin domains products get 12 --account 123 --output json
binadit admin domains products update 12 --account 123 \
  --version 'ETAG_UIT_GET' --set sell_price=12.50 --dry-run
binadit admin domains products update 12 --account 123 \
  --version 'ETAG_UIT_GET' --set sell_price=12.50

De API-paden zijn /api/v1/accounts/{account}/admin/{area}/products, met area gelijk aan domains, exchange of spam. GET ondersteunt limit van 1 tot 100 en cursor; GET /{product} levert een ETag. PATCH /{product} vereist die exacte waarde in If-Match en een idempotentiesleutel. De CLI bewaart de intentie bij herhaalde verzoeken; een onduidelijke fout is geen reden voor een nieuwe sleutel.

De expliciete velden staan in OpenAPI: name, sell_price, purchase_price, margin, important, active, wefact_product_code en de modulespecifieke details. Verkoop- en inkoopbedragen hebben maximaal twee decimalen; marges maximaal vier en ten hoogste 9999,9999 procent. Bedragen zijn niet negatief en begrensd. Valuta blijft EUR. Leveranciersgegevens, geheimen en willekeurige productdetails worden niet teruggegeven.

Bij domeinen omvat details alleen period (jaren), enabled, fixedPrice en domicilie. Extensienamen worden naar kleine letters zonder voorlooppunt genormaliseerd. Bij Exchange zijn mailboxQuota (GB) en period (maanden) beschikbaar; een nieuw product vereist een quota. Namen mogen niet dubbel voorkomen binnen een module. De identiteit van een bestaande extensie blijft vast; trek een oude keuze in en maak een nieuwe aan om een andere extensie te verkopen. De identiteitsnaam van een spamproduct blijft gebonden aan het leveranciersproduct en kan via deze API niet worden veranderd.

Nieuwe domein- en Exchange-keuzes gebruiken POST op de collectie of products create --from-file product.json. DELETE /{product} trekt een keuze uit de verkoop en bewaart het product voor bestaande abonnementen en historische verwijzingen. Gebruik hiervoor:

binadit admin exchange products retire 12 --account 123 \
  --version 'ETAG_UIT_GET' --confirm-product 12

Deze actie verwijdert geen mailboxen, abonnementen of klantgegevens. Spamproducten komen uit de leverancierscatalogus; deze beheerflow voegt er geen willekeurige nieuwe aan toe.

Standaardmarge en synchronisatiebeleid

binadit admin spam pricing-policy get --account 123 --output json
binadit admin spam pricing-policy update --account 123 \
  --version 'ETAG_UIT_GET' --set margin=30 --set apply_to_all=true --dry-run

De API gebruikt GET/PUT /admin/{area}/pricing-policy. margin is verplicht. apply_to_all is standaard uit: een nieuwe standaardmarge verandert dan geen bestaande productprijzen. Met expliciete true worden de toekomstige catalogusprijzen volgens de ingestelde afronding opnieuw berekend. Domeinen met fixedPrice=Y behouden hun vaste verkoopprijs. Bestaande betaalafspraken, abonnementen en facturen worden niet geherprijsd.

Daarnaast zijn rounding (none, cents, whole, charm), auto_update_sell_price, auto_create_products en auto_enable_products instelbaar. Deze velden regelen de bestaande leverancierssynchronisatie; een policywijziging voert niet zelf een leverancierssync uit. Lees het beleid opnieuw om de nieuwe ETag te ontvangen.

Lezen initialiseert geen beleidsrecords. Ook een dry-run valideert actuele rechten, versies, dubbele namen, rekenkundige grenzen en de complete beoogde wijziging; hij bewaart geen product, policy of operatie. Een ontbrekende versie geeft 428, een verouderde versie 412 en ongeldige invoer 422. Herlaad en beoordeel de gewijzigde configuratie vóór opnieuw uitvoeren. Een verwachte validatieweigering verbruikt geen idempotentiesleutel.

Dit document beschrijft geïmplementeerde code; de functiematrix en releasegegevens blijven leidend voor de daadwerkelijke productieacceptatie en de overige beheerfuncties, waaronder Hosting-provisioning, imports en eigendomsoverdrachten.