@grepr/cli 1.8.5-ca825ac → 1.8.6-7c73069

package/build/dist/docs-index/1c6d4bf9-b722-4b16-aa92-2a2d0e2df660.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/1c6d4bf9-b722-4b16-aa92-2a2d0e2df660.txt

@@ -0,0 +1,34 @@
+# SqlOperation
+
+Processes data through a sequence of SQL statements executed in order. Supports VIEW statements that create temporary tables, OUTPUT statements that produce DataStream results, and IO statements that perform side effects.
+
+**Type**: `object`
+
+## Properties
+
+- name: availableDatasets (optional)
+  type: array of string
+  description: IDs of datasets whose tables can be referenced in SQL statements. These will be registered as queryable tables in the SQL environment. The tables from each dataset will appear in a separate namespace based on the dataset name.
+
+- name: globalStateTtl (optional)
+  type: string
+  description: Global time-to-live for operation state. When calculating aggregations or joins in streaming mode, Grepr pipelines will keep track of some state (such as the count and sum of values for an averaging aggregation). To prevent the size of the state from growing indefinitely, Grepr will set a default time-to-live value for any state. If state does not receive updates after this TTL, it will be considered idle and the state will be cleared. Aggregations for will be reset for the idle group for example.
+
+- name: inputs (optional)
+  type: object
+  description: Input table names that can be referenced in SQL statements. Each input table corresponds to an input stream that is connected to this operation in the job graph. All connected input types must be compatible with the SQL operations. Each type specifies what the schema of the resulting table that is available for the SQL statements looks like. For `COMPLETE_SPAN`, the table schema uses SQL row field names, which differ from the REST JSON property names in the `CompleteSpan` schema.
+
+- name: name (required)
+  type: string
+
+- name: statements (required)
+  type: array of `SqlExecutable`
+  description: List of SQL statements to execute in order. Each statement can reference tables created by previous statements, the input tables, and any tables from the available datasets.
+
+- name: type (required)
+  type: enum: `sql-operation`
+  description: Processes data through a sequence of SQL statements.
+
+- name: watermarkDelay (optional)
+  type: string
+  description: Delay for watermark generation. Default is 5 seconds. Watermarks are used to track event time progress in streaming jobs. The watermark is usually the maximum event time seen by a processing task minus this delay. Watermarks are used to trigger time-based operations like windowing. This delay defines how far behind the system can be in processing events before it considers the event time to be 'late'. Late events would not be included in windowing operations that might have already been closed (ie where the data is already sent). This also means that the results of windowing operations will be delayed by this delay, as the system waits for the watermark to catch up. For more information, see the Flink documentation on watermarks.

package/build/dist/docs-index/1c885279-e929-4c15-88f0-4afa2991005f.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/1c885279-e929-4c15-88f0-4afa2991005f.txt

@@ -0,0 +1,117 @@
+Learn how to safely test data transformation changes to a running production pipeline with the Grepr live edit feature.
+
+# View pipeline data flows and test changes with live edit
+
+The Grepr live edit feature allows you to:
+
+* Safely test changes to data transformations in a running production pipeline. Using live edit, you can make and test changes to the pipeline's data processing and transformations without impacting the processing of live data and the flow of that data to your observability tools. After you've validated your changes, you can apply those changes to the production pipeline.
+* See a live view of how data flows and is processed by the running production pipeline. You can use this capability to monitor the data flowing through your pipeline in real time, even if you're not making changes to the pipeline.
+
+The live edit feature works by creating a temporary copy of the current pipeline but excludes the sink, preventing duplicate data from being sent to your observability platform. Your changes run in the copy of the pipeline. The state of the data at each step of the copied pipeline can be seen in the live edit view. You can also use this view to compare the results of processing between the original and copy pipelines, allowing you to get fast feedback on your changes.
+
+> To ensure that the data passing through the pipeline copy doesn't exceed the UI's capacity, the pipeline copy receives a sampling of the pipeline data. To ensure the pipeline copy is receiving the data you need and the output data contains only the fields you need, you can use filter functionality in the live edit UI. See [Create a subset of data for testing using filters](#filter-source-data).
+
+Any changes you make that are not applied to the production pipeline are visible only in the pipeline copy, and no data is sent to configured sinks or data lakes. When your changes are tested and ready to apply to production, you can apply them to the original pipeline.
+
+## Using live edit with your pipelines
+
+To use live edit:
+
+1. In the Grepr UI, go to the details page for your pipeline.
+
+2. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer**.
+
+3. To create and start a temporary copy of your pipeline, in the expanded **Pipeline Log Viewer** pane, click the play icon.
+
+4. Grepr creates a temporary copy of your pipeline and runs it using log events sampled from the original pipeline's source data. The **Pipeline Log Viewer** pane updates to show the status of the pipeline copy as it's created and started.
+
+5. When the temporary pipeline copy is provisioned and started, the **Pipeline Log Viewer** pane displays the raw logs sampled from the original pipeline's source data. You can use this view to examine logs at different stages of processing, and to test and validate changes to processing.
+
+To examine logs at different stages of processing, use the **Left table link** or **Right table link** menus to select the stage of processing to view.
+
+To view details of a log event, click the event in the **Pipeline Log Viewer** pane to open the log detail pane. The log detail pane displays the contents of the selected log event at the selected processing steps. The top bar of the log detail pane displays the event type, such as `INFO`, `ERROR`, or `DEBUG`, and the timestamp of the log message. To view the state of the event in the selected processing step in the left table, click **LEFT**. To view the state of the event in the selected processing step in the right table, click **RIGHT**. Click **DIFF** to view a JSON comparison of the event state in the left and right panels.
+
+## Create a subset of data for testing using filters \[#filter-source-data]
+
+Because the pipeline copy is receiving a sampling of the source data to ensure that the UI's capacity is not exceeded, the **Pipeline Log Viewer** supports functionality to filter source data. This filtering functionality ensures you get the correct data required for your testing. You can also use this feature to select specific columns to include in tables created from the filtered data.
+
+To use the filter functionality, click the filter icon next to the stop icon. In the filter dialogue, select your preferred query syntax from the **Query language** menu, and enter your filter query in the **Sampler query** text box. To select the columns you want to see in a table created from the filtered data, add and remove column names in the **Table Columns** input.
+
+## Example: Use live edit to add and test a pipeline filter
+
+You can use a local file containing logs for testing instead of streaming live data from the pipeline. This feature can be useful for tasks such as
+
+> * This example uses the pipeline created in the [Build your first Grepr pipeline](/tutorials/first-pipeline) tutorial. If you want to follow the example, first complete that tutorial.
+> * Although this example uses Datadog, you can use the live edit feature with any Grepr-supported observability platform. For the complete list of supported observability vendors, see [Supported integrations](/integrations/support-matrix).
+
+In this example, you use the following steps to test a filter that removes any log messages received by your Grepr pipeline that are assigned the hostname `my-test-host-1`.
+
+1. In the Grepr UI, go to the details page for your running pipeline.
+2. In the left pane, click **Pre-parsing filter** to open the filter configuration, and click **Add** next to **Filters**.
+3. Make sure **Query language** is set to **Datadog**, and enter the following expression in the **Query** field:
+
+```bash
+-host:my-test-host-1
+```
+
+1. *Do not* click **Apply Changes**. Before applying the changes to the production pipeline, use the live edit feature to test and validate the filter.
+
+2. In the lower right corner of the page, click the expand icon to open the **Pipeline Log Viewer** and click the play icon to create and start a temporary copy of your pipeline with the filter added.
+
+3. In the **Pipeline Log Viewer** left table, click a log message from `my-test-host-1`. The log detail pane opens. Because the filter removes the log messages from the pipeline, only the **LEFT** table view is displayed.
+
+4. When you complete validation of your change, click **Apply Changes** to save the new configuration to the production pipeline.
+
+## Use a local file for testing
+
+You can use log events in a local file for testing instead of streaming live data from the pipeline. This can be useful when you want to test pipeline changes against a consistent set of log events, or if you want to test with specific log events that are not currently flowing through the pipeline.
+
+> The log file must be formatted as JSON or plain text, and must not exceed 10 MB in size.
+
+To upload a file for testing:
+
+1. In the **Pipeline Log Viewer** pane, next to the play icon, click **Live** and click the **UPLOAD** tab.
+2. Drag and drop the file to upload, or click the upload area to select the file.
+3. Click **Apply**
+
+## Frequently Asked Questions
+
+### What is the Grepr live edit feature?
+
+Live edit is a feature that allows you to safely test changes to data transformations in a running production pipeline without impacting live data. It creates a temporary copy of your pipeline that excludes sinks, preventing duplicate data from being sent to your observability platform while you test changes.
+
+### How do I start using live edit?
+
+To use live edit, go to the details page for your running pipeline, click the expand icon in the lower right corner to open the Pipeline Log Viewer, and then click the play icon to create and start a temporary copy of your pipeline with sampled data.
+
+### Will live edit changes affect my production pipeline?
+
+No. Changes made in live edit are only visible in the temporary pipeline copy and do not affect production. No data is sent to configured sinks or data lakes until you explicitly apply the changes to the production pipeline.
+
+### What is the Pipeline Log Viewer?
+
+The Pipeline Log Viewer is a pane in the pipeline details that displays logs sampled from the original pipeline's source data. It allows you to examine logs at different processing stages, see how transformations affect data, and compare results between the original and test pipelines.
+
+### Can I see how data flows through each stage of my pipeline?
+
+Yes. Use the Pipeline Log Viewer to examine logs at different stages of processing. Select the processing step from the Left table link or Right table menu to see data at that point. Click a log event to open the detail pane and view its state at different processing steps.
+
+### Why does live edit use sampled data instead of all pipeline data?
+
+Live edit uses sampled data to ensure the pipeline copy doesn't exceed the UI's capacity. This prevents performance issues while still providing representative data for testing. You can use filter functionality to select specific data needed for your testing.
+
+### How do I filter the data shown in Pipeline Log Viewer?
+
+Click the filter icon next to the stop icon in the Pipeline Log Viewer. In the filter dialog, select your preferred query language syntax and enter your filter query in the Sampler query text box. You can also add or remove column names in the Table Columns input to customize the displayed data.
+
+### What does DIFF view show in the log detail pane?
+
+DIFF view shows a JSON comparison of an event's state between the left and right panels of the Pipeline Log Viewer. This allows you to see exactly what changed when processing logs through different pipeline stages or comparing original versus modified pipelines.
+
+### How do I apply tested changes to my production pipeline?
+
+After you've validated your changes in live edit, click 'Apply Changes' in the pipeline editor to save the new configuration to the production pipeline. Your changes will be applied to the running pipeline.
+
+### Can I use live edit to monitor data without making changes?
+
+Yes. You can use live edit to see a live view of how data flows and is processed by your running production pipeline without making any modifications. This allows you to monitor pipeline behavior and performance in real-time.

package/build/dist/docs-index/1cb8b828-e2d2-4789-9382-c2a078f0b730.json

@@ -0,0 +1 @@
+{"docType":"doc"}

package/build/dist/docs-index/1cb8b828-e2d2-4789-9382-c2a078f0b730.txt

@@ -0,0 +1,138 @@
+Understand the data processing models, data models, and abstractions used by Grepr jobs, the types of Grepr jobs, processing modes for jobs, and the jobs lifecycle.
+
+# The Grepr processing and data models
+
+At its core, Grepr is powered by a robust data processing engine that executes *jobs*. These jobs process individual units of data, called *events*.
+
+## Log event model
+
+Grepr uses a data model that makes it easy for you to conceptualize. Log events in Grepr support both structured and unstructured data. The unstructured part is stored in a top-level field called `message` while all structured data is under `attributes`. Additional labels or tags that can be used to identify the source of data and do quick filtering is under `tags`.
+
+Grepr pipeline operators operate on this data model. When using the UI, most of the details of the model are abstracted away. When using the API, you need to understand the model well to build a well-functioning pipeline.
+
+Each log event has the following properties:
+
+* **`id`**: A globally unique id that identifies the log event.
+* **`receivedTimestamp`**: Timestamp when Grepr received the event.
+* **`eventTimestamp`**: Timestamp when the event occurred, usually parsed from the event itself.
+* **`tags`**: A set of key-value pairs that can be used to filter and route events. Some of the commonly used tags are `host`, `service`, `environment`, etc. This is a map from a string key to a set of string values.
+* **`attributes`**: Structured data and fields that are associated with the event. These could be sent with the event from the source or extracted by Grepr from the message.
+* **`message`**: The log message itself.
+* **`severity`**: The severity of the log message. This is an integer, following the OpenTelemetry convention of 1-4 for `TRACE`, 5-8 for `DEBUG`, 9-12 for `INFO`, 13-16 for `WARN`, 17-20 for `ERROR`, and 21-24 for `FATAL`. Severity is usually sent along with the message, but may be parsed from the event too.
+
+An example log event in JSON would look like:
+
+```json
+{
+  "id": "0H19GZK97FTKS",
+  "eventTimestamp": "2024-08-21T04:21:14.062Z",
+  "receivedTimestamp": "2024-08-21T04:21:14.188Z",
+  "severity": 9,
+  "message": "State backend is set to heap memory",
+  "tags": {
+    "app": "greprdev-0gvrs39hhft9q",
+    "kube_ownerref_kind": "deployment",
+    "source": "grepr-query",
+    "organizationId": "greprdev",
+    "service": "grepr-query",
+    "pod_phase": "running",
+    "host": "ip-10-12-4-129.ec2.internal",
+    "image_tag": "0.1.0-3421150",
+    "container_id": "b743c4b78b8ec25c6c73ea03de443ebe19acf760d293dc4145bd31170768a216"
+  },
+  "attributes": {
+    "process": {
+      "thread": {
+        "name": "thread-0"
+      }
+    },
+    "ecs": {
+      "version": "1.2.0"
+    },
+    "timestamp": 1724214074114,
+    "status": "info"
+  }
+}
+```
+
+## Grepr job model \[#grepr-job-model]
+
+All processing within Grepr is a *job*. Each job has a name, a desired state, a current state, and a job graph that describes the data sources, sinks, and the transformations on the data between the sources and sinks. These jobs can:
+
+* Ingest data continuously from various kinds of agents.
+* Execute queries on the Grepr data lake and return the result to the user.
+* Backfill data from the Grepr data lake back to observability vendors.
+
+### The job graph \[#grepr-job-graph]
+
+Each job is a directed acyclic graph (DAG), consisting of vertices and edges. Vertices can be sources, sinks, or transforms. We often refer to vertices in the graph as operators as well. The Grepr UI abstracts away much of the complexity of job management into an app-like experience, so learning the details of these operators and how they work are not necessary.
+
+Each operator may have 0 or more inputs and outputs. Sinks have no outputs while sources have no inputs. All transforms have at least 1 input and 1 output. Many operators will require an integration to work, such as the Iceberg sink or Datadog source.
+
+### Job execution \[#grepr-job-execution]
+
+Jobs have two properties that describe how they are executed: `Execution` and `Processing`.
+
+#### Execution
+
+Jobs have two execution modes: `SYNCHRONOUS` and `ASYNCHRONOUS`. Synchronous jobs are executed immediately and their result is streamed back to the caller. Asynchronous jobs are submitted and run in the background. The results of an asynchronous job end up in a preconfigured sink.
+
+#### Processing
+
+Jobs have two processing modes: `STREAMING` and `BATCH`. Streaming jobs execute continuously on the data as it arrives. They will continue running until they are stopped. Batch jobs have a bounded amount of data that arrives from the sources, which they will read and process, and then they will complete.
+
+When we mention "pipeline" in the docs, we mean `ASYNCHRONOUS` `STREAMING` jobs that will continuously receive data from a source, process it, and then deliver it to one or more sinks. Queries on the other hand are usually `SYNCHRONOUS` `BATCH` jobs that will return a result to the caller, although they can be `ASYNCHRONOUS` `BATCH` jobs too, such as backfill jobs.
+
+### Job lifecycle
+
+Jobs also have a lifecycle. The lifecycle of batch and streaming jobs are different. Batch jobs are submitted, processed, and then completed. Streaming jobs, on the other hand, have a long lifetime and will be running until they are stopped. However, they might need to be reconfigured, upgraded, stopped, and restarted for various reasons over their lifetimes, so their lifecycles are more complex.
+
+A user will specify the desired state for the job, and Grepr will try to make the current state of the job match the desired state. Grepr will automatically start, stop, reconfigure, and restart jobs as needed.
+
+### Autoscaling
+
+Streaming jobs automatically scale up and down to handle an increase or decrease in load and align execution cost with need. Batch jobs automatically execute at an optimal level of parallelism to reduce latency without sacrificing efficiency.
+
+During scale-up or scale-down periods for streaming jobs, there may be a few seconds of data processing delay, during which the pipeline is switching from the old deployment to the new deployment. At the same time, there may be an increase in data lag when there's an increase in load until the pipeline scales up to handle the increase. We aim to keep this lag to less than 5 minutes of delay in the worst case.
+
+## Frequently Asked Questions
+
+### What is a log event in Grepr?
+
+A log event in Grepr is a data unit containing unstructured message data and structured attributes. Each log event has a unique id, receivedTimestamp (when Grepr received it), eventTimestamp (when the event occurred), tags for filtering and routing, attributes for structured data fields, the message itself, and a severity level following OpenTelemetry conventions.
+
+### How are log events structured in Grepr?
+
+Log events support both structured and unstructured data. The unstructured message is stored in a top-level field called 'message', while all structured data is under 'attributes'. Labels or tags that identify the data source and enable quick filtering are stored under 'tags'. This model makes it easy to process logs whether they come in structured or unstructured form.
+
+### What are the different components of a log event?
+
+A log event includes: id (unique identifier), receivedTimestamp (when Grepr received it), eventTimestamp (when it occurred), tags (key-value pairs for filtering), attributes (structured data fields), message (the log text), and severity (following OpenTelemetry 1-24 scale). Each component serves a specific purpose in processing and analyzing the log.
+
+### What is a Grepr job?
+
+A Grepr job is a unit of processing work with a name, desired state, current state, and a job graph describing data sources, sinks, and transformations. Jobs can ingest data continuously from agents, execute queries on the data lake, or backfill data from the data lake to observability vendors. All processing within Grepr is implemented as jobs.
+
+### What is a job graph?
+
+A job graph is a directed acyclic graph (DAG) consisting of vertices and edges. Vertices can be sources (no inputs), sinks (no outputs), or transforms (at least 1 input and 1 output). The job graph describes the data flow from sources through transformations to sinks. The Grepr UI abstracts away the complexity of job graphs into an app-like experience.
+
+### What is the difference between streaming and batch processing?
+
+Streaming jobs execute continuously on data as it arrives and run until stopped, making them ideal for ongoing pipeline operations. Batch jobs have bounded input data from sources, process it, and then complete. Pipelines are typically asynchronous streaming jobs, while queries are usually synchronous batch jobs that return results to the caller.
+
+### What are execution modes in Grepr?
+
+Jobs have two execution modes: Synchronous jobs execute immediately and stream results back to the caller, while asynchronous jobs are submitted and run in the background with results delivered to a preconfigured sink. The choice of execution mode depends on whether you need immediate results or background processing.
+
+### How does job autoscaling work?
+
+Streaming jobs automatically scale up and down to handle increases or decreases in load and align execution cost with need. Batch jobs automatically execute at optimal parallelism levels to reduce latency without sacrificing efficiency. During scaling transitions, there may be a few seconds of processing delay, with a worst-case data lag target of less than 5 minutes.
+
+### What is the lifecycle of a Grepr job?
+
+Jobs have a lifecycle where you specify the desired state and Grepr works to match the current state to it. Batch jobs are submitted, processed, and complete. Streaming jobs have longer lifespans and may be reconfigured, upgraded, stopped, and restarted. Grepr automatically manages job state transitions and handles the complexity of job lifecycle management.
+
+### How does severity work in the Grepr data model?
+
+Severity is an integer following OpenTelemetry conventions: 1-4 for TRACE, 5-8 for DEBUG, 9-12 for INFO, 13-16 for WARN, 17-20 for ERROR, and 21-24 for FATAL. Severity is usually sent with the message from the source but may also be parsed from the event itself during processing.

package/build/dist/docs-index/1d20a88c-4ccb-48e0-ae54-999c209fd288.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1d20a88c-4ccb-48e0-ae54-999c209fd288.txt

@@ -0,0 +1,20 @@
+# List all Gemini integrations
+
+**GET** `/v1/integrations/gemini`
+
+**Operation ID**: `list_5`
+**Summary**: List all Gemini integrations
+Get all Google Gemini integrations for your organization. This will contain masked API keys if present.
+
+## Tags
+- Gemini Integration
+## Responses
+
+### 200
+
+Integrations retrieved successfully
+
+- **Content-Type**: `application/json` / `ItemsCollectionReadGemini`
+### 401
+
+Unauthorized

package/build/dist/docs-index/1d20eca8-3c96-4663-8f23-02e8d151319d.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/1d20eca8-3c96-4663-8f23-02e8d151319d.txt

@@ -0,0 +1,20 @@
+# MaskingOperator
+
+**Type**: `object`
+
+## Properties
+
+- name: attributeMasks (required)
+  type: array of `AttributeMask`
+  description: Masks to apply to attribute values. Each entry names an attribute path (as a list of segments) and the masks to apply to the value at that path. Only string values at the exact path are masked; missing or non-string attributes are skipped. Paths must be unique. The same matching rules as messageMasks apply.
+
+- name: messageMasks (required)
+  type: object
+  description: Masks to apply to the log message, as a map of label to regular expression. Each match is replaced with the label in square brackets, e.g. a match of the regex labeled "email" becomes "[email]". Labels may be up to 64 characters. Overlapping matches resolve to the leftmost match first, then the longest; declaration order breaks remaining ties, so declare more specific patterns first. Regexes must be compatible with Hyperscan syntax (no lookbehind or backreferences).
+
+- name: name (required)
+  type: string
+
+- name: type (required)
+  type: enum: `masking-operator`
+  description: Masks sensitive substrings in log events by replacing regex matches with decorated labels.

package/build/dist/docs-index/1d6e9646-ea07-46b6-847d-0b4734356fcd.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1d6e9646-ea07-46b6-847d-0b4734356fcd.txt

@@ -0,0 +1,32 @@
+# Delete a custom role
+
+**DELETE** `/v1/roles/{roleId}`
+
+**Operation ID**: `deleteRole`
+**Summary**: Delete a custom role
+Deletes a custom role. System roles cannot be deleted.
+
+## Tags
+- Roles
+## Parameters
+
+- **roleId** (required) - path
+  - Type: string
+
+## Responses
+
+### 204
+
+Role deleted successfully
+
+### 400
+
+Cannot delete system role or role in use
+
+### 403
+
+Insufficient permissions
+
+### 404
+
+Role not found

package/build/dist/docs-index/1dc360d0-171b-45cd-b0c5-c8557c02d695.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1dc360d0-171b-45cd-b0c5-c8557c02d695.txt

@@ -0,0 +1,24 @@
+# getUsersInTeam
+
+**GET** `/v1/teams/{id}/users`
+
+**Operation ID**: `getUsersInTeam`
+**Summary**: No summary provided.
+## Tags
+- Teams
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **pageSize** (optional) - query
+  - Type: integer
+- **page** (optional) - query
+  - Type: integer
+
+## Responses
+
+### default
+
+default response
+
+- **Content-Type**: `application/json` / `UsersListInfos`

package/build/dist/docs-index/1e614dde-8753-4a34-a04c-df163c02b5f1.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1e614dde-8753-4a34-a04c-df163c02b5f1.txt

@@ -0,0 +1,33 @@
+# Create a new SSO claim mapping
+
+**POST** `/v1/sso-claim-mapping`
+
+**Operation ID**: `createClaimMapping`
+**Summary**: Create a new SSO claim mapping
+Creates a new SSO claim mapping that assigns roles when token claims match
+
+## Tags
+- SSO Claim Mappings
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `WriteSsoClaimMapping`
+
+## Responses
+
+### 201
+
+Claim mapping created successfully
+
+### 400
+
+Invalid request data (missing required fields, invalid role/team IDs, or validation failed)
+
+### 403
+
+Insufficient permissions
+
+### 409
+
+Claim mapping with this key-value pair already exists

package/build/dist/docs-index/1ea065a8-1936-4e71-8082-480a7242d480.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1ea065a8-1936-4e71-8082-480a7242d480.txt

@@ -0,0 +1,20 @@
+# List all Slack MCP integrations
+
+**GET** `/v1/integrations/slack-mcp`
+
+**Operation ID**: `list_9`
+**Summary**: List all Slack MCP integrations
+Get all Slack MCP server integrations for your organization. This will contain masked tokens if present.
+
+## Tags
+- Slack MCP Integration
+## Responses
+
+### 200
+
+Integrations retrieved successfully
+
+- **Content-Type**: `application/json` / `ItemsCollectionReadSlackMcp`
+### 401
+
+Unauthorized

package/build/dist/docs-index/1ed69735-ae08-4d9c-921d-9b97f48d4d6e.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/1ed69735-ae08-4d9c-921d-9b97f48d4d6e.txt

@@ -0,0 +1,24 @@
+# Delete a S3 Data Warehouse integration
+
+**DELETE** `/v1/integrations/s3-data-warehouse/{id}`
+
+**Operation ID**: `delete_4`
+**Summary**: Delete a S3 Data Warehouse integration
+Deletes an external S3 Data Warehouse integration if it exists. No-op otherwise.
+
+## Tags
+- External S3 Data Warehouse Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+S3 Data Warehouse integration deleted successfully
+
+### 401
+
+Unauthorized

package/build/dist/docs-index/1f8eb26e-67fc-4597-a462-eddb6c60870b.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/1f8eb26e-67fc-4597-a462-eddb6c60870b.txt

@@ -0,0 +1,15 @@
+# TemplateInput
+
+Input values for instantiating a template.
+
+**Type**: `object`
+
+## Properties
+
+- name: draft (optional)
+  type: boolean
+  description: Whether to enable draft mode for the template. In draft mode, the template will receive an additional 'draft' variable with value 'true'. The template should then produce a job graph that includes draft outputs.
+
+- name: values (optional)
+  type: object
+  description: Map of variable names to their values.

package/build/dist/docs-index/1f9a2566-6cfe-43b7-9dcd-e5d4e42e84c9.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/1f9a2566-6cfe-43b7-9dcd-e5d4e42e84c9.txt

@@ -0,0 +1,10 @@
+# RoleIds
+
+The role IDs to assign to the user.
+
+**Type**: `object`
+
+## Properties
+
+- name: roleIds (optional)
+  type: array of string

package/build/dist/docs-index/1fa08424-383e-4bb5-94c8-91213b18e099.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/1fa08424-383e-4bb5-94c8-91213b18e099.txt

@@ -0,0 +1,32 @@
+# AgentConfigUpdate
+
+**Type**: `object`
+
+## Properties
+
+- name: enabledMcpIntegrations (required)
+  type: array of `AgentMcpIntegrations`
+
+- name: enabledSkills (required)
+  type: array of string
+
+- name: enabledTools (required)
+  type: array of string
+
+- name: maxTokens (optional)
+  type: integer
+
+- name: maxTurns (optional)
+  type: integer
+
+- name: modelConfiguration (required)
+  type: `ModelConfiguration`
+
+- name: name (required)
+  type: string
+
+- name: systemPrompt (required)
+  type: string
+
+- name: version (optional)
+  type: integer

package/build/dist/docs-index/20369a7a-cf0e-4d1d-9cef-5b2e6a3db0e7.json

@@ -0,0 +1 @@
+{"docType":"api"}

package/build/dist/docs-index/20369a7a-cf0e-4d1d-9cef-5b2e6a3db0e7.txt

@@ -0,0 +1,29 @@
+# Get a webhook integration
+
+**GET** `/v1/integrations/webhooks/{id}`
+
+**Operation ID**: `get_16`
+**Summary**: Get a webhook integration
+Get a webhook integration by ID.
+
+## Tags
+- Webhook Integration
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+
+## Responses
+
+### 200
+
+Integration retrieved successfully
+
+- **Content-Type**: `application/json` / `ReadWebhookIntegration`
+### 401
+
+Unauthorized
+
+### 404
+
+Integration not found.

package/build/dist/docs-index/209f1b87-c89a-44fd-b3e5-91c11b937085.json

@@ -0,0 +1 @@
+{"docType":"schema"}

package/build/dist/docs-index/209f1b87-c89a-44fd-b3e5-91c11b937085.txt

@@ -0,0 +1,8 @@
+# SocialUserInfo
+
+**Type**: `object`
+
+## Properties
+
+- name: idToken (required)
+  type: string

package/build/dist/docs-index/20d92a8d-5101-42fb-9acd-8dcb38cffe6b.json

@@ -0,0 +1 @@
+{"docType":"api"}