Feature Entitlements
The RSA Platform uses a two-level feature gate that controls which capabilities are available to each tenant and retailer.
Level 1: Platform Tenant Features
Controlled by the Platform API. A PlatformAdmin enables or disables features for an entire tenant.
/platform/api/v1/tenants/{id}/features/platform/api/v1/tenants/{id}/features/{featureKey}Example feature keys: fuel-offers, ecom-offers, digital-receipts, employee-discounts
Both levels must pass for a feature to be active for a retailer.
Level 2: Retailer Feature Flags
Controlled by the Admin API. A TenantAdmin can toggle features within their retailer, but only if the platform has enabled the feature at Level 1.
/admin/api/v1/features/admin/api/v1/features/{flagKey}Retailer feature flags are stored in Redis with a 5-minute TTL. Changes propagate within 5 minutes.
Feature Flag Impact on API Responses
| Feature | Affected Endpoints |
|---|---|
fuel-offers | GET /api/v1/offers/fuel, GET /pos/api/v1/offers/fuel |
ecom-offers | GET /api/v1/offers/ecom |
digital-receipts | GET /pos/api/v1/receipts/{basketId} |
employee-discounts | Offer resolution for Employee-type offers |
Feature-gated endpoints return 403 Forbidden when the feature is disabled.
Token-Level Enforcement
Feature entitlements also affect OAuth scopes. When a feature is disabled at platform level, the corresponding granular scope (e.g., pos:receipts:read) is excluded from the JWT even if the app has it registered. This means feature checks happen at token issuance, not just at the endpoint.
Querying Feature Status at POS
POS terminals can query the feature flags for a specific store:
/pos/api/v1/stores/{storeId}/featuresThis response is Redis-backed with a 5-minute cache. Use it to conditionally show or hide POS UI elements.