Update an availability reason
Administrator only. Change one or both writable fields; what is not sent stays untouched. At least one writable field must be present — an empty payload is a 400, not a no-op.
Authorizations
The id_token from POST /auth/v1/signin, sent as Authorization: Bearer <id_token>. Not the access_token — that one does not carry the identity Cloud Chat authorizes on.
Headers
Your Cloud Chat instance ID — an integer, fixed for your company, told at onboarding. The API overview explains how instances work, how to find yours, and the errors a wrong or missing value produces.
1
Path Parameters
Your Cloud Chat account. It has to be an account your token grants membership on, and it has to live on the instance in the cloudchat-instance header — the two travel together. Account numbers are only unique within an instance, so the same number is a different company on another instance. Usually a mismatched pair fails closed with a 401, because your user does not exist on the other instance — but if your identity happens to exist on both, the call succeeds against the other company's data, silently. Read it and you are looking at the wrong help center; write it and you have stored into the wrong account. Send the two values that were given to you together, and never try a number to see what answers.
1
The id returned when the availability reason was created or listed.
4
Body
The changes go under an availability_reason wrapper. Administrator only. At least one writable field must be present — an empty payload is a 400, not a no-op.
Response
The availability reason after the update.
A reason an agent can select when going busy. The account never chooses any availability besides busy for a reason created through this API — that field is not part of the public contract.