How to download issued certificates via API using Bearer token?

Carlos.C.2188

Hello D2L team,

I’m currently using the Brightspace API to retrieve issued certificates for students in our institution via the endpoint:

bashCopiarEditarGET /d2l/api/bas/1.4/issued/users/{userId}

From the response, I obtain both the OrgUnitId and IssuedId, and construct the download URL as documented:

bashCopiarEditarhttps://ava.xpeducacao.com.br/d2l/awards/v1/{OrgUnitId}/certificate/render/{IssuedId}

However, this endpoint requires an active login session (via browser) and does not accept a Bearer token for authentication. When I try to download the file programmatically (e.g. using Python requests.get(...) with headers), I receive a 200 OK response with a Content-Type: text/html, which is the login page instead of the PDF file.

What I'm looking for:

I would like to know if there is an official API endpoint that allows:

• Downloading the issued certificate PDF using Bearer token authentication (without requiring an interactive login),
• Or retrieving a public or signed URL for temporary or permanent access to the certificate,
• Or any other recommended and supported way by D2L to automate the certificate download securely.

Ana.A.776

Hello @Carlos.C.2188

Thank you for reaching out in the Brightspace Community.

There are Brightspace APIs that allow you to retrieve already issued awards:
-you can fetch an issued award by providing the certificate identifier

-you can fetch all the issued awards for a specific user by providing the user’s identifier
However, the “without requiring an interactive login” is a challenge, as we do not allow direct service-to-Brightspace for our Brightspace APIs. All Brightspace APIs are made on behalf of a specific Brightspace user who must authenticate with the LMS as part of the authentication process.

If you are building an application that you expect to run without a user actively using it in a browser (headlessly), then we recommend the “service user pattern”:

-The LMS Admin should create a specific “service user” account in Brightspace (a user who’s only purpose will be to service this integration)
-The LMS Admin should create a specific “service role” to go with this user that carries only the role permissions required to run the APIs the application needs
-The LMS Admin registers/provisions the application with the proper scopes required to use the APIs needed
-During operation, the application will need to bootstrap by having an LMS Admin login as this service user once to gain an initial access token; after that point, the application can keep its access alive without need for human intervention using the two-legged “refresh token workflow” (by repeatedly turning in the one-use refresh token that comes with an access token to get a new access token/refresh token pair)

There are future plans to make provision and administration of these kinds of headless app integrations easier, but for now, this pattern is what we recommend.

Please let us know if this helps!

Best, Ana