The documented scope for /beta/sources/:id/load-accounts doesn't work

Feedback Bugs
, , ,
1

I’ve done some testing of the beta /load-accounts API with a configuration where I have a personal access token attached to an account with the SOURCE_SUBADMIN and a Governance group that limits the accounts access to the single source I am aggregating.

I’ve found that if I grant the PAT only the idn:accounts:manage scope, I cannot successfully perform a file-upload aggregation to the source. The response message is a 403 “The server understood the request but refuses to authorize it.”. If I add the idn:accounts-state:manage scope to the PAT then I can successfully upload the aggregation file.

I’ve just tested with a PAT that is an ADMIN role and found that the results are the same. I would guess that many people in the testing phase of moving to the replacement API are adding sp:scopes:all to their access tokens while they test.

2 Likes
2

Thanks for reporting this Ralph. I am only able to get this endpoint to work with sp:scopes:all. I have opened an engineering ticket (ISCAIM-23244) for them to fix the scope for this endpoint so it works correctly.

3

The correct scope is idn:sources:manage. We are updating the API spec to point to this scope.

1 Like
4

Hi Colin,

I can confirm that I’m also now seeing the behaviour you’ve described - I need sp:scopes:all, where when I was testing the other day prior to making the post I was able to perform the file upload/aggregation with the combination of the previously mentioned scopes:
idn:sources:manage
idn:accounts-state:manage

I had created three separate brand new accounts as part of work to move my connectors using the new endpoint to a least-privilege set of permissions (since this was not available when we originally implemented), so I’m very confident that it was working with those permissions at that time.

It’s worth noting that this shows that there has been a change to the endpoint without any notification, less than two weeks prior to the deprecation of the old endpoint - exactly why I previously raised my concerns about the replacement for a production endpoint being a /beta endpoint.

4 Likes
5

I agree a live API being deprecated for a BETA is very poor practice. We do not allow the use of BETA API’s in our production code as they can change or be deprecated without notice.

3 Likes