Filter obligations using a formula. The obligation property ID should be enclosed in brackets [ ] and the value should be enclosed in single quotes ' '.

Supported formula operations include the following with documentation found here:

• Equals / NotEqual
• Contains
• IsEmpty / IsNotEmpty
• LessThan / LessThanOrEqual
• GreaterThan / GreaterThanOrEqual
• Date / Today / RelativeDate
• And / Or

Free-text search across all obligation properties, matching the in-app search. Combined with filter and any other parameters using logical AND. Maximum 1000 characters.

The field to sort by. Default is 'name'.

The direction to sort by. Default is 'DESC'.

Set to occurrences to add occurrences (each source obligation's first 5 occurrences, ordered by due date with undated last) and occurrenceCount (its total) to every obligation in the list.

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-id is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-email is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.