One feature vocabulary
Plans, product surfaces, usage records, and runtime checks refer to the same feature definitions.
Plans, features, and usage
Turn pricing into product access.
Entitlements keeps plans, feature access, usage counters, limits, and customer-specific overrides behind one source-owned service boundary.
Inspect the published API contractEntitlements domain
Commercial access boundary
Product boundary
Plan plus usage plus overrides resolve into one effective entitlement.
01
Plan
The subscribed feature bundle
02
Feature
Boolean or limited capability
03
Usage
Recorded consumption by subject
04
Override
Customer-specific commercial rule
Runtime checksUsage recordsBilling-independent
- Lifecycle
- Available · v1
- Interfaces
- REST · Connect/gRPC · MCP via Agent Gateway
- AWS path
- Design-partner pilot
- Commercial basis
- Perpetual source license
Product outcome
Pricing changes should not require permission logic scattered across the codebase.
Billing tells you that a commercial event happened. Entitlements answers what the customer can use right now. Keeping that decision in one domain lets product, sales, and engineering change packaging without teaching every service a different plan model.
Commercial flexibility
Customer-specific overrides and plan changes stay explicit instead of becoming permanent application branches.
Billing stays replaceable
Payment providers remain upstream integrations rather than the runtime source of product access decisions.
01 / Domain capabilities
A complete Entitlements boundary, not a thin endpoint wrapper.
Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.
01
Feature and plan catalog
Define the product capabilities that can be packaged and compose them into plans behind a stable domain contract.
02
Runtime access checks
Ask whether a company can use a feature before the product performs the protected action.
03
Usage and limits
Record idempotent usage and resolve remaining access against the effective feature configuration.
04
Customer-specific overrides
Grant or change a feature for a specific subject without copying plan logic into application services.
02 / Product workflow
One path from product intent to an enforceable result.
The overview stays business-readable. The documentation and published contract contain field-level detail.
- 01
Define the feature
Create a stable product key and decide whether access is boolean, limited, or usage-aware.
- 02
Compose the plan
Assign features and limits to the commercial package the customer selected.
- 03
Resolve effective access
Combine plan configuration, customer-specific overrides, and current usage.
- 04
Check or record
Authorize the product action, then record usage with the documented idempotency behaviour.
03 / Technical depth
Clear operational boundaries for the team that owns it.
Support is 12 months of updates and support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.
Check a company feature limitHTTP / JSON
POST /entitlements.v1.EntitlementService/CheckLimit
Authorization: Bearer $TOKEN
Content-Type: application/json
{
"subject_id": "company_72",
"feature_key": "active_projects"
}Durable commercial model
Feature definitions, plans, subscriptions, overrides, and usage records remain queryable in the customer environment.
Replaceable billing input
Billing systems can assign plans or trigger lifecycle changes without becoming the entitlement engine.
Domain events
Reviewed integrations can react to plan, usage, and threshold changes without embedding provider logic.
04 / Where it fits
Entitlements supports products with real tenant and commercial complexity.
These are product patterns, not customer case studies or measured outcomes.
B2B plan packaging
Starter, growth, and enterprise packages resolve through the same feature keys used by the product.
Usage-aware capabilities
API calls, seats, projects, storage, or other product actions can be checked and recorded through one service.
Negotiated enterprise access
A customer-specific feature or limit can override the base plan without creating a bespoke application fork.
Ownership model
Own the service without owning every release problem.
The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.
01
Licensed Go source for the entitlement domain
02
Published REST and Connect/gRPC contract
03
Customer-controlled plan and usage data
04
Custom feature models and billing adapters can be scoped
Published API evidence active
Customer-cloud deployment path
Depends on identity
Entitlements architecture review
Put Entitlements behind a product boundary your team can own.
Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.
Frequently Asked Questions
Common Questions & Answers
Everything you need to know about integrating and hosting this Launch Rail service.