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.

Inspect an original operation after reconnecting

Keep the original company account, public principal_id from GET /api/v1/me, HTTP method, exact API path, JSON input, idempotency key and any returned operation ID before submitting a change. An expired access token can be refreshed within its existing connection. A new personal login creates a different API principal and therefore a different mutation replay namespace. Sending the old change with that new connection can create a second action, even when the key is unchanged.

After an uncertain response, inspect the original operation. Do not automatically submit the mutation again under a new connection or generate a replacement key. A failed or missing response can follow an accepted supplier request, charge or email. failed does not prove that no effect occurred.

A running HTTP request is not a completed request

The API exposes operation.request_status as the original durable HTTP request state: running, succeeded or failed. operation.status can instead describe the delivery of its background tasks. A successfully accepted order may have request_status: succeeded while delivery is queued, running or awaiting_payment. Inspect or watch that same operation for delivery; do not create a replacement order merely because provisioning is still pending.

The Rust CLI retains the original automatic pending key and exits with code 6 when a mutation returns HTTP 202, an uncompleted request state, or an explicit request/billing review marker. Partial or mixed HTTP success responses also remain held. It prints no successful result in these cases. Repeating the exact command under the same connection preserves the same key; it cannot turn a still-running replay into another accepted mutation. Only a later confirmed request receipt, or the explicit read-only acknowledgement described below, clears that pending record. A different connection still follows the original-principal inspection rules below and never resends the mutation automatically.

When request_status is explicitly succeeded, a later background failed, requires_approval, requires_reconciliation, cancelled or cancelling delivery state does not undo that accepted HTTP request. The CLI preserves and displays the delivery status; it does not assert that the worker or supplier finished. Inspect the same original operation and use its documented recovery or cancellation procedure. Explicit reconciliation flags on the request result still keep its local pending key held.

For older API responses without request_status, a terminal succeeded receipt or an accepted queued/awaiting_payment receipt on HTTP 200/201 remains compatible. An ambiguous legacy running state stays held. Malformed receipt metadata exits with code 1 and also retains the original key. Read-only catalogued inspection requests may display original running metadata; this does not confirm or re-execute that original mutation. Such inspections allocate no new mutation key or pending write record; omit --idempotency-key. One-time email proofs and protected credential delivery retain their separate documented rules.

Read-only recovery API

POST /api/v1/accounts/{account}/operations/original-receipt performs a SQL-only lookup of one proven original personal request. It sends no supplier request, creates no operation, and returns no historical result, secret, payment URL, mail token or provider error. It requires no new idempotency key. The {account} is the original canonical positive numeric company ID.

Use a current personal connection belonging to the same person, company and identity-security generation. It needs operations:read, the original action's current scope and company role, unrestricted resource access, and recent passkey or authenticator verification under the current company policy. Administrator actions also require current administrator authorization and the administrator API flag. An integration or a different administrator cannot adopt another person's receipt. Disabling new API writes does not prevent this read-only inspection, provided the API and required sensitive preview are available.

The JSON body has exactly this structure. The UUID and key below are synthetic; use the captured originals. Send JSON using a protected input file or standard input. Never put secrets in command arguments, URLs, shared logs or chat.

{
  "original_principal_id": "user:11111111-1111-4111-8111-111111111111",
  "original_key": "captured-original-idempotency-key",
  "request": {
    "method": "PATCH",
    "path": "/api/v1/accounts/42/admin/companies/83",
    "body": {"company_name": "Reviewed company name"}
  }
}

Supply the same method (POST, PUT, PATCH or DELETE), canonical full path and complete original JSON object. Preserve original types, nested fields, empty strings and opaque secret bytes. Newly submitted JSON API mutations do not trim values or convert empty strings to null. Query parameters, encoded path aliases, leading-zero company IDs and trailing slashes are refused for new mutations. The original request fingerprint uses the existing keyed canonical JSON algorithm; it is not a claim that historical If-Match headers were verified. The lookup applies the same framework input normalization policy as the original endpoint without dispatching that endpoint.

An original secret-changing request requires its original secret input to match the keyed fingerprint. The lookup does not return or persist that input. If the original input is unavailable, stop for operator review; do not infer it or use a new password as recovery evidence. Ordinary API bodies retain their 1 MiB limit. The Book image endpoint retains its existing 3 MiB JSON limit, and this lookup permits a 4 MiB envelope to carry that original input plus bounded metadata.

A successful response contains data: null, the original operation's ID, company, action, status and timestamps, plus these receipt fields:

An original queued order can have a succeeded HTTP request while provisioning or billing still needs review. Keep using the original task/order-specific status and reconciliation workflow. This endpoint never reapproves tasks, repeats billing, sends mail or clears a supplier hold.

404 original_receipt_unavailable covers missing historical provenance, different identity or epoch, mismatched original input, and unreadable or altered evidence. Preserve the original metadata for operator inspection. Do not treat 404 as permission to repeat an action. A 401/403 requires correcting current authentication or authorization; it does not change the historical outcome. 503 operation_receipts_unavailable means the server's receipt schema needs installation. A new mutation is refused before execution if that schema is absent; existing exact-key replay and previews remain available.

Evidence and release boundary

For newly allocated operations, the server atomically commits encrypted original actor, identity generation, scope ceiling and catalog-route evidence with the durable operation, before executing the action. A keyed binding covers the company, principal, operation, original key hash, request fingerprint and actual business action. Legacy operations are never silently backfilled using the current caller's identity. The evidence does not make arbitrary database rollback or full server compromise safe.

The native Rust CLI records a permanent private binding for each mutation key before submission, including a key supplied with --idempotency-key. It binds the configured endpoint, exact company, method, path and authenticated public principal obtained with the same bearer used for dispatch. A refreshed token is checked against that original principal; a new login cannot silently adopt an old key. A successful request does not erase this permanent key binding. A service connection cannot use the personal recovery API.

Automatic pending requests use a separate versioned private record. Only one unresolved automatic request is allocated per profile, endpoint, method and path. Neither its filename nor its contents include a digest of passwords, DNS values, private notes or other request values. Changing input while an original request is unresolved does not allocate a replacement key: the server still requires its original exact request fingerprint. Legacy unbound pending records, malformed/expired records and changed private files remain held for review. Never delete them merely to make a command continue.

Ordinary CLI mutations encountering a new personal connection inspect the original receipt and stop with exit code 6. Only validated original metadata is described on stderr; historical results and provider details are not printed. The automatic pending request stays in place. Workflows with their own protected reviews, such as registrar pages and service imports, retain their documented explicit recovery requirements and never switch their original mutation to the new connection. One-time credential exports also keep their original delivery/consumption journal; reconnecting does not reissue or reconsume a secret.

Explicitly acknowledge a succeeded automatic request

After reviewing the original succeeded HTTP request, use the generic api command with the original method, path and protected JSON input, adding the exact original operation UUID. For example:

binadit api /admin/companies/83 --method PATCH --account 42 \
  --from-file /private/original-request.json \
  --confirm-original-operation 33333333-3333-4333-8333-333333333333

The company, endpoint and profile must select the existing automatic pending request. This performs only the authenticated SQL receipt lookup. It clears that one automatic pending record only when the exact original UUID matches, the HTTP request succeeded and reconciliation is not required. It prints safe original metadata with receipt.local_pending_resolved: true, exits successfully, and stops. It does not perform --wait, POST the original action, create another key, or assert worker completion. No extra --yes is needed for this read-only acknowledgement.

The acknowledgement checks the enabled read-only original-receipt capability, so a maintenance flag disabling new mutations does not prevent it. Without the acknowledgement flag, a disabled original mutation capability keeps the ordinary command held; use the documented read-only inspection or acknowledgement rather than enabling writes to recover.

The flag is rejected before network access on typed commands, reads, login, previews, explicit-key requests, invalid UUIDs or a route without an existing automatic pending request. A failed, running, missing, foreign or reconciliation receipt never clears the pending record. Acknowledging again after the pending record was cleared is refused without a request. The permanent original-key binding remains in place.

For this acknowledgement only, protected JSON input may be up to 3 MiB so the original Book image request fits the 4 MiB server lookup envelope. Normal generic JSON input remains limited to 1 MiB. Preserve original opaque bytes and types. If the original input is unavailable, use operator review rather than inventing replacement input.

Stop after acknowledgement. A later ordinary invocation can express an intentional new change and allocate a new automatic key; do not run it as a recovery retry. For an explicit idempotency key, the permanent original-principal binding prevents that key from being submitted under a new connection even after a prior success. Public binary distribution still requires the complete Rust parity/security release gate and production rollout checks.

Contract for users and AI agents

1. Capture the original identity and intent before the first mutation; keep secret input private.
2. Inspect the original operation after uncertainty. Refresh the same connection when possible.
3. After a new login, use only the verified original-receipt or documented service-specific read-only recovery workflow. Do not POST the original mutation as a probe.
4. Treat failed, running, missing or reconciliation outcomes as unresolved. Never allocate a replacement order or infer no charge, no mail or no supplier change.
5. Treat a succeeded receipt as request metadata. Confirm actual task, billing or service completion through its original workflow before reporting completion.

For capability mail, follow the team invitation rules. Registrar paging has a separate original-step receipt; its run UUID and review contract remain required.

Explicit Workspace DNS application

POST /api/v1/accounts/{account}/workspaces/{workspace}/domains/{domain}/actions/apply-dns requires the domain's current If-Match, workspace:write and the normal original request key. It now queues an original DNS-only task: the response contains delivery_status: queued and task_ids. A succeeded HTTP receipt confirms that the task was stored; it does not mean the provider has already changed.

The approval freezes the complete current portal zone projection, the actual company, domain and Workspace/mail/Drive/Conserio server versions, provider source and original HTTP evidence. It preserves unrelated DNS records, literal TXT bytes, the customer's SPF mechanisms and TTL policy. The worker uses the portal's canonical DNS journal and history, outside SQL transactions. It rechecks the original connection's current rights before each supplier request. Changing a zone or service configuration does not silently replace this review.

The existing typed CLI command uses the same API contract:

binadit workspace domains actions run 8 apply-dns --workspace 4 --account 123 --version DOMAIN_ETAG --dry-run

After reviewing the current domain and its intended records, replace --dry-run with --yes to queue the actual original task. A preview allocates no task or mutation key.

Keep the original operation and task IDs. Inspect their existing operation/task status; an unresolved or failed domain task blocks a replacement request, including a request with a new key. A lost supplier reply keeps its original journal and is reconciled against that original intent; it never justifies a second PATCH. Revocation, changed ownership, unreadable original evidence or an unknown outcome requires the documented original-task review/reapproval flow. Do not remove a task or create another intent to bypass its hold.

The API contract above covers the explicit DNS-only action. Automatic native domain provisioning and ongoing maintenance require their own reviewed service-purpose authorization; older unattributed tasks are not silently adopted by this action.

DNS buttons in the portal

The Workspace DNS settings show current and required values with a status for every required record, including when the legacy DNS cache is empty. With current DNS permissions, choose Fix record or Fix all records. The latter repairs missing and conflicting required records while preserving unrelated records. The displayed comparison is the review; ordinary saves do not add a separate confirmation page or repeat a passkey check during a valid browser session already authenticated with a user-verified passkey or authenticator. Record values are derived by the server; forms cannot submit arbitrary DNS names, values or another company's zone. Demo customers can inspect their retained platform-managed domain but cannot edit it; only a currently authorized platform administrator can repair it. GET .../domains/{domain}/dns-status and binadit workspace domains dns status also expose the read-only records list (name, type, current, expected, status). Status is ok, missing or mismatch; reading it grants no write permission.

The browser retains one original UUID for the current person, identity generation, company, Workspace and domain. A lost response preserves this UUID and the original review versions. Background checks inspect only SQL task/journal status; they never send a replacement POST or a supplier request. A different record choice remains blocked while its original is unresolved. A stale review may return preparation_rejected: true with a signed, cancelled, non-dispatchable original task; only this exact terminal receipt or a verified completed DNS journal releases its browser marker. A missing task or a failed status request never proves no change occurred. Reload the page after a rejected review.

Expired human approval holds the original task. Renew it explicitly using the portal's original-task approval card or the existing CLI bridge:

The complete DNS comparison and typed workspace-create / conserio-set purposes require CLI 0.1.0-preview.20261104.1 or newer. Update an older CLI from the download page.

The typed commands also accept the workspace-create and conserio-set purposes emitted by the current Workspace/domain bridge. They preserve the exact original Workspace, target company, subject and intent. This does not add shared-mailbox or collaboration subjects to that bridge; use those workflows for their own originals. Unknown purposes remain refused.

binadit workspace portal-approvals get WORKSPACE ORIGINAL_UUID --account ACCOUNT
binadit workspace portal-approvals reapprove WORKSPACE ORIGINAL_UUID --account ACCOUNT --version WORKSPACE_ETAG --confirm-workspace WORKSPACE --target-account ACCOUNT --yes

The action is domain-dns. Reapproval retains the original task, approved records, source, journal and actor. API renewal adds a real revocable personal connection; revoking that connection stops subsequent supplier requests. Independent signed DNS-only tasks for other domains can remain held: renewing one original does not reveal, renew or dispatch those tasks. Other Workspace maintenance and billing grouping restrictions remain in force. Switching company context requires reloading the review; a form rendered for another company is refused before allocation.

DNS task completion confirms publication of its approved records. Domain onboarding, certificate issuance, mail cut-over and automatic ongoing maintenance remain their separate workflows; this action does not silently approve them. Agents must inspect the original task's terminal proof and retain all unresolved originals rather than clearing browser storage or generating another UUID.

SQL-only inspection of an original browser approval remains available to the same strongly verified human through a newly connected read-only personal token while new API writes are disabled, provided that person still has the original write privilege. It does not renew a job or grant supplier authority. The sensitive API feature must remain enabled for this inspection; an explicit shutdown blocks both inspection and renewal. Renewal always requires a current write-enabled connection.

When API writes are disabled, OAuth intentionally omits disabled write scopes from a newly issued connection. SQL-only original-receipt inspection still works with operations:read, current strong verification, the same original person/company/identity generation, the verified original scope ceiling and the person's current native write privileges. This maintenance exception does not add a scope to the new token or authorize any action. With writes enabled, the current connection must still contain the original action's scope.