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](/developers/guides/release-scope?lang=en). # Service renewal and original-request recovery Hosting subscriptions, Exchange mailboxes and Spam filters use the same cancellation workflow in the portal, API and CLI. Cancelling stops renewal while preserving the recorded paid delivery period. Resuming removes the original scheduled cancellation within that period. A separate domain registration is reviewed separately; neither action sends a confirmation email. Read the exact service first. Review its current company, paid-until date and ETag. Confirm one original intent UUID and keep it together with the HTTP operation ID and cancellation receipt UUID. Current company membership, module permission, identity generation and applicable login verification are checked again at the actual accounting boundary. Ordinary service connections retain their existing scoped access; internal portal administrators need current passkey approval. WeFact resumes a subscription by clearing `TerminationDate`. That operation resets the supplier's invoice counter to zero. Automatic resume therefore supports only an explicitly verified unlimited agreement (`TerminateAfter=0`) with unchanged supplier ID, debtor, currency, start date, period, quantity and price. Finite or missing limits require reconciliation before resuming; a request boolean cannot approve different future financial terms. ## API Use these resource paths beneath `/api/v1/accounts/{account}`: | Service | Resource path | Permission | |---|---|---| | Hosting | `hosting/subscriptions/{id}` | `hosting:write` | | Exchange | `exchange/mailboxes/{id}` | `exchange:write` | | Spam | `spam/filters/{id}` | `spam:write` | `POST {resource}/actions/cancel` and `POST {resource}/actions/resume` accept `{"intent_id":""}` plus `Idempotency-Key` and `If-Match`. If omitted, the server operation UUID becomes the business intent. Supplying an explicit UUID makes it possible to inspect that same business intent after a lost response even if the client lost its original HTTP key. A different HTTP key with the same business UUID returns the original receipt and original resource projection; it does not dispatch again. The response preserves the existing service fields and adds `cancellation`, including `cancellation_intent_id`, `intent_id`, original `operation_id`, `resource_type`, `resource_id`, `action`, `state`, `billing_confirmed` and `requires_reconciliation`. The embedded resource is the original result, not a fresh representation after later changes. Read the service again for its current ETag before a different action. A dry run performs local permission, version, resource, pending-order and billing checks without allocating an operation, preparing a journal or contacting a supplier. It reports `supplier_checks_performed:false`: actual remote commercial fields are verified only before a real submission. ## Recovery After timeout, transport failure or an uncertain result, do not create a new intent or repeat the accounting request. 1. `GET {resource}/cancellations?limit=25` lists original receipts for this connection. Follow the bounded UUID `next_cursor` to inspect further pages. 2. `GET {resource}/cancellations/{receipt}` reads the signed original local receipt without a supplier call. 3. Explicit `POST {resource}/cancellations/{receipt}/actions/reconcile` uses a new HTTP idempotency key for that readback action. It only reads the original supplier subscription; it never sends another terminate/resume request. Current permission and the original company/identity binding are required. A service integration must keep its original principal. A renewed personal connection of the same human and identity generation may inspect the original receipts. To reconcile through that new connection, provide `confirm_intent_id` equal to the original business UUID, `confirm_resource_id`, the current `If-Match`, and recent strong authentication. This approves only readback/local finalization; the original journal principal remains unchanged and no supplier mutation is repeated. Changed identity epochs or a different original human require a separately authorized operator recovery, outside these endpoints. Keep the original intent held until that recovery is available; never edit its journal/billing rows or submit a replacement accounting mutation. The accounting intent and exact requested termination date commit before dispatch. A received acknowledgement is retained independently of later local publication. Readback can finish the original local resource/reference/operation atomically, even after the original calendar boundary has passed. A hard-killed process leaves its durable marker and cannot cause a second automatic dispatch. `prepared` means that only an original receipt is known; inspect it before deciding anything. `requires_reconciliation` means accounting confirmation is missing. `completed` confirms the original accounting/local result. `not_submitted` proves this preparation did not dispatch: after inspecting it, read the current service and explicitly review a new intent. A pending whole order, unfinished delivery, ambiguous/foreign billing mirror, unknown subscription state or unreviewed imported billing remains blocked rather than reporting a false cancellation. ## CLI ```sh binadit exchange mailboxes get 73 --account 12 binadit exchange mailboxes renewal cancel 73 --account 12 --version --confirm-resource 73 --intent-id --yes binadit exchange mailboxes renewal list 73 --account 12 binadit exchange mailboxes renewal get 73 --account 12 binadit exchange mailboxes renewal reconcile 73 --account 12 --yes # After a new personal login, explicit renewed approval for readback: binadit exchange mailboxes renewal reconcile 73 --account 12 --version --confirm-resource 73 --confirm-intent --yes binadit exchange mailboxes renewal resume 73 --account 12 --version --confirm-resource 73 --intent-id --yes ``` The same `renewal` commands exist under `hosting subscriptions` and `spam filters`. Mutation output is restricted to verified receipt metadata. No command automatically repeats an uncertain accounting mutation or polls into a new action. Do not treat a CLI timeout as cancellation of the original attempt. ## Portal and agents The service row opens an explicit review with its frozen version. Confirm once. The receipt stays visible; an uncertain response offers original-receipt inspection and explicit readback, with no automatic POST retry. Internal administrators can renew passkey proof and then review the service again. Read the current service before starting another change. Agents must preserve account context, typed service ID, original intent UUID, HTTP operation and receipt. They must never substitute an unrelated domain order with an equal numeric ID, cancel one held item out of an unfinished whole order, infer financial success from a transport error, automatically approve a finite billing-counter reset, or reconstruct an uncertain mutation with a new date. These endpoints currently cover Hosting, Exchange and Spam renewal; Domain/Workspace ownership and other cancellation consumers retain their separate documented workflows until explicitly migrated. A completed response also requires the intended local service state, cancellation reference and original receipt to have been stored and read back. A cancelled or changed local write keeps the accepted accounting acknowledgement for explicit read-only reconciliation. That recovery never sends another termination or resume request. A terminal receipt that changes during commit is reported as unconfirmed; retain the original intent and inspect its evidence before taking another action.