Working with Multiple Libraries

If you manage multiple Apicbase libraries and need to interact with each via the API, the recommended approach is to generate a Service Account Token per library. Service account tokens are bound to the library, not to a user account, so they are unaffected by who is logged in or which library is currently active in the UI.

For step-by-step instructions on generating a service account token, see Token types or the Quick Start Tutorial.

One token per library

Each library can have its own API application. Generate a separate token for each library you need to access and store them mapped to their respective library IDs. When making requests, use the token that corresponds to the library you intend to operate on.

# Requests to Library A
curl --request GET \
     --url https://api.apicbase.com/api/v2/library/recipes/ \
     --header 'authorization: Bearer TOKEN_FOR_LIBRARY_A'

# Requests to Library B
curl --request GET \
     --url https://api.apicbase.com/api/v2/library/recipes/ \
     --header 'authorization: Bearer TOKEN_FOR_LIBRARY_B'

Remember that each library will have its own Client ID and Client Secret, separate from any other library. When managing multiple libraries, store each library's credentials independently and keep track of which credentials belong to which library.

This matters most when refreshing tokens. Access tokens expire after 7 days, and refresh requests must use the Client ID and Client Secret of the application that issued the token. Using the wrong credentials will fail. Make sure your token refresh logic is wired to the correct application credentials for each library.

# Refreshing a token — use the credentials for the library that issued it
curl --request POST \
     --url https://api.apicbase.com/oauth/token/ \
     --header 'content-type: application/x-www-form-urlencoded' \
     --data 'grant_type=refresh_token' \
     --data 'client_id=CLIENT_ID_FOR_LIBRARY_A' \
     --data 'client_secret=CLIENT_SECRET_FOR_LIBRARY_A' \
     --data 'refresh_token=REFRESH_TOKEN_FOR_LIBRARY_A'

For partners

Partner applications that allow customers to connect their own libraries via OAuth should inform users that the resulting token operates on whichever library the user has active. If a user switches their active library in the Apicbase UI, the token will follow.

To avoid this, library owners can generate a service account token from Library Settings → API Settings and provide it to your application directly, instead of going through the OAuth authorization flow. See Token types for the distinction.

If your application needs to operate across multiple libraries using personal tokens, use the accounts endpoints to manage which library is active before making requests:

• Get libraries — GET /api/v2/accounts/libraries/ — returns all libraries the token's user has access to, along with their IDs and status
• Get active library — GET /api/v2/accounts/libraries/active/ — returns the library currently active for the token's user
• Switch active library — POST /api/v2/accounts/libraries/active/ — switches the active library before subsequent requests

A typical multi-library flow would be: call Get libraries once to discover and store the available library IDs, then call Switch active library before each operation that targets a specific library, and confirm the switch with Get active library if needed.

Note that switching the active library via the API changes it for that user's session. If the same user account is used in the Apicbase UI simultaneously, this can cause unexpected behavior. For stable multi-library access, service account tokens — one per library — remain the recommended approach.

If your partner application needs access to many customer libraries at scale, contact [email protected] to discuss options.