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.

Bestaande Workspace-mailboxen overnemen

Een interne beheerder kan een bestaand domein en gewone mailboxen op een geconfigureerde Workspace-mailserver aan een bedrijf koppelen. Het portaal en de API gebruiken dezelfde inspectie en bevestigingsservice. De controle voert alleen begrensde JMAP-reads uit; de bevestiging maakt lokale koppelingen, facturatieafspraken en taken atomisch aan. Het bestaande wachtwoord blijft behouden. Er wordt geen domein of mailbox opnieuw aangemaakt en er worden geen DNS-records gepubliceerd.

Deze beheerfunctie vereist een menselijke beheerder, admin:read voor controle, admin:write voor bevestiging, een recente passkey en ingeschakelde beheercapabilities. Een serviceclient kan deze rechten niet gebruiken. Beschikbaarheid in de API beschrijft de actuele releaseconfiguratie; tests met nagebootste leveranciers zijn geen bewijs van een uitgevoerde productieovername.

Portaal

Open Workspace → Bestaande mailboxen overnemen. Bevestig met je passkey, kies de bestaande mailserver en voer de exacte kleine-letterdomeinnaam in. Selecteer de gewone, nog niet gekoppelde mailboxen, het doelbedrijf en de facturatie. Controleer daarna het bedrijf, de server, de bestaande en toekomstige limieten en de volledige maandprijs. Bevestig de overname binnen tien minuten. Een gewijzigde mailboxidentiteit, serverconfiguratie, bedrijfsafspraak of pakketprijs vereist een nieuwe controle.

Een gratis overname bewaart de bestaande opslaglimiet, ook wanneer geen pakket groot genoeg is. Een expliciete limiet van 0 blijft onbeperkt; een onbekende, geërfde limiet moet eerst worden opgehelderd. Er wordt een expliciete gratis afspraak met prijs nul vastgelegd. Bij maandfacturatie moet een actief aangeboden pakket minstens de bestaande limiet én de opgeslagen hoeveelheid data kunnen dragen. De bestaande betaalafspraak van het bedrijf moet maandfacturatie toelaten; beheerdersrechten omzeilen geen betaling vooraf. De afspraken beginnen vandaag en lopen mee op de bestaande maandelijkse bedrijfsfactuur. De overname maakt geen afzonderlijke directe factuur aan.

API-controle

Het bedrijf in het URL-pad is de huidige beheercontext. account_id in de input is het expliciete doelbedrijf en mag daarvan verschillen. server_id is een bestaande mailserver, met een gedeelde serverbinding of een exacte private binding aan dat doelbedrijf.

Gebruik bij voorkeur POST /api/v1/accounts/{context}/admin/workspace/adoptions/inspect, met JSON:

{
  "account_id": 123,
  "server_id": 17,
  "domain": "example.test",
  "name": "Voorbeeld Workspace",
  "mailboxes": ["alice", "bob"],
  "billing": "none"
}

Deze POST is uitsluitend een controle. Er is geen Idempotency-Key nodig en er wordt geen operatie, facturatie of leveranciersmutatie aangemaakt. Voor kleine selecties bestaat ook GET .../adoptions/inspect met dezelfde velden als queryparameters; gebruik JSON voor grote selecties. De inspectie is begrensd tot 1.000 accounts, met pagina’s en object-reads van maximaal 100 en maximaal 2 MiB per leveranciersantwoord.

Het antwoord bevat data.input, snapshot_version, reviewed_at, expires_at, het expliciete bedrijf en de server, de geselecteerde leveranciersidentiteiten, de huidige en toekomstige quota, system_mailbox en de maandprijzen exclusief btw in EUR. De ETag is dezelfde momentopnameversie. Bewaar de goedgekeurde input en toon deze vóór bevestiging aan de beheerder. Leverancierssleutels, wachtwoorden en ruwe leveranciersantwoorden worden niet teruggegeven.

Bevestigen en herstellen

Stuur POST /api/v1/accounts/{context}/admin/workspace/adoptions, met de ongewijzigde data.input, aangevuld met reviewed_at en een nieuw intent_id (UUID). Stuur de momentopname-ETag in If-Match en een duurzame Idempotency-Key. intent_id identificeert dezelfde gecontroleerde lokale overname; bewaar deze bij een onduidelijk antwoord. Een andere body onder hetzelfde intent-ID wordt geweigerd. Ook een herhaalde bevestiging met een andere HTTP-idempotentiesleutel retourneert de oorspronkelijke lokale overname en taakintentie, zonder extra mailboxen of afspraken.

dry_run:true controleert dezelfde actuele voorwaarden zonder lokale koppelingen, afspraken of taken aan te maken. Een succesvolle bevestiging geeft workspace_id, account_id, domain_id, task_ids, task_intent_id, de maandprijs en facturatiekeuze terug. De lokale ontvangstregistratie en API-operatie worden in dezelfde database-transactie vastgelegd. Volg de oorspronkelijke operatie; maak bij een verloren antwoord geen nieuwe overname aan.

De gewone portaalworkers verwerken daarna de gekoppelde configuratie. Alle via de API aangemaakte taken dragen de oorspronkelijke expliciete beheermachtiging voor dit Workspace. Ingetrokken rechten blokkeren die taken. Gebruik het bestaande Workspace-beheer opnieuw goedkeuren-contract voor dezelfde operatie en dezelfde taakintentie nadat een actuele beheerder de blokkade heeft beoordeeld. Er wordt daarbij geen nieuwe overname of factuur aangemaakt.

Gegevens die eerst moeten worden opgehelderd

Een leveranciersidentiteit die al aan een Workspace is gekoppeld, wordt nooit opnieuw toegewezen. Gebruikers met beheerdersrollen, afwijkende rechten, groeps- of tenantbindingen, aangepaste aanvullende quota of uitgeschakelde/vreemde aliases vereisen een afzonderlijke expliciete migratie. Een domein met zelfstandige postmaster, abuse of mailer-daemon-accounts of verdeelde systeemadressen vereist eerst reconciliatie. Als gewone mailboxaliases deze systeemadressen al ontvangen, blijft dezelfde geselecteerde mailbox de systeemmailbox. Een bestaande catch-all moet verwijzen naar een mailbox die tegelijk wordt overgenomen.

412 betekent dat de controle is verlopen of de goedgekeurde gegevens zijn veranderd. 409 betekent dat een identiteit, serverbinding, quota of betaalafspraak niet veilig kan worden overgenomen. Bij ontbrekende sterke verificatie moet de beheerder opnieuw met de passkey verbinden. Verander geen pakket of betaalafspraak uitsluitend om een weigering te omzeilen.

CLI

Sla het bovenstaande invoervoorbeeld op als privébestand (0600 op Unix). De getypeerde opdrachten gebruiken dezelfde portaalservice:

binadit admin workspace adoptions inspect --from-file adoption-input.json \
  --file adoption-review.json --account 1
binadit admin workspace adoptions commit --from-file adoption-review.json \
  --confirm-company 123 --account 1 --yes --no-input

De eerste opdracht maakt alleen een nieuw privébeoordelingbestand aan; bestaande bestanden worden nooit overschreven. Het bestand bevat de exacte selectie, portaal- en beheercontext, momentopnameversie, oorspronkelijke intent en HTTP-idempotentiesleutel. Het bevat geen wachtwoorden, leverancierssleutels of gecachete prijzen. De CLI toont de werkelijke serverbeoordeling en leest vóór een normale bevestiging de huidige quota en prijzen opnieuw bij het portaal. Met het oorspronkelijke reviewed_at blijft dezelfde momentopname controleerbaar; een gewijzigde HMAC stopt vóór de bevestiging. Deze optionele tijdparameter geeft uitsluitend een nieuwe leescontrole binnen dezelfde tienminutengrens en verlengt geen goedkeuring.

Nieuwe Rust-beoordelingen hebben schema binadit-workspace-adoption/v2 en bewaren de publieke persoonlijke original_principal_id uit /me, met hetzelfde token als de inspectie. De uiteindelijke POST vereist dezelfde aantoonbare verbinding en gebruikt het token dat op dat moment is gecontroleerd. De oorspronkelijke privébeoordeling en het exclusieve duurzame verzendkenmerk worden na authenticatie, vlak vóór verzending en vóór resultaatweergave gecontroleerd. Het kenmerk bewaart alleen vaste publieke intentmetadata en de ondoorzichtige serverbeoordelingversie. Het bevat geen vrije notities of beoordelingsinhoud. Een onduidelijk antwoord houdt deze oorspronkelijke aanvraag vast; een volgende normale opdracht stopt vóór een nieuwe leveranciersinspectie.

Een bevestigd lokaal ontvangstbewijs betekent dat de Workspace, afspraken en taken atomisch zijn opgenomen. Het betekent niet dat de workers al klaar zijn. Rust toont dit onderscheid met local_adoption_confirmed, synchronization_status, synchronization_complete en de veilige oorspronkelijke operation. Een normale API-bevestiging kan queued of running teruggeven. Met commit ... --wait --timeout 5m leest de CLI uitsluitend die oorspronkelijke operatie totdat zij klaar is of aandacht nodig heeft. Een timeout of geblokkeerde taak verwijdert het verzendkenmerk niet en start geen nieuwe overname.

--confirm-company is het echte doelbedrijf, terwijl --account de beheercontext blijft. In automatisering zijn zowel de exacte bedrijfsbevestiging als --yes vereist. Een proefuitvoering met commit ... --dry-run voert de actuele controles uit zonder overname of duurzame HTTP-intent. inspect ... --dry-run maakt ook geen beoordelingsbestand aan en claimt geen verificatie van schrijfrechten.

Bij een onduidelijk antwoord blijft het oorspronkelijke bestand bewaard. Onderzoek de oorspronkelijke operatie. Alleen een expliciete herstelopdracht herhaalt dezelfde oorspronkelijke aanvraag met dezelfde selectie en dezelfde HTTP-sleutel:

binadit admin workspace adoptions commit --from-file adoption-review.json \
  --confirm-company 123 --recover --confirm-intent OORSPRONKELIJK-UUID \
  --account 1 --yes --no-input

Deze opdracht kan de oorspronkelijke goedgekeurde overname afmaken of het eerdere resultaat teruggeven. Ze kiest geen nieuwe prijs of intent en wordt nooit automatisch uitgevoerd na een netwerkfout. Beoordeel een nieuwe selectie met een nieuw bestand wanneer er nog geen oorspronkelijke aanvraag is geweest. Voor Rust moet ook herstel de aantoonbare oorspronkelijke persoonlijke verbinding behouden. Een gewone tokenvernieuwing verandert die principal niet; expliciet opnieuw inloggen wel. Een oude beoordeling zonder vastgelegde principal of een andere actieve verbinding wordt niet voor een oorspronkelijke POST overgenomen. Bewaar de oorspronkelijke beoordeling, UUID, sleutel en operatie voor beheerderonderzoek; wijzig geen opgeslagen principal en maak geen nieuwe overname om een onbekend resultaat te omzeilen. De algemene herstelbeperking voor andere API-functies blijft afzonderlijk van dit overnamecontract bestaan.

--from-file - leest vertrouwde stdin. Op Windows wordt invoer via stdin vereist; de CLI doet geen aannames over de privé-ACL van een bestaand invoerpad. Het uitvoerbestand wordt met de bestaande privébestandsfunctie voor het platform aangemaakt. Startgids voor AI-agents en Workspace-beheer beschrijven de overige context-, versie- en herstelregels.

Bronnen en verificatie

De adapter gebruikt de bestaande Stalwart-configuratie van het portaal en de gedocumenteerde Account-objecten en Domain-objecten. Verplichte volledige querytellingen, query-state, exacte object-ID’s en correlatietags worden gecontroleerd; een onvolledig of onbekend leveranciersantwoord wordt geweigerd. De repository bevat daarnaast de oorspronkelijke Stalwart 0.16-contractprobe in het naastliggende Workspace-project; die muterende probe wordt niet automatisch uitgevoerd.

Op 29 oktober 2026 bevestigde een uitsluitend leesproef op de bestaande geconfigureerde productie-mailserver deze antwoordvorm: vijf vaste JMAP-queries/gets met limit:1, calculateTotal:true, maximaal 2 MiB per antwoord en zonder redirects. Query-state, positie, totaaltelling, exacte GET-identiteit en expliciete rol-/rechtenvelden hadden het vereiste type. De uitvoer bevatte alleen booleans, typen en paginagrootte; er werden geen sleutels, object-ID’s, namen, adressen of leveranciersantwoorden weergegeven. Dit controleert protocolcompatibiliteit en bewijst geen uitgevoerde productieovername.