B2B CIAM · Entitlement Service
What each customer bought, in one reliable service
Identity providers have no place for plans, seats or contract dates. We build an entitlement service that does — fed by CRM and billing events, read at login and by every API, and publishing changes so access follows the contract.
- Plans, features, seats and validity
- Fast, cached access checks
- Every change audited
Standards & integrations
- REST API
- OAuth client credentials
- PostgreSQL
- Redis
- Transactional outbox
- Event bus
Overview
Why entitlements need their own home
Tiers turned into roles multiply until nobody can read them, and plans stored in user attributes go stale the day a contract changes. An entitlement service keeps a product catalog, subscribers, subscriptions, entitlements with seats and validity, and per-customer overrides, with an immutable history of every change and its source. Writes go through a validated command API; reads come from a cached access-check endpoint that the Keycloak login flow and your APIs call.
What we deliver
- Entitlement data model and schema migrations
- Command API with seat and date invariants
- Cached access-check API
- Outbox publisher and event contracts
- Keycloak login-time authenticator and claim mapper
- Operational dashboards and audit reports
Capabilities
What Entitlement Service covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Product catalog
Products, plans and features with default limits, so packaging changes are data rather than code.
Subscribers for B2B and B2C
Entitlements attach to an organization or an individual, linked to CRM accounts and Keycloak identifiers.
Seat management
Seats are reserved, assigned and released atomically, with the seat limit enforced in the same transaction.
Fast access checks
A read-only, cached endpoint returns status, plan and seat for a subscriber, product and user, with no personal data in the response.
Change events through an outbox
Every committed change publishes a versioned event, so OpenFGA, caches and revocation workers stay in step without dual writes.
Overrides and audit
Sales-negotiated extras are time-limited overrides, and every change records its source: a CRM event, an admin action or a migration.
API
Entitlement API surface
A hot, cached read path and a validated write path.
| Endpoint | Caller | Purpose |
|---|---|---|
| GET /v1/access-check | Keycloak login extension, product APIs | Status, plan and seat for a subscriber, product and user |
| GET /v1/subscribers/{id}/entitlements | Admin portal, product UIs | All entitlements with effective features |
| POST /v1/subscribers | Onboarding orchestrator | Create a subscriber, idempotent on the CRM account ID |
| POST /v1/subscribers/{id}/entitlements | Onboarding orchestrator | Grant products, plans, seats and dates |
| PATCH /v1/entitlements/{id} | Onboarding orchestrator | Plan, seat, date or status change with optimistic locking |
| POST /v1/entitlements/{id}/seats | Admin portal, migration service | Reserve or assign a seat; conflict when the limit is reached |
| DELETE /v1/entitlements/{id}/seats/{user} | Admin portal, deprovisioning | Release a seat |
How it works
From first call to production
Model the catalog and subscribers
We map your products, plans, features, seat models and customer types into the data model.
Build the write and read paths
A command API with invariants, a cached access-check API, the outbox publisher and client-credential security.
Connect login and APIs
A Keycloak authenticator and your APIs call the access check, and events feed OpenFGA and revocation workers.
Use cases
Where teams put it to work
Multi-product, multi-tier SaaS
Each organization holds different products on different plans, with features resolved per plan and override.
Named-seat licensing
Seat limits are enforced when users are invited or join, and admins see exactly who holds a seat.
Trials, grace periods and renewals
Status moves from trial to active, grace and suspended, and access follows automatically.
FAQ
Entitlement Service questions, answered
What happens at login if the entitlement service is down?
The login extension caches recent answers and uses short timeouts. For paid products we fail closed — access is refused with a retry message — and the service runs highly available because login depends on it.
Does the token carry every feature?
No. The access token carries a lean claim: product, plan and status. Full feature maps and seat counts are read from the service when needed, so tokens stay small and don't go stale.
Can a customer have different contracts per product?
Yes. A subscriber can hold several subscriptions, each granting one or more products, with at most one active entitlement per product at a time.
Ready to roll out Entitlement Service?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.