Per-seat pricing for team products

One billing manager, many seats. Prorated automatically.

Sell a product where one customer pays for a team. Invitations, claims, and proration are handled by Polar so you don't have to build seat management yourself.

One product, many seats

A seat-based product is purchased by a single billing manager who decides how many seats they need. From there, they assign seats to teammates by email or by your own external customer ID.

Benefits only fire when a seat is actually claimed by the recipient, which keeps usage in step with billing. The billing manager doesn't receive benefits unless they assign a seat to themselves, so a finance buyer can pay without consuming a seat they'll never use.

The same primitive covers recurring subscriptions and perpetual licenses. Subscriptions stay in sync with the team while the plan is active; licenses grant benefits forever once a seat is claimed, and growth happens through new orders rather than mutating the original purchase.

Invite by email

Assign seats by email or external customer ID. Claim links handle onboarding.

Prorated changes

Adding seats charges immediately, prorated. Reducing seats issues a credit.

Customer Portal

Customers manage their own team without you in the loop.

API and webhooks

Assign seats programmatically and react to seat.claimed and seat.revoked events.

Three pricing models

Pick the shape that matches the way you sell to teams. The choice is made when the product is created.

  • Fixed price per seatEvery seat costs the same amount. The simplest option, and the easiest to launch with.
  • Graduated tiersEach tier range is billed at its own rate. Seats in tier 1 use the tier 1 price; seats in tier 2 use the tier 2 price. The total is the sum of every range.
  • Volume discountsA single rate is chosen by total seat count and applied to every seat. Crossing a threshold lowers the price for the whole subscription, not just the new seats.

Seat statuses

Polar separates the act of paying for a seat from the act of using one. Three statuses describe where any seat is in that process.

  • PendingA seat has been assigned and an invitation has been sent. The recipient hasn’t claimed it yet, and the billing manager can resend if the link expires.
  • ClaimedThe teammate accepted the invitation. Benefits are granted automatically and the seat counts toward the team’s usage of the product.
  • RevokedThe billing manager pulled access from a specific teammate. Benefits drop, but the subscription keeps paying for the slot until the seat count itself is reduced.
  • Reduce vs revokeRevoking frees a slot for reassignment. Reducing the seat count is what actually lowers the bill, and Polar issues a prorated credit for the unused remainder of the cycle.

API and webhooks

Seat assignments are first-class objects in the API. List them on a subscription, assign them programmatically when a customer onboards a teammate inside your app, and revoke them through the same endpoint.

On the receiving side, seat.claimed, seat.revoked, and subscription.updated webhooks let your own permission system stay in lockstep without polling.

The model supports up to 1,000 seats per subscription and arbitrary metadata on every seat, so role, team, or external user ID can travel with the assignment. Seat-based pricing is in beta today; enable it under Settings → General → Features.

Sell to teams

Create a seat-based product and Polar handles assignment, claim, and proration.