Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3709239305/Role+Actions#Administration-Users-Manage-API-Tokens

Panel
panelIconIdatlassian-light_bulb_on
panelIcon:light_bulb_on:
panelIconText:light_bulb_on:
bgColor#DEEBFF

Auth tokens can be used in the creation of HTTP request headers. For example, if using the curl command line tool:

-H "Authorization: Bearer <your_token>"

… a full curl request could be formulated like the following:

curl -i "http://customer.clinspark.com/clinspark/api/v1/exampleApiFunction" -H "Authorization: Bearer eyJVVUlEIjoiZWYzMTMxMWMtYzJhMS00NGE4SSylYzAtZGJlOGU2YTAyM2Q4In0="

User Account Permissions

A specific API role action must be assigned to a user account in ClinSpark to use the API. For most use cases, these are typically accounts that facilitate workflows via ClinSpark web services. Integration applications that use specific ‘system’ accounts in ClinSpark must also be configured with this role action.

...

Other than the assigned role action and intended use, there are no unique properties of accounts used for API invocation.

Credential Management

Customers are expected to manage all user account credentials intended for API use.

We strongly suggest customers follow security best practices by assigning highly complex passwords (up to 255 characters) to the accounts and rotating them regularly. More information about ClinSpark user account management can be viewed in this article: User Management

...

Customers are encouraged to create and manage multiple API users if they decide to adhere to a

...

strict credential management practice. Additionally, the creation and management of multiple bearer auth tokens set with expiry dates. This is our recommendation, so customers can properly process leavers/joiners with their own service account credentials, instead of having a pool of team members using shared credentials for singular service accounts.

Note

We discourage the practice of customers creating, sharing, and soliciting use of integration user accounts that contain API role actions outside of site organization teams.