POST
Approve a requested order claim

Authorizations

Authorization
string
header
required

A secret API key. Publishable keys cannot reach this API. A key may carry an expiry, and an expired key is refused exactly like an unknown one, with a 401 that names no reason; check the key's expires_at in the dashboard rather than inferring it from a response. When a merchant rolls a key's secret they choose a grace window of up to 3 days, and for its duration BOTH the new secret and the one it replaced authenticate, so an integration moves over on its own deploy schedule instead of at the instant the button is pressed. Move before the window closes: after it, the old secret is refused. Nothing else about this contract moves with a roll. The key keeps its id and its scopes, so the only thing an integration updates is the credential itself.

Headers

Idempotency-Key
string
required

A unique key per logical write. Replaying a request with the same key returns the first response byte for byte instead of applying the write twice.

Path Parameters

claimId
string
required

Body

application/json

Takes no parameters, and an empty body is expected. Moves a requested claim to approved, which is the merchant agreeing to settle and nothing more: NO MONEY MOVES HERE. The payment happens on POST /api/v1/order-claims/{claimId}/resolve and nowhere else, so approving a refund-type claim on an order with no captured payment SUCCEEDS and the refusal arrives later, at resolve, as 409 not_refundable. LEGAL ONLY FROM requested. An approved, resolved, rejected or cancelled claim answers 409 invalid_transition, so this is not idempotent by shape: a replayed Idempotency-Key answers the stored response, and a FRESH key on an already-approved claim answers 409 rather than 200. IT EMAILS THE SHOPPER. A claim opened through this API carries no_notification false and cannot set it, so every transition on it mails the customer; a claim a staff member opened in the dashboard with notifications suppressed stays suppressed here. The mail is best effort: a failure is logged and never returned, so a 200 is not evidence the message was delivered. There is no approved_at column, so the only stamp this moves is updated_at. THE BODY IS READ ONLY TO REFUSE IT. refund_amount and refund_amount_minor are refused BY NAME, because the settlement figure was computed when the claim was opened and this grant chooses whether to settle, never for how much; a client that sent one would otherwise read the 200 as having chosen it. status is refused because the route in the url is the transition and only one of the two could win, and reason because a transition carries no note of its own. The response is the WHOLE claim in the shape GET /api/v1/order-claims/{claimId} serves, so treat it as a fresh read rather than following it with a GET.

Response

Success

data
object