Confirmation Flow

By default an assignment becomes an active deployment immediately. With the confirmation flow enabled, a new assignment first enters a wait_for_confirmation state and does not deploy until it is confirmed — either by the device over DDI, or by an operator activating auto-confirm.

This mirrors hawkBit’s confirmation flow (confirmationBase), which clients like the RAUC hawkbit-updater support.

The client has to implement confirmationBase. With the flow on, a waiting target’s poll offers confirmationBase and no deploymentBase. A client that doesn’t parse that link — the mainline Zephyr hawkbit client (subsys/mgmt/hawkbit) ignores it entirely, as do older SWUpdate/RAUC setups — sees nothing it understands, so it polls forever and never installs, with no error reported anywhere. raptor logs a warning at startup when the flow is on. Use auto_confirm_default (below) or per-target auto-confirm for those devices.

Enabling the flow

It’s a server-wide toggle in the config:

[ddi]
confirmation_flow = true

When off (the default), behavior is exactly as before — assignments go straight to running.

What a device sees

With the flow on, a target’s poll offers a confirmationBase link instead of deploymentBase:

$ curl localhost:8088/DEFAULT/controller/v1/device-42
# _links.confirmationBase -> .../confirmationBase/7

GET .../confirmationBase/{actionId} returns the pending deployment (the same chunk/artifact shape as deploymentBase, under a confirmation key) so the device can decide. The device then confirms or denies:

# confirm -> action goes to running; next poll offers deploymentBase
curl -X POST localhost:8088/DEFAULT/controller/v1/device-42/confirmationBase/7/feedback \
  -H 'Content-Type: application/json' \
  -d '{"confirmation":"confirmed","details":["operator approved"]}'

# deny -> action stays waiting (a "denied" ActionStatus row is recorded)
curl -X POST localhost:8088/DEFAULT/controller/v1/device-42/confirmationBase/7/feedback \
  -H 'Content-Type: application/json' \
  -d '{"confirmation":"denied","details":["not now"]}'

A denied action remains in wait_for_confirmation; the device may confirm later, or an operator can cancel it.

Auto-confirm

A target can be set to auto-confirm, so assignments skip the wait state entirely. Toggle it from the Management API:

curl -u admin:pw localhost:8088/rest/v1/targets/device-42/autoConfirm
# {"active": false}

curl -u admin:pw -X POST localhost:8088/rest/v1/targets/device-42/autoConfirm/activate
curl -u admin:pw -X POST localhost:8088/rest/v1/targets/device-42/autoConfirm/deactivate

Or by the device itself over DDI:

curl -X POST localhost:8088/DEFAULT/controller/v1/device-42/confirmationBase/activateAutoConfirm
curl -X POST localhost:8088/DEFAULT/controller/v1/device-42/confirmationBase/deactivateAutoConfirm

Activating auto-confirm releases any already-pending actions on that target — they transition straight to running. New assignments to an auto-confirm target never enter the wait state.

Auto-confirm by default

To run the flow only for the devices that actually support it, have every new target start out auto-confirming and deactivate it on the ones you want to confirm explicitly:

[ddi]
confirmation_flow = true
auto_confirm_default = true

This applies to targets created either way — DDI self-registration or POST /rest/v1/targets. It only affects new targets; existing ones keep whatever auto-confirm state they have.

Operator confirm/deny

There is currently no per-action operator confirm/deny over the Management API — device-driven confirm/deny is DDI-only. The operator path is to activate auto-confirm on the target (which releases pending actions), or to cancel the action.