The authentication process produces an access token for your application, which you use to make requests. The access token is tied to the user that generated it, not to a particular library.
API requests made with an access token will execute actions on the currently active library of the user who generated the token. Therefore, if the user switches libraries, this will change the library that the API requests made with the token operate on, possibly unintentionally.
We provide some solutions for integrating clients that do not desire this behaviour.
If you are a user with multiple libraries and building your own applications, a workaround for the issue of having your applications switch libraries together with your user is to create a dedicated user in each library. This user's sole purpose should be to generate tokens for your application. As long as this user remains in the same library, the tokens it generates will act like library-bound tokens.
Running a large operation? Talk to us.
If you're managing a large operation with multiple libraries and outlets, it may be beneficial to have your own set of credentials that function similarly to a partner application. To inquire about obtaining these credentials, please contact us at [email protected].
You have a set of client credentials with which you can access multiple libraries. If your application allows users to generate access tokens through the OAuth auth code flow by logging in, it's important to make them aware that switching libraries will change the library that your application operates on.
Some partners don't provide a login method and request their users to produce a token from their API Settings page. If this is your case, no special cautions need to be taken because tokens generated this way are always bound to the same library.
Updated 4 months ago