# Parent & child

import { Mermaid } from "zudoku/mermaid";

A **parent** subscription groups several **child** subscriptions under one
billing relationship — one customer agreement that spans many entitlements (for
example, a head office with one contract and a subscription per site or seat
group). This page explains the concept; the parent-child configuration itself is
managed on the customer-facing API, which is not yet documented here.

<Mermaid chart={`flowchart TD
  P["Parent subscription"] --> C1["Child · Site A"]
  P --> C2["Child · Site B"]
  P --> C3["Child · Site C"]
`} />

## Invoicing modes

A parent bills in one of two modes:

| Mode | What the customer receives |
|---|---|
| **Consolidated** | One invoice for the parent, with every child's charges as line items. |
| **Per-child** | A separate invoice per child subscription. |

Each child still has its own products, cadence, and
[timeline](/guides/subscriptions/data-model); the mode only decides how their
charges are grouped onto invoices.

## The chain id across the hierarchy

Parent and child are each their own [subscription chain](/guides/subscriptions/data-model)
with its own stable id. A `subscription.*` webhook and a
`GET /v1/subscriptions/{id}` always refer to a single chain — reconcile each
child by its own id, and the parent by the parent id.

## Configuration

Creating the parent-child relationship and choosing the invoicing mode is done
on the customer API, not the public `/v1/subscriptions/*` surface — there is no
public endpoint to assemble a hierarchy. Documentation for that surface is
forthcoming; until then, treat parent-child as a concept you read about over
webhooks and reads, not one you assemble over the public API.