Managing Access

The DPDP Accelerator provides two ways to access its capabilities:

1. Access to the Consent Portal — control what users can do when they sign in to the Consent Portal.
2. Direct API access — allow applications and backend systems to call the accelerator APIs directly using an access token.

If you are setting up access for people who use the Consent Portal, start with Part 1: Managing access to the Consent Portal.

If you are integrating the accelerator with another application or testing its APIs using curl or Postman, go to Part 2: Managing access to the APIs directly.

---

Part 1: Managing access to the Consent Portal

The DPDP Accelerator includes the Consent Portal, which is used by different types of users. Since the same portal is used for different purposes, each user is assigned a role that determines what they can access and manage.

Understand the built-in roles

The DPDP Accelerator comes with three predefined roles. Each role includes a set of permissions that defines what the user can do in the Consent Portal.

Role	Intended for	What they can do
dpdp-consent-user	Data Principal	Manage their own consents, view history and track their own complaints etc.
dpdp-consent-admin	Data Fiduciary Administrator	Manage all consents, purposes and data elements and manage event notifications
dpdp-consent-dpo	Data Protection Officer and complaint-handling staff	View and manage complaints across the organization.

Understanding roles and scopes

Roles provide a convenient way to group permissions, while scopes are what the system actually checks when a user performs an action.

For example, the Data Fiduciary Administrator role has a broader set of scopes because administrators need access to more functionality. The Data Principal role has only the scopes required for users to manage their own data and complaints.

You can also create custom roles when the built-in roles do not match your organization's requirements. Assign only the scopes required for each role.

tip

Haven't created your users yet? Follow Configuring Users and Roles to create users and assign these roles before continuing.

Scope reference

The following sections provide the technical mapping between API operations, required scopes, and the built-in roles.

You normally do not need to work with these scope names when assigning the predefined roles. They are mainly useful when you are creating custom roles, configuring an API integration, or troubleshooting an authorization error.

Consent management

Operation	Required scope(s)	Admin	Data principal	DPO
Sign in and manage own consents	internal_login	✓	✓	✓
View or manage other users' consents	internal_consent_mgt_consent_view, internal_consent_mgt_consent_create, internal_consent_mgt_consent_update	✓	✗	✗
View purposes	internal_consent_mgt_purpose_view	✓	✗	✗
Create, update, or delete purposes	internal_consent_mgt_purpose_create, internal_consent_mgt_purpose_update, internal_consent_mgt_purpose_delete	✓	✗	✗
View data elements	internal_consent_mgt_element_view	✓	✗	✗
Create or delete data elements	internal_consent_mgt_element_create, internal_consent_mgt_element_delete	✓	✗	✗

Consent history

Operation	Required scope	Admin	Data principal	DPO
View own status-audit history	consent:status-history:view:self	✓	✓	✗
View own full snapshot history	consent:history:view:self	✓	✓	✗
View organization-wide status-audit history	consent:status-history:view:any	✓	✗	✗
View organization-wide full snapshot history	consent:history:view:any	✓	✗	✗

Complaints

Operation	Required scope(s)	Admin	Data principal	DPO
Create, view, reply to, or transition own complaints	complaints:read:self, complaints:write:self	✗	✓	✗
View or manage any complaint in the organization	complaints:read:any, complaints:write:any	✗	✗	✓

Event notifications

Operation	Required scope	Admin	Data principal	DPO
View topics	notifications:topics:read	✓	✗	✗
Create or deregister topics	notifications:topics:write	✓	✗	✗
View subscriptions and delivery history	notifications:subscriptions:read	✓	✗	✗
Create, verify, or delete subscriptions	notifications:subscriptions:write	✓	✗	✗
View events and delivery history	notifications:events:read	✓	✗	✗
Publish events	notifications:events:write	✓	✗	✗
Poll event deliveries	notifications:events:poll	✗	✗	✗
Submit delivery-completion evidence	notifications:event-deliveries:complete	✗	✗	✗

The last two scopes are intended for applications that receive events. For example, you can create dedicated applications with only the permissions they require:

Integration	Scopes to assign
event-publisher	notifications:events:write
event-receiver	notifications:events:poll, notifications:event-deliveries:complete

---

Part 2: Managing access to the APIs directly

The roles described above control access for users of the Consent Portal.

For system-to-system integrations, you can use a machine-to-machine application to access the accelerator APIs. This is useful for testing APIs with curl or Postman, integrating the accelerator with another system, or running backend services that call the APIs.

Step 1: Create an application

1. Sign in to the Identity Server Console:

   https://<HOST>/console

2. Select Applications from the left navigation.

3. Click New Application.

4. Select Machine-to-Machine Application.

   This application type is intended for backend services and scripts that need to access APIs without an interactive user login.

   

5. Enter a name for the application, such as my-integration, and click Create.

6. Open the Protocol tab and note the Client ID and Client Secret. You will use these credentials to obtain an access token.

   

Keep the client secret secure. Do not commit it to source control or expose it in client-side applications.

Step 2: Authorize the required scopes

After creating the application, authorize the scopes required by the APIs you want to call.

1. Open the application's API Authorization tab.

2. Click Authorize an API.

3. Select the API you want to access, such as DPDP Consent History, Complaints, or Event Notification.

4. Select the scopes required by your integration.

   

   

Only authorize the permissions the application actually needs. For example, an application that only publishes events should not be given complaint-management or consent-management permissions.

Refer to the scope tables above to identify the scopes required for each operation.

Step 3: Get an access token

Use the client ID and client secret of your machine-to-machine application to request an access token using the OAuth 2.0 client_credentials grant.

curl -X POST "https://<HOST>/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<CLIENT_ID>" \
  -d "client_secret=<CLIENT_SECRET>" \
  -d "scope=internal_consent_mgt_consent_view"

Replace the following placeholders with values from your environment:

• <HOST> — the hostname of your Identity Server
• <CLIENT_ID> — the client ID of your machine-to-machine application
• <CLIENT_SECRET> — the client secret of your machine-to-machine application

Replace internal_consent_mgt_consent_view with the scopes authorized for your application. For multiple scopes, separate them with spaces.

Local testing with a self-signed certificate

Add -k to the curl command above if your local Identity Server uses the default self-signed certificate. Never use -k in production — configure a trusted CA certificate, or pass it explicitly with --cacert instead.

Step 4: Call the API

Once you have the access token, include it as a Bearer token in the API request. For example, fetching all consents in the tenant:

curl "https://<HOST>/api/identity/consent-mgt/v2.0/consents" \
  -H "Authorization: Bearer <ACCESS_TOKEN>"

Replace <ACCESS_TOKEN> with the access_token value from the response in Step 3.

The API validates the access token and checks whether it contains the scope required for the requested operation.

Troubleshooting authorization errors

If the request fails, check the HTTP status code:

• 401 Unauthorized — The access token is missing, invalid, or expired. Obtain a new access token and try again.
• 403 Forbidden — The access token is valid, but it does not contain the scope required by the API. Return to Step 2 and authorize the required scope for the application.

Next Steps

• Try Out: Consent — see the scopes and tokens from this page used in a real API call.
• Consent — learn how consent is given, reviewed, and revoked.
• Role Guide — the full reference for roles, scopes, and permissions.