Skip to main content

Concept

Operations and Statuses

Many ZennoHosting operations are asynchronous. A successful write request often means the server accepted work, not that the VM, network, backup, or forwarding rule already reached the final state your workflow needs.

What accepted means

  • 202 Accepted means the request was accepted for processing.

  • commandId identifies the accepted command, not the final resource state.

  • A client should fetch the affected resource afterward and inspect its current state fields.

  • For VMs, operationStatus and bootStatus are especially important before follow-up automation.

  1. 1

    Send the mutating request

    Create, update, restore, attach, and forwarding operations often start as asynchronous work rather than immediate state transitions.

  2. 2

    Record identifiers from the accepted response

    Keep the returned commandId and the resource identifiers already known in the request context.

  3. 3

    Fetch the affected resource

    Read the VM, network, backup, or public IP state from the corresponding resource endpoint instead of assuming success from the write response alone.

  4. 4

    Interpret resource fields

    Use status-related fields such as operation, operationStatus, bootStatus, and resource-specific statuses to determine whether your next action is safe.

Where this matters most

  • VM creation, start, stop, and reboot.
  • Private network creation and VM network attach or detach.
  • Backup creation and restore.
  • Public IP forwarding rule creation, update, and deletion.

Implementation rule

Build automation around observed resource state, not around write acknowledgements. In ZennoHosting, the accepted response tells you that work started. The resource representation tells you whether that work finished.