Based on the available documentation, the Permit FE SDK doesn't explicitly mention TTL (Time-To-Live) caching functionality. (1) (2) The SDK stores permissions in a local state that persists until you explicitly reset it using the

reset()

method. (2) Once you load permissions via

loadLocalState()

or

loadLocalStateBulk()

, they remain in the local state for the duration of the session unless manually cleared. (1) (2) If you need time-based cache invalidation, you would need to implement that logic yourself by calling

reset()

and reloading permissions after your desired TTL expires. (2)

To learn more, see the sources I considered: [[1] permit-fe-sdk](https://github.com/permitio/permit-fe-sdk/blob/main/README.md) [[2] https://github.com/permitio/permit-fe-sdk/blob/main/src](https://github.com/permitio/permit-fe-sdk/blob/main/src)

@Ask Inkeep help me pls

To manage real-time permissions without overloading your PDP, the PDP includes a built-in caching mechanism that can significantly improve performance. (1) The PDP server includes a configurable caching mechanism that stores results of policy decisions with a configurable time-to-live (TTL) . (2) When enabled, the cache stores results of policy decisions, providing performance benefits for frequently evaluated permissions. You can configure the cache using these environment variables: (1) • ​*PDP_CACHE_STORE*​: Set to

in-memory

or

redis

(default is

none

) • ​*PDP_CACHE_TTL*​: Time-to-live in seconds for cached items (default is

3600

) • ​*PDP_CACHE_MEMORY_CAPACITY*​: Memory capacity in MiB for in-memory cache (default is

128

) • ​*PDP_CACHE_REDIS_URL*​: Redis connection URL when using redis store The cache is supported for

/allowed

,

/allowed/bulk

,

/user-permissions

, and

/authorized_users

endpoints. (2) For the

/allowed/bulk

endpoint, the cache is applied to each individual query within the bulk request and is shared with the

/allowed

endpoint. Note that while caching significantly improves performance, it may lead to temporarily inaccurate results if permissions change during the cache TTL period. For your frontend, you can combine this PDP-level caching with your own client-side caching strategy. The PDP cache handles th

To learn more, see the sources I considered: [[1] Configurations](https://docs.permit.io/concepts/pdp/configuration) [[2] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview)

Actually, you ​*can*​ balance real-time performance and high availability - that's exactly what Permit.io's architecture is designed for. (1) (2) The PDP is designed to be highly available, performant, and physically close to your services to minimize latency and ensure high availability. (1) You have several deployment options to achieve both goals: ​*For High Availability:*​ • Deploy PDPs as ​*sidecars*​ next to each microservice for the lowest latency • Use a ​*cluster of PDPs*​ behind a load balancer for scalability and redundancy • Deploy a ​*centralized PDP*​ to handle authorization queries from multiple services ​*For Real-Time Updates:*​ The PDP is powered by OPAL (Open Policy Administration Layer) , which streams live policy and data updates to PDPs via WebSocket/Pub-Sub, ensuring zero-latency enforcement. This means your PDPs receive policy changes in real-time without requiring constant polling. ​*The Caching Strategy:*​ The PDP's configurable caching mechanism (with TTL) doesn't prevent real-time updates - it reduces redundant evaluations for the ​*same*​ permission checks. When permissions change in your control plane, OPAL streams those updates to all PDPs immediately, and the cache is updated accordingly. So you get: • ​*Real-time*​: Policy changes propagate instantly via OPAL streaming • ​*High performance*​: Cached results for frequently-checked permissions • ​*High availability*​: Multiple PDP instances with load balancing The trade-off with caching is that during the cache TTL period, you might see temporarily stale results ​*only if*​ permissions change mid-cache. You ca

To learn more, see the sources I considered: [[1] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview) [[2] Best Practices for Multi-Tenant Authorization](https://www.permit.io/blog/best-practices-for-multi-tenant-authorization)

@permit support automation2 help me pls

@Ask Inkeep help me pls

Based on the available sources, I don't have specific documentation about

getUserPermission()

or filtering instance-level permissions to extract only RBAC permissions for frontend initialization. The sources discuss RBAC concepts and multi-tenant authorization patterns (1) (2) , but they don't provide detailed guidance on using

getUserPermission()

specifically for your use case of filtering out instance-level permissions. For the best approach to initialize frontend permissions with RBAC-only data, I'd recommend reaching out to the Permit.io team directly at help@permit.io with: 1. Your specific use case (filtering instance_id permissions from getUserPermission() ) 2. Your current implementation approach 3. Whether you're looking for RBAC-only permissions or a mix of authorization models They can provide guidance on whether

getUserPermission()

is the right API for your needs or if there's a better approach for frontend permission initialization.

To learn more, see the sources I considered: [[1] Role-Based Access Control](https://docs.permit.io/how-to/build-policies/rbac/overview) [[2] Implement Multi-Tenancy Role-Based Access Control (RBAC) in MongoDB](https://www.permit.io/blog/implement-multi-tenancy-rbac-in-mongodb)

My goal is to be able to pre-load basic permissions on the frontend to improve the UX