Vijaysree Kalvakolanu
09/10/2026, 10:43 AMAsk Inkeep
09/10/2026, 10:43 AMAsk Inkeep
09/10/2026, 10:43 AMelements_list_audit_logs endpoint lists audit logs for a specific elements config, scoped to tenant(1), while get_detailed_audit_log retrieves a detailed audit log by its specific log ID(2). These serve different purposes — one is a scoped list view tied to an Elements config, the other is a direct detailed lookup by ID — but I don't have documentation explicitly confirming they return "the same data" as each other or explaining the architectural reasoning behind having both.
For your other points (users, user_invites, and roles), I don't have information in the available sources that documents those specific Facts/Schema endpoints or confirms whether their data overlaps with Elements data endpoints. I can't verify or deny those specific claims without that documentation.
If you want, I can give a general answer based on my broader understanding of Permit.io's architecture rather than strictly cited documentation — just let me know.
If this relates to something not behaving as expected with your PDP or policy checks, it'd help to know:
1. Which Workspace / Project / Env you're using
2. The exact calls you're making (SDK code or CURL)
3. Your PDP version
4. Any relevant PDP logsAsk Inkeep
09/10/2026, 10:43 AMdavid
09/10/2026, 10:56 AMpermit_session cookie that permit.elements.loginAs() mints for a specific user in a specific tenant, and designed to be called from the browser inside the embedded Element.
Both exist because an API secret key can never reach a browser. The Elements endpoints let an end user with no API key manage users in their own tenant, with no ability to reach other tenants, assign above their permission level, or see Hidden Roles.
The responses also genuinely differ:
• elements/…/data/roles returns ElementsRoleRead (only roles assignable at the caller's level) vs RoleRead (every role, full permission definitions)
• Elements role assignment takes {role} while Facts requires {role, tenant}
• The Elements audit log endpoint is tenant-scoped, where /v2/pdps/…/audit_logs is environment-wide
Rule of thumb: server-side automation goes to Facts/Schema/PDP with your API key, and end-user self-service goes to Elements. Avoid calling Elements endpoints from a backend with an API key, since the scoping comes from the session rather than the key.Vijaysree Kalvakolanu
09/10/2026, 11:12 AMdavid
09/10/2026, 11:13 AMAsk Inkeep
09/10/2026, 11:13 AMAsk Inkeep
09/10/2026, 11:13 AMViewerContextType.user, the permit_session cookie, permit.elements.loginAs(), or how to authenticate a request as a ViewerContextType.user versus an API key. None of the provided sources address this specific error or the Elements viewer-context authentication flow, so I can't confirm or provide a fix from what's cited here.
Since this sounds like a specific request failing against your PDP/environment, it would help to know:
1. Which Workspace / Project / Env you're using
2. The exact calls you're making (SDK code or CURL)
3. Your PDP version
4. Any relevant PDP logs
If you'd like, I can give a general answer based on broader understanding rather than cited documentation — just let me know. Otherwise, reaching out at help@permit.io would get you a direct answer on the viewer-context/session flow.Ask Inkeep
09/10/2026, 11:13 AMVijaysree Kalvakolanu
09/10/2026, 11:14 AMVijaysree Kalvakolanu
09/10/2026, 11:15 AMVijaysree Kalvakolanu
09/10/2026, 11:15 AM{
"project_id": "e960c97f0ab74e768fd9fb856786b15e",
"environment_id": "5842004fae3b4508919cd5ff2effd448"
}Or Weis
09/10/2026, 11:33 AMVijaysree Kalvakolanu
09/11/2026, 12:04 PMpermit_session cookie that permit.elements.loginAs() mints for a specific user in a specific tenant?Or Weis
09/11/2026, 12:06 PMOr Weis
09/11/2026, 12:08 PMVijaysree Kalvakolanu
09/11/2026, 12:28 PMOr Weis
09/11/2026, 12:51 PMVijaysree Kalvakolanu
09/11/2026, 12:57 PMOr Weis
09/11/2026, 1:01 PM