What role permissions are needed to prevent the "Not Authorized" API response?

Hi Mateen,

A resource for you to review is linked below that you should find useful:

• https://community.d2l.com/brightspace/kb/articles/1369-brightspace-api-authentication-guide-best-practices

A quick way to troubleshoot the API Service User role permission issue is to access the Brightspace UI with the API Service user account used to make the API calls. If in the UI and you can/cannot perform the action you want to perform through an API call, you'll need to adjust the role permissions accordingly. Also make sure you have included all the necessary Scopes for your application.

Hope that helps!

Please note that our API documentation does discuss the topic of managing API versions: both how we manage changes to versions and how we recommend you think about managing your code to align with that. Here's a summary you may find helpful when reading that topic in the documentation:

We divide our APIs into buckets called “product components” and each one of those manages its own version history.

We introduce a new API version for a product component whenever an API change would require a new version boundary to contain it. Brightspace itself has APIs that you can use to discover what API versions are supported by each individual Brightspace you are currently using to support your app.

Our support policy for APIs is a moving frame of time-windows that roll forward with each release:

• Basically, if an API version has been released in the past few years, we promise to provide full support for it.
  
• For API versions with a release date that’s a little bit older than that (usually about three years old), we only promise to offer non-priority support; those API versions have fallen “out of maintenance” — those API versions will remain as they are, but may not receive priority in support or fixing (if maintenance is needed). We call this state “Deprecated”.
  
• For API versions with a release date that is even older than that (usually about four years old and older), we do not promise to provide support at all; those API versions have fallen “out of support” — those API versions may change or go away with any new release of Brightspace. We call this state “Obsolete”.

However, we should also point out that, with very rare exceptions, we have hardly ever actually removed or broken any API version all the way back to the original release. Additionally, it is our practice to reduce the risk of breaking existing applications as much as we can, so when we do release a new API version for a product component, we generally ensure that all the APIs in that component operate as much as possible as they used to. For the most part, app maintainers should be able to just increment the version of the APIs they're using, do quick testing to ensure their apps still behave as they ought to, and move on. In rare cases, breaking changes do come with a new version; in those cases, the old version of the API should continue to work as always (in very rare cases, for security or performance reasons, we may have decided to actually remove old APIs, but we prefer in those cases to remove them rather than change them).

Because we offer this rolling window of support, and because we have historically extended access to APIs even in their obsolete state, we believe that app maintainers have plenty of time to adapt their code to the newer versions' requirements. Most commonly, this manifests as a JSON structure changing to contain new, required fields that must be sent with data sent by the app in a new API version.

It's hard in this forum to know what background information people here know and what they don't. Rather than try to explain to you what "deprecated" means, I was trying to explain to you the support lifecycle that we use to manage our APIs in Brightspace. For historical reasons (in our past, we had many different release versions of Brightspace deployed simultaneously across many clients; presently, we use a continuous release model to keep everyone on the same release version), Brightspace had the need to support a variety of API versions at once.

We built our lifecycle for our APIs to provide a version boundary when new features or changes appeared so that client applications could have a measuring point for determining when the Brightspace instance they were talking to at the moment supported those features or not.

We also have an aversion to breaking client applications and we know that our clients and partners aren't always in the position to uniformly update their code so everyone is always using a recent version of an API.

Our decision to support multiple versions of our APIs at once has lead to the present day where we have this long tail of APIs available. We fully support the most recent API versions; currently, for the lp product component, we fully support versions 1.43 through to 1.48 in market. We offer non-priority support to API versions 1.35 through 1.42 in lp. We don't explicitly offer any support for LP API versions older than 1.35; however, our practice of not wanting to break existing integrations and wanting to give our partners and clients as much time as possible to adapt their code has lead to us historically still offering even the "obsolete" versions of our APIs (for lp that's version 1.34 and older).

Every year, with the January release of Brightspace, we roll forward the support windows for our APIs: as of the 20.25.1 release, only the versions 1.46 and forward for lp will be fully supported; versions 1.43 through 1.45 will be partially supported, and versions older than 1.43 will not be explicitly supported.

I hope this helps make the picture clearer for you.