@bpmnkit/camunda-docspack 0.0.0

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

@@ -0,0 +1,29 @@
+# Update global user task listener
+
+`PUT /global-task-listeners/{id}`
+
+Updates a global user task listener.
+
+- Required permissions: UPDATE_TASK_LISTENER on GLOBAL_LISTENER.
+- Added in Camunda 8.9.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  id (path, GlobalListenerId, required)
+
+Request body:
+  application/json: UpdateGlobalTaskListenerRequest (required)
+
+Responses:
+  200 GlobalTaskListenerResult — The global listener was updated 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 global user task listener 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/update-global-task-listener.api

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

@@ -0,0 +1,30 @@
+# Update group
+
+`PUT /groups/{groupId}`
+
+Update a group with the given ID.
+
+- Required permissions: UPDATE on GROUP.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  groupId (path, GroupId, required)
+
+Request body:
+  application/json: GroupUpdateRequest (required)
+    name (string, required) — The new name of the group.
+    description (string) — The new description of the group.
+
+Responses:
+  200 GroupUpdateResult — The group was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  404 ProblemDetail — The group with the given ID 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/update-group.api

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

@@ -0,0 +1,31 @@
+# Update job
+
+`PATCH /jobs/{jobKey}`
+
+Update a job with the given key.
+
+- 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: JobUpdateRequest (required)
+    changeset (JobChangeset, required)
+    operationReference (OperationReference)
+    leaseToken (string) — The token identifying a leased job's activation, obtained from `ActivatedJobResult.leaseToken`. For a leased job, a supplied token is validated to prove the…
+
+Responses:
+  204 — The job was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  404 ProblemDetail — The job with the jobKey is 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/update-job.api

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

@@ -0,0 +1,26 @@
+# Update jobs (batch)
+
+`POST /jobs/batch-update`
+
+Creates a batch operation to update jobs matching the given filter. At least one changeset field must be non-null. 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.10.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Request body:
+  application/json: JobBatchUpdateRequest (required)
+    filter (JobFilter, required) — The job filter. At least one dimension must be set.
+    changeset (JobChangeset, required) — The fields to update. At least one field must be non-null.
+    operationReference (OperationReference)
+
+Responses:
+  200 BatchOperationCreatedResult — The batch operation was created.
+  400 ProblemDetail — The job batch update 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/update-jobs-batch-operation.api

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

@@ -0,0 +1,28 @@
+# Update mapping rule
+
+`PUT /mapping-rules/{mappingRuleId}`
+
+Update a mapping rule.
+
+- Required permissions: UPDATE on MAPPING_RULE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  mappingRuleId (path, MappingRuleId, required)
+
+Request body:
+  application/json: MappingRuleUpdateRequest
+
+Responses:
+  200 MappingRuleUpdateResult — The mapping rule was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — The request to update a mapping rule was denied. More details are provided in the response body.
+  404 ProblemDetail — The request to update a mapping rule was denied.
+  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/update-mapping-rule.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.update-role.api.md

@@ -0,0 +1,30 @@
+# Update role
+
+`PUT /roles/{roleId}`
+
+Update a role with the given ID.
+
+- Required permissions: UPDATE on ROLE.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  roleId (path, RoleId, required)
+
+Request body:
+  application/json: RoleUpdateRequest (required)
+    name (string, required) — The display name of the new role.
+    description (string) — The description of the new role.
+
+Responses:
+  200 RoleUpdateResult — The role was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  401 ProblemDetail — The request lacks valid authentication credentials.
+  404 ProblemDetail — The role with the ID 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/update-role.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.update-tenant-cluster-variable.api.md

@@ -0,0 +1,32 @@
+# Update a tenant-scoped cluster variable
+
+`PUT /cluster-variables/tenants/{tenantId}/{name}`
+
+Updates the value of an existing tenant-scoped cluster variable.
+The variable must exist, otherwise a 404 error is returned.
+
+- Required permissions: UPDATE on CLUSTER_VARIABLE.
+- Added in Camunda 8.9.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+  name (path, ClusterVariableName, required)
+
+Request body:
+  application/json: UpdateClusterVariableRequest (required)
+    value (object, required) — The new 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…
+
+Responses:
+  200 ClusterVariableResult — Cluster variable updated 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 — Cluster variable 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/update-tenant-cluster-variable.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.specifications.update-tenant.api.md

@@ -0,0 +1,30 @@
+# Update tenant
+
+`PUT /tenants/{tenantId}`
+
+Updates an existing tenant.
+
+- Required permissions: UPDATE on TENANT.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  tenantId (path, TenantId, required)
+
+Request body:
+  application/json: TenantUpdateRequest (required)
+    name (string, required) — The new name of the tenant.
+    description (string) — The new description of the tenant.
+
+Responses:
+  200 TenantUpdateResult — The tenant was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — Not found. 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/update-tenant.api

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

@@ -0,0 +1,30 @@
+# Update user task
+
+`PATCH /user-tasks/{userTaskKey}`
+
+Update a user task with the given key. Updates wait 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: UserTaskUpdateRequest
+    changeset (Changeset)
+    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 "update".
+
+Responses:
+  204 — The user task was updated 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/update-user-task.api

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

@@ -0,0 +1,31 @@
+# Update user
+
+`PUT /users/{username}`
+
+Updates a user.
+
+- Required permissions: UPDATE on USER.
+- Added in Camunda 8.8.
+- Consistency: strong.
+
+Authentication: bearerAuth or basicAuth
+
+Parameters:
+  username (path, Username, required)
+
+Request body:
+  application/json: UserUpdateRequest (required)
+    password (string) — The password of the user. If blank, the password is unchanged.
+    name (string) — The name of the user.
+    email (string) — The email of the user.
+
+Responses:
+  200 UserUpdateResult — The user was updated successfully.
+  400 ProblemDetail — The provided data is not valid.
+  403 ProblemDetail — Forbidden. The request is not allowed.
+  404 ProblemDetail — The 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/update-user.api

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.create-a-role-post.md

@@ -0,0 +1,44 @@
+# Beginner tutorial — Create a role (POST)
+
+1. Outline your function:
+
+```javascript
+async function createRole([roleName]) {
+  const accessToken = await getAccessToken(authorizationConfiguration);
+  const camundaApiUrl = process.env.CAMUNDA_REST_ADDRESS;
+  const url = `${camundaApiUrl}/roles`;
+}
+```
+
+2. Configure the API call:
+
+```javascript
+const options = {
+  method: "POST",
+  url,
+  headers: {
+    Accept: "application/json",
+    Authorization: `Bearer ${accessToken}`,
+  },
+  data: {
+    name: roleName,
+  },
+};
+```
+
+3. Process the results:
+
+```javascript
+try {
+  const response = await axios(options);
+  const newRole = response.data;
+  console.log(`Role added! Name: ${roleName}. Key: ${newRole.roleKey}.`);
+} catch (error) {
+  console.error(error.message);
+}
+```
+
+4. Run in your terminal `node cli.js camunda8 create <name>`.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.delete-a-role-delete.md

@@ -0,0 +1,44 @@
+# Beginner tutorial — Delete a role (DELETE)
+
+1. Outline your function:
+
+```javascript
+async function deleteRole([roleKey]) {
+  const accessToken = await getAccessToken(authorizationConfiguration);
+  const camundaApiUrl = process.env.CAMUNDA_REST_ADDRESS;
+  const url = `${camundaApiUrl}/roles/${roleKey}`;
+}
+```
+
+2. Configure the API call:
+
+```javascript
+const options = {
+  method: "DELETE",
+  url,
+  headers: {
+    Accept: "application/json",
+    Authorization: `Bearer ${accessToken}`,
+  },
+};
+```
+
+3. Process the results:
+
+```javascript
+try {
+  const response = await axios(options);
+  if (response.status === 204) {
+    console.log("Role deleted!");
+  } else {
+    console.error("Unable to delete this role!");
+  }
+} catch (error) {
+  console.error(error.message);
+}
+```
+
+4. Run in your terminal `node cli.js camunda8 delete <role>`.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.getting-started.md

@@ -0,0 +1,25 @@
+# Beginner tutorial — Getting started
+
+- You need authentication to access the API endpoints. Find more information [here](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-authentication).
+
+
+## Set up authentication
+
+If you're interested in how we use a library to handle auth for our code, or to get started, examine the `auth.js` file in the GitHub repository. This file contains a function named `getAccessToken` which executes an OAuth 2.0 protocol to retrieve authentication credentials based on your client ID and client secret. Then, we return the actual token that can be passed as an authorization header in each request.
+
+To set up your credentials, create an `.env` file which will be protected by the `.gitignore` file. You will need to add the following:
+
+- `CAMUNDA_CLIENT_ID`
+- `CAMUNDA_CLIENT_SECRET`
+- `CAMUNDA_REST_ADDRESS` (after creating a client and downloading the .env variables, this is reflected in the Console UI as `ZEEBE_REST_ADDRESS`)
+- `CAMUNDA_TOKEN_AUDIENCE` (represented as `ZEEBE_TOKEN_AUDIENCE` in the Console UI), which is `zeebe.camunda.io` in a Camunda 8 SaaS environment. For example, your audience may be defined as `CAMUNDA_TOKEN_AUDIENCE=zeebe.camunda.io`.
+
+These keys will be consumed by the `auth.js` file to execute the OAuth protocol, and should be saved when you generate your client credentials in [prerequisites](#prerequisites).
+
+Examine the existing `.env.example` file for an example of how your `.env` file should look upon completion. Do not place your credentials in the `.env.example` file, as this example file is not protected by the `.gitignore`.
+
+**Note**
+In this tutorial, we will execute arguments to list all roles, create a role, retrieve a role, and delete a role. You can examine the framework for processing these arguments in the `cli.js` file before getting started.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.if-you-get-stuck.md

@@ -0,0 +1,11 @@
+# Beginner tutorial — If you get stuck
+
+Having trouble configuring your API calls or want to examine an example of the completed tutorial? Navigate to the `completed` folder in the [GitHub repository](https://github.com/camunda/camunda-api-tutorials/tree/main/completed), where you can view an example `camunda-8.js` file.
+
+
+## Next steps
+
+You can script several additional API calls as outlined in the [Orchestration Cluster REST API reference material](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-overview).
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.list-all-roles-post.md

@@ -0,0 +1,75 @@
+# Beginner tutorial — List all roles (POST)
+
+First, let's script an API call to list all existing roles.
+
+To do this, take the following steps:
+
+1. In the file named `camunda-8.js`, outline the authentication configuration in the first few lines. This will pull in your `.env` variables to obtain an access token before making any API calls:
+
+```javascript
+const authorizationConfiguration = {
+  clientId: process.env.CAMUNDA_CLIENT_ID,
+  clientSecret: process.env.CAMUNDA_CLIENT_SECRET,
+  audience: process.env.CAMUNDA_TOKEN_AUDIENCE,
+};
+```
+
+2. Examine the function `async function listRoles()` below this configuration. This is where you will script out your API call.
+
+3. Within the function, you must first generate an access token for this request, so your function should now look like the following:
+
+```javascript
+async function listRoles() {
+  const accessToken = await getAccessToken(authorizationConfiguration);
+}
+```
+
+4. Using your generated client credentials from [prerequisites](#prerequisites), capture your Orchestration Cluster REST API URL beneath your call for an access token by defining `camundaApiUrl`:
+
+```javascript
+const camundaApiUrl = process.env.CAMUNDA_REST_ADDRESS;
+```
+
+On the next line, script the API endpoint to list the existing roles:
+
+```javascript
+const url = `${camundaApiUrl}/roles/search`;
+```
+
+5. Configure your POST request to the appropriate endpoint, including an authorization header based on the previously acquired `accessToken`:
+
+```javascript
+const options = {
+  method: "POST",
+  url,
+  headers: {
+    Accept: "application/json",
+    Authorization: `Bearer ${accessToken}`,
+  },
+  data: {},
+};
+```
+
+6. Call the endpoint, process the results from the API call, and emit an error message from the server if necessary:
+
+```javascript
+try {
+  const response = await axios(options);
+  const results = response.data;
+  results.items.forEach((x) =>
+    console.log(`Role Name: ${x.name}; key: ${x.key}`)
+  );
+} catch (error) {
+  console.error(error.message);
+}
+```
+
+7. In your terminal, run `node cli.js camunda8 list`.
+
+**Note**
+This `list` command is connected to the `listRoles` function at the bottom of the `camunda-8.js` file, and executed by the `cli.js` file. While we will work with roles in this tutorial, you may add additional arguments depending on the API calls you would like to make.
+
+The existing roles (if any) will now output. If you have an invalid API name or action name, or no arguments provided, or improper/insufficient credentials configured, an error message will output as outlined in the `cli.js` file. If no action is provided, it will default to "assign" everywhere, except when unassigning a user.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

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

@@ -0,0 +1,22 @@
+# Beginner tutorial
+
+New to the Orchestration Cluster REST API? Step through our tutorial to list all roles, create a role, retrieve a role, and delete a role.
+
+Beginner
+
+In this tutorial, we'll step through examples to highlight the capabilities of the Orchestration Cluster REST API, such as listing all roles, creating a role, retrieving a role, and deleting a role.
+
+
+## Prerequisites
+
+- If you haven't done so already, [create a cluster](https://docs.camunda.io/docs/next/components/hub/organization/manage-clusters/create-cluster).
+- Upon cluster creation, [create your first client](https://docs.camunda.io/docs/next/components/hub/organization/manage-clusters/manage-api-clients#create-a-client). Ensure you check the `Orchestration Cluster API` client scope box.
+
+**Note**
+Make sure you keep the generated client credentials in a safe place. The **Client secret** will not be shown again. For your convenience, you can download the client information to your computer.
+
+- In this tutorial, we utilize a JavaScript-written [GitHub repository](https://github.com/camunda/camunda-api-tutorials) to write and run requests. Clone this repo before getting started.
+- Ensure you have [Node.js](https://nodejs.org/en/download) installed as this will be used for methods that can be called by the CLI (outlined later in this guide). Run `npm install` to ensure you have updated dependencies.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/apis-tools.orchestration-cluster-api-rest.tutorial.retrieve-a-role-get.md

@@ -0,0 +1,41 @@
+# Beginner tutorial — Retrieve a role (GET)
+
+1. Outline your function:
+
+```javascript
+async function getRole([roleKey]) {
+  const accessToken = await getAccessToken(authorizationConfiguration);
+  const camundaApiUrl = process.env.CAMUNDA_REST_ADDRESS;
+  const url = `${camundaApiUrl}/roles/${roleKey}`;
+}
+```
+
+2. Configure the API call.
+
+```javascript
+const options = {
+  method: "GET",
+  url,
+  headers: {
+    Accept: "application/json",
+    Authorization: `Bearer ${accessToken}`,
+  },
+};
+```
+
+3. Process the results:
+
+```javascript
+try {
+  const response = await axios(options);
+  const results = response.data;
+  console.log(`Role Name: ${results.name}; Key: ${results.key};`);
+} catch (error) {
+  console.error(error.message);
+}
+```
+
+4. Run in your terminal `node cli.js camunda8 view <role>`.
+
+---
+Source: https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/tutorial

package/.llms/chunks/components.best-practices.architecture.data-flow.command-processing-path.md

@@ -0,0 +1,21 @@
+# Data flow — Command processing path
+
+A command travels from the client to primary storage and then to the engine. A response only comes back after processing.
+Its processing path (command lifecycle) follows this pattern:
+
+**Client (REST or gRPC) → Camunda API (Gateway) → Broker (Command API) → Raft partition (log) → Raft replication → Processing Engine → event on log → RocksDB state update → Client response**
+
+See it in green in the diagram below:
+
+![Camunda 8.8+ architecture overview - Data Flow Command processing path](assets/architecture-8.8plus-data-flow-command.jpg)
+
+Client responses are not sent until the command is fully processed by the engine. The engine can only process a command once it has been committed to the log (as part of the Raft consensus protocol). Commands are read sequentially per partition, only one command per partition is processed at a time, and only the Raft partition leader runs the engine.
+
+This means command response latency is bounded below by Raft commit time, engine processing time, and processing queue length. In a healthy and stable cluster, this typically results in sub-second response latency for simple commands.
+
+If the engine cannot process commands fast enough, for example, because disk I/O is saturated, network latency is high, or the backlog is large, the Command API applies backpressure to the client.
+
+See [internal processing](https://docs.camunda.io/docs/next/components/zeebe/technical-concepts/internal-processing) for more details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/architecture/data-flow

package/.llms/chunks/components.best-practices.architecture.data-flow.export-pipeline.md

@@ -0,0 +1,27 @@
+# Data flow — Export pipeline
+
+After the engine processes a command, it confirms its state change with an event on the log. Exporters asynchronously read such events from the log (only committed events) and write them to secondary storage in _batches_. See it in blue in the diagram below:
+
+![Camunda 8.8+ architecture overview - Data Flow Export pipeline](assets/architecture-8.8plus-data-flow-export-path.jpg)
+
+**The exporters run on the same leader as the engine.** They are partition-bounded and cannot scale independently of partition count. There are three built-in exporters in play:
+
+- **[Camunda Exporter](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/exporters/camunda-exporter)**: aggregates and writes enriched data to secondary storage (ES/OS) for Operate, Tasklist, and the REST Query API
+- **[RDBMS Exporter](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/exporters/rdbms-exporter)**: aggregates and writes enriched data to secondary storage (RDBMS) for Operate, Tasklist, and the REST Query API.
+- **[Elasticsearch Exporter](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/exporters/elasticsearch-exporter) / [OpenSearch Exporter](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/exporters/opensearch-exporter)**: writes raw engine events into specific Elasticsearch/OpenSearch indices, consumed by Optimize.
+
+The Camunda Exporter and RDBMS Exporter are mutually exclusive, only one can be enabled at a time. The Elasticsearch/OpenSearch exporter is independent and can be enabled alongside either of the other two.
+
+**Note**
+Read events are applied to the registered exporters one by one, in the same order as they appear on the log. Each event is applied to ALL exporters before the next event is processed.
+
+The exporters track their position in the Exporter state (backed by RocksDB). If the exporting backlog grows over a certain threshold, Camunda reduces the record write rate via a corresponding [flow control](https://docs.camunda.io/docs/next/self-managed/operational-guides/configure-flow-control/configure-flow-control) mechanics to keep the exporting backlog manageable. In extreme cases, client commands are rejected via the standard backpressure mechanism.
+
+Exporter behavior and performance is important for the system, because:
+
+- If an exporter falls behind, it holds up all exporters for that partition.
+- Slow secondary storage directly reduces process execution throughput.
+- Custom exporters can have a high impact on overall throughput if they are not performant enough.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/architecture/data-flow