Description:
To support features like user portals, the API must provide a way to retrieve all Group IDs associated with a specific user. This enables the caller to group consents by Group ID using existing search API parameters.
Note: Group ID was Client ID in earlier versions.
The consent management API should expose this as a consent-domain lookup, not as a user resource. The service does not own users and does not maintain a user table. The userId is only a filter value stored against consent authorization resources.
Proposed endpoint:
GET /consents/group-ids?userId={userId}
Required header:
org-id: {orgId}
The API should return only distinct group IDs. It must not resolve or return group metadata such as group name, description, image, or similar fields. The caller, such as the portal backend, is responsible for resolving the authenticated user, calling this API with the resolved userId, fetching group metadata from the configured metadata resolver, and returning enriched group data to the frontend.
Expected response:
{
"groupIds": [
"tpp-client-123",
"tpp-client-456"
],
"count": 2
}
OpenAPI schema:
ConsentGroupIdsResponse:
type: object
required:
- groupIds
- count
properties:
groupIds:
type: array
description: Distinct group IDs from matching consents.
items:
type: string
count:
type: integer
description: Number of distinct group IDs returned.
Suggested database lookup:
SELECT DISTINCT c.GROUP_ID
FROM CONSENT_AUTH_RESOURCE car
JOIN CONSENT c
ON c.CONSENT_ID = car.CONSENT_ID
AND c.ORG_ID = car.ORG_ID
WHERE car.USER_ID = ?
AND car.ORG_ID = ?
ORDER BY c.GROUP_ID;
This approach keeps the API aligned with the consent service’s data ownership. It avoids introducing user-resource coupling while still supporting the portal requirement to group consent entries by client.
Suggested Labels:
enhancement, api, consent-management
Description:
To support features like user portals, the API must provide a way to retrieve all Group IDs associated with a specific user. This enables the caller to group consents by Group ID using existing search API parameters.
Note: Group ID was Client ID in earlier versions.
The consent management API should expose this as a consent-domain lookup, not as a user resource. The service does not own users and does not maintain a user table. The
userIdis only a filter value stored against consent authorization resources.Proposed endpoint:
GET /consents/group-ids?userId={userId}Required header:
org-id: {orgId}The API should return only distinct group IDs. It must not resolve or return group metadata such as group name, description, image, or similar fields. The caller, such as the portal backend, is responsible for resolving the authenticated user, calling this API with the resolved
userId, fetching group metadata from the configured metadata resolver, and returning enriched group data to the frontend.Expected response:
{ "groupIds": [ "tpp-client-123", "tpp-client-456" ], "count": 2 }OpenAPI schema:
Suggested database lookup:
This approach keeps the API aligned with the consent service’s data ownership. It avoids introducing user-resource coupling while still supporting the portal requirement to group consent entries by client.
Suggested Labels:
enhancement, api, consent-management