POST
Bind a tax rate to a product, product type or tax class

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

taxRateId
string
required

Body

application/json

THIS IS THE LAYER THAT DECIDES WHAT A PRODUCT ACTUALLY PAYS. The resolver ranks the rules matching a line by how specific their binding is, product beating product_type beating product_tax_class beating the jurisdiction default, and takes the most specific non-combinable one as the base rate. IT IS IDEMPOTENT IN EFFECT, not merely by Idempotency-Key: the binding is unique per (rate, reference, reference_id), so a create replayed outside the idempotency window returns the rule that is already there instead of minting a second. That is what makes a reconciler binding one rate across a whole catalogue safe to re-run, and it is a guarantee POST /api/v1/tax-rates cannot offer. THERE IS NO PATCH. A rule is a binding rather than a record with editable fields, so a rebind is a delete plus a create, and the delete needs write_tax:delete.

reference
enum<string>
required

Required. What KIND of thing reference_id names. The three are a PRECEDENCE order, most specific first, not interchangeable tags: sending the wrong one changes which rate wins on every line where two of them match. A value outside the set is a 400.

Available options:
product,
product_type,
product_tax_class
reference_id
string
required

Required. The id of the target, read according to reference. IT IS NOT VALIDATED against the catalogue and carries no foreign key, so a rule may name a product that was deleted afterwards. Such a rule is INERT rather than broken: it never becomes a candidate and the line falls back to the next most specific rate. That is deliberate, so a migration can write its tax matrix before its products.

Response

Created

data
object