Exchange is excluded from this API/CLI release. Any historical Exchange API or CLI example in this guide is unavailable; native portal behavior is outside this exclusion. See current release scope.

Workspace administration

This guide covers the implemented platform operations for internal Binadit administrators: inventory, temporary suspension, resumption, Conserio synchronization and explicit reapproval of authorization-held work. Customer service changes, purchases, cancellation and permanent deletion have their own workflows. Company transfer uses the separately reviewed workflow below. Adoption has its own explicit administration workflow.

Connection and company selection

Use a personal human connection with admin:read and admin:write. Add operations:read to inspect and watch asynchronous results. Service credentials cannot perform platform administration. Your current identity must be a verified internal administrator, your administration company membership must still be active, and the connection must have a verified passkey authentication less than five minutes old. API, writes, sensitive access and administration must be enabled by the server. A resource-restricted grant cannot administer another company.

Two company IDs have distinct meanings:

• --account / the URL's {account} selects the company associated with your personal administration connection.
• --target-account / body target_account_id explicitly confirms the Workspace's actual current customer company.

An administrator can manage another company's Workspace without being added to its team. The server checks the Workspace's actual ownership; changing the target ID cannot redirect an existing approval. The target company must be active and unblocked. Administration creates no customer membership, purchasing authority or billing agreement.

API contract

Every path below starts with /api/v1/accounts/{account}/admin/workspace/workspaces.

Inventory does not contain passwords, server keys, Conserio Drive credentials or raw provider errors. The ordinary suspension, resumption, synchronization and reapproval actions require If-Match with the current Workspace ETag, an Idempotency-Key, and an exact JSON body:

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

For reapprove, include original_operation_id as a UUID. Read and review the current Workspace again before approving. The platform endpoint only accepts its own original Workspace administration operations. Customer purchase reapproval cannot promote an order into platform authority.

Conserio synchronization reapplies the current portal settings, including enabled state, user access and retention. Review the returned retention metadata before approving; applying a shorter configured retention can remove older supplier data. This action does not change the configured retention or its paid package.

Use X-Binadit-Dry-Run: true to validate current permissions, ownership, version, state and prerequisites without changing portal rows, creating an operation or contacting suppliers. A preview does not reserve the Workspace; those checks run again for the actual change.

CLI examples

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

Use resume or conserio-resync in the same position. CURRENT_ETAG means the exact current value returned by get; do not reuse an old value after another change. The CLI retains the durable mutation intent, applies its normal company and capability checks and never obtains a provider key.

Watch the returned operation with binadit operations watch OPERATION_UUID --account 1. An accepted request means work is queued; the supplier result follows asynchronously. A watch timeout does not cancel work.

Preconditions and recovery

These actions change access or synchronization, never billing. Temporary suspension does not cancel paid services or stop recurring charges. Resume cannot lift an outstanding invoice suspension: resolve the original invoice and payment reconciliation first. Uncertain legacy agreements also require reconciliation before resume. Deleting or unknown Workspace states are refused.

Existing pending, held, running, waiting, failed or unknown-status work for this Workspace or its children prevents another ordinary administration action. Inspect that work first. These endpoints never silently replace another payment or approval. Workspaces with more than 1,000 mailboxes or domains require a separately reviewed bounded operation.

Queued platform approval is fixed to the original company, Workspace, action and administration grant. The worker rechecks current authority before execution and each HTTP dispatch, including retries. Revocation, demotion, company changes, changed task bindings or expired passkey proof hold remaining work before another supplier request. Already accepted supplier effects remain possible; holding work is not a rollback.

When an original platform operation reports requires_approval, reconnect with a recent verified passkey and inspect the same operation and Workspace. Then:

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

This keeps the existing tasks and original intent, creates no invoice and does not repeat a completed task. A moved Workspace, changed desired action or non-platform task must be reconciled through its own workflow.

Automation and AI agents

Discover capability availability and the current OpenAPI contract before writing. Confirm both company IDs and the exact Workspace ID; global read access does not make the selected administration context the resource owner. Fetch a fresh version, preview the intended action and submit one durable intent. Poll that operation. On an ambiguous HTTP result, reuse the same intent or inspect the original operation; do not manufacture another approval.

Stop on 412 and fetch/review the new version. Stop on workspace_work_pending and inspect existing work. For requires_approval, obtain a new human passkey authorization and use the explicit platform reapproval endpoint. For requires_reconciliation, preserve the original operation and ask an operator to establish the provider outcome. Never interpret temporary suspension as cancellation or payment authorization.

Transfer a Workspace to another company

The portal offers Transfer Workspace in Workspace settings and a bounded selection of at most 20 Workspaces in the overview. Selection is read-only. Verify your passkey, choose the actual target company, review each Workspace’s price and type its exact number to confirm it separately. Completing one Workspace does not silently confirm the rest. After a lost response, resubmitting the same reviewed confirmation returns its existing receipt.

The transfer preserves the company on all original invoices, historical billing items and corrections. Unbilled periods through yesterday remain payable by the original company. The old monthly item ends yesterday; a new item starts today (or its original future start). Existing end dates and prepaid coverage remain intact. The target receives only future responsibility. Registered domains keep their independent registrar ownership and yearly billing: use the domain administration workflow to transfer those separately. There is no immediate invoice, payment, password reset or DNS write.

An existing paid service keeps its agreed monthly price. start_billing: true converts free services to paid future services at the existing contract price; it does not reprice from the current catalogue. Services stay free for an internal target company. Paid transfers require the target’s normal monthly invoice policy or a verified automatic-payment mandate and EUR. Administration cannot override a pay-first policy. Dedicated servers must already be bound to the target company or be shared.

{"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

Add --start-billing to both review and confirmation only when deliberately converting free services. A changed company, contract, resource or date invalidates the signed plan. On 412, inspect and approve a fresh plan. Unpaid or uncertain company invoices, refunds/chargebacks, unresolved child tasks, invoice suspension, active/uncertain legacy agreements or ambiguous billing items block transfer. Resolve the original agreement instead of moving responsibility to bypass it.

The committed receipt is atomic with ownership, future billing items and the native synchronization task. SQL company claims serialize it against monthly invoice planning; a process crash leaves a fail-closed claim for the documented operator recovery. Supplier synchronization runs asynchronously and uses v2 platform authority fixed to the new actual company and original administrator grant. Watch the returned operation. If authority expires, use the common reapprove command with that original transfer operation, the Workspace’s new current version and --target-account equal to its new owner. Reapproval creates neither a second transfer nor another bill. Completed historical dependency proofs can follow only a verified immutable ownership chain; unfinished purchases never change company implicitly.

For AI agents: show both old and new companies, effective date, exact future monthly amount, free-to-paid choice and preserved unpaid history before committing. Keep the original plan, request body, idempotency key, operation ID and transfer receipt together. Do not rewrite billing item account_id, invoice ownership or worker payloads directly. A locally committed transfer is distinct from confirmed supplier synchronization.

Rust CLI validation and asynchronous results

The Rust handlers preserve the separate administration connection (--account) and actual customer binding (--target-account). They validate the exact Workspace, current version, original operation and requested action before accepting a receipt. List pagination preserves native integer IDs, including values larger than JavaScript can represent exactly. Nullable or zero legacy metadata never grants authority to another company.

Transfer review shows typed item coverage and checks the exact decimal monthly total, free-item choices and preserved history. Confirmation sends the reviewed plan version, Workspace version, target company, free-to-paid choice and decimal amount unchanged. A successful local transfer receipt confirms local ownership and future billing responsibility; it does not claim that supplier synchronization has finished.

Use --wait on a mutation to follow only its returned operation. Polling renews ordinary access tokens as needed, returns bounded safe status metadata and never repeats the mutation. A timeout leaves the server operation running; resume with binadit operations watch ORIGINAL_OPERATION_UUID --account ADMINISTRATION_ACCOUNT. Read-only inventory, resource reads and transfer-plan review do not turn --wait into another action. An unexpected account, resource, action, price or history flag retains the original request intent for investigation.

The general personal relogin recovery boundary remains a separate release requirement. Preserve the original connection, request intent, signed plan and receipt; do not adopt an unbound legacy request or create another transfer to bypass an uncertain result. No public Rust CLI release is activated by this source checkpoint.

Browser Workspace settings and synchronization

The Workspace page uses the same native queue for changing the displayed name, suspending or resuming access, and synchronizing Drive or Conserio. The page reuses your valid passkey or authenticator login according to the current administrator and company sign-in policy; ordinary submission does not require the same factor again. Name changes and Drive synchronization require current Workspace write permission. Suspending, resuming and Conserio administration require the current internal administrator role. Impersonation cannot approve these actions.

Each form carries the version you reviewed and an original intent UUID. A changed Workspace requires a fresh page review. The short local transaction commits its desired state and original synchronization tasks together; it sends no supplier request and creates no order or invoice. An unresolved earlier task blocks a new action. A billing suspension can only be lifted through the original payment/reconciliation process.

Maintenance and original-task reapproval forms also retain the company context in which they were displayed. Switching companies in another tab requires reloading and reviewing the form; an old form cannot silently approve its action in the new context. Missing or mismatching context is refused before new work is allocated. For agents maintaining the native adapter, preserve the rendered context_account_id along with the reviewed version and intent; never replace it with the current session value during submission.

Queued browser tasks carry a signed v3 approval containing the original actor, identity generation, company context, Workspace, desired name/status and a supplier-source signature. This is a browser approval, not an OAuth session or a new API key. Turning API feature flags off does not disable normal browser administration. Workers check current identity, membership, permissions, company status, supplier source and the original strong authentication, including immediately before each canonical HTTP dispatch and again after any database wait. Each queued row and its full immutable payload have a separate task-ID-bound signature, so copying the original approval cannot authorize another task or additional input. Native child synchronization tasks receive their own signatures within a short local transaction. The approval lasts five minutes; withdrawal or expiry retains the original tasks on hold instead of reporting success or allocating replacement work.

To resume an authorization-held browser action, open Workspace → Settings, review the displayed original action and UUID and choose Approve original tasks again. A valid passkey or authenticator login in the same browser session supplies identity verification according to current company policy without another ceremony. Only the original person in the original company context may approve it. This explicitly renews the finite approval on the existing task IDs and retains their existing progress; it preserves the actual authentication timestamp and creates no new synchronization intent, order or invoice. New native passkey and authenticator approvals carry their own signed issued_at; older approvals retain their original expiry. Changed supplier bindings or changed desired state require operator reconciliation and cannot be adopted by this button. Other pending work must finish or be reconciled first. Original API tasks use the original-operation reapproval commands described above; original browser tasks can also use the explicit bridge below.

For other AI agents: never manufacture an OAuth grant from a web user or strip api_authority from a task to bypass a hold. Use WorkspacePortalChanges for the listed browser actions; WorkspacePortalApproval is the signed authority adapter used by ApiTaskAuthority v3. The v1 customer API and v2 platform API formats and their grant policies are unchanged. The native adapter also signs the explicitly supported workspace-create and conserio-set purposes and their bound provisioning tasks. The task purpose and exact subject determine the allowed action; an approval is never a general grant for checkout, password delivery or arbitrary paid apply payloads. Shared-mailbox and collaboration approvals use their own subject-specific workflows. Preserve each original approval and its corresponding DNS journal.

Browser maintenance also verifies that the reviewed local fields, each task proof, the retry status and its audit receipt were actually stored. A cancelled model event or mismatching persisted value rolls back the local change; it cannot return a successful approval with missing work. Reapproval retains the previous original hold if its renewed proof or retry cannot be persisted.

Renew original browser maintenance through the API or Rust CLI

Use the original browser intent UUID for this workflow. It is different from an API operation UUID. Sign in as the same person in the same original company context, with recent passkey or authenticator verification. A service integration cannot adopt a browser approval. The customer connection needs both workspace:read and workspace:write; it can inspect or renew name changes and Drive synchronization. Staff use the administration routes with both admin:read and admin:write, a current internal administrator role and a recent passkey. The administration connection's company and the actual Workspace company remain separate; no customer membership is created.

Inspection returns only Workspace/company/context IDs, original intent, action, current Workspace version, task IDs/statuses and billing_changed: false. It sends no supplier request and allocates no API operation or mutation key. It remains available when new API writes are disabled, provided the API, sensitive preview and current permissions remain available. It does not claim that a worker or supplier action finished.

For renewal, send the inspected Workspace ETag in If-Match, a stable new Idempotency-Key for this explicit renewal, and exactly:

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

The target company must match the original Workspace. Use the actual IDs; these numbers are examples. A dry_run: true preview validates the same review and does not consume a key or change tasks. Actual renewal requires enabled writes. It can resume only the same authorization-held original tasks, preserves their progress and supplier attempt evidence, and creates no order, invoice, payment or replacement task. Pending work from another intent, a changed name/status/source, an altered task signature, a different person/context or a stale Workspace version refuses renewal. A successful HTTP response means the existing local rows were renewed; follow those original task IDs for delivery.

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

Staff use binadit admin workspace portal-approvals get|reapprove with --account ADMINISTRATION_CONTEXT and the separately reviewed --target-account CUSTOMER_COMPANY. The two positional values are always the Workspace ID and original browser intent UUID. The commands reject invalid confirmations before authentication, preserve the full numeric IDs and print only validated public receipt fields. They do not support --wait; follow the original task IDs or inspect again.

After an API renewal, the signed maintenance approval also contains a binding to the real personal API session and its original scope ceiling. Worker checks retain current grant revocation, company policy, actor identity, source binding and the five-minute strong verification limit. No browser session is fabricated from API credentials. An explicit later browser renewal follows the browser's own current strong authentication rules; API flags remain independent of ordinary browser administration.

For AI agents: retain the original intent, context, Workspace version, reviewed target, renewal request key and returned operation/task IDs. Never submit another name change or resync to bypass a held task. On an uncertain renewal response, inspect the same original intent and API operation; preserve the pending key and follow the original-operation receipt guidance. A 409, 412, authorization refusal or malformed response is not permission to create replacement work. Never edit task payloads, remove connection_authority/task signatures, or substitute an API operation UUID for the browser intent.

Personal Drive cancellation and permanent purge

These customer operations use /api/v1/accounts/{account}/workspaces/{workspace}/mailboxes/{mailbox}. They use the company's current Workspace permissions rather than the platform administration paths above.

A purge body is {"expected_used_bytes":7000,"confirm_address":"ada@example.nl","understood":true}. Read the actual contents and confirm the company first; use the current mailbox version. The Rust CLI supports:

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

Remove --dry-run only after reviewing the company, address and current contents. A service connection may cancel an empty Drive when its actual current grant permits it; it cannot authorize a permanent purge. Native portal cancellation retains its original authenticated person, company context and identity generation throughout the request. A context switch or withdrawal of current permissions stops subsequent supplier calls.

Each accepted action retains one original Drive intent. The billing child, its supplier attempt and its exact public API checkpoint must be committed before a supplier mutation. A paid monthly period is retained; uncertain financial termination uses the same original financial child and supplier reads, without a second termination. An uncertain Drive attempt retains its attempt marker and is inspected rather than blindly sent again. Team folders and backup retention are unaffected by a personal Drive purge.

completion_verified: true means the signed original and its current local mailbox and billing projections agree. requires_reconciliation: true is a hold, including an unconfirmed allocated billing child. A known original supplier reply is retained privately even when the source or permission changes while the reply returns. Such a reply alone does not authorize publication through a replacement connection. Keys, immutable bindings, financial request bodies and raw supplier replies are not returned by status.

For users and AI agents: retain the original company, Workspace, mailbox, intent, API operation and financial child IDs. Read /drive-purge first. Do not clear a pending CLI request, change companies, substitute a provider connection, enable writes, or create a replacement purchase to bypass a hold. Existing controller recovery retains the original service intent; a later reviewed request is not proof that an earlier public request succeeded. The generic original-operation acknowledgement can clear an automatic pending request only after its exact public operation is independently confirmed as succeeded. If that original remains failed or running, preserve the pending request for operator review. Older intents without a verifiable signed receipt remain held and are never silently adopted.

Original API mail-server tasks

New API Workspace, domain and mailbox tasks retain a private signed original company, subject, routing and mail-server connection binding captured when the task is allocated. Private input hashes bind password and paid-change inputs without retaining their values in that source capsule; the existing handler can record only their exact one-way erasure. Before each actual Stalwart request, the worker checks that original source, the current real API grant and financial prerequisites. The SDK also checks the actual destination, method, credentials, exact JMAP body and transport settings. A grant withdrawn after a successful reply prevents the next request; the accepted reply is retained.

Tasks allocated before this source proof existed remain held. Do not edit their payload, copy a proof from another task, switch servers, or use a DNS agreement to authorize mail or certificate changes. The existing explicit task reapproval can renew the real grant for an already bound original task; it preserves the original source proof and adds a separately signed same-task renewal witness. It cannot adopt an unbound legacy task or a changed source. Users and AI agents must retain the original operation, task and intent IDs and inspect a hold rather than submit replacement work. Direct password-reset authorization and supplier acknowledgement checks are separate from this queued-task contract.

Direct mailbox password resets

The portal and API use the same immediate password-reset writer. In the portal, verify with your passkey or authenticator first, then choose Reset password on the current mailbox page. A stale page must be refreshed. The action checks your current company context, membership, credential permissions and original login identity again immediately before the actual mail-server request. It does not create a maintenance task, API connection or replacement login identity. Native portal resets remain available when the API is disabled.

For the API and Rust CLI, use a personal connection authenticated with the required passkey or authenticator within the previous five minutes, with both workspace.credentials:write and workspace.credentials:read for the exact Workspace. Read the mailbox and retain its ETag. Send an empty JSON object to POST /api/v1/accounts/{account}/workspaces/{workspace}/mailboxes/{mailbox}/actions/password-reset, with that ETag in If-Match and one durable Idempotency-Key. The typed CLI command writes the one-time result directly to a new private file; it does not print the password:

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

Choose a new destination in your private directory. Preserve an uncertain destination and its original request intent; do not delete it to force a retry. Never print credentials in shared terminals or save them in source control.

A successful reset requires one bounded, correlated positive acknowledgement naming exactly the intended mail-server account. A generic HTTP 200, an empty updated object, another account, an unrelated JMAP response or a timeout cannot prove success. The original encrypted rotation and its exclusive mailbox fence commit before any supplier request. Supplier calls run outside database transactions. Passwords, administrative keys and raw supplier error bodies are not exposed in failure responses.

The reset response contains a short-lived credential_claim_id, not the password. Consume it once through POST /api/v1/accounts/{account}/credential-claims/{credential_claim_id}/consume; the claim expires after two minutes and requires current credential-read permission and recent strong authentication. A repeated successful reset request with its original HTTP key replays its receipt without another supplier write. The portal's reset display is encrypted in its session, expires after two minutes, and is reauthorized before its single display. Changing company, withdrawing membership or replacing the login identity prevents disclosure.

If a supplier outcome is uncertain, preserve the original HTTP operation and its password_rotation_id. Its operation status requires reconciliation; another HTTP key cannot bypass the mailbox's durable fence. Do not retry the supplier request, change its account/server, clear a pending CLI request, edit journal rows or create a replacement reset. Ask the operator to inspect the original private receipt and actual mail-server outcome. There is no automatic resend or adoption of a legacy or uncertain reset. If the supplier confirmed the change but local publication failed, its private confirmation remains held; do not claim that the old cached password is current. If local publication completed but one-time delivery was refused, an authorized user can use the separately protected password-reveal flow after reconnecting with current strong authentication, without another reset. Revoking access after an accepted reply prevents delivery; it does not undo the actual remote password change.

Native domain catch-all

The existing catch-all form now requires current strong verification and the originally rendered company, Workspace, domain and selected mailbox versions. It queues a signed domain-catch-all browser approval for that exact existing verified mail domain. The worker performs only that catch-all change: it grants no DNS, account creation, certificate or financial work. API write flags do not disable this independently approved native operation.

An exact bounded supplier updated receipt confirms the original domain. After a missing or malformed reply the same task only inspects x:Domain/get; it never automatically repeats the write. If strong verification expires, explicitly renew the same original task through the native approval form or the existing personal workspace portal-approvals get/reapprove commands. A changed actor, company, domain, mailbox or mail-server source cannot adopt the original. Unbound old native tasks remain held; they are never upgraded with a DNS agreement or a fabricated API grant.

Native mail-domain provisioning

Adding a domain or choosing Check again reviews the current company, Workspace, domain version and mail-server source with your recent strong verification. The portal queues a signed domain-mail approval for that exact native operation. This remains available with the API disabled. The worker first requires public TXT ownership proof or the currently owned portal zone. It provisions only the reviewed mail domain and prepares its DNS records; it does not create mailboxes, modify DNS or change billing. Applying DNS requires its separate explicit DNS review. A later reviewed check can activate the domain after the actual public records match. Certificate requests remain marked as requested until their own outcome is verified.

Keep the original task and intent IDs. If verification expires, renew those same tasks through the native approval form or the personal workspace portal-approvals get/reapprove commands. A changed human, company, domain or supplier source cannot adopt the old operation. New API approvals and renewals still require their current API write permission; a native approval does not manufacture an API grant.

Mail-domain creation and certificate requests have durable independent attempted/confirmed receipts. A timeout, malformed reply, unknown create ID or older restored task state never permits another create. A known accepted ID remains private until an exact name check proves the original target. Recovery retains that same ID and may use read-only supplier checks; it never adopts another domain by name. An uncertain request remains held for operator inspection. Do not clear its receipt, submit a replacement domain, copy a proof or upgrade unbound old tasks. Existing mailbox creation, aliases and domain deletion are separate operations with their own approval requirements.

Mail-server synchronization receipts

Mail-server replies are bounded and matched to the exact original method and call tag. Account and domain writes require positive receipts for precisely the requested creation keys, updated targets or deleted IDs; an empty HTTP 200 is not completion. Supplier error text and transport exception chains are withheld because they can echo administrative credentials or a newly generated password. Preserve the original task after an uncertain reply. These checks do not grant a new approval, authorize a different supplier target or permit replay of an uncertain create. Native mailbox, alias and deletion approvals remain distinct from mail-domain and DNS approvals.

Native mailbox creation, settings, aliases and cancellation

The portal reviews the rendered company, Workspace and mailbox versions with current strong verification. Display name, primary address, extra aliases and blocking create a signed mailbox-mail operation for the exact existing mail account. Each review changes only its displayed fields; it does not buy a product, change quota, modify DNS or silently purge Drive. Confirmed mailbox changes also update that same existing Conserio user, preserving its role and the current original authority. Uncertain writes recover through an exact account read on the same original; they are never sent again because a task was restored or retried.

Direct mailbox and basket checkout use the existing payment and monthly-item flow under a separate signed mailbox-checkout approval, valid for 24 hours. Current issuer permissions, identity generation, company, product, original supplier source and payment remain required during delivery. An API token is not fabricated for native work. An uncertain account creation stays held; an exact retained creation receipt can finish its original local publication. Native operation does not depend on API availability.

Cancellation requires the rendered mailbox version and typed original address. The signed mailbox-cancel operation terminates each existing known billing agreement through the canonical financial child, preserves its identity and price, and keeps mail available until the reviewed paid end date. On that date it clears only the original reviewed catch-all references and deletes the exact original mail-server account. Separate durable witnesses prevent another catch-all or account mutation after a lost reply; recovery reads only the original provider target. Unknown billing or an unresolved checkout remains held. Personal Drive data requires its explicit existing purge flow first; mailbox cancellation never silently deletes Drive data.

Renew the same original through the native approval form or personal workspace portal-approvals get/reapprove commands. Keep its original task IDs and intent. Creation and cancellation cannot borrow a settings, mail-domain or DNS approval. Reapproval requires the actual same person, original company context, current rights and strong verification; the CLI does not allocate a replacement supplier intent.

Native password disclosure and creation displays

Viewing a stored mailbox password in the portal requires a valid current portal session, the actual current workspace manager, current credential permissions and compliance with the current company sign-in policy. A valid signed-in session does not require another passkey or authenticator check just to view the password. API and CLI sensitive-action authentication rules are unchanged. The server checks access again after recording the audit event and immediately before returning the secret. Passwords never enter that audit entry. Leave customer impersonation before using this action; an administrator can use their own identity and explicitly selected customer workspace.

Single and basket mailbox creation use the same encrypted one-time display as native password reset. The session stores ciphertext bound to the original user, identity generation, company context and mailbox, with a 120-second lifetime. Opening the display consumes it and rechecks current access and the current password. A stale, expired or withdrawn display is discarded. Batch displays retain every final verification deadline. Legacy plaintext password flashes are not rendered or copied into JSON. The JSON or page containing an authorized plaintext display is private and must not be cached.

The existing API credential-claim and Rust private-file delivery remain separate; a browser display is not a reusable API claim. Preserve original operation receipts when a reset or creation is held instead of submitting another supplier mutation.

Native mailbox packages and the existing Drive pool

Changing a mailbox package or enabling its Drive requires the rendered company, Workspace, mailbox, current monthly item and product versions plus current strong verification. The original mailbox-checkout task is stored before supplier delivery. A package change keeps the same monthly item and uses the existing pro-rata upgrade adjustment; it does not create an invoice or call the legacy agreement writer. Drive enablement binds the current verified company pool and its existing monthly item, and ends any compatible old individual Drive monthly item through the existing monthly billing flow. The worker checks the reviewed ledger, pool and current native authority before sending the quota or Drive request, outside SQL transactions.

As with the existing API billing guard, an active or uncertain legacy WeFact subscription must be reconciled before a package or pool change. It is not silently repriced or terminated. Ordinary known monthly items remain usable. Disabling Drive continues to use the explicit current empty-drive cancellation or purge flow; it does not queue an unapproved mailbox rewrite. Existing original-task inspection and renewal commands apply; no additional supplier command or replacement intent is required.

Services switched on with a new mailbox

A new mailbox can come with the services that exist per account, in the portal form ("Services"), the basket, and an API or CLI quote of kind workspace_mailbox (also inside an order batch):

Both are booleans and default to false. conserio_admin: true additionally requires workspace:write on that Workspace, the right the existing actions/conserio-admin action needs, next to orders:write and workspace.mailboxes:write. A quote is refused with 422 when a prerequisite is missing; at commit the prerequisite is checked again against the locked Workspace, so Chat switched off after the quote refuses the order before anything is billed or made.

Neither adds an invoice line. The mailbox is made first; its Drive is set by the same mailbox task, and the Conserio sync that follows a mailbox on the mail server sends the administrator role. Every account gets Chat, Meet and Book when they are on for the Workspace; those are not chosen per mailbox. Example input:

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