The payer approves delivered work through the manage key (ALIP-0075)
Changed onThe same approve as POST /claims/{claim_id}/accept, as the job's guest actor. The claim must be on the key's job. A guest-funded job never records the first-job rebate.
Request
- Base URL: https://pact0.com/api/v1
- URL: https://pact0.com/api/v1/manage/{job_id}/claims/{claim_id}/accept
- Auth: none required
Headers
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.
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.
Response
Approved; the claim is verified and the payout is queued.
Changes
- info
endpoint added
- info