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.

Workspace-beheer

Deze handleiding behandelt de geïmplementeerde platformbewerkingen voor interne Binadit-beheerders: inventaris, tijdelijk blokkeren, hervatten, Conserio-synchronisatie en expliciet opnieuw goedkeuren van werk dat vanwege bevoegdheid is geblokkeerd. Klantwijzigingen aan diensten, aankopen, opzegging en definitieve verwijdering hebben eigen procedures. Bedrijfsoverdracht gebruikt de afzonderlijk beoordeelde procedure hieronder. Overname heeft een eigen expliciete beheerprocedure.

Verbinding en bedrijfskeuze

Gebruik een persoonlijke menselijke verbinding met admin:read en admin:write. Voeg operations:read toe om asynchrone resultaten te bekijken en volgen. Servicesleutels kunnen geen platformbeheer uitvoeren. Je actuele identiteit moet een geverifieerde interne beheerder zijn, je lidmaatschap bij het beheerbedrijf moet nog actief zijn en de verbinding moet geverifieerde passkey-authenticatie van minder dan vijf minuten oud hebben. API, schrijven, gevoelige toegang en beheer moeten op de server zijn ingeschakeld. Een resourcebeperkte toekenning kan geen ander bedrijf beheren.

Twee bedrijfs-ID's hebben verschillende betekenissen:

• --account / {account} in de URL selecteert het bedrijf dat bij je persoonlijke beheerverbinding hoort.
• --target-account / target_account_id in de berichtinhoud bevestigt expliciet het werkelijke actuele klantbedrijf van de Workspace.

Een beheerder kan de Workspace van een ander bedrijf beheren zonder aan het team te worden toegevoegd. De server controleert het werkelijke eigendom van de Workspace; een gewijzigd doel-ID kan een bestaande goedkeuring niet omleiden. Het doelbedrijf moet actief en niet-geblokkeerd zijn. Beheer maakt geen klantlidmaatschap, aankoopbevoegdheid of facturatieafspraak aan.

API-contract

Elk pad hieronder begint met /api/v1/accounts/{account}/admin/workspace/workspaces.

De inventaris bevat geen wachtwoorden, serversleutels, Conserio Drive-inloggegevens of ruwe leveranciersfouten. Gewoon blokkeren, hervatten, synchroniseren en opnieuw goedkeuren vereisen If-Match met de actuele Workspace-ETag, een Idempotency-Key en een exacte JSON-berichtinhoud:

{"confirm_workspace_id":12,"target_account_id":123}

Voeg voor reapprove een original_operation_id als UUID toe. Lees en beoordeel de actuele Workspace opnieuw vóór goedkeuring. Het platformendpoint accepteert uitsluitend zijn eigen oorspronkelijke Workspace-beheerbewerkingen. Het opnieuw goedkeuren van een klantaankoop kan een bestelling niet tot platformbevoegdheid verheffen.

Conserio-synchronisatie past de actuele portaalinstellingen opnieuw toe, inclusief ingeschakelde status, gebruikerstoegang en bewaartermijn. Beoordeel vóór goedkeuring de teruggegeven bewaartermijnmetadata; het toepassen van een kortere ingestelde bewaartermijn kan oudere leveranciersgegevens verwijderen. Deze actie wijzigt niet de ingestelde bewaartermijn of het bijbehorende betaalde pakket.

Gebruik X-Binadit-Dry-Run: true om actuele rechten, eigendom, versie, status en voorwaarden te valideren zonder portaalrijen te wijzigen, een bewerking aan te maken of leveranciers te benaderen. Een proefuitvoering reserveert de Workspace niet; die controles worden bij de werkelijke wijziging herhaald.

CLI-voorbeelden

binadit admin workspace workspaces list --account 1 --limit 50
binadit admin workspace workspaces get 12 --account 1
binadit admin workspace workspaces suspend 12 --account 1 \
  --target-account 123 --confirm-workspace 12 --version CURRENT_ETAG --dry-run
binadit admin workspace workspaces suspend 12 --account 1 \
  --target-account 123 --confirm-workspace 12 --version CURRENT_ETAG --yes

Gebruik resume of conserio-resync op dezelfde positie. CURRENT_ETAG betekent exact de actuele waarde die get retourneert; hergebruik geen oude waarde na een andere wijziging. De CLI bewaart de blijvende wijzigingsintentie, past de normale bedrijfs- en mogelijkhedencontroles toe en verkrijgt nooit een leverancierssleutel.

Volg de teruggegeven bewerking met binadit operations watch OPERATION_UUID --account 1. Een geaccepteerd verzoek betekent dat werk is ingepland; het leveranciersresultaat volgt asynchroon. Een time-out bij volgen annuleert het werk niet.

Voorwaarden en herstel

Deze acties wijzigen toegang of synchronisatie, nooit facturatie. Tijdelijk blokkeren zegt geen betaalde diensten op en stopt geen terugkerende kosten. Hervatten kan een openstaande factuurblokkade niet opheffen: los eerst de oorspronkelijke factuur- en betalingsafstemming op. Onzekere oude afspraken vereisen eveneens afstemming vóór hervatten. Verwijderende of onbekende Workspace-statussen worden geweigerd.

Bestaand werk voor deze Workspace of onderliggende resources dat openstaat, is vastgehouden, wordt uitgevoerd, wacht, is mislukt of een onbekende status heeft, verhindert een andere gewone beheeractie. Controleer dat werk eerst. Deze endpoints vervangen nooit stilzwijgend een andere betaling of goedkeuring. Workspaces met meer dan 1.000 mailboxen of domeinen vereisen een afzonderlijk beoordeelde begrensde bewerking.

Ingeplande platformgoedkeuring ligt vast op het oorspronkelijke bedrijf, de Workspace, actie en beheertoekenning. Het werkproces controleert vóór uitvoering en elke HTTP-verzending opnieuw de actuele bevoegdheid, ook bij herhalingen. Intrekking, rolverlaging, bedrijfswijzigingen, gewijzigde taakbindingen of verlopen passkey-bewijs houden resterend werk tegen vóór nog een leveranciersverzoek. Reeds geaccepteerde leverancierseffecten kunnen blijven bestaan; werk blokkeren draait niets terug.

Meldt een oorspronkelijke platformbewerking requires_approval, verbind dan opnieuw met een recente geverifieerde passkey en controleer dezelfde bewerking en Workspace. Daarna:

binadit admin workspace workspaces reapprove 12 --account 1 \
  --target-account 123 --confirm-workspace 12 --version CURRENT_ETAG \
  --operation ORIGINAL_OPERATION_UUID --dry-run
binadit admin workspace workspaces reapprove 12 --account 1 \
  --target-account 123 --confirm-workspace 12 --version CURRENT_ETAG \
  --operation ORIGINAL_OPERATION_UUID --yes

Dit behoudt de bestaande taken en oorspronkelijke intentie, maakt geen factuur aan en herhaalt geen voltooide taak. Een verplaatste Workspace, gewijzigde gewenste actie of niet-platformtaak moet via zijn eigen procedure worden afgestemd.

Automatisering en AI-agents

Vraag vóór schrijven de beschikbare mogelijkheden en het actuele OpenAPI-contract op. Bevestig beide bedrijfs-ID's en het exacte Workspace-ID; globale leestoegang maakt de gekozen beheercontext niet tot resource-eigenaar. Haal een actuele versie op, beoordeel een proefuitvoering van de bedoelde actie en dien één blijvende intentie in. Vraag de status van die bewerking op. Hergebruik bij een onduidelijk HTTP-resultaat dezelfde intentie of controleer de oorspronkelijke bewerking; verzin geen andere goedkeuring.

Stop bij 412 en haal de nieuwe versie op en beoordeel die. Stop bij workspace_work_pending en controleer bestaand werk. Verkrijg voor requires_approval nieuwe menselijke passkey-autorisatie en gebruik het expliciete platformendpoint voor opnieuw goedkeuren. Bewaar bij requires_reconciliation de oorspronkelijke bewerking en vraag een beheerder de leveranciersuitkomst vast te stellen. Interpreteer tijdelijk blokkeren nooit als opzegging of betalingsautorisatie.

Een Workspace naar een ander bedrijf overdragen

Het portaal biedt Workspace overdragen in de Workspace-instellingen en een begrensde selectie van maximaal 20 Workspaces in het overzicht. Selecteren is alleen-lezen. Verifieer je passkey, kies het werkelijke doelbedrijf, beoordeel de prijs van elke Workspace en typ het exacte nummer om elke Workspace afzonderlijk te bevestigen. Eén Workspace afronden bevestigt niet stilzwijgend de rest. Na een verloren antwoord retourneert opnieuw indienen van dezelfde beoordeelde bevestiging het bestaande bewijs.

De overdracht behoudt het bedrijf op alle oorspronkelijke facturen, historische facturatieregels en correcties. Niet-gefactureerde perioden tot en met gisteren blijven verschuldigd door het oorspronkelijke bedrijf. De oude maandregel eindigt gisteren; een nieuwe regel begint vandaag (of op zijn oorspronkelijke toekomstige begindatum). Bestaande einddatums en vooruitbetaalde dekking blijven intact. Het doel krijgt alleen toekomstige verantwoordelijkheid. Geregistreerde domeinen behouden hun onafhankelijke registrareigendom en jaarfacturatie: draag die apart over via het domeinbeheer. Er is geen directe factuur, betaling, wachtwoordherstel of DNS-schrijfactie.

Een bestaande betaalde dienst behoudt zijn afgesproken maandprijs. start_billing: true zet gratis diensten om naar toekomstige betaalde diensten tegen de bestaande contractprijs; het herprijst niet volgens de actuele catalogus. Diensten blijven gratis voor een intern doelbedrijf. Betaalde overdrachten vereisen het normale maandfactuurbeleid van het doel of een geverifieerde automatische-incassomachtiging en EUR. Beheer kan betaling vooraf niet omzeilen. Eigen servers moeten al aan het doelbedrijf zijn gekoppeld of gedeeld zijn.

{"confirm_workspace_id":12,"target_account_id":456,"start_billing":false,"plan_version":"EXACT_64_CHARACTER_PLAN_VERSION","monthly_price_excl":"9.95"}

binadit admin workspace workspaces transfer-plan 12 --account 1 \
  --target-account 456 --output json
binadit admin workspace workspaces transfer 12 --account 1 \
  --target-account 456 --confirm-workspace 12 --version WORKSPACE_VERSION \
  --plan-version PLAN_VERSION --monthly-price 9.95 --dry-run
binadit admin workspace workspaces transfer 12 --account 1 \
  --target-account 456 --confirm-workspace 12 --version WORKSPACE_VERSION \
  --plan-version PLAN_VERSION --monthly-price 9.95 --yes

Voeg --start-billing uitsluitend bij bewust omzetten van gratis diensten toe aan zowel beoordeling als bevestiging. Een gewijzigd bedrijf, contract, resource of datum maakt het ondertekende plan ongeldig. Controleer en keur bij 412 een nieuw plan goed. Onbetaalde of onzekere bedrijfsfacturen, restituties/terugboekingen, onopgeloste onderliggende taken, factuurblokkade, actieve/onzekere oude afspraken of onduidelijke facturatieregels blokkeren overdracht. Los de oorspronkelijke afspraak op in plaats van verantwoordelijkheid te verplaatsen om die te omzeilen.

Het vastgelegde bewijs is atomair met eigendom, toekomstige facturatieregels en de bestaande synchronisatietaak. SQL-bedrijfsclaims voorkomen gelijktijdige uitvoering met maandfactuurplanning; na een procescrash blijft een veilig blokkerende claim over voor het gedocumenteerde beheerderherstel. Leverancierssynchronisatie draait asynchroon en gebruikt v2-platformbevoegdheid, vastgelegd op het nieuwe werkelijke bedrijf en de oorspronkelijke beheerdertoekenning. Volg de teruggegeven bewerking. Verloopt bevoegdheid, gebruik dan de algemene opdracht reapprove met die oorspronkelijke overdrachtsbewerking, de nieuwe actuele Workspace-versie en --target-account gelijk aan de nieuwe eigenaar. Opnieuw goedkeuren maakt geen tweede overdracht of andere factuur aan. Afgeronde historische afhankelijkheidsbewijzen kunnen uitsluitend een geverifieerde onveranderlijke eigendomsketen volgen; onafgeronde aankopen veranderen nooit impliciet van bedrijf.

Voor AI-agents: toon vóór vastleggen zowel oud als nieuw bedrijf, de ingangsdatum, het exacte toekomstige maandbedrag, de gratis-naar-betaald-keuze en behouden onbetaalde historie. Bewaar oorspronkelijk plan, verzoekinhoud, idempotentiesleutel, bewerkings-ID en overdrachtsbewijs samen. Herschrijf niet rechtstreeks account_id van facturatieregels, factuureigendom of taakinhoud. Een lokaal vastgelegde overdracht verschilt van bevestigde leverancierssynchronisatie.

Rust-CLI-validatie en asynchrone resultaten

De Rust-afhandelaars behouden de afzonderlijke beheerverbinding (--account) en werkelijke klantbinding (--target-account). Ze valideren de exacte Workspace, actuele versie, oorspronkelijke bewerking en gevraagde actie voordat ze een bewijs accepteren. Lijstpaginering behoudt oorspronkelijke gehele ID's, inclusief waarden die groter zijn dan JavaScript exact kan weergeven. Oude metadata die null of nul bevat, verleent nooit bevoegdheid over een ander bedrijf.

Overdrachtsbeoordeling toont getypeerde regeldekking en controleert het exacte decimale maandtotaal, keuzes voor gratis regels en behouden historie. Bevestiging verstuurt de beoordeelde planversie, Workspace-versie, het doelbedrijf, de gratis-naar-betaald-keuze en het decimale bedrag ongewijzigd. Een geslaagd lokaal overdrachtsbewijs bevestigt lokaal eigendom en toekomstige facturatieverantwoordelijkheid; het beweert niet dat leverancierssynchronisatie klaar is.

Gebruik --wait bij een wijziging om alleen de teruggegeven bewerking te volgen. Statusopvragen vernieuwen waar nodig gewone toegangstokens, retourneren begrensde veilige statusmetadata en herhalen de wijziging nooit. Een time-out laat de serverbewerking doorlopen; hervat met binadit operations watch ORIGINAL_OPERATION_UUID --account ADMINISTRATION_ACCOUNT. Alleen-lezen inventaris, resourceleesacties en beoordeling van overdrachtsplannen veranderen --wait niet in een andere actie. Een onverwacht account, resource, actie, prijs of historievlag behoudt de oorspronkelijke verzoekintentie voor onderzoek.

De algemene herstelgrens na opnieuw persoonlijk inloggen blijft een afzonderlijke releasevoorwaarde. Bewaar de oorspronkelijke verbinding, verzoekintentie, het ondertekende plan en het bewijs; neem geen ongebonden oud verzoek over en maak geen andere overdracht om een onzekere uitkomst te omzeilen. Dit broncodecontrolepunt activeert geen publieke Rust-CLI-release.

Workspace-instellingen en synchronisatie in de browser

De Workspace-pagina gebruikt dezelfde bestaande wachtrij om de getoonde naam te wijzigen, toegang te blokkeren of hervatten en Drive of Conserio te synchroniseren. De pagina hergebruikt je geldige aanmelding met een passkey of authenticator volgens het actuele aanmeldbeleid voor beheerder en bedrijf; normaal indienen vraagt niet opnieuw om dezelfde factor. Naamwijzigingen en Drive-synchronisatie vereisen actuele Workspace-schrijfrechten. Blokkeren, hervatten en Conserio-beheer vereisen de actuele interne beheerdersrol. Inloggen als klant kan deze acties niet goedkeuren.

Elk formulier bevat de beoordeelde versie en een oorspronkelijke intentie-UUID. Een gewijzigde Workspace vereist opnieuw beoordelen van de pagina. De korte lokale transactie legt gewenste status en oorspronkelijke synchronisatietaken samen vast; ze verstuurt geen leveranciersverzoek en maakt geen bestelling of factuur aan. Een onopgeloste eerdere taak blokkeert een nieuwe actie. Een facturatieblokkade kan alleen via het oorspronkelijke betalings-/afstemmingsproces worden opgeheven.

Onderhoudsformulieren en formulieren voor opnieuw goedkeuren van oorspronkelijke taken behouden ook de bedrijfscontext waarin ze werden getoond. Van bedrijf wisselen in een ander tabblad vereist herladen en opnieuw beoordelen van het formulier; een oud formulier kan zijn actie niet stilzwijgend in de nieuwe context goedkeuren. Ontbrekende of afwijkende context wordt geweigerd voordat nieuw werk wordt toegewezen. Agents die de bestaande adapter onderhouden moeten de getoonde context_account_id samen met de beoordeelde versie en intentie behouden; vervang deze bij indienen nooit door de actuele sessiewaarde.

Ingeplande browsertaken bevatten een ondertekende v3-goedkeuring met de oorspronkelijke actor, identiteitsgeneratie, bedrijfscontext, Workspace, gewenste naam/status en een leveranciersbronhandtekening. Dit is browsergoedkeuring, geen OAuth-sessie of nieuwe API-sleutel. API-functievlaggen uitschakelen schakelt normaal browserbeheer niet uit. Werkprocessen controleren actuele identiteit, lidmaatschap, rechten, bedrijfsstatus, leveranciersbron en de oorspronkelijke sterke authenticatie, ook direct vóór elke canonieke HTTP-verzending en opnieuw na iedere databasewachttijd. Elke ingeplande rij en zijn volledige onveranderlijke inhoud hebben een afzonderlijke aan het taak-ID gebonden handtekening, zodat het kopiëren van oorspronkelijke goedkeuring geen andere taak of aanvullende invoer kan autoriseren. Bestaande onderliggende synchronisatietaken krijgen hun eigen handtekeningen binnen een korte lokale transactie. Goedkeuring geldt vijf minuten; intrekking of verlopen houdt de oorspronkelijke taken geblokkeerd in plaats van succes te melden of vervangend werk toe te wijzen.

Open om een bevoegdheidsgeblokkeerde browseractie te hervatten Workspace → Instellingen, beoordeel de getoonde oorspronkelijke actie en UUID en kies Oorspronkelijke taken opnieuw goedkeuren. Een geldige aanmelding met een passkey of authenticator in dezelfde browsersessie levert identiteitsverificatie volgens het actuele bedrijfsbeleid zonder nog een verificatiehandeling. Alleen de oorspronkelijke persoon in de oorspronkelijke bedrijfscontext mag goedkeuren. Dit vernieuwt expliciet de eindige goedkeuring op de bestaande taak-ID's en behoudt hun voortgang; het behoudt de werkelijke authenticatietijd en maakt geen nieuwe synchronisatie-intentie, bestelling of factuur. Nieuwe browsergoedkeuringen met passkey of authenticator dragen hun eigen ondertekende issued_at; oudere goedkeuringen behouden hun oorspronkelijke vervaltijd. Gewijzigde leveranciersbindingen of gewenste status vereisen beheerderafstemming en kunnen niet met deze knop worden overgenomen. Ander openstaand werk moet eerst afronden of worden afgestemd. Oorspronkelijke API-taken gebruiken de hierboven beschreven opdrachten voor opnieuw goedkeuren van de oorspronkelijke bewerking; oorspronkelijke browsertaken kunnen ook de expliciete brug hieronder gebruiken.

Voor andere AI-agents: verzin nooit een OAuth-toekenning vanuit een webgebruiker en verwijder nooit api_authority uit een taak om een blokkade te omzeilen. Gebruik WorkspacePortalChanges voor de genoemde browseracties; WorkspacePortalApproval is de ondertekende bevoegdheidsadapter die door ApiTaskAuthority v3 wordt gebruikt. De v1-klant-API- en v2-platform-API-formaten en hun toekenningsbeleid blijven ongewijzigd. De native adapter ondertekent ook de expliciet ondersteunde doeleinden workspace-create en conserio-set en de daaraan gebonden inrichtingstaken. Het taakdoel en het exacte onderwerp bepalen de toegestane actie; een goedkeuring geeft nooit algemene rechten voor afrekenen, wachtwoordlevering of willekeurige betaalde apply-invoer. Goedkeuringen voor gedeelde mailboxen en samenwerking gebruiken hun eigen onderwerpspecifieke procedures. Bewaar iedere oorspronkelijke goedkeuring met het bijbehorende DNS-journaal.

Browseronderhoud verifieert ook dat de beoordeelde lokale velden, elk taakbewijs, de herhaalstatus en het auditbewijs werkelijk zijn opgeslagen. Een geannuleerde modelgebeurtenis of afwijkende opgeslagen waarde draait de lokale wijziging terug; er kan geen geslaagde goedkeuring met ontbrekend werk worden teruggegeven. Opnieuw goedkeuren behoudt de vorige oorspronkelijke blokkade als het vernieuwde bewijs of opnieuw inplannen niet kan worden opgeslagen.

Oorspronkelijk browseronderhoud vernieuwen via API of Rust-CLI

Gebruik voor deze procedure de oorspronkelijke browserintentie-UUID. Deze verschilt van een API-bewerkings-UUID. Log in als dezelfde persoon in dezelfde oorspronkelijke bedrijfscontext, met recente passkey- of authenticatorverificatie. Een servicekoppeling kan geen browsergoedkeuring overnemen. De klantverbinding heeft zowel workspace:read als workspace:write nodig en kan naamwijzigingen en Drive-synchronisatie bekijken of vernieuwen. Medewerkers gebruiken de beheerroutes met zowel admin:read als admin:write, een actuele interne beheerdersrol en recente passkey. Het bedrijf van de beheerverbinding en het werkelijke Workspace-bedrijf blijven gescheiden; er wordt geen klantlidmaatschap aangemaakt.

Controle retourneert uitsluitend Workspace-/bedrijfs-/context-ID's, oorspronkelijke intentie, actie, actuele Workspace-version, taak-ID's/-statussen en billing_changed: false. Er wordt geen leveranciersverzoek verstuurd en geen API-bewerking of wijzigingssleutel toegewezen. Dit blijft beschikbaar wanneer nieuwe API-schrijfacties uitstaan, zolang API, gevoelige beoordeling en actuele rechten beschikbaar blijven. Het beweert niet dat een werkproces- of leveranciersactie klaar is.

Stuur voor vernieuwen de bekeken Workspace-ETag in If-Match, een stabiele nieuwe Idempotency-Key voor deze expliciete vernieuwing en exact:

{"confirm_workspace_id":7,"target_account_id":42}

Het doelbedrijf moet overeenkomen met de oorspronkelijke Workspace. Gebruik de werkelijke ID's; deze nummers zijn voorbeelden. Een proefuitvoering met dry_run: true valideert dezelfde beoordeling en verbruikt geen sleutel en wijzigt geen taken. Werkelijk vernieuwen vereist ingeschakelde schrijfacties. Het kan alleen dezelfde bevoegdheidsgeblokkeerde oorspronkelijke taken hervatten, behoudt hun voortgang en bewijs van leverancierspogingen en maakt geen bestelling, factuur, betaling of vervangende taak aan. Openstaand werk van een andere intentie, gewijzigde naam/status/bron, aangepaste taakhandtekening, andere persoon/context of verouderde Workspace-versie weigert vernieuwing. Een geslaagd HTTP-antwoord betekent dat bestaande lokale rijen zijn vernieuwd; volg die oorspronkelijke taak-ID's voor levering.

binadit workspace portal-approvals get 7 ORIGINAL_BROWSER_INTENT_UUID --account 42
binadit workspace portal-approvals reapprove 7 ORIGINAL_BROWSER_INTENT_UUID \
  --account 42 --target-account 42 --confirm-workspace 7 \
  --version CURRENT_WORKSPACE_VERSION --dry-run
binadit workspace portal-approvals reapprove 7 ORIGINAL_BROWSER_INTENT_UUID \
  --account 42 --target-account 42 --confirm-workspace 7 \
  --version CURRENT_WORKSPACE_VERSION --yes

Medewerkers gebruiken binadit admin workspace portal-approvals get|reapprove met --account ADMINISTRATION_CONTEXT en het afzonderlijk beoordeelde --target-account CUSTOMER_COMPANY. De twee positiewaarden zijn altijd het Workspace-ID en de oorspronkelijke browserintentie-UUID. De opdrachten weigeren ongeldige bevestigingen vóór authenticatie, behouden volledige numerieke ID's en tonen alleen gevalideerde publieke bewijsvelden. Ze ondersteunen geen --wait; volg de oorspronkelijke taak-ID's of controleer opnieuw.

Na API-vernieuwing bevat de ondertekende onderhoudsgoedkeuring ook een binding aan de werkelijke persoonlijke API-sessie en haar oorspronkelijke scopeplafond. Werkprocescontroles behouden actuele intrekking van toekenning, bedrijfsbeleid, actoridentiteit, bronbinding en de vijfminutengrens voor sterke verificatie. Er wordt geen browsersessie uit API-inloggegevens verzonnen. Expliciete latere browservernieuwing volgt de eigen actuele sterke-authenticatieregels van de browser; API-vlaggen blijven onafhankelijk van gewoon browserbeheer.

Voor AI-agents: bewaar de oorspronkelijke intentie, context, Workspace-versie, het beoordeelde doel, de vernieuwingsverzoeksleutel en de teruggegeven bewerkings-/taak-ID's. Dien nooit een andere naamwijziging of hersynchronisatie in om een geblokkeerde taak te omzeilen. Controleer bij een onzeker vernieuwingsantwoord dezelfde oorspronkelijke intentie en API-bewerking; bewaar de openstaande sleutel en volg de richtlijnen voor oorspronkelijke bewerkingsbewijzen. Een 409, 412, autorisatieweigering of ongeldig gevormd antwoord geeft geen toestemming voor vervangend werk. Bewerk nooit taakinhoud, verwijder geen connection_authority/taakhandtekeningen en vervang de browserintentie niet door een API-bewerkings-UUID.

Persoonlijke Drive opzeggen en definitief wissen

Deze klantbewerkingen gebruiken /api/v1/accounts/{account}/workspaces/{workspace}/mailboxes/{mailbox}. Ze gebruiken de actuele Workspace-rechten van het bedrijf in plaats van de platformbeheerpaden hierboven.

De berichtinhoud voor wissen is {"expected_used_bytes":7000,"confirm_address":"ada@example.nl","understood":true}. Lees de werkelijke inhoud en bevestig eerst het bedrijf; gebruik de actuele mailboxversie. De Rust-CLI ondersteunt:

binadit workspace accounts drive contents 7 --workspace 3 --account 123
binadit workspace accounts drive status 7 --workspace 3 --account 123
binadit workspace accounts drive purge 7 --workspace 3 --account 123 \
  --expected-used-bytes 7000 --confirm-address ada@example.nl --understood \
  --version MAILBOX_ETAG --dry-run

Verwijder --dry-run pas nadat je bedrijf, adres en actuele inhoud hebt beoordeeld. Een serviceverbinding mag een lege Drive opzeggen als haar werkelijke actuele toekenning dit toestaat; ze kan geen definitief wissen autoriseren. Bestaande portaalopzegging behoudt de oorspronkelijke geauthenticeerde persoon, bedrijfscontext en identiteitsgeneratie gedurende het hele verzoek. Van context wisselen of actuele rechten intrekken stopt volgende leveranciersaanroepen.

Elke geaccepteerde actie behoudt één oorspronkelijke Drive-intentie. De onderliggende facturatietaak, de leverancierspoging en het exacte publieke API-controlepunt moeten vóór een leverancierswijziging zijn vastgelegd. Een betaalde maandperiode blijft behouden; onzekere financiële beëindiging gebruikt dezelfde oorspronkelijke financiële taak en leveranciersleesacties, zonder tweede beëindiging. Een onzekere Drive-poging behoudt haar pogingmarkering en wordt onderzocht in plaats van blind opnieuw verstuurd. Teammappen en back-upbewaartermijn worden door het wissen van een persoonlijke Drive niet geraakt.

completion_verified: true betekent dat het ondertekende origineel en de actuele lokale mailbox- en facturatieweergaven overeenkomen. requires_reconciliation: true is een blokkade, ook bij een onbevestigde toegewezen facturatietaak. Een bekend oorspronkelijk leveranciersantwoord blijft privé bewaard, ook wanneer bron of bevoegdheid verandert terwijl het antwoord terugkomt. Dat antwoord alleen autoriseert geen publicatie via een vervangende verbinding. Sleutels, onveranderlijke bindingen, financiële verzoekinhoud en ruwe leveranciersantwoorden worden niet door status teruggegeven.

Voor gebruikers en AI-agents: bewaar de oorspronkelijke bedrijfs-, Workspace-, mailbox-, intentie-, API-bewerkings- en financiële taak-ID's. Lees eerst /drive-purge. Wis geen openstaand CLI-verzoek, wissel niet van bedrijf, vervang geen leveranciersverbinding, schakel schrijfacties niet in en maak geen vervangende aankoop om een blokkade te omzeilen. Bestaand controllerherstel behoudt de oorspronkelijke dienstintentie; een later beoordeeld verzoek bewijst niet dat een eerder publiek verzoek geslaagd is. De generieke bevestiging van de oorspronkelijke bewerking kan een automatisch openstaand verzoek alleen vrijgeven nadat onafhankelijk is bevestigd dat exact die publieke bewerking geslaagd is. Blijft dat origineel mislukt of actief, bewaar het openstaande verzoek dan voor beheerderbeoordeling. Oudere intenties zonder verifieerbaar ondertekend bewijs blijven geblokkeerd en worden nooit stilzwijgend overgenomen.

Oorspronkelijke API-mailservertaken

Nieuwe API-taken voor Workspace, domein en mailbox bewaren een privé ondertekende oorspronkelijke bedrijfs-, onderwerp-, routerings- en mailserververbindingsbinding, vastgelegd bij toewijzing van de taak. Privé-invoerhashes binden wachtwoord- en betaalde-wijzigingsinvoer zonder hun waarden in die broncapsule te bewaren; de bestaande afhandelaar kan uitsluitend hun exacte eenrichtingsverwijdering vastleggen. Vóór elk werkelijk Stalwart-verzoek controleert het werkproces die oorspronkelijke bron, de actuele werkelijke API-toekenning en financiële voorwaarden. De SDK controleert ook de werkelijke bestemming, methode, inloggegevens, exacte JMAP-inhoud en transportinstellingen. Een toekenning die na een geslaagd antwoord wordt ingetrokken verhindert het volgende verzoek; het geaccepteerde antwoord blijft bewaard.

Taken die zijn toegewezen voordat dit bronbewijs bestond, blijven geblokkeerd. Bewerk hun inhoud niet, kopieer geen bewijs van een andere taak, wissel niet van server en gebruik geen DNS-afspraak om mail- of certificaatwijzigingen te autoriseren. Bestaand expliciet opnieuw goedkeuren kan de werkelijke toekenning voor een al gebonden oorspronkelijke taak vernieuwen; het behoudt het oorspronkelijke bronbewijs en voegt een afzonderlijk ondertekend vernieuwingsbewijs voor dezelfde taak toe. Het kan geen ongebonden oude taak of gewijzigde bron overnemen. Gebruikers en AI-agents moeten de oorspronkelijke bewerkings-, taak- en intentie-ID's behouden en een blokkade onderzoeken in plaats van vervangend werk in te dienen. Rechtstreekse wachtwoordherstelautorisatie en controles op leveranciersbevestiging staan los van dit contract voor ingeplande taken.

Rechtstreeks mailboxwachtwoorden opnieuw instellen

Portaal en API gebruiken dezelfde directe wachtwoordherstelbewerking. Verifieer in het portaal eerst met je passkey of authenticator en kies daarna Wachtwoord opnieuw instellen op de actuele mailboxpagina. Een verouderde pagina moet worden vernieuwd. De actie controleert je actuele bedrijfscontext, lidmaatschap, inloggegevensrechten en oorspronkelijke loginidentiteit opnieuw direct vóór het werkelijke mailserververzoek. Zij maakt geen onderhoudstaak, API-verbinding of vervangende loginidentiteit aan. Bestaand portaalherstel blijft beschikbaar wanneer de API uitstaat.

Gebruik voor API en Rust-CLI een persoonlijke verbinding die in de afgelopen vijf minuten met de vereiste passkey of authenticator is geauthenticeerd, met zowel workspace.credentials:write als workspace.credentials:read voor exact de Workspace. Lees de mailbox en bewaar de ETag. Stuur een leeg JSON-object naar POST /api/v1/accounts/{account}/workspaces/{workspace}/mailboxes/{mailbox}/actions/password-reset, met die ETag in If-Match en één blijvende Idempotency-Key. De getypeerde CLI-opdracht schrijft het eenmalige resultaat rechtstreeks naar een nieuw privébestand en toont het wachtwoord niet:

binadit workspace accounts credentials reset MAILBOX_ID --account COMPANY_ID \
  --workspace WORKSPACE_ID --version MAILBOX_ETAG --file NEW_PRIVATE_FILE --yes

Kies een nieuwe bestemming in je privémap. Bewaar een onzekere bestemming en de oorspronkelijke verzoekintentie; verwijder die niet om een herhaling af te dwingen. Toon inloggegevens nooit in gedeelde terminals en sla ze niet op in versiebeheer.

Geslaagd opnieuw instellen vereist één begrensde, gecorreleerde positieve bevestiging die exact het bedoelde mailserveraccount benoemt. Een generieke HTTP 200, leeg updated-object, ander account, ongerelateerd JMAP-antwoord of time-out kan geen succes aantonen. De oorspronkelijke versleutelde rotatie en exclusieve mailboxblokkade worden vóór elk leveranciersverzoek vastgelegd. Leveranciersaanroepen draaien buiten databasetransacties. Wachtwoorden, beheersleutels en ruwe leveranciersfoutinhoud worden niet in foutantwoorden blootgesteld.

Het herstelantwoord bevat een kortlevende credential_claim_id, niet het wachtwoord. Verbruik deze eenmaal via POST /api/v1/accounts/{account}/credential-claims/{credential_claim_id}/consume; de claim verloopt na twee minuten en vereist actuele rechten om inloggegevens te lezen en recente sterke authenticatie. Een herhaald geslaagd herstelverzoek met zijn oorspronkelijke HTTP-sleutel retourneert het bewijs zonder nog een leveranciersschrijfactie. De herstelweergave in het portaal is versleuteld in de sessie, verloopt na twee minuten en wordt vóór haar eenmalige weergave opnieuw geautoriseerd. Van bedrijf wisselen, lidmaatschap intrekken of de loginidentiteit vervangen verhindert bekendmaking.

Is de leveranciersuitkomst onzeker, bewaar dan de oorspronkelijke HTTP-bewerking en zijn password_rotation_id. De bewerkingsstatus vereist afstemming; een andere HTTP-sleutel kan de blijvende mailboxblokkade niet omzeilen. Herhaal het leveranciersverzoek niet, wijzig account/server niet, wis geen openstaand CLI-verzoek, bewerk geen journaalrijen en maak geen vervangend wachtwoordherstel. Vraag de beheerder het oorspronkelijke privébewijs en de werkelijke mailserveruitkomst te onderzoeken. Er is geen automatische herverzending of overname van oud of onzeker wachtwoordherstel. Heeft de leverancier de wijziging bevestigd maar mislukte lokale publicatie, dan blijft de privébevestiging geblokkeerd; beweer niet dat het oude gecachete wachtwoord actueel is. Is lokale publicatie voltooid maar eenmalige levering geweigerd, dan kan een bevoegde gebruiker na opnieuw verbinden met actuele sterke authenticatie de afzonderlijk beveiligde wachtwoordweergave gebruiken, zonder nog een herstelactie. Toegang intrekken na een geaccepteerd antwoord verhindert levering; het draait de werkelijke externe wachtwoordwijziging niet terug.

Bestaande domein-catch-all

Het bestaande catch-allformulier vereist nu actuele sterke verificatie en de oorspronkelijk getoonde versies van bedrijf, Workspace, domein en geselecteerde mailbox. Het plant een ondertekende domain-catch-all-browsergoedkeuring in voor exact dat bestaande geverifieerde maildomein. Het werkproces voert alleen die catch-allwijziging uit: het verleent geen DNS-, accountaanmaak-, certificaat- of financieel werk. API-schrijfvlaggen schakelen deze onafhankelijk goedgekeurde bestaande bewerking niet uit.

Een exact begrensd leveranciersbewijs updated bevestigt het oorspronkelijke domein. Na een ontbrekend of ongeldig gevormd antwoord bekijkt dezelfde taak alleen x:Domain/get; de schrijfactie wordt nooit automatisch herhaald. Verloopt sterke verificatie, vernieuw dan expliciet dezelfde oorspronkelijke taak via het bestaande goedkeuringsformulier of de bestaande persoonlijke opdrachten workspace portal-approvals get/reapprove. Een gewijzigde actor, bedrijf, domein, mailbox of mailserverbron kan het origineel niet overnemen. Ongebonden oude browsertaken blijven geblokkeerd; ze worden nooit opgewaardeerd met een DNS-afspraak of verzonnen API-toekenning.

Bestaande levering van maildomeinen

Een domein toevoegen of Opnieuw controleren kiezen beoordeelt actueel bedrijf, Workspace, domeinversie en mailserverbron met je recente sterke verificatie. Het portaal plant een ondertekende domain-mail-goedkeuring in voor exact die bestaande bewerking. Dit blijft beschikbaar met uitgeschakelde API. Het werkproces vereist eerst publiek TXT-eigendomsbewijs of de momenteel eigen portaalzone. Het levert uitsluitend het beoordeelde maildomein en bereidt de DNS-records voor; het maakt geen mailboxen aan, wijzigt geen DNS en verandert geen facturatie. DNS toepassen vereist een afzonderlijke expliciete DNS-beoordeling. Een later beoordeelde controle kan het domein activeren nadat de werkelijke publieke records overeenkomen. Certificaatverzoeken blijven als aangevraagd gemarkeerd totdat hun eigen uitkomst is geverifieerd.

Bewaar de oorspronkelijke taak- en intentie-ID's. Verloopt verificatie, vernieuw dan dezelfde taken via het bestaande goedkeuringsformulier of de persoonlijke opdrachten workspace portal-approvals get/reapprove. Een gewijzigde mens, bedrijf, domein of leveranciersbron kan de oude bewerking niet overnemen. Nieuwe API-goedkeuringen en vernieuwingen blijven actuele API-schrijfrechten vereisen; een browsergoedkeuring verzint geen API-toekenning.

Maildomein aanmaken en certificaatverzoeken hebben blijvende onafhankelijke poging-/bevestigingsbewijzen. Een time-out, ongeldig antwoord, onbekend aanmaak-ID of oudere herstelde taakstatus staat nooit opnieuw aanmaken toe. Een bekend geaccepteerd ID blijft privé totdat een exacte naamcontrole het oorspronkelijke doel bewijst. Herstel behoudt hetzelfde ID en mag uitsluitend lezende leverancierscontroles gebruiken; het neemt nooit een ander domein op naam over. Een onzeker verzoek blijft vastgehouden voor beheerderonderzoek. Wis het bewijs niet, dien geen vervangend domein in, kopieer geen bewijs en waardeer ongebonden oude taken niet op. Bestaand mailboxen aanmaken, aliassen en domeinverwijdering zijn afzonderlijke bewerkingen met eigen goedkeuringsvereisten.

Mailserversynchronisatiebewijzen

Mailserverantwoorden worden begrensd en gekoppeld aan exact de oorspronkelijke methode en aanroeptag. Account- en domeinschrijfacties vereisen positieve bewijzen voor precies de gevraagde aanmaaksleutels, bijgewerkte doelen of verwijderde ID's; een lege HTTP 200 is geen afronding. Leveranciersfouttekst en transportuitzonderingsketens worden achtergehouden omdat ze beheersleutels of een nieuw gegenereerd wachtwoord kunnen herhalen. Bewaar de oorspronkelijke taak na een onzeker antwoord. Deze controles verlenen geen nieuwe goedkeuring, autoriseren geen ander leveranciersdoel en staan geen herhaling van onzeker aanmaken toe. Bestaande mailbox-, alias- en verwijdergoedkeuringen blijven gescheiden van maildomein- en DNS-goedkeuringen.

Mailboxen aanmaken, instellingen, aliassen en opzegging in het portaal

Het portaal beoordeelt de getoonde bedrijfs-, Workspace- en mailboxversies met actuele sterke verificatie. Weergavenaam, hoofdadres, extra aliassen en blokkeren maken een ondertekende mailbox-mail-bewerking voor exact het bestaande mailaccount. Elke beoordeling wijzigt alleen de getoonde velden; ze koopt geen product, wijzigt geen quota, past geen DNS aan en wist Drive niet stilzwijgend. Bevestigde mailboxwijzigingen werken ook dezelfde bestaande Conserio-gebruiker bij, met behoud van rol en actuele oorspronkelijke bevoegdheid. Onzekere schrijfacties herstellen via een exacte accountleesactie op hetzelfde origineel; ze worden nooit opnieuw verstuurd omdat een taak is hersteld of herhaald.

Rechtstreeks mailboxen afrekenen en afrekenen via de winkelmand gebruiken de bestaande betalings- en maandregelprocedure onder een afzonderlijke ondertekende mailbox-checkout-goedkeuring die 24 uur geldig is. Actuele rechten van de uitgever, identiteitsgeneratie, bedrijf, product, oorspronkelijke leveranciersbron en betaling blijven bij levering vereist. Er wordt geen API-token voor browserwerk verzonnen. Onzeker accountaanmaken blijft geblokkeerd; een exact bewaard aanmaakbewijs kan de oorspronkelijke lokale publicatie afronden. Bestaande browserwerking hangt niet af van API-beschikbaarheid.

Opzegging vereist de getoonde mailboxversie en het getypte oorspronkelijke adres. De ondertekende mailbox-cancel-bewerking beëindigt elke bestaande bekende facturatieafspraak via de canonieke financiële taak, behoudt identiteit en prijs en houdt mail beschikbaar tot de beoordeelde betaalde einddatum. Op die datum wist zij alleen de oorspronkelijke beoordeelde catch-allverwijzingen en verwijdert ze exact het oorspronkelijke mailserveraccount. Afzonderlijke blijvende bewijzen verhinderen nog een catch-all- of accountwijziging na een verloren antwoord; herstel leest alleen het oorspronkelijke leveranciersdoel. Onbekende facturatie of een onopgeloste betaling blijft geblokkeerd. Persoonlijke Drive-gegevens vereisen eerst de bestaande expliciete wisprocedure; mailboxopzegging verwijdert Drive-gegevens nooit stilzwijgend.

Vernieuw hetzelfde origineel via het bestaande goedkeuringsformulier of de persoonlijke opdrachten workspace portal-approvals get/reapprove. Bewaar oorspronkelijke taak-ID's en intentie. Aanmaken en opzegging kunnen geen instellingen-, maildomein- of DNS-goedkeuring lenen. Opnieuw goedkeuren vereist werkelijk dezelfde persoon, oorspronkelijke bedrijfscontext, actuele rechten en sterke verificatie; de CLI wijst geen vervangende leveranciersintentie toe.

Wachtwoorden tonen en weergave na aanmaken in het portaal

Een opgeslagen mailboxwachtwoord bekijken in het portaal vereist een geldige actuele portaalsessie, de werkelijke actuele Workspace-beheerder, actuele inloggegevensrechten en naleving van het huidige aanmeldbeleid van het bedrijf. Een geldige aangemelde sessie vraagt niet opnieuw om een passkey of authenticator om het wachtwoord te bekijken. De authenticatieregels voor gevoelige API- en CLI-acties blijven ongewijzigd. De server controleert toegang opnieuw na het vastleggen van de auditgebeurtenis en direct vóór het teruggeven van het geheim. Wachtwoorden komen nooit in die auditregel. Verlaat inloggen als klant vóór deze actie; een beheerder kan zijn eigen identiteit en een expliciet geselecteerde klant-Workspace gebruiken.

Enkelvoudig mailboxen aanmaken en aanmaken via de winkelmand gebruiken dezelfde versleutelde eenmalige weergave als bestaand wachtwoordherstel. De sessie bewaart versleutelde tekst, gebonden aan oorspronkelijke gebruiker, identiteitsgeneratie, bedrijfscontext en mailbox, met een levensduur van 120 seconden. Het openen verbruikt de weergave en controleert actuele toegang en het actuele wachtwoord opnieuw. Een verouderde, verlopen of ingetrokken weergave wordt weggegooid. Groepsweergaven behouden elke laatste verificatiedeadline. Oude wachtwoordmeldingen in platte tekst worden niet getoond of naar JSON gekopieerd. De JSON of pagina met een geautoriseerde wachtwoordweergave in platte tekst is privé en mag niet worden gecachet.

De bestaande API-claim voor inloggegevens en de privébestandslevering van Rust blijven afzonderlijk; een browserweergave is geen herbruikbare API-claim. Bewaar oorspronkelijke bewerkingsbewijzen wanneer herstellen of aanmaken is geblokkeerd, in plaats van nog een leverancierswijziging in te dienen.

Bestaande mailboxpakketten en de bestaande Drive-pool

Een mailboxpakket wijzigen of Drive inschakelen vereist de getoonde versies van bedrijf, Workspace, mailbox, actuele maandregel en product, plus actuele sterke verificatie. De oorspronkelijke mailbox-checkout-taak wordt vóór leverancierslevering opgeslagen. Een pakketwijziging behoudt dezelfde maandregel en gebruikt de bestaande evenredige opwaardeercorrectie; er wordt geen factuur aangemaakt en de oude afsprakenbewerking wordt niet aangeroepen. Drive inschakelen bindt de actuele geverifieerde bedrijfspool en bestaande maandregel en beëindigt elke passende oude individuele Drive-maandregel via de bestaande maandfacturatieprocedure. Het werkproces controleert het beoordeelde grootboek, de pool en actuele browserbevoegdheid vóór het versturen van het quota- of Drive-verzoek, buiten SQL-transacties.

Zoals bij de bestaande API-facturatiecontrole moet een actief of onzeker oud WeFact-abonnement worden afgestemd vóór een pakket- of poolwijziging. Het wordt niet stilzwijgend herprijsd of beëindigd. Gewone bekende maandregels blijven bruikbaar. Drive uitschakelen blijft de expliciete actuele opzeggings- of wisprocedure voor een lege Drive gebruiken; het plant geen ongeautoriseerde herschrijving van de mailbox in. Bestaande opdrachten voor oorspronkelijke-taakcontrole en vernieuwing zijn van toepassing; er is geen aanvullende leveranciersopdracht of vervangende intentie nodig.

Diensten die met een nieuwe mailbox aangaan

Een nieuwe mailbox kan direct de diensten krijgen die per account bestaan: in het portaalformulier ("Diensten"), het winkelmandje en een API- of CLI-offerte van soort workspace_mailbox (ook in een orderbatch):

Beide zijn booleans, standaard false. conserio_admin: true vraagt daarnaast workspace:write op die Workspace, het recht dat de bestaande actie actions/conserio-admin ook vraagt, naast orders:write en workspace.mailboxes:write. Ontbreekt een voorwaarde, dan weigert de offerte met 422; bij bevestigen wordt de voorwaarde opnieuw gecontroleerd tegen de vergrendelde Workspace, dus Chat die na de offerte uit is gezet, weigert de bestelling voordat er iets gefactureerd of gemaakt is.

Geen van beide geeft een factuurregel. Eerst wordt de mailbox gemaakt; zijn Drive zet dezelfde mailboxtaak, en de Conserio-sync die volgt zodra de mailbox op de mailserver staat, stuurt de beheerdersrol mee. Elk account krijgt Chat, Meet en Book als die aan staan voor de Workspace; die worden niet per mailbox gekozen. Voorbeeld:

{"kind": "workspace_mailbox", "input": {"workspace_id": 7, "product_id": 9, "domain_id": 12, "local_part": "ada", "drive": true, "conserio_admin": true}}