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). # Domeinhouders: portaal, API, CLI en herstel van oorspronkelijke verzoeken ## Implementatiegrens De portaalformulieren voor aanmaken, bewerken en verwijderen van houders en de API gebruiken dezelfde `HolderChanges`-procedure en de bestaande registrarkoppeling van het portaal. Publieke API-beschikbaarheid blijft afhankelijk van de API-, schrijf- en gevoelige-toegangsinstellingen van de omgeving. Deze implementatie installeren activeert geen productierelease en publiceert geen CLI-downloads. ## Houders gebruiken ### Standaardhouder vanuit het bestaande account `POST holders/default` met een leeg JSON-object beoordeelt of zorgt voor de standaarddomeinhouder van het geselecteerde account. Dit vereist zowel `holders:read` als `holders:write`. De bestaande juridische/contactgegevens van het account worden gebruikt; ontbrekende velden kunnen uitsluitend worden aangevuld vanuit de uniek gekoppelde WeFact-debiteur. Er wordt niet gezocht op een vergelijkbare naam of e-mailadres, geen andere debiteur aangemaakt en geen facturatie- of bankgegeven gewijzigd. ```sh binadit api /holders/default -X POST --account 123 --dry-run binadit api /holders/default -X POST --account 123 --yes --no-input --output json ``` De beoordeling retourneert `status` en, bij een onvolledig profiel, `missing_fields`. `pending_incomplete` maakt geen domeinhouder aan. Bedrijven behouden hun bedrijfsgegevens; consumenten krijgen een persoonlijke houder. Ontbrekende adressen, namen, telefoonnummers of geslacht worden nooit verzonnen. Een al bevestigde standaardhouder blijft behouden. Hergebruik van een bestaande overeenkomende eigen houder verifieert eerst exact die houdercode met een GET bij de registrar; die houder wordt niet overschreven. Nieuwe accounts volgen dezelfde procedure nadat het e-mailadres van hun eigenaar is geverifieerd en het vereiste profiel volledig is. Publieke registratie maakt geen domeinhouders aan voor ongeverifieerde identiteiten. Het afronden van accountinstelling of profiel en een expliciet toegepaste WeFact-wijziging kunnen een openstaande standaardhouder afronden. Leverancierswerk begint nadat de werkelijke buitenste accounttransactie is vastgelegd; een teruggedraaide registratie/import verstuurt geen houderverzoek. Bij domeinregistratie wordt een eigen standaardhouder voorgesteld voor een winkelmand gekoppeld aan het actuele account. Een expliciet gekozen houder blijft behouden; een oude ongebonden winkelmand of een houder van een ander bedrijf wordt niet geraden. Heeft aanmaken een onzekere uitkomst, bewaar dan de oorspronkelijke wijziging en gebruik de herstelprocedure hieronder. Een andere sleutel, profielwijziging of automatische instellingspoging kan de oorspronkelijke blokkade niet omzeilen. Een houder die als accountstandaard wordt gebruikt, kan niet worden verwijderd zolang die verwijzing bestaat. ### Expliciete aanvullende houders Gebruik het geselecteerde moderne bedrijf met een uniek gekoppelde registrarklant. `holders:read` staat een begrensde houderlijst/-detail en veilige metadata van oorspronkelijke verzoeken toe; `holders:write` staat gewone wijzigingen toe onder de actuele modulevoorwaarden van het bedrijf. Beperkte DNS-/Workspace-sleutels kunnen geen houders beheren. Eigendom, houdercodes, wederverkoperkoppelingen en leverancierssleutels worden door de server toegewezen. `GET /api/v1/accounts/{account}/holders/{id}` retourneert de bewerkbare publieke houdervelden, de `meta.etag` en HTTP-ETag. Gebruik die exacte actuele ETag in `If-Match` voor `PUT` of `DELETE`. Vóór verwijdering moet een houder ongebruikt zijn in iedere domeincontactrol. Een niet-gekoppelde lokale houder kan worden verwijderd zonder een leveranciersverbinding op te bouwen; een exact gedocumenteerde afwezigheid bij de leverancier kan ook lokaal afronden zonder te doen alsof een DELETE plaatsvond. Maak aan met `POST holders`; vervang de volledige bewerkbare houder met `PUT holders/{id}`. Relatieve paden in deze handleiding staan onder `/api/v1/accounts/{account}/`. Beide gebruiken dit JSON-contract: ```json { "companyname": "Example BV", "initials": "A", "firstname": "Alice", "prefix": null, "lastname": "Example", "gender": "F", "street": "Example street", "number": "7", "suffix": null, "zipcode": "1234AB", "city": "Utrecht", "state": null, "country": "NL", "email": "alice@example.test", "tel1": "31", "tel2": "30", "tel3": "1234567", "fax1": null, "fax2": null, "fax3": null, "vat": null, "coc": "12345678" } ``` `companyname` is de schrijfwijze van het invoerveld; de bestaande leesweergave noemt het `companyName`. Vereiste velden zijn initialen, voornaam, achternaam, geslacht (`M`/`F`), straat, huisnummer, postcode, plaats, landcode van twee hoofdletters, e-mailadres, landcode van telefoon (`tel1`) en abonneenummer (`tel3`). Een weggelaten netnummer (`tel2`) wordt als `0` verstuurd; telefoonnummers krijgen het canonieke voorvoegsel `+` bij de landcode. Het OpenAPI-schema geeft exacte lengten. Optionele velden accepteren null; volledige vervanging verstuurt ondersteunde lege optionele waarden expliciet en bewijst ze in teruggelezen leveranciersgegevens voordat lokale velden worden gewist. Alleen-lezen-ID's, houdercodes en tijdstempels mogen niet naar een vervangingsverzoek worden gekopieerd. Geslacht is lokale portaalmetadata omdat het REST-klantcontract van de registrar dit niet bevestigt. Privé-identificatiedocumenten en geboortegegevens vallen buiten dit publieke bewerkcontract. Persoonsnamen en bedrijfsnamen zijn bij de leverancier onveranderlijk. Het portaal maakt deze velden alleen-lezen bij bewerken; API-wijzigingen retourneren `422 holder_name_is_immutable`. Maak voor een wijziging expliciet een afzonderlijke houder aan en beoordeel die; wijzig daarna de contactrollen van elk domein via de domeinprocedure. Een houder wijzigen past op zichzelf geen domeinrol of DNS-record aan. De Rust-CLI gebruikt dezelfde houderpaden: ```sh binadit holders get 7 --account 123 --output json binadit holders create --account 123 --from-file contact.json --dry-run binadit holders create --account 123 --from-file contact.json --yes binadit holders update 7 --account 123 --version CURRENT_CONTACT_ETAG --from-file contact.json --yes binadit holders delete 7 --account 123 --version CURRENT_CONTACT_ETAG --confirm-resource 7 --yes ``` Bewaar houderinvoer in een beschermd bestand of vertrouwde stdin (`--from-file -`). Bewaar na een time-out de oorspronkelijke berichtinhoud, het bedrijf, de aanvragende identiteit en idempotentiesleutel. De blijvende identiteitsbinding van de CLI geldt ook voor deze generieke houderopdrachten; een nieuwe login mag een onzekere oorspronkelijke wijziging nooit stilzwijgend herhalen. Beschikbaarheid van CLI-broncode/bouw en ondertekende publieke distributie worden apart beschreven in de [CLI-handleiding](/developers/cli?lang=nl). ## Een bestaande domeinhouder importeren Interne beheerders kunnen een onafhankelijk geverifieerde bestaande houdercode importeren met `POST admin/holders/import` en een nieuwe persoonlijke `admin:write`-toekenning/passkey. Stuur een oorspronkelijke `Idempotency-Key` en `{"target_account_id":123,"handle":"AA123456-NL"}`. Het doel is het expliciete moderne bedrijf, waarvan de oude klantbinding uniek en actief moet zijn. Een servicesleutel of gewoon klantlidmaatschap verleent deze personeelsmogelijkheid niet. Bestaande lokale houdercodes vereisen expliciete toewijzing; import verplaatst ze nooit stilzwijgend. Import verstuurt uitsluitend een begrensde GET via de geconfigureerde registrarverbinding van het portaal. De actuele oorspronkelijke identiteitsgeneratie, scope, personeelsrol, sterke verificatie, beheercontext, leveranciersbron en het doel worden vóór en na die GET en opnieuw bij lokale publicatie gecontroleerd. Intrekking of een gewijzigd doel/bron verhindert publicatie. Lokale houdervelden en het oorspronkelijke API-succesbewijs worden samen vastgelegd; een geannuleerde of gewijzigde opslagactie weigert veilig. Herhalen met exact dezelfde oorspronkelijke sleutel retourneert het opgeslagen bewijs zonder tweede leveranciers-GET. Ook vóór het melden van succes vindt een laatste controle van vastgelegde status en actuele bevoegdheid plaats. Wijzigt de bevoegdheid/bron direct na lokale vastlegging, dan kan de houder al bestaan terwijl het actuele verzoek een fout meldt; controleer vóór een andere import het oorspronkelijke bewijs en de portaalstatus. De browseractie **Toevoegen met houdercode** bindt de bedrijfscontext die bij het openen van de pagina werd getoond. Herlaad na het wisselen van bedrijf. Import accepteert de REST-contactvelden in `snake_case` van de registrar en de bestaande oude veldaliassen; tegenstrijdige waarden worden geweigerd. Telefoon-/faxonderdelen, registratienummers en geboortegegevens behouden hun oorspronkelijke toewijzing. Identificatievelden en leveranciersopmerkingen blijven buiten publieke API-/CLI-antwoorden. De portefeuillesynchronisatie gebruikt dezelfde blokkade voor openstaand aanmaken, zodat import/synchronisatie een onopgelost oorspronkelijk houderverzoek niet kunnen omzeilen. ## Een onzekere uitkomst Een onderbroken leverancierswijziging retourneert `409 holder_mutation_requires_reconciliation`, met veilige `errors.intent_id` en `provider_mutation_repeated: false`. Het oorspronkelijke bewerkingsresultaat bevat ook `holder_mutation_id`. Deze UUID identificeert het oorspronkelijke bedrijfsverzoek en mag niet door een andere UUID/sleutel worden vervangen. Een mislukte HTTP-bewerking kan volgen op een geaccepteerd leverancierseffect. De browser toont **Oorspronkelijk verzoek beoordelen** en opent `/module_holders/mutations/{originalUUID}`. Hij behoudt de formulier-UUID/-versie en dient niet automatisch opnieuw in. De beoordelingspagina toont alleen veilige status en biedt expliciete verificatie. Een actuele bedrijfseigenaar moet eerst verifiëren met een passkey of authenticator onder de actuele bedrijfsvoorwaarden; interne beheerders hebben hun actuele passkey nodig. Gewone moduleschrijvers en servicekoppelingen kunnen geen ander oorspronkelijk houderverzoek herstellen. Herstel door de actuele eigenaar kan een oorspronkelijk portaal- of API-verzoek in hetzelfde bedrijf afronden zonder de historische aanvragende identiteit of leveranciersintentie te wijzigen. API-herstel gebruikt deze endpoints: | Methode en pad | Doel | | --- | --- | | `GET holders/mutations/{originalUUID}` | Veilige status uit alleen SQL, actuele journaal-ETag en oorspronkelijk houder-ID; geen leveranciersverzoek | | `POST holders/mutations/{originalUUID}/actions/reconcile` | Alleen leveranciers-GET, daarna atomaire lokale afronding van het oorspronkelijke verzoek | | `POST holders/mutations/{originalUUID}/actions/abandon` | Alleen een ondertekende voorbereiding annuleren die aantoonbaar nooit is verstuurd | Afstemmen en opgeven vereisen `holders:write`, ingeschakelde gevoelige acties, een actuele onbeperkte persoonlijke eigenaarsverbinding met recente sterke verificatie, een nieuwe HTTP-idempotentiesleutel voor deze afzonderlijk goedgekeurde actie en de journaal-ETag in `If-Match`. Lever aan: ```json { "confirm_intent_id": "11111111-1111-4111-8111-111111111111", "confirm_holder_id": 7, "confirm_holder_version": "CURRENT_64_HEX_CONTACT_ETAG", "confirm_no_supplier_mutation": true } ``` Bij oorspronkelijk aanmaken is `confirm_holder_id` null en bestaat geen houderversie. Lees voor wijzigen/verwijderen eerst de actuele oorspronkelijke houder en bevestig diens exacte 64-hex-versie zonder aanhalingstekens. De journaalversie en houderversie zijn afzonderlijke bewijzen. Zodra een oorspronkelijke verwijdering klaar is, verhindert het ontbreken van de lokale houder niet dat het bewijs wordt opgehaald. `412` vereist opnieuw lezen en beoordelen; dit geeft geen toestemming om het leverancierseffect te herhalen. Ging de bevestiging van aanmaken verloren, voeg dan `verified_provider_handle` uitsluitend toe nadat een beheerder de exacte oorspronkelijke houdercode onafhankelijk bij de leverancier heeft vastgesteld. Afstemming haalt die expliciete houdercode met GET op en vereist exact de privéopmerking van het oorspronkelijke verzoek en iedere goedgekeurde houderwaarde van dezelfde geconfigureerde leverancier. Een identieke naam/e-mailadres, ontbrekende opmerking of onbekende houdercode blijft geblokkeerd. De privé-correlatie-MAC is geen publieke bevoegdheid en wordt nooit getoond in API-, CLI- of audituitvoer. Een gewijzigde leveranciersidentiteit, onduidelijk eigendom of ongeverifieerd antwoord vereist beheerderonderzoek; bewerk het journaal niet, zet de verzendmarkering niet terug en importeer geen kandidaat om dit te omzeilen. Onbekend openstaand aanmaken blokkeert uit voorzorg import van domeinhouders totdat onderzoek plaatsvindt; bevestigd aanmaken blokkeert import van exact de oorspronkelijke houdercode. De generieke Rust-API-opdracht biedt hetzelfde expliciete herstelcontract zonder een andere leverancierswijziging: ```sh binadit api /holders/mutations/ORIGINAL_UUID --account 123 binadit api /holders/mutations/ORIGINAL_UUID/actions/reconcile --method POST \ --account 123 --version CURRENT_JOURNAL_ETAG --from-file recovery.json --yes ``` Lees na succes het oorspronkelijke verzoek opnieuw en controleer `completion_verified: true` en `requires_reconciliation: false`. `provider_acknowledged` blijft false wanneer herstel via GET een verloren bevestiging aantoonde; herstel verzint nooit een oorspronkelijke ACK. Herhaal nooit een POST/PUT/DELETE als verificatieproef. ## Backendbewijs en beveiligingsgrens De gedeelde service `HolderMutations` beheert korte SQL-transacties voor `prepare`, `inspect`, `begin`, `acknowledge`, `uncertain`, `confirm`, `complete` en `abandonPrepared`. Elke publieke fase vereist transactieniveau nul bij binnenkomst. Leveranciers-I/O gebeurt buiten deze transacties. De oorspronkelijke bevoegdheidsadapter van de aanroeper leest actuele voorwaarden onder de fasevergrendelingen en retourneert een zuivere laatste tijdscontrole; die controle draait na vastleggen opnieuw voordat de aanroeper een verzoek mag versturen. Het privéjournaal bindt de oorspronkelijke bewerkings-/bedrijfs-UUID, de vingerafdrukomhulling van het oorspronkelijke API-verzoek/-sleutel, aanvragende identiteit, actor-/beveiligingsgeneratie, modern bedrijf, uniek gekoppelde oude eigenaar, leveranciersbron, actie, doelhouder/-code en goedgekeurde versie. Het versleutelt begrensde oorspronkelijke invoer, bevoegdheidscontext, leveranciersbevestiging en teruggelezen gegevens. Sleutelgebonden bewijzen binden die velden, het vastgelegde bewijs van eenmalige verzending, teruggelezen gegevens en het definitieve lokale ontvangstbewijs. Privébewijs, leverancierssleutels en interne correlatieopmerkingen horen nooit in publieke bewerkingsmetadata of logboeken. Normale geautoriseerde houderantwoorden bevatten de expliciete publieke houderweergave. Eén actieve doelblokkade verhindert dat een andere sleutel dezelfde houder wijzigt. Onzeker aanmaken blokkeert ook hetzelfde bedrijf en dezelfde leveranciersinvoer; een andere UUID kan dit niet ontwijken. Een verstuurde intentie kan nooit opnieuw verstuurbaar worden door status of tijdstempel terug te zetten: het onafhankelijke ondertekende bewijs moet nog steeds overeenkomen. Alleen een ondertekende voorbereiding die nooit is verstuurd kan zonder leveranciersbewijs worden opgegeven. Afgeronde historie geeft een blokkade alleen vrij na ondertekende eindverificatie, zonder alle oude houderinvoer te ontsleutelen. `begin` wordt vastgelegd vóór de daadwerkelijke klantwijziging. Elke journaalopslag vereist een waar resultaat en exact de opnieuw opgeslagen bedoelde velden; een door een modelgebeurtenis geannuleerde opslag kan geen fase verderzetten. De werkelijke verzendcontrole controleert daarna de vastgelegde ondertekende markering en actuele oorspronkelijke bevoegdheid via autocommit-leesacties met een laatste zuivere tijdscontrole, zonder nog een verificatietransactie te openen. Geannuleerde lokale opslag-/verwijderacties en geannuleerde wijzigingen van oorspronkelijke API-bewijzen behouden eveneens de oorspronkelijke blokkade in plaats van afronding te melden. `acknowledge` bewaart een gevalideerde oorspronkelijke bevestiging ook nadat bevoegdheid verloren gaat. Geen van beide methoden staat een tweede wijziging toe. `confirm` accepteert uitsluitend een vertrouwde zuivere backendverificatie van exact de oorspronkelijke teruggelezen gegevens. `complete` publiceert de lokale houder en het oorspronkelijke bovenliggende bewijs atomair met de ondertekende afrondingsstatus, na actuele controles op bevoegdheid, eigendom, versie en bron. Deze bewijzen maken een willekeurige terugdraaiing van de gehele database of een gecompromitteerde server niet veilig. ## Canoniek leverancierscontract De strikte kloon behoudt de bestaande geconfigureerde registrar en het cURL-transport. HTTPS is verplicht buiten een privé-loopbacktest. De tokencache gebruikt het volledige privébewijs van de sleutelbron als sleutel, zodat gewijzigde inloggegevens geen eerdere strikte sessie kunnen hergebruiken. Het oude gedrag en de cachenaamruimte van de basis-SDK blijven ongewijzigd. `withDispatchGuard` blijft een actuele-bevoegdheidscontrole voor authenticatie en alle leveranciersverzoeken. `withCustomerMutationGuard` markeert uitsluitend de werkelijke klant-POST/PUT/DELETE na authenticatie. Authenticatie en GET's kunnen die journaalmarkering niet verbruiken. Strikte klantwijzigingen authenticeren nooit automatisch opnieuw en herhalen nooit na een HTTP 401. Het strikte antwoordcontract vereist een geslaagd HTTP-antwoord, gehele leverancierscode `0` en een getypeerde gegevensomhulling. Aanmaken vereist de canonieke houdercode. Wijzigen/verwijderen vereisen `data.success === true`; een leeg antwoord of een als waar geïnterpreteerde tekst is onvoldoende. GET moet de exacte houdercode, een positief leverancierswederverkoper-ID en een booleaanse verwijderstatus identificeren. Een HTTP 404 alleen bewijst geen afwezigheid. De gedocumenteerde leverancierscode `176` identificeert een ontbrekende klantcode; de hersteladapter bindt deze aan exact de oorspronkelijke GET en bron. De wijzigingsbewerking past de naam of het bedrijf van een houder niet aan. Alleen de ondersteunde veranderbare velden worden verstuurd; teruglezen verifieert zowel de ongewijzigde naam- en bedrijfsvelden als alle goedgekeurde veranderbare houdervelden. De gedeelde procedure weigert wijzigingen van onveranderlijke velden en publiceert alleen waarden die de registrar bevestigt. Verwijdering van een houder kan uitsluitend als geen domein of andere dienstresource er nog naar verwijst. ## Herstelregels voor gebruikers en AI-agents Bewaar het oorspronkelijke bedrijf, de intentie-/bewerkings-UUID, het houder-ID/de houdercode, de goedgekeurde versie en oorspronkelijke sleutel. Een mislukt of onderbroken verzoek kan volgen op een geaccepteerd leverancierseffect. Wijs geen andere UUID toe en verstuur geen POST als herstelproef. Afstemming mag exact de oorspronkelijke houdercode lezen en bewezen lokale publicatie afronden; zij mag geen nieuw aanmaak-, wijzigings- of verwijderverzoek versturen. Een gewijzigde oorspronkelijke API-verzoekomhulling blijft ook geblokkeerd: herstel door een nieuwe eigenaar mag de methode-/berichtinhoud-/sleutelidentiteit niet vervangen en gewijzigde bovenliggende metadata niet goedkeuren. Onzeker aanmaken zonder teruggegeven houdercode blijft geblokkeerd. Een andere houder op naam of e-mailadres vinden bewijst niet dat het oorspronkelijke aanmaken die heeft opgeleverd. Herstel vereist een geverifieerd oorspronkelijk leveranciersbewijs of beheerderonderzoek. Leid uit een onbekende uitkomst geen afwezigheid of ontbreken van kosten af. De lokale tests omvatten versleuteld bewijs, dubbele blokkades, gewijzigde bron/eigenaar/versie, vervalste eindstatus, teruggezette verzendmarkering, late bevestigingen en terugdraaien van lokale publicatie. Een tijdelijke MariaDB-proef via uitsluitend een lokale socket bewijst zichtbaarheid na vastleggen, actueel eigendom na een oudere repeatable-read-momentopname en een werkelijk hard beëindigd canoniek HTTP-verzoek dat geen tweede POST kan veroorzaken. De privé-HTTP-testopstelling controleert gedocumenteerde antwoordvormen, authenticatie na sleutelrotatie, één klantmarkering na login en weigering van herhaling na HTTP 401. Deze tests benaderen geen klant of externe leverancier. ## Browsercontext en de oorspronkelijke openstaande markering Bestaande browserverzoeken voor aanmaken, bewerken en verwijderen moeten de oorspronkelijk getoonde `holder_context_account_id` bevatten. Het portaal levert deze verborgen waarde. Als een tweede tabblad van actief bedrijf wisselt, kan dat het aanmaken van een houder met een ouder formulier niet omleiden; de server weigert dit vóór een registrarverzoek. Ga terug naar het oorspronkelijke bedrijf en herlaad in plaats van een onzekere oorspronkelijke UUID te vervangen. Bestaande vastgelegde verzoeken blijven geblokkeerd en behouden hun oorspronkelijke beoordelingslink. Bij medewerkers die een houder van een ander bedrijf bewerken zijn de werkelijke houdereigenaar en oorspronkelijke beheercontext gescheiden. De herstelpagina bewaart beide. Zij wist uitsluitend een definitieve overeenkomende UUID-markering onder de oorspronkelijke browsercontext, geen gelijkgenummerde markering bij het doelbedrijf. Een optionele `browser_context_account_id` op de beoordelingslink selecteert uitsluitend de actuele geautoriseerde browsercontext of de oorspronkelijke vastgelegde context. Dit verleent nooit toegang, kiest geen bedrijfseigenaar en wijzigt het registrardoel niet. ## Platformbeheerders: houders bij een ander bedrijf Platformbeheer gebruikt `/api/v1/accounts/CONTEXT_ID/admin/holders`. `CONTEXT_ID` is de beheercontext van de actuele persoonlijke verbinding, geen impliciete houdereigenaar. Een actuele interne beheerder, recente passkey en de juiste scope `admin:read` of `admin:write` zijn vereist. Er wordt geen lidmaatschap bij het doelbedrijf aangemaakt. Machineverbindingen kunnen geen houders beheren. | Actie | API | Rust-CLI | | --- | --- | --- | | Begrensde publieke lijst | `GET admin/holders?limit=25&cursor=0&search=AA` | `admin holder-contacts list --limit 25 --search AA` | | Domeincontactrollen controleren | `GET admin/holders/CONTACT_ID/domains` | `admin holder-contacts domains CONTACT_ID --limit 25` | | Bewerkbare velden en ETag lezen | `GET admin/holders/CONTACT_ID` | `admin holder-contacts get CONTACT_ID` | | Aanmaken voor een expliciet bedrijf | `POST admin/holders` | `admin holder-contacts create --confirm-company COMPANY_ID --input contact.json --yes` | | Veranderbare velden vervangen | `PUT admin/holders/CONTACT_ID` | `admin holder-contacts update CONTACT_ID --version ETAG --input contact.json --yes` | | Een ongebruikte houder verwijderen | `DELETE admin/holders/CONTACT_ID` | `admin holder-contacts delete CONTACT_ID --confirm-holder CONTACT_ID --version ETAG --yes` | | Een oorspronkelijk verzoek controleren | `GET admin/holders/mutations/ORIGINAL_UUID` | `admin holder-contacts mutation ORIGINAL_UUID` | | Uitsluitend lezend oorspronkelijk herstel | `POST admin/holders/mutations/ORIGINAL_UUID/actions/reconcile` | `admin holder-contacts reconcile ORIGINAL_UUID --confirm-mutation ORIGINAL_UUID --input recovery.json --yes` | | Een nooit verstuurde voorbereiding opgeven | `POST admin/holders/mutations/ORIGINAL_UUID/actions/abandon` | `admin holder-contacts abandon ORIGINAL_UUID --confirm-mutation ORIGINAL_UUID --input recovery.json --yes` | Voeg `--account CONTEXT_ID` toe aan elke CLI-opdracht. Lijstpaginering is expliciet: gebruik de teruggegeven `meta.next_cursor` met `--cursor`; maximaal 100 houders worden teruggegeven. Zoeken behandelt `%` en `_` letterlijk. Geautoriseerde houderuitvoer bevat de bewerkbare publieke velden, nooit privé-identificatiedocumenten, oorspronkelijk leveranciersbewijs, inloggegevens of interne correlatieopmerkingen. `contact.json` gebruikt de hierboven beschreven klantcontactvelden. Aanmaken vereist ook overeenkomende gehele `target_account_id` en `confirm_target_account_id`. CLI-optie `--confirm-company` moet met beide overeenkomen. Wijzigen kan geen persoons- of bedrijfsnaam aanpassen, eigendom verplaatsen, de leverancierscode vervangen of de wederverkoperidentiteit veranderen. Expliciete lokale toewijzing/import blijft een afzonderlijke beheerbewerking. Verwijder-JSON bevat `confirm_holder_id`. Nieuwe schrijfacties gebruiken de normale blijvende idempotentiesleutel en beoordeling met `--dry-run`; een proefuitvoering verstuurt geen leveranciersverzoek en maakt geen houderjournaal aan. Lees voor herstel eerst de oorspronkelijke metadata en bewaar de ETag. Dit is de journaal-ETag, verschillend van de actuele houder-ETag. Bijvoorbeeld: ```json { "version": "CURRENT_JOURNAL_ETAG_64_HEX", "confirm_intent_id": "ORIGINAL_UUID", "confirm_holder_id": 123, "confirm_holder_version": "CURRENT_CONTACT_ETAG_64_HEX", "confirm_no_supplier_mutation": true } ``` Gebruik `confirm_holder_id: null` voor oorspronkelijk aanmaken. Onzeker aanmaken zonder bewaarde houdercode vereist ook `verified_provider_handle` uit geverifieerd oorspronkelijk leveranciersbewijs; leid eigendom nooit af uit een overeenkomende naam/e-mailadres. De Rust-CLI verwijdert `version` uit deze JSON en verstuurt het als `If-Match`. Rechtstreekse API-clients sturen die header zelf en laten de extra eigenschap `version` weg. Herstel vereist **beide** actuele beheerscopes en een recente passkey, maar nieuwe leveranciersschrijfacties mogen uit blijven. Stuur geen `Idempotency-Key`, `--dry-run`, `--wait` of andere UUID naar deze herstelacties. Ze maken geen nieuwe API-bewerking aan. Opgeven weigert ieder verstuurd of onzeker origineel. Een actuele bevoegde beheerder mag via deze adapter expliciet een oorspronkelijk klant-API-, portaal- of personeels-API-verzoek herstellen. Het ondertekende oorspronkelijke doelbedrijf, de actor, aanvragende identiteit, bron, verzoekomhulling en bovenliggende bewerking blijven ongewijzigd. Bovenliggende personeels-API-verzoeken horen bij hun oorspronkelijke beheercontext; het houderjournaal en de houder horen bij het werkelijke doelbedrijf. Dit onderscheid tussen contexten wordt vóór leveranciersleesacties en lokale publicatie tegen het oorspronkelijke privébewijs gecontroleerd. Een nieuwe verbinding geeft geen toestemming om een oude schrijfactie automatisch opnieuw te versturen. Voor AI-agents: gebruik `HolderAdministratorChanges` uitsluitend als bevoegdheids-/transportadapter om `HolderChanges`, `HolderMutations` en `HolderPublication`. Behoud hun bewijs van eenmalige verzending en actuele bron-/eigendomscontroles. Een bovenliggend personeelsverzoek gebruikt bedrijfs-/routeactie `admin.holders.create`, `.update` of `.delete` en het bestaande canonieke privébewerkingsbewijs; herschrijf dit niet naar de klantnaamruimte van het doelbedrijf. Beleidsleesacties gebruiken de canonieke primaire database en een laatste zuivere tijdscontrole volgt op de laatste leesactie zonder nieuwe vastlegging. Deze opdrachten zijn in de broncode geïmplementeerd en afgedekt door lokale contracttests. Publicatie van publieke programmabestanden en productieactivering blijven onder de algemene API-/CLI-releasecontroles vallen.