Skip to content
In this section

Billing API Changelog

Dated changes to the public contract, and how long a major version is supported.

This is the public change record for the Billing API. Billing follows Fynex's shared public API lifecycle policy: Payments and Billing both support a public major version for at least 12 months after its successor is generally available, and both give at least 90 calendar days' notice before removing a public contract.

2026-10-19

Changed: includedUnits on contract usage is the billed allowance

GET /billing-api/v1/contracts/{contractId}/usage now reports, as includedUnits, the allotment.includedUnits of the metric price effective for the period — the allowance the period close rates with — instead of the limit policy's included units. percentOfPlan follows it. The backoffice GraphQL usage view reports the same value.

What changes for an integration that reads the field:

Metric Before Now
Priced, allotment 10 000, limit policy 0 includedUnits: "0", no percentOfPlan includedUnits: "10000", percentOfPlan against 10 000
Priced, allotment 0, limit policy 10 000 includedUnits: "10000", percentOfPlan against 10 000 includedUnits: "0", no percentOfPlan — every unit is billed
Not priced yet, limit policy 10 000 includedUnits: "10000" unchanged

If you compute overage or alerts from includedUnits, the new value is the one your invoices are rated with; the limit policy's cap is still reported as capQuantity.

Fixed: pausing a subscription needs no body

POST /billing-api/v1/subscriptions/{subscriptionId}/pause with no request body pauses until resumed, as {} always did, instead of answering 400.

2026-09-18

Changed: metering routes under /billing-api/v1 accept secret keys only

/billing-api/v1/usage/* now applies the same credential rule as every other operation under the Billing prefix: only sk_test_… / sk_live_… secret keys authenticate, and any other bearer value answers 401. Before this date those routes also accepted the older prefix-less seller token. Nothing changes for integrations that already send a secret key, which is what every guide has documented since the prefix was published. The legacy /usage/v1/* routes are unchanged and continue to accept the credentials they always did.

Fixed: webhook documentation

The Billing webhook pages described the signature as an HMAC over the raw body and deliveries as "retried until 2xx". The signature has always been computed over <X-Fynex-Timestamp>.<raw body>, only a 200 counts as delivered, and a delivery is attempted at most 3 times. The documentation now says so; no delivery behaviour changed.

2026-09-13

Deprecated: origin=subscription query alias

origin=subscription is a deprecated alias for origin=recurring on GET /billing-api/v1/invoices. Notice date: 2026-09-13. The legacy alias is still accepted and returns the same invoice rows as origin=recurring, but it is no longer produced for newly created invoices. Update integrations to use origin=recurring.

The planned removal date is 2026-12-13, providing 91 calendar days' notice, which is at least 90 calendar days. This is a query-value deprecation, not an HTTP operation retirement. An OpenAPI deprecated: true marker applies to an operation, parameter, field or schema; this individual enum-like query value cannot be represented by an operation-level marker. The public changelog entry is therefore the applicable value-level deprecation signal. Do not mark the whole origin query parameter deprecated, and do not expect Deprecation or Sunset response headers for this query value.