To clarify, the
/bulk_enroll/v1/bulk_enroll endpoint lives in edx-platform, correct? That endpoint doesn’t factor in any enterprise-specific permissions which is why you’re able to get a valid response when calling it.
/enterprise/api/v1/enterprise-customer/<UUID>/course_enrollments endpoint on the other hand, uses edx-rbac in order to limit access based on the enterprise-specific roles available to a user. As this endpoint uses the
@permission_required decorator for the
enterprise.can_enroll_learners rule (defined here), only users that have a role that matches that permissions rule will have access. In this case, it’s looking for the user to have the “enrollment_api_admin” feature role. Generally, our worker users (e.g.,
enterprise_catalog_worker) are granted this feature role such that we can make service-to-service calls to endpoints with permissions such as this one.
The permissions for the
/enterprise/api/v1/enterprise-customer/ endpoint are based on whether or not your authenticated user is linked to at least one enterprise (via
DjangoModelPermissions). Do you have have an
EnterpriseCustomerUser record configured for your authenticated user to indicate they are linked to an enterprise? Staff/superuser users should get a valid response from this endpoint without an explicit
Unfortunately, as you mentioned, the
enterprise-catalog service is technically now a pre-requisite to use enterprise catalogs. When you create/update a catalog in edx-enterprise, it automatically syncs to the
enterprise-catalog service. Related, the checks during enrollment to verify that a given course is part of an enterprise’s catalog(s) also make a call to the
enterprise-catalog service as well.
I hope this helps to clarify some things for you!