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.
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":"<original UUID>"} 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.
GET {resource}/cancellations?limit=25lists original receipts for this connection. Follow the bounded UUIDnext_cursorto inspect further pages.GET {resource}/cancellations/{receipt}reads the signed original local receipt without a supplier call.- Explicit
POST {resource}/cancellations/{receipt}/actions/reconcileuses 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, provideconfirm_intent_idequal to the original business UUID,confirm_resource_id, the currentIf-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
binadit exchange mailboxes get 73 --account 12
binadit exchange mailboxes renewal cancel 73 --account 12 --version <etag> --confirm-resource 73 --intent-id <uuid> --yes
binadit exchange mailboxes renewal list 73 --account 12
binadit exchange mailboxes renewal get 73 <receipt-uuid> --account 12
binadit exchange mailboxes renewal reconcile 73 <receipt-uuid> --account 12 --yes
# After a new personal login, explicit renewed approval for readback:
binadit exchange mailboxes renewal reconcile 73 <receipt-uuid> --account 12 --version <current-etag> --confirm-resource 73 --confirm-intent <original-uuid> --yes
binadit exchange mailboxes renewal resume 73 --account 12 --version <new-etag> --confirm-resource 73 --intent-id <new-uuid> --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.