nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

"system" or "service" user for offline processing?

Ryan Chappell

In this bit from the auth docs (https://developer.blackbaud.com/skyapi/docs/authorization):

You can store this access token (and the refresh token) in your application, and use it when making API calls on that user's behalf.

My understanding is this would be used during user browser sessions. For offline processing, do we create “system” or “service” user for those API interactions?

So for example, we want to call Altru API to update a constituent record when they complete an aquarium post-visit survey. Do we need a user created for these offline interactions?

Find more posts tagged with

Comments

Ben Regier

@Ryan Chappell
The first time you get your access and refresh token, you will need to authenticate with a user account. This can be a service account, your own account, or whatever you want depending on your preferences.

Once you have the tokens, you can store them so you won't have to go through that manual authentication process again, and can instead programmatically get new tokens whenever you need them using the refresh token. But any action you take with those tokens will be tied to the user account that originally completed the authorization.

Ben Lambert

@Ryan Chappell this is not for browser sessions - it's for ANY calls to SKY API. The OAuth flow is used to get a token attached to the consenting user (a Blackbaud ID account). We use this to enforce that user's security permissions - i.e., if the user doesn't have permission to do <x> in the product, it can't be done in the API.

So all API calls happen in the context of a Blackbaud ID user account so that we can respect that user's security permissions (which are controlled by an organization's admin). That user account can be an actual human at the organization, or could be a dedicated bespoke service account that you create for the purposes of your API scenario. So for example, an admin might create a Blackbaud ID named “Web site service account” and invite that account to your Blackbaud environment and grant only the permissions it needs to do the specific operation(s) you want when a constituent completes the survey. So you can think of your survey website as being a trusted backoffice user account with limited permissions (just the ability to update constituent records).

Hope that helps!

Ryan Chappell

@Ben Lambert:
So for example, an admin might create a Blackbaud ID named “Web site service account” and invite that account to your Blackbaud environment and grant only the permissions it needs

Perfect thank you!