Skip to main content

Versions and concurrency

Use a version precondition when you update a resource that supports concurrency checks. This prevents an update based on stale state from overwriting a newer change.

Precondition controls​

ControlBehavior
versionRead the current resource version
If-MatchSupplies the update precondition; takes precedence over ifVersion
ifVersionOptional integer precondition; integer strings are normalized
HTTP 412The precondition did not match
Version range0 through 9007199254740991

Update with a version​

Use https://<your-api-host> as your API base URL. The host is shown in the Balancer portal. Examples use $BALANCER_API_KEY for an existing credential with the required access.

  1. Read your load balancer and record its returned version as VERSION:
curl --fail-with-body -sS -X GET "https://<your-api-host>/http-loadbalancers/$HTTP_LB_ID" \
  -H "x-api-key: $BALANCER_API_KEY"

Expect HTTP 200 with the saved load balancer and version.

  1. Submit the version with the update:
curl --fail-with-body -sS -X PATCH "https://<your-api-host>/http-loadbalancers/$HTTP_LB_ID" \
  -H "x-api-key: $BALANCER_API_KEY" \
  -H "If-Match: $VERSION" \
  -H "Content-Type: application/json" \
  --data '{"name":"updated-site"}'

Expect HTTP 200 on a successful update. A stale precondition returns 412.

  1. Read the resource again with the first request. Verify the name and current version. On 412, read current state, reconcile your intended change and retry with the current version. See changes at the edge before treating the update as active.