@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.orchestration-cluster-api-rest-swagger.prerequisites.md

@@ -0,0 +1,40 @@
+# Try with Swagger — Prerequisites
+
+Before using Swagger UI, ensure you have:
+
+- **A running Camunda 8 Orchestration Cluster:** SaaS or Self-Managed
+- **Appropriate [access permissions](https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations)** to the resources you want to manage via the API (if authorizations are enabled).
+
+
+## Accessing Swagger UI
+
+### SaaS
+
+For SaaS clusters, Swagger UI is accessible through your cluster's dedicated endpoint.
+
+1. In the Camunda Console, go to your cluster
+2. In **Cluster Details**, find your **Region ID** and **Cluster ID**
+3. Use this URL format: `https://${REGION_ID}.api.camunda.io/${CLUSTER_ID}/swagger`
+
+**Note**
+Swagger UI is protected with CSRF. If you are logged into the Camunda Console, you can access Swagger UI directly. If not, you may need to log in first.
+
+**Example:**
+If your Region ID is `bru-2` and Cluster ID is `abc123-def456-ghi789`, your Swagger UI URL would be:
+`https://bru-2.api.camunda.io/abc123-def456-ghi789/swagger`
+
+### Self-Managed
+
+For Self-Managed deployments, Swagger UI is available at your configured [Zeebe Gateway](https://docs.camunda.io/docs/next/reference/glossary#zeebe-gateway) endpoint.
+
+**Default setup:**
+`http://localhost:8080/swagger`
+
+**Custom configuration:**
+Use the host and path defined for your Zeebe Gateway in the [configuration guide](https://docs.camunda.io/docs/next/self-managed/deployment/helm/configure/ingress/ingress-setup), then append `/swagger`.
+
+**Example with custom domain:**
+`https://your-zeebe-gateway.company.com/swagger`
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-swagger

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.orchestration-cluster-api-rest-swagger.using-swagger-ui-effectively.md

@@ -0,0 +1,27 @@
+# Try with Swagger — Using Swagger UI effectively
+
+### Making your first API call
+
+1. **Test connectivity**: Try the `GET /topology` endpoint to verify your connection and authentication
+2. **Explore endpoints**: Browse the available operations organized by category (processes, user tasks, variables, etc.)
+3. **Try sample requests**: Click "Try it out" on any endpoint to see the request form
+4. **Execute requests**: Fill in parameters and click "Execute" to see real responses
+
+### Understanding the interface
+
+- **Endpoints are grouped by resource type** - Find process-related operations under "Process Instances", task operations under "User Tasks", etc.
+- **Required parameters are marked** - Look for the red asterisk (\*) next to required fields
+- **Example values are provided** - Use the "Example Value" links to populate request bodies quickly
+- **Response schemas are documented** - Expand the response sections to understand the data structure
+
+### Testing workflows
+
+Use Swagger UI to test complete workflows:
+
+1. **Deploy a process** - Use `POST /deployments` to upload a BPMN file
+2. **Start a process instance** - Use `POST /process-instances` with your process definition
+3. **Query and manage** - Use search endpoints to find and interact with your data
+4. **Complete tasks** - Use `POST /user-tasks/{userTaskKey}/completion` to progress workflows
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-swagger

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.activate-ad-hoc-sub-process-activities.api.md

@@ -0,0 +1,33 @@
+# Activate activities within an ad-hoc sub-process
+
+`POST /element-instances/ad-hoc-activities/{adHocSubProcessInstanceKey}/activation`
+
+Activates selected activities within an ad-hoc sub-process identified by element ID.
+The provided element IDs must exist within the ad-hoc sub-process instance identified by the
+provided adHocSubProcessInstanceKey.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  adHocSubProcessInstanceKey (path, string, required)
+
+Request body:
+  application/json: AdHocSubProcessActivateActivitiesInstruction (required)
+    elements (AdHocSubProcessActivateActivityReference[], required) — Activities to activate.
+    cancelRemainingInstances (boolean) — Whether to cancel remaining instances of the ad-hoc sub-process.
+
+Responses:
+  204 — The ad-hoc sub-process instance is modified.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The ad-hoc sub-process instance is not found or the provided key does not identify an ad-hoc sub-process.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/activate-ad-hoc-sub-process-activities.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.activate-jobs.api.md

@@ -0,0 +1,33 @@
+# Activate jobs
+
+`POST /jobs/activation`
+
+Iterate through all known partitions and activate jobs up to the requested maximum.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: JobActivationRequest (required)
+    type (string, required) — The job type, as defined in the BPMN process (e.g. <zeebe:taskDefinition type="payment-service" />)
+    worker (string) — The name of the worker activating the jobs, mostly used for logging purposes.
+    timeout (integer, required) — A job returned after this call will not be activated by another call until the timeout (in ms) has been reached.
+    maxJobsToActivate (integer, required) — The maximum jobs to activate by this request.
+    fetchVariable (string[]) — A list of variables to fetch as the job variables; if empty, all visible variables at the time of activation for the scope of the job will be returned.
+    requestTimeout (integer) — The request will be completed when at least one job is activated or after the requestTimeout (in ms). If the requestTimeout = 0, a default timeout is used. If…
+    tenantIds (TenantId[]) — A list of IDs of tenants for which to activate jobs.
+    tenantFilter (TenantFilterEnum) — The tenant filtering strategy - determines whether to use provided tenant IDs or assigned tenant IDs from the authenticated principal's authorized tenants.
+    withLease (boolean) — Whether to activate the jobs with a lease. When true, each activated job is assigned a distinct, opaque lease token, returned as ActivatedJobResult.leaseToken.…
+
+Responses:
+  200 JobActivationResult — The list of activated jobs.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/activate-jobs.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-client-to-group.api.md

@@ -0,0 +1,28 @@
+# Assign a client to a group
+
+`PUT /groups/{groupId}/clients/{clientId}`
+
+Assigns a client to a group, making it a member of the group.
+Members of the group inherit the group authorizations, roles, and tenant assignments.
+
+- Required permissions: UPDATE on GROUP.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  groupId (path, GroupId, required)
+  clientId (path, ClientId, required)
+
+Responses:
+  204 — The client was assigned successfully to the group.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The group with the given ID was not found.
+  409 ProblemDetail — The client with the given ID is already assigned to the group.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-client-to-group.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-client-to-tenant.api.md

@@ -0,0 +1,27 @@
+# Assign a client to a tenant
+
+`PUT /tenants/{tenantId}/clients/{clientId}`
+
+Assign the client to the specified tenant.
+The client can then access tenant data and perform authorized actions.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  clientId (path, ClientId, required)
+
+Responses:
+  204 — The client was successfully assigned to the tenant.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The tenant was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-client-to-tenant.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-group-to-tenant.api.md

@@ -0,0 +1,27 @@
+# Assign a group to a tenant
+
+`PUT /tenants/{tenantId}/groups/{groupId}`
+
+Assigns a group to a specified tenant.
+Group members (users, clients) can then access tenant data and perform authorized actions.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  groupId (path, GroupId, required)
+
+Responses:
+  204 — The group was successfully assigned to the tenant.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. The tenant or group was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-group-to-tenant.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-mapping-rule-to-group.api.md

@@ -0,0 +1,27 @@
+# Assign a mapping rule to a group
+
+`PUT /groups/{groupId}/mapping-rules/{mappingRuleId}`
+
+Assigns a mapping rule to a group.
+
+- Required permissions: UPDATE on GROUP.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  groupId (path, GroupId, required)
+  mappingRuleId (path, MappingRuleId, required)
+
+Responses:
+  204 — The mapping rule was assigned successfully to the group.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The group or mapping rule with the given ID was not found.
+  409 ProblemDetail — The mapping rule with the given ID is already assigned to the group.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-mapping-rule-to-group.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-mapping-rule-to-tenant.api.md

@@ -0,0 +1,26 @@
+# Assign a mapping rule to a tenant
+
+`PUT /tenants/{tenantId}/mapping-rules/{mappingRuleId}`
+
+Assign a single mapping rule to a specified tenant.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  mappingRuleId (path, MappingRuleId, required)
+
+Responses:
+  204 — The mapping rule was successfully assigned to the tenant.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. The tenant or mapping rule was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-mapping-rule-to-tenant.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-process-instance-business-id.api.md

@@ -0,0 +1,36 @@
+# Assign business id to process instance
+
+`POST /process-instances/{processInstanceKey}/business-id-assignment`
+
+Assigns a business id to an already-running process instance that currently has none.
+
+The assignment is single and irreversible: only artifacts created after the assignment
+(for example future jobs, user tasks, decision instances, and message subscriptions) carry
+the business id, while existing artifacts are not retroactively enriched. Re-sending the
+same business id succeeds as a no-op. This endpoint is only useful while business id
+uniqueness enforcement is disabled; when it is enabled, the request is rejected with a 409
+response.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  processInstanceKey (path, string, required)
+
+Request body:
+  application/json: ProcessInstanceBusinessIdAssignmentInstruction (required)
+    businessId (BusinessId, required)
+
+Responses:
+  204 — The business id is assigned to the process instance.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The process instance is not found.
+  409 ProblemDetail — The business id assignment failed because the process instance is not eligible, for example it already has a different business id, it is a call-activity child, or business id uniqueness enforcement is enabled. More details are provided in the response body.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-process-instance-business-id.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-role-to-client.api.md

@@ -0,0 +1,27 @@
+# Assign a role to a client
+
+`PUT /roles/{roleId}/clients/{clientId}`
+
+Assigns the specified role to the client. The client will inherit the authorizations associated with this role.
+
+- Required permissions: UPDATE on ROLE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  roleId (path, RoleId, required)
+  clientId (path, ClientId, required)
+
+Responses:
+  204 — The role was assigned successfully to the client.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The role with the given ID was not found.
+  409 ProblemDetail — The role was already assigned to the client with the given ID.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-role-to-client.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-role-to-group.api.md

@@ -0,0 +1,27 @@
+# Assign a role to a group
+
+`PUT /roles/{roleId}/groups/{groupId}`
+
+Assigns the specified role to the group. Every member of the group (user or client) will inherit the authorizations associated with this role.
+
+- Required permissions: UPDATE on ROLE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  roleId (path, RoleId, required)
+  groupId (path, GroupId, required)
+
+Responses:
+  204 — The role was assigned successfully to the group.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The role or group with the given ID was not found.
+  409 ProblemDetail — The role is already assigned to the group with the given ID.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-role-to-group.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-role-to-mapping-rule.api.md

@@ -0,0 +1,27 @@
+# Assign a role to a mapping rule
+
+`PUT /roles/{roleId}/mapping-rules/{mappingRuleId}`
+
+Assigns a role to a mapping rule.
+
+- Required permissions: UPDATE on ROLE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  roleId (path, RoleId, required)
+  mappingRuleId (path, MappingRuleId, required)
+
+Responses:
+  204 — The role was assigned successfully to the mapping rule.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The role or mapping rule with the given ID was not found.
+  409 ProblemDetail — The role is already assigned to the mapping rule with the given ID.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-role-to-mapping-rule.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-role-to-tenant.api.md

@@ -0,0 +1,27 @@
+# Assign a role to a tenant
+
+`PUT /tenants/{tenantId}/roles/{roleId}`
+
+Assigns a role to a specified tenant.
+Users, Clients or Groups, that have the role assigned, will get access to the tenant's data and can perform actions according to their authorizations.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  roleId (path, RoleId, required)
+
+Responses:
+  204 — The role was successfully assigned to the tenant.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. The tenant or role was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-role-to-tenant.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-role-to-user.api.md

@@ -0,0 +1,27 @@
+# Assign a role to a user
+
+`PUT /roles/{roleId}/users/{username}`
+
+Assigns the specified role to the user. The user will inherit the authorizations associated with this role.
+
+- Required permissions: UPDATE on ROLE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  roleId (path, RoleId, required)
+  username (path, Username, required)
+
+Responses:
+  204 — The role was assigned successfully to the user.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The role or user with the given ID or username was not found.
+  409 ProblemDetail — The role is already assigned to the user with the given ID.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-role-to-user.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-user-task.api.md

@@ -0,0 +1,31 @@
+# Assign user task
+
+`POST /user-tasks/{userTaskKey}/assignment`
+
+Assigns a user task with the given key to the given assignee. Assignment waits for blocking task listeners on this lifecycle transition. If listener processing is delayed beyond the request timeout, this endpoint can return 504. Other gateway timeout causes are also possible. Retry with backoff and inspect listener worker availability and logs when this repeats.
+
+- Added in Camunda 8.5.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  userTaskKey (path, string, required)
+
+Request body:
+  application/json: UserTaskAssignmentRequest (required)
+    assignee (string) — The assignee for the user task. The assignee must not be empty or `null`.
+    allowOverride (boolean) — By default, the task is reassigned if it was already assigned. Set this to `false` to return an error in such cases. The task must then first be unassigned to…
+    action (string) — A custom action value that will be accessible from user task events resulting from this endpoint invocation. If not provided, it will default to "assign".
+
+Responses:
+  204 — The user task's assignment was adjusted.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The user task with the given key was not found.
+  409 ProblemDetail — The user task with the given key is in the wrong state currently. More details are provided in the response body.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+  504 ProblemDetail — The request timed out between the gateway and the broker. For these endpoints, this often happens when user task listeners are configured and the corresponding listener job is not completed within the request timeout. Common causes include no available job workers for the listener type, busy or crashed job workers, or delayed job completion. As with any gateway timeout, general timeout causes (for example transient network issues) can also result in a 504 response. Troubleshooting: - verify that job workers for the listener type are running and healthy - check worker logs for crashes, retries, and completion failures - check network connectivity between workers, gateway, and broker - retry with backoff after transient failures - fail without retries if a problem persists
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-user-task.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-user-to-group.api.md

@@ -0,0 +1,28 @@
+# Assign a user to a group
+
+`PUT /groups/{groupId}/users/{username}`
+
+Assigns a user to a group, making the user a member of the group.
+Group members inherit the group authorizations, roles, and tenant assignments.
+
+- Required permissions: UPDATE on GROUP.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  groupId (path, GroupId, required)
+  username (path, Username, required)
+
+Responses:
+  204 — The user was assigned successfully to the group.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The group or user with the given ID or username was not found.
+  409 ProblemDetail — The user with the given ID is already assigned to the group.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-user-to-group.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.assign-user-to-tenant.api.md

@@ -0,0 +1,26 @@
+# Assign a user to a tenant
+
+`PUT /tenants/{tenantId}/users/{username}`
+
+Assign a single user to a specified tenant. The user can then access tenant data and perform authorized actions.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  username (path, Username, required)
+
+Responses:
+  204 — The user was successfully assigned to the tenant.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. The tenant or user was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/assign-user-to-tenant.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.broadcast-signal.api.md

@@ -0,0 +1,26 @@
+# Broadcast signal
+
+`POST /signals/broadcast`
+
+Broadcasts a signal.
+
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: SignalBroadcastRequest (required)
+    signalName (string, required) — The name of the signal to broadcast.
+    variables (object) — The signal variables as a JSON object.
+    tenantId (TenantId) — The ID of the tenant that owns the signal.
+
+Responses:
+  200 SignalBroadcastResult — The signal was broadcast.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The signal is not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+  503 ProblemDetail — The service is currently unavailable. This may happen only on some requests where the system creates backpressure to prevent the server's compute resources from being exhausted, avoiding more severe failures. In this case, the title of the error object contains `RESOURCE_EXHAUSTED`. Clients are recommended to eventually retry those requests after a backoff period. You can learn more about the backpressure mechanism here: https://docs.camunda.io/docs/components/zeebe/technical-concepts/internal-processing/#handling-backpressure .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/broadcast-signal.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.cancel-batch-operation.api.md

@@ -0,0 +1,28 @@
+# Cancel Batch operation
+
+`POST /batch-operations/{batchOperationKey}/cancellation`
+
+Cancels a running batch operation.
+This is done asynchronously, the progress can be tracked using the batch operation status endpoint (/batch-operations/{batchOperationKey}).
+
+- Required permissions: UPDATE on BATCH.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  batchOperationKey (path, BatchOperationKey, required)
+
+Request body:
+  application/json: 
+
+Responses:
+  204 — The batch operation cancel request was created.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. The batch operation was not found.
+  500 ProblemDetail — An internal error occurred while processing the request.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/cancel-batch-operation.api