Update a customer unit
Renames, re-types, re-parents or annotates a unit, the root included. externalId cannot change. Re-parenting (parentExternalId) moves the unit with everything under it. Spend already recorded keeps naming the unit it landed on; caps are evaluated on the current tree, so from the move on the unit’s spend in the running cap period counts toward its new ancestors’ caps and no longer toward the old ones. billable flips the unit’s own setting; moving a unit under a non-billable one makes it non-billable in effect (effectiveBillable). 409 for a deleted unit (CUSTOMER_UNIT_DELETED), a draft (CUSTOMER_UNIT_DRAFT), a parent that does not exist or is not ACTIVE, a move of the root (ROOT_UNIT_IMMOVABLE), billable: false on the root (ROOT_UNIT_ALWAYS_BILLABLE), a move under the unit’s own subtree, or a tree that would get too deep. 403 FEATURE_NOT_ENABLED for billable: false when non-billable units are not enabled for your organization. Use the value returned as customer.id, for example cus_abc123; if you have your own customer ID, use the /api/v2/customers/external/{externalId}/… twin.
Authentication
Path parameters
Your own id for the unit (its externalId), unique within this customer.
Request
Your structural vocabulary for the unit (department, tenant, team, ...). Free text; filterable; Paid never branches on it.
Your external ID of the new parent unit; moves the unit and its subtree.
Flips the unit's own setting either way. Under a non-billable ancestor the unit stays non-billable in effect (effectiveBillable) whatever its own value. Refused on the root unit, which is always billable (409 ROOT_UNIT_ALWAYS_BILLABLE). Sending false needs non-billable units enabled for your organization (403 FEATURE_NOT_ENABLED otherwise). Usage on a non-billable unit is still recorded but not billed: it burns no credits, adds nothing to invoices or overage, and counts toward no cap, on a price whose usage comes from a meter (read from your events when the invoice closes) too. A meter's derived signal, and a correlation-window meter's window, follow the source event they take their unit from (the window's closing event, else its opening event): they are not billed when that event was not. Usage is still billed when it is sent with a customer API key, and on cost-plus pricing, which bills from costs that carry no unit. Only signals sent to /api/v2/signals that resolve to an active unit, by its key or through an alias on it, can be non-billable, and a change applies to signals received afterwards.
Response
Paid's id for the unit (cu_…), unique within the organization and stable across renames of the customer. For reference only: no unit route accepts it, and routes and signals name a unit by its externalId.
Your own id for the unit, unique within the customer; the identifier every unit route takes.
Paid's id of the customer the unit belongs to (cus_…). null only for a legacy customer that has no Paid id; customerExternalId still names it.
ACTIVE; DELETED after a soft delete (one-way); or DRAFT, a placeholder that holds the key for this customer until you create the unit with that key (which promotes it) or delete it (soft, the key stays reserved, as for any unit). A draft is never a parent and never carries a cap.
externalId of the parent unit; null only on the customer's root unit.
Whether this unit is the customer's root: the one unit without a parent. Derived from the missing parent, not stored. At most one active root per customer; the root cannot be moved, and once deleted a new root can be created.
The unit's own setting, as last created or updated: false marks it, and every unit under it, non-billable. Always true on the root. effectiveBillable says whether the unit is billable once its ancestors are counted. Usage on a non-billable unit is still recorded but not billed: it burns no credits, adds nothing to invoices or overage, and counts toward no cap, on a price whose usage comes from a meter (read from your events when the invoice closes) too. A meter's derived signal, and a correlation-window meter's window, follow the source event they take their unit from (the window's closing event, else its opening event): they are not billed when that event was not. Usage is still billed when it is sent with a customer API key, and on cost-plus pricing, which bills from costs that carry no unit. Only signals sent to /api/v2/signals that resolve to an active unit, by its key or through an alias on it, can be non-billable, and a change applies to signals received afterwards.
Read-only. Whether the unit is billable in effect: false when the unit or any unit above it has billable: false. A unit cannot make itself billable under a non-billable ancestor, and moving a unit under one makes it non-billable.