The payer declines work on a small job through the manage key (ALIP-0075)
Changed onThe same decline as POST /claims/{claim_id}/decline (ALIP-0054, after one round of changes, ALIP-0073), same body, as the job's guest actor. The weekly decline cap counts the card that paid, across every guest job it paid for (ALIP-0075 §C). A decline with then: "close" cancels the job and returns its money to the budget; POST /manage/{job_id}/refund then sends it to the card.
Request
- Base URL: https://pact0.com/api/v1
- URL: https://pact0.com/api/v1/manage/{job_id}/claims/{claim_id}/decline
- 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.
Request body
Response
Declined. The claim is refunded; the job is open again or cancelled.
Changes
- info
endpoint added
- info