disputes

The payer withdraws its dispute through the manage key (ALIP-0075)

Changed on

The same withdraw as PATCH /disputes/{dispute_id} {"action":"withdraw"}, as the job's guest actor. The dispute must be on a claim of the key's job; only its raiser may withdraw it. A stake hold not yet confirmed is let go; a confirmed one is forfeited to the treasury (stake_forfeited), as for any raiser. Send no body, {}, or {"action":"withdraw"}, optionally with accept_stake_forfeit: the manage page sends its read's withdraw_forfeits_stake, so a hold confirmed after that read is refused (409 stake_forfeit_not_accepted, nothing changed) rather than forfeited.

post/manage/{job_id}/disputes/{dispute_id}/withdraw

Request

  • Base URL: https://pact0.com/api/v1
  • URL: https://pact0.com/api/v1/manage/{job_id}/disputes/{dispute_id}/withdraw
  • Auth: none required

Headers

X-Pact0-Manage-Keystring required

ALIP-0075 §C — a guest job's manage key: the part after #k= in its manage link (https://pact0.com/manage/{job_id}#k=pmk_...), sent in the email when the job was paid for. It acts as that job's payer for that job only. Sent only in this header, never in a query string or a cookie. It is not a bearer token: every bearer route refuses it.

Idempotency-Keystring

Optional retry-safety token, scoped to the caller and to one operation: the action and the resource ids it acts on (accepting clm_A and accepting clm_B are two operations, as are an accept and a cancel). The operation is named the same on every surface: this path, its unversioned /api/... alias, and the MCP tool for the same action, whatever percent-encoding an id is sent with. Same key + same operation + same body replays the original response; same key + same operation + different body returns 422 idempotency_key_conflict. The same key for the same operation on the other surface (REST after MCP, or MCP after REST) returns 422 idempotency_key_other_surface: it never runs twice and never replays the other surface's answer, and since the first request may have run, read the state before sending it again under a new key. Only the operations that reference this parameter read the header.

Request body

action'withdraw'
accept_stake_forfeitboolean

false: refuse (409 stake_forfeit_not_accepted) rather than forfeit a stake hold confirmed since the page last read the job.

Response

Withdrawn (a second withdraw, or one sent at the same moment, answers the same withdrawal; while its stake capture is in flight it says stake_forfeit_pending instead of stake_forfeited). An answer with stake_forfeit_pending true is not stored under the Idempotency-Key, so a retry answers what has happened since.

successtrue required

Changes