Remove a tax-inclusive display preference
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 row is named by the server-minted id in the path, not by the (attribute, value) pair the upsert is keyed on, so a client holding a stale pair cannot remove a preference the merchant has since retargeted. The body is still READ AND VALIDATED: is_tax_inclusive is refused BY NAME because a delete carries no flag AND because the two are different operations, attribute and value because this route addresses the row by id, and id, created_at and updated_at for the usual reasons. DELETING IS NOT WRITING false, and getting that backwards gives the opposite of what was intended. Resolution is the region row, then the currency row, then the literal false. Delete a REGION row and the CURRENCY row underneath it starts winning, so a store with currency usd true and region reg_x false flips reg_x to tax-inclusive display. Write false to that same region row instead and false is PINNED over the currency row whatever it holds. For a currency row with no region row matching the same shopper both paths land on false and the rendered price is identical; the delete still erases the merchant's recorded choice. REMOVING THE LAST ROW MATCHING A SHOPPER DROPS THEM TO TAX-EXCLUSIVE DISPLAY, which is a price shown BELOW what checkout collects. No money moves and no amount changes: this row decides what is SHOWN, and a VAT market rendering every price without its tax is the failure this family exists to prevent. It takes effect IMMEDIATELY, because the storefront resolves this at read time and never snapshots it, so carts already open re-render. NOT REVERSIBLE BY REPLAY. There is no soft delete and no restore, and re-creating the preference through the POST mints a NEW id and a new created_at, so an integration keyed on the old id has to be updated. Nothing is emitted, because this family registers no webhook topics. That is why this route takes write_pricing:delete on top of write_pricing while the upsert takes write_pricing alone. 404 WHEN THE ID NAMES NOTHING, rather than a blanket 204. The id was minted by this platform rather than composed by the caller, so a miss can only mean the id is wrong or another actor already removed the row, and a client syncing display settings needs to hear both. Answering honestly costs a genuine retry nothing: replaying the Idempotency-Key returns the stored 204 without re-executing, and only a FRESH key against an already-deleted row reaches the 404.
Response
Success. The response has no body.