You can read more about modeling preferences and preferences in general in the Preferences guide. In the guide below, we walk through the technical details of integrating the Knock preferences model into your product.
Preferences live under a user or an object and are used to structure a set of rules about what notifications a recipient should receive (called a
PreferenceSet). They are designed to be flexible and expressive to accommodate complex scenarios like per-resource muting (example: muting notifications for a given Slack channel).
In the following examples, you'll see how to integrate preferences into your backend codebase using one of our server-side SDKs.
You can retrieve a given set of preferences using the
getPreferences method. Please note that even if the preferences are not set, you will receive an empty
PreferenceSet in response.
You can update an entire set of preferences using the
setPreferences method. This will overwrite any existing preferences set:
You can use the
setPreferences method to also set preferences with conditions that are evaluated. Please refer to the documentation on preference conditions to learn more.
You can update the preferences of up to 1000 users in a single batch by using the
users.bulkSetPreferences method. This executes an asynchronous job which will overwrite any existing preferences for the users provided. You can track the progress of the
BulkOperation returned via the bulk operation API.
By default, all preference sets are set with an
default. To set a per-tenant preference set for a user you must pass the
tenant.id as the
id of the preference set. At workflow execution time, Knock will select a matching per-tenant preference set for the workflow run when a
tenant is passed into your workflow trigger.
In the case in which the per-tenant preference set doesn't exist, the
default preference set is used.
Preferences can also be set for one or more recipients during a workflow trigger using inline identify.
One or more preference sets can be set inline for the recipient during the workflow trigger, including the ability to set per-tenant preferences by passing a dictionary of preference sets, where the key in the dictionary is the preference set id.
The preferences API can also be invoked from the client, provided you have authenticated a user first and have a valid API token.
Note: at this time only the current user's preferences can be retrieved or updated.