Remove a quantity price break
Authorizations
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
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
Body
Takes no parameters, and an empty body is expected. The tier id in the path addresses the band on its own, which is why this route is TOP LEVEL rather than nested under the variant: a {variantId} segment would be one nothing verifies, so a request naming variant A and a tier belonging to variant B would delete B's tier and answer as though it had honoured the path. The body is still READ AND VALIDATED: amount_minor and amount are refused BY NAME because a delete carries no amount, and variant_id, currency_code and min_quantity are refused because the tier id already names all three. EVERY ORDER IN THE REMOVED BAND REVERTS to the variant's resolved single-unit price at the next cart recompute, which is a PRICE INCREASE for exactly the shoppers the band was written for. Resolution is never snapshotted, so carts already open re-price. Nothing is emitted: this family publishes no webhook topics, so no integrator is told. IT IS NOT UNDONE BY A REPLAY: the previous amount is gone, there is no soft delete and no restore, and rebuilding the band means knowing its floor, its top and its amount and posting it again. That is why this route takes write_pricing:delete on top of write_pricing while the POST that writes a band takes write_pricing alone. 204 whether or not a row was removed. Reporting the miss as 404 would fail a retry after a lost 204 for a request that had SUCCEEDED, and would make this route an existence oracle for tier ids in stores the key cannot read.
Response
Success. The response has no body.
