Example 💡
A customer runs two business units, each with its own subscription to the same plan: a monthly platform fee plus usage-based “Transactions processed”. Events are sent with
record.subscription_id set to the subscription of the business unit that generated them. Each subscription’s “Transactions processed” product has a metering filter subscription_id equals <its own ID>, so each one bills only its own transactions.How it works
- A subscription is created in Hyperline (from a template, a quote, the app, or the API).
- Hyperline sends a
subscription.createdwebhook to your endpoint. - Your endpoint updates the subscription and adds a metering filter on its usage-based products:
subscription_id equals <subscription ID>. - Your system sends usage events with
record.subscription_idset to the subscription ID. - Each subscription only counts the events carrying its ID.
The filter value doesn’t have to be the Hyperline subscription ID. Any identifier your system already stores per subscription (contract ID, workspace ID, etc.) works, as long as the same value is set in the filter and in the events.
1. Listen to the subscription creation
Add a webhook endpoint listening to thesubscription.created event. The payload contains the subscription and customer IDs:
webhook-id, webhook-timestamp and webhook-signature headers.
2. Add the metering filter to the subscription
Metering filters on a subscription’s prices are set through the API with Update subscription.- Retrieve the subscription with Get subscription.
- For each usage-based product (
type: "dynamic") to filter, add ametering_filteron each of its prices. - Send the phases back with
PUT /v2/subscriptions/{id}. The payload uses the same structure as theGETresponse, so you can send the retrieved phases with only themetering_filteradded.
3. Send events tagged with the subscription
Add the subscription ID to therecord of every event, under the property used in the filter:
Events without the property, or with another subscription’s ID, are ignored by filtered products. They still appear in the customer’s usage.
4. Check the usage per subscription
- Get subscription with
include_live_billing=truereturns the usage and amount currently computed for each product of the subscription. - Each subscription’s open invoice shows its own usage. When listing invoices with the API, pass
status=opento include them. - The customer Usage tab shows the total usage of the customer, across all subscriptions.
Good to know
- The filter is set on the subscription, not on the product or the template: every new subscription needs its own filter, which is why the update runs on
subscription.created. - Prices and other product settings are kept as they are: the update only adds the filter.
- A metering filter can combine several conditions. If your prices already use metering filters (for example per region), add the
subscription_idcondition to the existing fields withconditional: "and".
Is something still unclear? Don’t hesitate to reach out to our team
via the in-app chat if you need additional support.

