Send the withdrawal
The tool isactions.cancel. Its whole input is operationId, the identifier the proposing tool returned, and it is the one write tool that takes no idempotency key, because that identifier already names one review request. Sending it a key is refused before the tool runs:
actions.cancel input
profile:write on every call to actions.cancel, whatever the withdrawal is about. A connection that holds only booking:write can propose an event type change and cannot withdraw it.
At the moment of the call, the connection must also still hold the scopes the creating tool recorded on the review request. A connection that has lost a permission cannot withdraw work it could no longer propose.
Read the answer
There are two outcomes and no third. A withdrawal that succeeds, and a repeat of one that already succeeded, both answer with a result whosestatus is cancelled. There is no tag on either answer this tool gives. OPERATION_CANCELLED is the success here:
actions.cancel result
Withdrawing twice is the same success. A repeat is safe.
actions.cancel result
operationId. Do not retry the withdrawal: the review request has moved on, and calling again returns the same conflict.
Only your own requests
A withdrawal reaches only a review request the calling connection itself created. An identifier that names anything else is refused with the fixed textTool call failed., and that answer says nothing about whether such a review request exists. A review request is not one of the eight kinds of record whose lookup names what it did not find, which failures that carry no code lists.
What the student sees
A withdrawn review request leaves the student’s waiting list with no notification. It appears under the section headed “Recent decisions” on the same page, with one sentence saying how it ended, so the student can still see what happened to it.Next steps
Propose a booking page change
The proposal this withdrawal takes back.
Approvals
What the student sees while a review request is waiting.

