OpenA vendor-neutral contract.
The specification defines the model and evaluation semantics. OEREP carries those decisions over HTTP using generic SDK providers.
Read the protocol → Open source · v0.1 draft Product entitlements.
Product entitlements.
A shared contract.
Define what a customer can use—and how much—in a model your application owns. Evaluate plans, overrides, and grants through a consistent API, independent of your billing vendor.
Apache-2.0Self-hostableTypeScript + Python
ONE CUSTOMER. A CLEAR ANSWER.
A
AcmeBusiness plan
Resolvedseats.max250 seats
Plan default100
Negotiated override250
Effective entitlement250
OVERRIDE / Every decision has a reason.
Your terms. Your infrastructure.Delivered through the open OEREP protocol.
Illustrative data from the included demo.
BUILT FOR THE ENTITLEMENT LAYERFeatures & limits✳Negotiated contracts✳Trials & grants✳Self-hosted products
DEFINED BEHAVIOR, ACROSS IMPLEMENTATIONS.
Define the agreement.
Keep the meaning.
Features and limits have explicit types. Resolution has a defined order. Implementations can be tested against the same requirements, so a change of backend does not have to change your product gates.
01Your applicationFeatures declared in code
02One SDK APITypeScript or Python
03OpenEntitlementOEREP · your service · your data
Write the gate.
Let the agreement change.
Check a feature. Read a limit. Inspect why a decision was made. Your application uses the same API whether a customer is on a standard plan or a negotiated contract.
Meet the SDKconst client = createClient({
catalog,
provider: new RemoteProvider({
baseUrl: 'https://entitlements.example.com',
}),
});
await client.isEnabled('sso', { organizationId });
await client.getLimit('seats.max', { organizationId });from openentitlement import RemoteProvider, create_client
client = create_client(
catalog=catalog,
provider=RemoteProvider(
'https://entitlements.example.com',
),
)
context = {'organization_id': organization_id}
client.is_enabled('sso', context)
client.get_limit('seats.max', context)POST /oerep/v1/resolve/seats.max HTTP/1.1
Host: entitlements.example.com
Content-Type: application/json
Authorization: Bearer <evaluation-token>
{
"context": {
"organizationId": "acme"
}
}STANDARD PLANS. REAL-WORLD EXCEPTIONS.
Same product.
Different agreements.
A plan is the starting point. Overrides replace a value. Grants add quota. Switch between demo customers to see how the pieces fit.
EXPLORE THE MODEL
Illustrative examples, evaluated locally in this page. Run the quickstart to query the actual service.
Run the live demo →A
Business planAcme
seats.maxNegotiated from 100 to 250projects.maxProjects the organization may createapi_calls.monthlyNo finite capsso.enabledBoolean feature gateLESS COUPLING. MORE CLARITY.
Open contracts.
Inspectable decisions.
OpenEntitlement resolves what an organization may do. Authentication, permissions, release flags, and usage counting stay with the systems that own them.
More than yes or no.
Return the effective value, plan value, applied grants, stale overrides, and reason. Make decisions support teams can understand.
Understand resolution →Host it on your terms.
Run the service with Postgres, try it in memory, or embed a provider. No billing account is required.
Self-host the service →START WITH ONE ENTITLEMENT.
Your first decision
is a curl away.
Run the reference service and inspect the value, source, and reason behind a decision.
Get started →OPEN DEVELOPMENT
The specification, reference service, SDKs, and conformance suite are Apache-2.0 licensed. The draft and its implementation are available for inspection.
Review the source ↗