Signals Notebook supports two authentication methods for programmatic access to our External APIs. The decision of which to use is best determined by the type of use cases being delivered.
1. API Key
The first method is via API key. The API key is set by the admin and is tied to a given user. The key can be expired by the admin, but is not expired on a given timeline. Access via the External APIs is controlled via the access rights for the assigned user. Any actions are recorded as being taken by the designated user. This method is optimal for server to server interactions, where an end user is not actively involved. We support multiple API keys, with a maximum of 10. This is designed to allow discrimination of different servers that interact with the External APIs, allowing both different access rules and different records in the audit trail of which integration was responsible for which change. We strongly caution against using this to interact with the APIs on behalf of actual end users without their direct interaction however as this would compromise the trustability of your audit trail. For more details, please refer to System Configuration Guide > System Settings > API Key.
2. Bearer Token Exchange
The second method is via a Bearer Token Exchange. This method essentially grants a temporary API key to a given user, which expires 30 days after it is last used. The admin can also force the expiration of tokens. The user is initially required to authenticate against Signals Notebook in order to be granted this token. This method is optimal for when your integration workflow involves an actual end user. Again, all actions taken are recorded as being conducted by that user. The use of the Bearer Token Exchange is documented in System Configuration Guide > Bearer Token Exchange. It does require us to create a Client ID for you, which can be requested via our Support organization.
Comments
0 comments
Article is closed for comments.