Plan your first integration.
Start with one product, one commercial source and one runtime. This guide explains Liceno’s intended integration model so you can define your requirements for your private beta evaluation. It is a planning guide; production API references and installation instructions are not yet published here.
1. Identify the commercial source
Record where the agreement lives: a billing subscription, a marketplace agreement or an enterprise contract. Identify the provider account as well as the external customer and agreement IDs. Different accounts can have overlapping identifiers.
Decide which upstream state is authoritative for access. An event can signal that something changed; it is not necessarily a complete or current description of the customer's rights.
Connect the systems that already own the relationship
Commerce and billing systems describe what was bought; marketplace and enterprise agreements may express those rights differently. Liceno’s intended role is to normalize these sources before projecting rights into software enforcement.
Stripe, Paddle and Lemon Squeezy are initial connection priorities. Lago, internal contract systems and Azure Marketplace are exploration paths; AWS is a later direction. Cloud GTM intermediaries such as Suger, Tackle, Clazar and Labra are also potential paths for marketplace state. Confirm each integration’s availability and scope for your private beta evaluation.
Entitlement context can also inform rollout tools such as LaunchDarkly or GrowthBook, with events for CRM and analytics. These are exploration paths: rollout tools retain their targeting and experimentation responsibilities, and commercial providers retain billing, tax and marketplace operations.
2. Define the software entitlement
Translate the commercial agreement into rights your application understands, independently of the provider's terminology.
For example, a subscription to a desktop editor might grant high-resolution export, a seat allowance and access to updates for a defined period. The entitlement captures those rights; a signed credential carries the subset the application needs to check.
Consider features, quantitative limits, seats, devices, concurrent use, metering policies, version or maintenance rights, and expiry or grace periods. Which dimensions matter depends on your software.
3. Choose how the runtime checks access
A connected application can use current server state. An intermittently connected or offline application needs an explicit credential lifetime and refresh policy. Air-gapped deployments also need a practical way to transfer credentials and updates.
Local verification checks a signature with a trusted public key, then checks the intended issuer, product or audience, validity period and required rights. A valid signature alone is not enough to enable a feature.
4. Plan the lifecycle
Work through upgrades, downgrades, renewals, refunds, suspension and manual overrides. The intended reconciliation model converges authoritative commercial state into canonical rights despite duplicate, retried or out-of-order events.
Decide what happens to credentials already issued. A disconnected application cannot immediately observe a refund or revocation. Token lifetimes, refresh rules and reconnection bound how long an older grant may remain usable.
5. Validate the complete path
Use scenarios that cross the commercial and runtime boundary:
- A new agreement grants only the intended features and limits.
- An altered, expired or wrong-product credential is rejected.
- Replayed or out-of-order events converge to the correct rights.
- Refund and downgrade behavior matches the defined offline policy.
- Key rotation and credential refresh behave as expected.
- Separate provider accounts and billing migrations preserve customer identity and rights.
The exact connector behavior, key-management procedure and SDK calls need verified implementation guidance before production use.
Bring your use case
Tell us where you sell, where your software runs and which lifecycle failures cost your team time. We can use this model to assess the integration and deployment requirements together.