@bpmnkit/camunda-docspack 0.0.0

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

@@ -0,0 +1,29 @@
+# Cancel process instance
+
+`POST /process-instances/{processInstanceKey}/cancellation`
+
+Cancels a running process instance. As a cancellation includes more than just the removal of the process instance resource, the cancellation resource must be posted. Cancellation can wait on listener-related processing; when that processing does not complete in time, 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.
+
+- Required permissions: CANCEL_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  processInstanceKey (path, string, required)
+
+Request body:
+  application/json: CancelProcessInstanceRequest
+    operationReference (OperationReference)
+
+Responses:
+  204 — The process instance is canceled.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The process instance 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 .
+  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/cancel-process-instance.api

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

@@ -0,0 +1,28 @@
+# Cancel process instances (batch)
+
+`POST /process-instances/cancellation`
+
+Cancels multiple running process instances.
+Since only ACTIVE root instances can be cancelled, any given filters for state and
+parentProcessInstanceKey are ignored and overridden during this batch operation.
+This is done asynchronously, the progress can be tracked using the batchOperationKey from the response and the batch operation status endpoint (/batch-operations/{batchOperationKey}).
+
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: ProcessInstanceCancellationBatchOperationRequest (required)
+    filter (ProcessInstanceFilter, required) — The process instance filter.
+    operationReference (OperationReference)
+
+Responses:
+  200 BatchOperationCreatedResult — The batch operation request was created.
+  400 ProblemDetail — The process instance batch operation failed. More details are provided in the response body.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  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-process-instances-batch-operation.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.change-cluster-mode-as-cluster-admin.api.md

@@ -0,0 +1,30 @@
+# Change the cluster mode of one or every physical tenant
+
+`PATCH /cluster/v2/mode`
+
+Transitions physical tenants between processing and recovery mode.
+
+If the `physicalTenantId` parameter is not provided, all available physical tenants are transitioned individually.
+
+Requires the cluster-admin security chain. Although this operation lists `bearerAuth` / `basicAuth` like the rest of the Orchestration Cluster API, it does not accept an Orchestration Cluster user's credentials — only the separate cluster-admin credentials are valid here.
+
+- Added in Camunda 8.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  mode (query, Mode, required)
+  physicalTenantId (query, string)
+  dryRun (query, boolean)
+
+Responses:
+  200 ClusterModeChangeResponse — The mode change request was accepted; returns the planned cluster change covering every requested physical tenant.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  404 ProblemDetail — The requested `physicalTenantId` does not exist in this cluster.
+  409 — The mode change conflicts with the cluster state, for example because another configuration change is in progress.
+  500 ProblemDetail — An internal error occurred while processing the request.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/change-cluster-mode-as-cluster-admin.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.change-cluster-mode.api.md

@@ -0,0 +1,24 @@
+# Change cluster mode
+
+`PATCH /mode`
+
+Transitions the cluster between processing and recovery mode. This is a non-blocking operation: the request is acknowledged once the change has been accepted, before the transition itself has completed. Entering recovery mode deactivates all partitions so that only a restricted set of read-only operations remains available; exiting recovery mode returns the cluster to normal processing. Returns the planned cluster change so its progress can be monitored via the topology.
+
+- Added in Camunda 8.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  mode (query, Mode, required)
+  dryRun (query, boolean)
+
+Responses:
+  200 ClusterModeChangeResponse — The mode change request was accepted; returns the planned cluster changes.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  500 ProblemDetail — An internal error occurred while processing the request.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/change-cluster-mode.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.complete-job.api.md

@@ -0,0 +1,32 @@
+# Complete job
+
+`POST /jobs/{jobKey}/completion`
+
+Complete a job with the given payload, which allows completing the associated service task.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  jobKey (path, string, required)
+
+Request body:
+  application/json: JobCompletionRequest
+    variables (object) — The variables to complete the job with.
+    result (JobResult)
+    leaseToken (string) — The token identifying a leased job's activation, obtained from `ActivatedJobResult.leaseToken`. For a leased job, the matching token must be supplied to prove…
+    businessId (BusinessId) — An optional business id to assign to the process instance the job belongs to, as part of completing the job, letting a worker set the identifier from work it…
+
+Responses:
+  204 — The job was completed successfully.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The job with the given key was not found.
+  409 ProblemDetail — The job 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 .
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/complete-job.api

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

@@ -0,0 +1,30 @@
+# Complete user task
+
+`POST /user-tasks/{userTaskKey}/completion`
+
+Completes a user task with the given key. Completion 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: UserTaskCompletionRequest
+    variables (object) — The variables to complete the user task with.
+    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 "complete".
+
+Responses:
+  204 — The user task was completed successfully.
+  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/complete-user-task.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.correlate-message.api.md

@@ -0,0 +1,32 @@
+# Correlate message
+
+`POST /messages/correlation`
+
+Publishes a message and correlates it to a subscription.
+If correlation is successful it will return the first process instance key the message correlated with.
+The message is not buffered.
+Use the publish message endpoint to send messages that can be buffered.
+
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: MessageCorrelationRequest (required)
+    name (string, required) — The message name as defined in the BPMN process
+    correlationKey (string) — The correlation key of the message.
+    variables (object) — The message variables as JSON document
+    tenantId (TenantId) — the tenant for which the message is published
+    businessId (BusinessId) — An optional business id used to enforce uniqueness of the process instance that a message start event would create. If provided and uniqueness enforcement is…
+
+Responses:
+  200 MessageCorrelationResult — The message is correlated to one or more process instances
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — 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/correlate-message.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-admin-user.api.md

@@ -0,0 +1,26 @@
+# Create admin user
+
+`POST /setup/user`
+
+Creates a new user and assigns the admin role to it. This endpoint is only usable when users are managed in the Orchestration Cluster and while no user is assigned to the admin role.
+
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Request body:
+  application/json: UserRequest (required)
+    password (string, required) — The password of the user.
+    username (Username, required) — The username of the new user.
+    name (string) — The name of the user.
+    email (string) — The email of the user.
+
+Responses:
+  201 UserCreateResult — The admin user was created successfully.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  409 ProblemDetail — A user with this username already exists.
+  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/create-admin-user.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-agent-instance-history-item.api.md

@@ -0,0 +1,41 @@
+# Create agent instance history item
+
+`POST /agent-instances/{agentInstanceKey}/history`
+
+Appends a single history item to an agent instance's conversation history.
+The created item has commitStatus PENDING until the job identified by jobLease
+completes successfully, at which point it transitions to COMMITTED. If the job
+fails or is superseded by a retry, the item is marked DISCARDED.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  agentInstanceKey (path, string, required)
+
+Request body:
+  application/json: AgentInstanceHistoryItemRequest (required)
+    elementInstanceKey (ElementInstanceKey, required) — The key of the currently-active element instance.
+    jobKey (JobKey, required) — The key of the current job activation during which this history item was produced.
+    jobLease (string, required) — Opaque lease token received from the job activation response.
+    loopIteration (LoopIterationId) — The loop iteration this item belongs to. Omit if not grouping items by loopIteration.
+    role (AgentInstanceHistoryRoleEnum, required) — The role of this history item in the conversation.
+    content (AgentInstanceMessageContent[], required) — The content blocks of this history item.
+    toolCalls (AgentInstanceToolCall[]) — Tool calls associated with this history item. For ASSISTANT items: tool calls dispatched by this LLM response. For TOOL_RESULT items: single-entry array…
+    metrics (AgentInstanceHistoryItemMetrics) — Per-call token and latency metrics. Present on ASSISTANT items only.
+    producedAt (string, required) — The agent-side timestamp of when this message was produced.
+
+Responses:
+  201 AgentInstanceHistoryItemCreationResult — The history item was created.
+  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 agent instance with the given key was not found, or the specified jobKey does not correspond to an active job. 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/create-agent-instance-history-item.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-agent-instance.api.md

@@ -0,0 +1,31 @@
+# Create agent instance
+
+`POST /agent-instances`
+
+Creates a new agent instance. The returned key identifies the instance and must
+be used in subsequent update and query calls.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: AgentInstanceCreationRequest (required)
+    elementInstanceKey (ElementInstanceKey, required) — The key of the AI Agent Sub-process or AI Agent Task element instance. The engine uses this key to infer processInstanceKey, elementId, processDefinitionKey,…
+    definition (AgentInstanceDefinition, required) — Static definition set once at creation.
+    limits (AgentInstanceLimits) — Limits for the agent execution. When omitted, all limits default to -1 (no limit).
+
+Responses:
+  200 AgentInstanceCreationResult — The agent instance was created.
+  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 elementInstanceKey does not correspond to an active element instance. More details are provided in the response body.
+  409 ProblemDetail — An agent instance already exists for the given element instance.
+  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/create-agent-instance.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-authorization.api.md

@@ -0,0 +1,26 @@
+# Create authorization
+
+`POST /authorizations`
+
+Create the authorization.
+
+- Required permissions: CREATE on AUTHORIZATION.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: AuthorizationRequest (required)
+
+Responses:
+  201 AuthorizationCreateResult — The authorization was created successfully.
+  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 owner 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/create-authorization.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-deployment.api.md

@@ -0,0 +1,26 @@
+# Deploy resources
+
+`POST /deployments`
+
+Deploys one or more resources, including BPMN processes, DMN decision models, forms, RPA resources, and generic files.
+A deployment can contain any file type. Files that are not interpreted as BPMN, DMN, form, or RPA resources are stored as deployable generic resources in the engine.
+This is an atomic call, i.e. either all resources are deployed or none of them are.
+
+- Required permissions: CREATE on RESOURCE.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  multipart/form-data: object (required)
+    resources (string[], required) — The binary data to create the deployment resources. It is possible to have more than one form part with different form part names for the binary data to create…
+    tenantId (TenantId)
+
+Responses:
+  200 DeploymentResult — The resources are deployed.
+  400 ProblemDetail — The provided data is not valid.
+  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/create-deployment.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-document-link.api.md

@@ -0,0 +1,29 @@
+# Create document link
+
+`POST /documents/{documentId}/links`
+
+Create a link to a document in the Camunda 8 cluster.
+
+Note that this is currently supported for document stores of type: AWS, Azure, GCP
+
+- Required permissions: CREATE on DOCUMENT.
+- Added in Camunda 8.7.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  documentId (path, DocumentId, required)
+  storeId (query, string)
+  contentHash (query, string)
+
+Request body:
+  application/json: DocumentLinkRequest
+    timeToLive (integer) — The time-to-live of the document link in ms.
+
+Responses:
+  201 DocumentLink — The document link was created successfully.
+  400 ProblemDetail — The provided data is not valid.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-document-link.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-document.api.md

@@ -0,0 +1,30 @@
+# Upload document
+
+`POST /documents`
+
+Upload a document to the Camunda 8 cluster.
+
+Note that this is currently supported for document stores of type: AWS, Azure, GCP, in-memory (non-production), local (non-production)
+
+- Required permissions: CREATE on DOCUMENT.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  storeId (query, string)
+  documentId (query, DocumentId)
+
+Request body:
+  multipart/form-data: object (required)
+    file (string, required)
+    metadata (DocumentMetadata)
+
+Responses:
+  201 DocumentReference — The document was uploaded successfully.
+  400 ProblemDetail — The provided data is not valid.
+  415 ProblemDetail — The server cannot process the request because the media type (Content-Type) of the request payload is not supported by the server for the requested resource and method.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-document.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-documents.api.md

@@ -0,0 +1,42 @@
+# Upload multiple documents
+
+`POST /documents/batch`
+
+Upload multiple documents to the Camunda 8 cluster.
+
+The caller must provide a file name for each document, which will be used in case of a multi-status response
+to identify which documents failed to upload. The file name can be provided in the `Content-Disposition` header
+of the file part or in the `fileName` field of the metadata. You can add a parallel array of metadata objects. These
+are matched with the files based on index, and must have the same length as the files array.
+To pass homogenous metadata for all files, spread the metadata over the metadata array.
+A filename value provided explicitly via the metadata array in the request overrides the `Content-Disposition` header
+of the file part.
+
+In case of a multi-status response, the response body will contain a list of `DocumentBatchProblemDetail` objects,
+each of which contains the file name of the document that failed to upload and the reason for the failure.
+The client can choose to retry the whole batch or individual documents based on the response.
+
+Note that this is currently supported for document stores of type: AWS, Azure, GCP, in-memory (non-production), local (non-production)
+
+- Required permissions: CREATE on DOCUMENT.
+- Added in Camunda 8.7.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  storeId (query, string)
+
+Request body:
+  multipart/form-data: object (required)
+    files (string[], required) — The documents to upload.
+    metadataList (DocumentMetadata[]) — Optional JSON array of metadata object whose index aligns with each file entry. The metadata array must have the same length as the files array.
+
+Responses:
+  201 DocumentCreationBatchResponse — All documents were uploaded successfully.
+  207 DocumentCreationBatchResponse — Some documents were uploaded successfully, others failed.
+  400 ProblemDetail — The provided data is not valid.
+  415 ProblemDetail — The server cannot process the request because the media type (Content-Type) of the request payload is not supported by the server for the requested resource and method.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-documents.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-element-instance-variables.api.md

@@ -0,0 +1,35 @@
+# Update element instance variables
+
+`PUT /element-instances/{elementInstanceKey}/variables`
+
+Updates all the variables of a particular scope (for example, process instance, element instance) with the given variable data.
+Specify the element instance in the `elementInstanceKey` parameter.
+Variable updates can be delayed by listener-related processing; if processing exceeds 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.
+
+- Required permissions: UPDATE_PROCESS_INSTANCE on PROCESS_DEFINITION.
+- Added in Camunda 8.6.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  elementInstanceKey (path, string, required)
+
+Request body:
+  application/json: SetVariableRequest (required)
+    variables (object, required) — JSON object representing the variables to set in the element’s scope.
+    local (boolean) — If set to `true`, the variables are merged strictly into the local scope (as specified by the `elementInstanceKey`). Otherwise, the variables are propagated to…
+    operationReference (OperationReference)
+
+Responses:
+  204 — The variables were updated.
+  400 ProblemDetail — The provided data is not valid.
+  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/create-element-instance-variables.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-global-cluster-variable.api.md

@@ -0,0 +1,29 @@
+# Create a global-scoped cluster variable
+
+`POST /cluster-variables/global`
+
+Create a global-scoped cluster variable.
+
+- Required permissions: CREATE on CLUSTER_VARIABLE.
+- Added in Camunda 8.9.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: CreateClusterVariableRequest (required)
+    name (ClusterVariableName, required) — The name of the cluster variable. Must be unique within its scope (global or tenant-specific).
+    value (object, required) — The value of the cluster variable. Can be any JSON object or primitive value. Will be serialized as a JSON string in responses.
+    metadata (object) — A generic key-value metadata bag attached to the cluster variable. Values must be strings or numbers. Limited to 100 entries and a configurable maximum…
+    kind (ClusterVariableKindEnum) — The kind of the cluster variable. Defaults to JSON if not specified.
+
+Responses:
+  200 ClusterVariableResult — Cluster variable created
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  409 ProblemDetail — A cluster variable with this name already exists.
+  500 ProblemDetail — An internal error occurred while processing the request.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-global-cluster-variable.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-global-task-listener.api.md

@@ -0,0 +1,27 @@
+# Create global user task listener
+
+`POST /global-task-listeners`
+
+Create a new global user task listener.
+
+- Required permissions: CREATE_TASK_LISTENER on GLOBAL_LISTENER.
+- Added in Camunda 8.9.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: CreateGlobalTaskListenerRequest (required)
+    id (GlobalListenerId, required)
+
+Responses:
+  201 GlobalTaskListenerResult — The global user task listener was created successfully.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  409 ProblemDetail — A global listener with this id already exists.
+  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/create-global-task-listener.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.create-group.api.md

@@ -0,0 +1,44 @@
+# Create group
+
+`POST /groups`
+
+Create a new group.
+
+The supplied `groupId` is validated against `^[a-zA-Z0-9_~@.+-]+
+(max 256 characters) by `IdentifierValidator.validateId` in the
+runtime. This strict validation applies wherever the Groups API
+is available: in OIDC deployments that set
+`camunda.security.authentication.oidc.groupsClaim` the Groups
+API (including this endpoint) is disabled entirely, so group
+CRUD never sees externally-minted IdP IDs. The BYOG relaxation
+only loosens validation when a group is referenced *as a member*
+of a role or tenant (`assignRoleToGroup`,
+`assignGroupToTenant`); group CRUD itself always uses the strict
+default-id regex. The constraint is not advertised on the
+`GroupId` schema so that the same schema can be reused at
+member-reference sites without falsely rejecting
+externally-minted IdP group IDs there.
+
+- Required permissions: CREATE on GROUP.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: GroupCreateRequest
+    groupId (GroupId, required) — The ID of the new group.
+    name (string, required) — The display name of the new group.
+    description (string) — The description of the new group.
+
+Responses:
+  201 GroupCreateResult — The group was created successfully.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  409 ProblemDetail — Group with this id already exists.
+  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/create-group.api