POST
Reject 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. Refuses the claim outright, and it is LEGAL ONLY FROM requested. An APPROVED claim cannot be rejected: that answers 409 invalid_transition, and cancel is what withdraws an approval. The asymmetry is deliberate rather than an oversight, because reject records the merchant refusing the claim and cancel records it being called off, and a merchant reporting on disputes has to tell the two apart. TERMINAL AND NOT REVERSIBLE. No route returns a claim to requested, so a rejection cannot be undone through this API. It does RELEASE the claimed quantity back to the order lines, so those units become claimable again and the repair for a rejection sent in error is a new claim over the same lines rather than a second transition on this one. NO MONEY MOVES and no stock moves. There is no rejected_at column, so the only stamp this moves is updated_at, and a client tells a rejection from a cancellation by the status rather than by a timestamp. IT EMAILS THE SHOPPER, on the same terms as the approve route: a claim opened through this API cannot suppress the mail, and the mail is best effort, so a 200 is not evidence of delivery. THE BODY IS READ ONLY TO REFUSE IT. reason is the key an integrator reaches for first here and it is refused BY NAME, because a transition carries no note of its own and the claim's own reason column is published from neither door, so a rejection note sent here could never be read back. refund_amount, refund_amount_minor and status are refused too. The response is the WHOLE claim in the shape GET /api/v1/order-claims/{claimId} serves.

Response

Success

data
object