Hello, can someone please help me understand this?...
# permit-saas
v
Hello, can someone please help me understand this? I found that the Elements data/* endpoints are just scoped views of the same underlying data that the Facts/Schema/PDP endpoints expose. 1. api.permit.io/v2/elements/…/users returns same data as end_user → GET /v2/facts/{proj}/{env}/users 2. api.permit.io/v2/elements/…/user-invites returns same data as user_invite → GET /v2/facts/{proj}/{env}/user_invites 3. api.permit.io/v2/elements/…/audit_logs returns same data as pdp_audit_logs → GETapi.permit.io/v2/pdps/…/audit_logs 4. api.permit.io/v2/elements/…/roles returns same data as role → GET /v2/schema/{proj}/{env}/roles Can you please confirm this is true and why do we have two different endpoints fetching the same set of data? Please let me know if I am missing something here. Truly appreciate your insights here. Thanks!
a
Hi @Vijaysree Kalvakolanu, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
I can only confirm part of what you're describing based on what's documented. For audit logs specifically, there are two distinct endpoints: the
elements_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 logs
To learn more, see the sources I considered: [[1] GET /v2/elements/{proj_id}/{env_id}/config/{elements_config_id}/data/audit_logs](https://api.permit.io/v2/redoc#tag/Audit-Elements-Data/operation/elements_list_audit_logs) [[2] GET /v2/pdps/{proj_id}/{env_id}/audit_logs/{log_id}](https://api.permit.io/v2/redoc#tag/Audit-Logs/operation/get_detailed_audit_log)
d
Hi Vijaysree, you're half right. Both families read from the same source of truth, but they aren't duplicates. They differ in who calls them and with what credential. Facts/Schema/PDP is your management plane: env-level API secret key, called from your backend, full environment scope. *Elements `data/*`* is the delegated end-user plane: authenticated by the
permit_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.
v
@david How do I get ViewerContextType.user? I am getting an error message, "error_code": "FORBIDDEN_ACCESS", "message": "Your data was not changed, we could not let you perform this action, this request requires authentication using ViewerContextType.user but you provided ViewerContextType.api_key. Try to perform this request with ViewerContextType.user.\nIf you verified that you are using ViewerContextType.user, contact our support on Slack for further guidance."
d
@Ask Inkeep what do you think?
a
Thanks for tagging me @david. I'll look through relevant sources and get back to you shortly.
I don't have documentation in the available sources that covers
ViewerContextType.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.
Feel free to tag me with additional questions. I also appreciate feedback, it helps me improve. 👍 button 👎 button
v
curl --location 'api.permit.io/v2/elements/…/users' \ --header 'authorization: Bearer permit_key_xxx'
This is the curl command
Copy code
{
  "project_id": "e960c97f0ab74e768fd9fb856786b15e",
  "environment_id": "5842004fae3b4508919cd5ff2effd448"
}
o
Hi @Vijaysree Kalvakolanu can you share what you’re trying to do - so we can provide better guidance. In general Elements API is meant to run on the frontend (browser) end-customer side- which is a low trust and risky environment. The backend API / PDP API is meant to run on your backend infrastructure, which is a high trust and less risky environment
v
Hey @Or Weis Could you please let me know if there is a way for us to fetch this
permit_session
cookie that
permit.elements.loginAs()
mints for a specific user in a specific tenant?
o
If you're using the frontend-only option, then no- that violates the browsers cross origin policy.
It sounds like you're trying to hack something together, and not use the product as described. I suggest you avoid doing that, and instead tell us what you're trying to do and we can tell you if /how to go about it
v
Hey @Or Weis I am not doing any such activities. I am actually building connectors for Hevo. so I am currently working on building permit.io as a source connector to our users. In order to support this Elements object, I understand we need to user login session cookie, so I just wanted to know if there is any way for us to fetch that so users can fetch the data through this object. Please refer to our docs to understand I am working on docs.hevodata.com
o
Elements are meant exclusively for embedding our ready made components as-is into your UI. You are not supposed to utilize them directly, aside from the basic setup If you need to export/connect to/ or otherwise use data from Permit you should use the regular api or PDP api, not elements
v
@Or Weis So let's say a user is creating a pipeline in Hevo using permit.io as source, I have built all the objects except for Elements. I am currently blocked on this because of login session cookie. So does this mean this object should not be implemented in a connector? Do users generally don't have the requirement to fetch this data? If at all they want this data, can they use the other equivalent endpoints I shared in the initial conversation to fetch the data. I understand the above endpoints fetch the entire data and elements return a subset of this entire data. I would appreciate your insights here, thanks!
o
Yes, there is no reason to source the Elements data separately, it's meant as a an embedded display only over the common api data.
👀 1