Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
license:
name: GPL-v2.0
url: http://www.gnu.org/licenses/gpl-2.0.txt
version: 1.0.9
title: Bonita Delegation API
description: "<p> \n<a download=\"openapi.yaml\" href=\"./openapi.yaml\" target=\"_blank\" class=\"btn-download\">Download OpenAPI specification</a>\n<a download=\"postman.json\" href=\"./postman.json\" target=\"_blank\" class=\"btn-download\">Download Postman collection</a>\n</p>\n\n<hr>\n\nThe REST API lets you access the data with HTTP requests; it is useful when implementing rich web forms / pages for a good user experience.\n\nAn open source [java client](https://github.com/bonitasoft/bonita-java-client) is implemented above the HTTP API. It is available on [Maven central](https://search.maven.org/search?q=g:%22org.bonitasoft.web%22%20AND%20a:%22bonita-java-client%22).\n\nIf your application is using a technology other than Java, you can integrate it with the Bonita solution using the Web REST API. This API provides\naccess to all Bonita objects (like processes, tasks, users, connectors etc.), to execute operations on them (create, retrieve, update, delete).\nYou can use these operations to create a workflow with Bonita and integrate it into your application. The Bonita Engine remains responsible for executing\nthe workflow logic (connectors, gateways with conditions, messages, timers etc.) while your application gives access to the workflow.\nUsers can manage processes and tasks, and perform administrative activities.\n\n### API Extensions\n\nYou can create [Rest API Extensions](https://documentation.ofelia.com/bonita/latest/api/rest-api-extensions) to extend the Rest API by adding missing resources (not provided by the Rest API).\nIt is possible for an extension to interact with the engine (via the API) or with any other external service (for example a database, a directory, or a web service).\n\n### Create a resource\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/ `|\n|:-|:-|\n| Request Method | POST|\n| Request Payload | an item in JSON|\n| Response | the same item in JSON, containing the values provided in the posted item, completed with default values and identifiers provided by Bonita Engine.|\n\n### Read a resource\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/{id} `|\n|:-|:-|\n| Request Method | GET|\n| Response | an item in JSON|\n\nExample `http://.../API/identity/user/5 `\n\n#### Extend resource response\n\nOn some resources, in GET methods the `d` (deploy) URL query parameter can be used to extend the response objects. The value of this parameter consists of an attribute for which you want to make an extended request (called a deploy) and retrieve attributes of a linked resource.\nThis means that instead of retrieving the ID or a parent or referenced resource, you can retrieve the full object.\n\nFor example, when you retrieve a task, you can also retrieve the process definition attributes in addition to the process definition ID that is already part of the task resource.\nThe supported deploy values for a task include its process (d=processId).\n\nSpecifiy multiple `d` parameter to extend several resources. For instance, to retrieve the flow node of id 143 and the associated process, process instance and assigned user, call `/API/bpm/flowNode/143?d=processId&d=caseId&d=assigned_id`\n\n#### With compound identifier\n\nThe order of the identifier parts for each resource type is given in the table above.\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/{id_part1}/{id_part2} `|\n|:-|:-|\n| Request Method | GET|\n| Response | an item in JSON|\n\nExample `http://.../API/identity/membership/5/12/24 `\n\n### Update a resource\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/{id} `|\n|:-|:-|\n| Request Method | PUT|\n| Request Payload | a map in JSON containing the new values for the attributes you want to change.|\n| Response | the corresponding item in JSON with new values where you requested a modification|\n\nExample `http://.../API/identity/user/5`\n\n#### With compound identifier:\n\nResponse: the corresponding item in JSON with new values where you requested a modification.\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/{id_part1}/{id_part2} `|\n|:-|:-|\n| Request Method | PUT|\n| Request Payload | ` a map in JSON containing the new values for the attributes you want to change `|\n| Response | ` the corresponding item in JSON with new values where you requested a modification`|\n\nExample\n`http://.../API/identity/membership/5/12/24 `\n\n### Delete resources\n\nUse the DELETE request to remove multiple resources.\n\n| Request URL | `http://.../API/{API_name}/{resource_name}/ `|\n|:-|:-|\n| Request Method | DELETE|\n| Request Payload | A list of identifiers in JSON, for example `[\"id1\",\"id2\",\"id3\"]`. Compound identifiers are separated by '/' characters.|\n| Response | `empty `|\n\nExample\n`http://.../API/identity/membership/ `\n\n### Search for a resource\n\nThe required object is specified with a set of filters in the request URL. The URL parameters must be URL-encoded.\n\nResults are returned in a paged list, so you have to specify the page (counting from zero), and the number of results per page (count), additionally you can define a sort key (order). You can see the total number of matching results in the HTTP response header Content-Range.\nIf you are searching for business data using a custom query, there must be a [count query in the BDM](https://documentation.ofelia.com/bonita/latest/data/define-and-deploy-the-bdm). If there is no count query, results from a custom query on business data cannot be paged properly (the header Content-Range will be absent).\nFor business data default queries, the count query is defined automatically.\n\nThe available filters are the attributes of the item plus some specific filters defined by each item.\n\n| Request URL | `http://.../API/{API_name}/{resource_name}?p={page}&c={count}&o={order}&s={query}&f={filter_name}={filter_value}&f=... `|\n|:-|:-|\n| Request Method | GET|\n| Response | an array of items in JSON|\n\nExample\n`/API/identity/user?p=0&c=10&o=firstname&s=test&f=manager_id=3`\n\nFor a GET method that retrieves more than one instance of a resource, you can specify the following request parameters:\n\n* p (Mandatory): index of the page to display\n* c (Mandatory): maximum number of elements to retrieve\n* o: order of presentation of values in response: must be either `attributeName ASC` or `attributeName DESC`. The final order parameter value must be URL encoded.\n* f: list of filters, specified as `attributeName=attributeValue`. To filter on more than one attribute, specify an f parameters for each attribute. The final filter parameter value must be URL encoded.\n The attributes you can filter on are specific to the resource.\n* s: search on name or search indexes. Before Bonita 2024.1, the matching policy depended on the configuration of [word-based search](https://documentation.ofelia.com/bonita/2023.2/api/using-list-and-search-methods#word_based_search).\n For example, if word-based search was enabled, `s=Valid` returned matches containing the string \"valid\" at the start of any word in the attribute value word,\n such as \"Valid address\", \"Not a valid address\", and \"Validated request\" but not \"Invalid request\".\n If word-based search was disabled, `s=Valid` returned matches containing the string \"valid\" at the start of the attribute value, such as \"Valid address\" or \"Validated request\" but not \"Not a valid address\" or \"Invalid request\".\n Since Bonita 2024.1, the search mode can no longer be configured and a \"like-based\" algorithm is used. This means all the matching records for which the search term occurs anywhere in a phrase or a word are returned.\n\n### Errors\n\nThe API uses standard HTTP status codes to indicate the success or failure of the API call.\n\nIf you get a `401` response code :\n - make sure that the cookies have been transfered with the call\n - make sure that the cookies transfered are the ones generated during the last sucessfull login call\n - if one of the PUT, DELETE or POST method is used, make sure that the `X-Bonita-API-Token` header is included\n - if the X-Bonita-API-Token header is included, make sure that the value is the same as the one of the cookie generated during the last login\n - Maybe a logout was issued or the session has expired; try to log in again, and re run the request with the new cookies and the new value for the `X-Bonita-API-Token` header.\n"
x-logo:
url: images/ofelia-logo.svg
backgroundColor: '#19465f'
altText: Bonita API
href: /
servers:
- url: http://localhost:8080/bonita
description: Sample url for a local development server.
security:
- bonita_auth: []
bonita_token: []
- bearer_auth: []
tags:
- name: Delegation
x-displayName: Delegation
description: 'Delegate human tasks from one user (the delegator) to another (the delegate) for a bounded period and a whitelist of processes. Delegation grants the delegate visibility and execution rights on the delegator''s tasks without reassigning them: ownership and the audit trail are preserved. A user can hold at most one delegation rule at a time, and a rule''s status (scheduled, active, expired) is derived from its date range.
Id fields are sent as numeric `int64` in request bodies but returned as strings in responses, to avoid JavaScript precision loss on large `long` values; this is intentional and documented per field.
There is no `GET /API/delegation/rule/{ruleId}`: the engine does not expose a single-rule read, so fetch a rule through the search endpoint (`GET /API/delegation/rule`) filtered by `id`. This is a known API gap, not a spec omission.
This Web REST API is available in **Enterprise editions only**, since version 2026.2.
'
paths:
/API/delegation/rule:
get:
tags:
- Delegation
summary: Search delegation rules
description: '
Searches delegation rules with pagination and filters. The same endpoint serves regular users
(who see their own rule) and administrators (who see rules across users); authorization is
enforced by the engine.
- can order on `id`, `delegatorId`, `delegateId`, `startDate`, `endDate`, `lastUpdatedBy`, `lastUpdatedAt`
- can filter on `id`, `delegatorId`, `delegateId`, `startDate`, `endDate`, `lastUpdatedBy`, `lastUpdatedAt` and on `status` (a virtual filter accepting `scheduled`, `active` or `expired`)
- the free-text search term (`s`) is matched by the engine against the delegator and delegate user name, first name and last name
Available in Enterprise editions only, since Bonita 2026.2.
'
operationId: searchDelegationRules
parameters:
- $ref: '#/components/parameters/pageIndex'
- $ref: '#/components/parameters/pageCount'
- $ref: '#/components/parameters/pageFilter'
- $ref: '#/components/parameters/pageOrder'
- $ref: '#/components/parameters/pageSearch'
responses:
'200':
description: Successful operation
headers:
Content-Range:
schema:
type: integer
format: int64
description: The total number of matching items
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/DelegationRule'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
5XX:
$ref: '#/components/responses/ServerError'
post:
tags:
- Delegation
summary: Create or replace a delegation rule
description: '
Creates a delegation rule. `delegatorId` is optional and resolved from the session when
omitted (self-service); administrators may set it to create a rule on behalf of another user.
A user can hold at most one delegation rule: posting a rule for a delegator who already has
one replaces the existing rule (upsert).
Available in Enterprise editions only, since Bonita 2026.2.
'
operationId: createDelegationRule
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationRuleCreateRequest'
responses:
'201':
description: Delegation rule created
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationRule'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
5XX:
$ref: '#/components/responses/ServerError'
x-codegen-request-body-name: body
/API/delegation/rule/{ruleId}:
put:
tags:
- Delegation
summary: Update a delegation rule by ID
description: '
Replaces the `delegateId`, `startDate`, `endDate` and `processes` of an existing delegation
rule. The delegator of the rule cannot be changed.
Available in Enterprise editions only, since Bonita 2026.2.
'
operationId: updateDelegationRuleById
parameters:
- description: Numeric ID of the delegation rule to update (the `id` field returned by `DelegationRule`).
in: path
name: ruleId
required: true
schema:
type: string
pattern: ^[0-9]+$
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationRuleUpdateRequest'
responses:
'200':
description: Delegation rule updated
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationRule'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
5XX:
$ref: '#/components/responses/ServerError'
x-codegen-request-body-name: body
delete:
tags:
- Delegation
summary: Delete a delegation rule by ID
description: '
Deletes the delegation rule with the given ID. This is the only deactivation mechanism: there
is no soft delete or activation flag. Deleting a rule does not affect the underlying tasks,
which remain assigned to the delegator.
Available in Enterprise editions only, since Bonita 2026.2.
'
operationId: deleteDelegationRuleById
parameters:
- description: Numeric ID of the delegation rule to delete (the `id` field returned by `DelegationRule`).
in: path
name: ruleId
required: true
schema:
type: string
pattern: ^[0-9]+$
responses:
'204':
$ref: '#/components/responses/NoContent'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
5XX:
$ref: '#/components/responses/ServerError'
/API/delegation/task:
get:
tags:
- Delegation
summary: Search delegated tasks
description: '
Searches the human tasks a user can act on through an active delegation rule. Only
tasks covered by an `active` rule are returned: scheduled and expired rules yield nothing.
Tasks should be assigned to the delegator and remain assigned to them; the delegate gains visibility and execution rights
without reassignment.
- can order on `dueDate`, `priority`, `reachedStateDate`
- can search (`s`) on the task name and display name
- can filter on `delegateId` (must be numeric; scopes results to a delegate, enforced against the session user by (dynamic) authorization rules unless the caller is an administrator) and on `rootProcessName` (narrows results to a specific root process)
Available in Enterprise editions only, since Bonita 2026.2.
'
operationId: searchDelegatedTasks
parameters:
- $ref: '#/components/parameters/pageIndex'
- $ref: '#/components/parameters/pageCount'
- $ref: '#/components/parameters/pageFilter'
- $ref: '#/components/parameters/pageOrder'
- $ref: '#/components/parameters/pageSearch'
responses:
'200':
description: Successful operation
headers:
Content-Range:
schema:
type: integer
format: int64
description: The total number of matching items
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/DelegatedTask'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
5XX:
$ref: '#/components/responses/ServerError'
components:
responses:
ServerError:
description: Unexpected error.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
example:
message: An unexpected error occured.
NotFound:
description: The resource for the specified ID was not found.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
example:
message: Resource not found.
NoContent:
description: OK (no content).
BadRequest:
description: Bad request.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
example:
message: Bad request
Forbidden:
description: Forbidden, The request contained valid data and was understood by the server, but the server is refusing action.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
example:
message: Forbidden, The request contained valid data and was understood by the server, but the server is refusing action.
Unauthorized:
description: Authorization information is missing or invalid.
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
example:
message: Unauthorized
parameters:
pageIndex:
description: index of the page to display
explode: true
in: query
name: p
example: '0'
required: true
schema:
type: integer
minimum: 0
default: 0
format: int32
style: form
pageOrder:
description: can order on attributes
explode: true
in: query
name: o
required: false
schema:
type: string
maxLength: 250
pattern: ^[A-Za-z0-9%]{0,250}$
style: form
example: myProp%20ASC
pageFilter:
description: can filter on attributes with the format f={filter\_name}={filter\_value} with the name/value pair as url encoded string.
explode: true
in: query
name: f
required: false
schema:
type: array
items:
type: string
maxLength: 250
pattern: ^[A-Za-z0-9%]{0,250}$
style: form
example: abc%3d123
pageSearch:
description: can search on attributes
explode: true
in: query
name: s
required: false
schema:
type: string
maxLength: 250
pattern: ^[A-Za-z0-9%]{0,250}$
style: form
pageCount:
description: maximum number of elements to retrieve
explode: true
in: query
name: c
example: '10'
required: true
schema:
type: integer
minimum: 1
default: 20
format: int32
style: form
schemas:
ActivationState:
description: the state of the process definition (ENABLED or DISABLED)
type: string
enum:
- ENABLED
- DISABLED
DelegatedTask:
type: object
description: 'A human task that a user is allowed to act on through an active delegation rule,
returned by `GET /API/delegation/task`.
The task is still assigned to the delegator; delegation grants the delegate visibility and
execution rights but does not reassign ownership. The shape aligns with the legacy human-task
REST format (modernised to camelCase): `processDefinitionId` is exposed as `processId`,
`parentProcessInstanceId` as `parentCaseId`, `rootContainerId` as `rootCaseId`,
`expectedEndDate` as `dueDate` and `claimedDate` as `assignedDate`. The delegator, delegate
and delegation window are added on top so the front-end can render the delegation context
without a second round-trip.
All long id fields are serialized as strings to avoid JavaScript precision loss. Date fields
(`dueDate`, `assignedDate`, `reachedStateDate`, `lastUpdateDate`, `delegationStart`,
`delegationEnd`) are numeric, in milliseconds since epoch; some (such as `dueDate` and
`assignedDate`) may be `null`.
'
required:
- id
- name
- displayName
- state
- type
- priority
- processId
- parentCaseId
- rootCaseId
- actorId
- assigneeId
- executedBy
- executedBySubstitute
- flownodeDefinitionId
- delegator
- delegate
- delegationStart
- delegationEnd
- rootProcessInfo
properties:
id:
description: Identifier of the task instance. Serialized as a string to avoid JavaScript precision loss.
type: string
name:
description: Technical name of the task.
type: string
displayName:
description: Human-readable name of the task.
type:
- string
- 'null'
description:
description: Description of the task.
type:
- string
- 'null'
displayDescription:
description: Human-readable description of the task.
type:
- string
- 'null'
state:
description: Current state of the task (e.g. `ready`).
type: string
type:
description: Flow node type (e.g. `USER_TASK`).
type: string
priority:
description: Priority of the task (e.g. `NORMAL`).
type:
- string
- 'null'
dueDate:
description: Expected end date of the task, in epoch milliseconds, or `null` when none is set. (Maps to the engine `expectedEndDate`.)
type:
- integer
- 'null'
format: int64
assignedDate:
description: Date the task was claimed by its assignee, in epoch milliseconds, or `null` when unassigned. (Maps to the engine `claimedDate`.)
type:
- integer
- 'null'
format: int64
reachedStateDate:
description: Date the task reached its current state, in epoch milliseconds.
type: integer
format: int64
lastUpdateDate:
description: Date the task was last updated, in epoch milliseconds.
type: integer
format: int64
processId:
description: Identifier of the process definition. Serialized as a string. (Maps to the engine `processDefinitionId`.)
type: string
parentCaseId:
description: Identifier of the immediate containing process instance. Serialized as a string. (Maps to the engine `parentProcessInstanceId`.)
type: string
rootCaseId:
description: Identifier of the root process instance. Serialized as a string. (Maps to the engine `rootContainerId`.)
type: string
actorId:
description: Id of the actor that can execute this task. Serialized as a string.
type: string
assigneeId:
description: Id of the user this task is assigned to, or `0` if unassigned. Serialized as a string.
type: string
executedBy:
description: Id of the user who performed the task, or `0` if not yet executed. Serialized as a string.
type: string
executedBySubstitute:
description: Id of the user who performed the task on behalf of someone else, or `0` otherwise. Serialized as a string.
type: string
flownodeDefinitionId:
description: Identifier of the flow node definition. Serialized as a string.
type: string
delegator:
description: The user whose task this is (the delegator).
$ref: '#/components/schemas/DelegationUser'
delegate:
description: The user the task is surfaced to through delegation (the delegate).
$ref: '#/components/schemas/DelegationUser'
delegationStart:
description: Start of the delegation period, inclusive, in milliseconds since epoch. Same value as the delegation rule's `startDate`.
type: integer
format: int64
delegationEnd:
description: End of the delegation period, inclusive, in milliseconds since epoch. Same value as the delegation rule's `endDate`.
type: integer
format: int64
rootProcessInfo:
description: Deployment information of the process behind the root case that triggered the task, not the child case the task may directly belong to.
$ref: '#/components/schemas/ProcessDeploymentInfo'
example:
id: '2'
name: Validate request
displayName: Validate request
description: null
displayDescription: null
state: ready
type: USER_TASK
priority: NORMAL
dueDate: null
assignedDate: 1780576627723
reachedStateDate: 1780576595140
lastUpdateDate: 1780576627723
processId: '5270206374128493046'
parentCaseId: '1'
rootCaseId: '1'
actorId: '1'
assigneeId: '1'
executedBy: '0'
executedBySubstitute: '0'
flownodeDefinitionId: '7537946595085140972'
delegationStart: 1780524000000
delegationEnd: 1780696799999
delegator:
id: '1'
firstName: Walter
lastName: Bates
userName: walter.bates
iconId: null
title: null
jobTitle: null
creationDate: 1780477756657
createdBy: '-1'
lastUpdate: 1780477756657
lastConnection: 1780576504806
managerUserId: '0'
enabled: true
delegate:
id: '2'
firstName: Michael
lastName: Scott
userName: michael.scott
iconId: null
title: null
jobTitle: null
creationDate: 1780477806557
createdBy: '-1'
lastUpdate: 1780477806557
lastConnection: null
managerUserId: '0'
enabled: true
rootProcessInfo:
name: Vacation request
version: '1.0'
displayDescription: ''
deploymentDate: 1780576273140
deployedBy: '1'
configurationState: RESOLVED
activationState: ENABLED
processId: '5270206374128493046'
displayName: Vacation request
lastUpdateDate: 1780576574182
iconPath: null
description: ''
ConfigurationState:
description: the configuration state of the process (UNRESOLVED or RESOLVED)
type: string
enum:
- RESOLVED
- UNRESOLVED
DelegationUser:
type: object
description: 'User embedded in a delegation rule or a delegated task (delegator, delegate or last updater).
This is the engine `User` model serialized directly, so its field names (`userName`,
`managerUserId`, `creationDate`, ...) differ from the legacy snake_case `User` schema returned
by the `/API/identity/user` endpoints. The long id fields (`id`, `createdBy`, `managerUserId`)
are serialized as strings to avoid JavaScript precision loss, while the date fields
(`creationDate`, `lastUpdate`, `lastConnection`) are serialized as numeric epoch milliseconds.
'
required:
- id
- userName
- firstName
- lastName
- enabled
properties:
id:
description: User id. Serialized as a string to avoid JavaScript precision loss on large `long` values.
type: string
userName:
description: Login name of the user.
type: string
firstName:
description: First name of the user.
type:
- string
- 'null'
lastName:
description: Last name of the user.
type:
- string
- 'null'
title:
description: Civility title of the user.
type:
- string
- 'null'
jobTitle:
description: Job title of the user.
type:
- string
- 'null'
iconId:
description: Id of the icon row used as avatar, or `null` when no icon is set. Serialized as a string when present.
type:
- string
- 'null'
managerUserId:
description: Id of this user's manager, or `0` when none. Serialized as a string.
type: string
createdBy:
description: Id of the user who created this account (`-1` for system-created accounts). Serialized as a string.
type: string
creationDate:
description: Creation timestamp of the user account, in epoch milliseconds.
type: integer
format: int64
lastUpdate:
description: Last update timestamp of the user account, in epoch milliseconds.
type: integer
format: int64
lastConnection:
description: Last connection timestamp, in epoch milliseconds, or `null` if the user never logged in.
type:
- integer
- 'null'
format: int64
enabled:
description: Whether the user account is enabled.
type: boolean
example:
id: '2'
firstName: Michael
lastName: Scott
userName: michael.scott
iconId: null
title: null
jobTitle: null
creationDate: 1780477806557
createdBy: '-1'
lastUpdate: 1780477806557
lastConnection: null
managerUserId: '0'
enabled: true
DelegationRuleCreateRequest:
type: object
description: 'Body of `POST /API/delegation/rule`. Defines a new delegation rule.
`delegatorId` is optional: when omitted it is resolved from the current session
(self-service creation). An administrator creating a rule on behalf of another user provides
`delegatorId` explicitly.
The values must satisfy: `endDate` strictly after `startDate`, `delegateId` different from the
delegator, and a non-empty `processes` list. A violation is reported as `400`.
A user can hold at most one delegation rule: posting a rule for a delegator who already has one
replaces the existing rule (upsert).
'
required:
- delegateId
- startDate
- endDate
- processes
properties:
delegatorId:
description: Id of the user whose tasks are delegated. Optional; resolved from the session when omitted.
type: integer
format: int64
delegateId:
description: Id of the user receiving access. Must differ from the delegator.
type: integer
format: int64
startDate:
description: Start of the delegation period, inc
# --- truncated at 32 KB (44 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/bonitasoft/refs/heads/main/openapi/bonitasoft-delegation-api-openapi.yml