Skip to main content
POST
Entity Subscriptions
Entity subscriptions let one customer pay for multiple independently managed subscriptions. Each Entity keeps a stable subscription identity while using the standard Nozle plan, invoice, checkout, renewal, and reporting lifecycle. Auth: secret key only. Publishable keys are rejected.
Nozle validates the live Entity before creating or changing its subscription. Suspended or deleted Entities cannot start checkout. A newly created Entity that reuses an older external ID cannot inherit the older Entity’s subscription.

Ensure a subscription identity

This operation is idempotent. It creates the stable Entity-to-subscription identity but does not select or activate a plan.

Read subscriptions

Read one Entity subscription:
List all Entity subscriptions for a customer:
The response reports the current and pending plans independently for each Entity:

Start checkout

billing_time accepts anniversary or calendar for the initial subscription. Paid plans remain incomplete until verified payment succeeds. Retrying an incomplete checkout for the same plan reuses its subscription and invoice instead of creating another charge.

Purchase multiple Entity plans together

Use bulk Entity checkout when a customer purchases a mixed pool of plans in one payment. The merchant backend supplies one item per Entity; Nozle creates one invoice and one Stripe checkout for the complete basket. Use the Node SDK from your trusted backend. It wraps the API request, validates the basket, and returns the checkout contract:
The Python SDK exposes the same backend operation:
On the frontend, pass a Stripe result to the React checkout component:
The endpoint below remains available for backends that do not use the Node SDK.
The request accepts up to 100 unique Entities. Every plan must be paid, use the same currency, and use the same interval. Each Entity must be active and must not already have an active, pending, or incomplete subscription.
Nozle supports these result types:
  • stripe: mount the returned client secret in Stripe Checkout;
  • processing: Stripe completed, but the verified payment event is still being processed; and
  • completed: the invoice is already settled, so no Stripe session is required.
The idempotency key covers the customer, billing mode, return URL, Entity IDs, and plans. Retry the exact request with the same key. A different basket with the same key returns a conflict.

Shared customer billing anchor

Bulk Entity checkout establishes one stable billing calendar for the paying customer:
  • if the customer has never completed a paid Entity checkout, the first successful payment establishes the anchor;
  • failed or abandoned first checkout does not establish an anchor;
  • concurrent first-paid checkouts are rejected while the anchor is unresolved;
  • later Entity purchases align to the established anchor and prorate their first period; and
  • the anchor remains stable even if the customer temporarily has no paid Entities.
For a fresh seat pool, send billing_time: "anniversary". For example, a successful first payment on August 6 renews on the sixth. A seat added on August 20 is charged only through September 6, then joins the normal renewal invoice.
The anchor is established only after confirmed payment. Creating an invoice or receiving a browser redirect is not enough.

Change plan

The configured plan-transition policy determines whether the change is immediate, payment-gated, or scheduled for the renewal boundary. Changing one Entity never changes another Entity’s subscription.

Cancel

Cancellation supports the same settlement controls as customer subscriptions. Prefer end_of_period unless the merchant explicitly intends to terminate access immediately.

Remove an unused identity

Removal is allowed only when the identity has no active, pending, or incomplete subscription. Historical billing records remain immutable.
Stripe webhooks are authoritative for paid activation. Do not grant paid access from a browser redirect or checkout callback alone.