A subscription check often starts as a small condition in a service method. Then you add another plan, a monthly allowance, an exception for one customer, and a second application that needs the same rules.
That is the problem we’re working on with Pmitz, short for Plans and Limits. I’m part of the team behind it. It’s an Apache 2.0 project for managing subscription feature access, usage limits, and usage recording.
The aim is to make what a plan includes easier to manage as your product grows. Any application that can call an HTTP API can integrate with the remote service.
Two questions before allowing an action
Imagine a document application with an export feature. A customer’s plan includes 100 exports per month.
Before allowing an export, your application needs to answer two questions:
- Does this subscription include exports?
- Is there enough allowance left for this export?
Those are separate decisions. A customer can have access to a feature and still have used up their allowance. Someone else might have no access at all, regardless of their usage.
Pmitz keeps subscription entitlement and usage-limit verification separate, and also provides a combined API. Its combined result distinguishes NOT_ALLOWED, LIMIT_EXCEEDED, and AVAILABLE, with remaining usage information.
This gives the application enough information to show the right outcome: unavailable on this plan, allowance used up, or ready to use.
Define the product rules
Pmitz models products, features, plans, subscriptions, and usage. A plan specifies included features; limits constrain how much a feature can be used.
Here is an illustrative product definition following the current documented configuration structure:
{
"productId": "documents",
"features": [
{
"featureId": "export",
"limits": [
{
"type": "CalendarPeriodRateLimit",
"id": "monthly-exports",
"quota": 100,
"periodicity": "MONTH"
}
]
}
],
"plans": [
{
"planId": "standard",
"includedFeatures": ["export"]
}
]
}
This defines product rules. It doesn’t create the customer’s subscription or provision the database. Those need to be set up through the appropriate repositories or API operations.
The example uses a calendar-aligned monthly limit. Pmitz also supports count limits, such as how many resources someone can hold at once, and user-specific limit overrides.
One set of rules across multiple applications
When a product spans several services, each one needs a consistent view of what a customer can access and how much they have used.
Pmitz can run as a standalone service behind a REST API. Applications call it over HTTP rather than reimplementing subscription and limit logic in each language.
The API includes operations to load product configuration, manage subscriptions, check entitlement, check limits, read usage, and record usage. The current remote server uses API-key authentication through the X-Api-Key header.
A typical application flow is:
- Identify the customer and the feature they want to use.
- Verify subscription access and the required usage allowance.
- Record the consumption and coordinate the business action.
- Return an appropriate result to the customer.
Decide what the allowance belongs to. A limit for an individual user is different from one shared by a subscription or organization. Pmitz supports individual users, subscriptions, and directory groups; callers need to use the intended subject consistently.
Integrate through the REST API
Your application communicates with Pmitz through HTTP requests. That means teams can share subscription rules and usage data across services without tying their applications to a particular programming language or framework.
Keep credentials on the server side. Your backend identifies the customer, calls Pmitz with the API key, and applies the decision before performing the requested action. The frontend can display remaining usage, but enforcement belongs in the backend.
You can host the open-source service yourself, or use our managed SaaS where we operate Pmitz and handle hosting and maintenance. In either case, the application-level concern is the same: which features the customer can access, the applicable limits, and the usage consumed.
Usage recording needs an explicit failure policy
A limit check and a completed business action are different events. If you record an export and then generating the file fails, should the attempt count?
That decision belongs to the application. Pmitz exposes usage reduction as well as recording, but retries and compensation need to match the action you are charging against an allowance.
A pre-check also isn’t a reservation for a later action. Two separate requests should not be assumed to provide an exactly-once or concurrency guarantee. Test parallel requests, retries, and failures against the storage and deployment you choose.
With a remote service, decide how your application handles timeouts and unavailable service responses. Keeping the rules in one place helps with consistency, but the integration still needs a deliberate failure policy.
Try it and tell us where the integration gets awkward
The repository contains the current implementation, integration examples, database setup instructions, and deployment documentation:
We also offer Pmitz as a managed SaaS, while keeping the open-source implementation available for self-managed deployments.
I’d like feedback from developers building subscription products: where do your current plan checks become difficult to maintain, and what would make integrating a shared plans-and-limits service easier?
Top comments (0)