@grepr/cli 1.2.0 → 1.3.0-4e666db

package/build/dist/docs-index/a9f93969-2452-4870-9696-4877500395b3.json

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

package/build/dist/docs-index/a9f93969-2452-4870-9696-4877500395b3.txt

@@ -1,168 +0,0 @@
----
-description: 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.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# 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 copy
-{
-  "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.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is a log event in Grepr?",
-    a: "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."
-  },
-  {
-    q: "How are log events structured in Grepr?",
-    a: "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."
-  },
-  {
-    q: "What are the different components of a log event?",
-    a: "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."
-  },
-  {
-    q: "What is a Grepr job?",
-    a: "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."
-  },
-  {
-    q: "What is a job graph?",
-    a: "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."
-  },
-  {
-    q: "What is the difference between streaming and batch processing?",
-    a: "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."
-  },
-  {
-    q: "What are execution modes in Grepr?",
-    a: "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."
-  },
-  {
-    q: "How does job autoscaling work?",
-    a: "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."
-  },
-  {
-    q: "What is the lifecycle of a Grepr job?",
-    a: "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."
-  },
-  {
-    q: "How does severity work in the Grepr data model?",
-    a: "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/aaa321a3-301f-4dd9-9ffd-86f7368229b4.json

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

package/build/dist/docs-index/aaa321a3-301f-4dd9-9ffd-86f7368229b4.txt

@@ -1,20 +0,0 @@
-# JobAnomaly
-
-**Type**: `object`
-
-## Properties
-
-- name: jobId (required)
-  type: string
-
-- name: ruleEngineName (required)
-  type: string
-
-- name: triggerId (required)
-  type: string
-
-- name: firstTriggeredAt (optional)
-  type: string
-
-- name: lastTriggeredAt (required)
-  type: string

package/build/dist/docs-index/ab33a2ad-935b-44ca-a50d-33e190324642.json

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

package/build/dist/docs-index/ab33a2ad-935b-44ca-a50d-33e190324642.txt

@@ -1,24 +0,0 @@
-# CreateUser
-
-**Type**: `object`
-
-## Properties
-
-- name: email (required)
-  type: string
-  description: The email associated with the user.
-
-- name: firstName (required)
-  type: string
-  description: The first name of the user.
-
-- name: lastName (required)
-  type: string
-  description: The last name of the user.
-
-- name: roleIds (required)
-  type: array of string
-  description: The roles associated with this user.
-
-- name: password (required)
-  type: `SecretApi`

package/build/dist/docs-index/ab4bc466-72d3-440a-a4bb-6abc5a56c408.json

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

package/build/dist/docs-index/ab4bc466-72d3-440a-a4bb-6abc5a56c408.txt

@@ -1,254 +0,0 @@
----
-description: This page provides a reference to the comprehensive set of transformers supported by the Grok parser in the Grepr platform.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# The Grepr Grok parser: Supported transformers
-
-Transformers are included in a Grok rule to convert matched values before adding them to output log events. This page provides a reference for the comprehensive set of transformers supported by the Grok parser in the Grepr platform.
-
-## Type conversion transformers [#type-conversion-transformers]
-
-**`number`**: Parses the matched value as a double-precision floating point number.
-
-```bash
-%{data:value:number}
-# Input:  "123.45"
-# Output: {"value": 123.45}
-```
-
-**`integer`**: Parses the matched value as an integer number.
-
-```bash
-%{data:count:integer}
-# Input:  "42"
-# Output: {"count": 42}
-```
-
-**`boolean`**: Parses `true` and `false` strings as booleans, ignoring case.
-
-```bash
-%{data:is_active:boolean}
-# Input:  "True"
-# Output: {"is_active": true}
-```
-
-## String transformers [#grok-string-transformers]
-
-**`lowercase`**: Converts the matched value to lowercase.
-
-```bash
-%{word:username:lowercase}
-# Input:  JohnDoe
-# Output: {"username": "johndoe"}
-```
-
-**`uppercase`**: Converts the matched value to uppercase.
-
-```bash
-%{word:status:uppercase}
-# Input:  active
-# Output: {"status": "ACTIVE"}
-```
-
-## Data parsing transformers [#grok-data-parsing-transformers]
-
-**`json`**: Parses a properly formatted JSON string into a JSON object.
-
-```bash
-%{data:metadata:json}
-# Input:  {"key": "value", "count": 42}
-# Output: {"metadata": {"key": "value", "count": 42}}
-```
-
-**`keyvalue([separatorStr[, characterAllowList[, quotingStr[, delimiter]]]])`**: Parses key-value pairs from strings into structured attributes.
-
-See [The key-value transformer](#grok-key-value-transformer).
-
-**`useragent([decodeuricomponent:true/false])`**: Parses a user-agent string and returns a JSON object containing device, operating system, and browser information.
-
-**Parameters:**
-- `decodeuricomponent`: If set to `true`, URL-decodes the user-agent string before parsing (default: `false`)
-
-**Output structure:**
-```json
-{
-  "userAgent": {
-    "family": "Chrome",
-    "major": "120",
-    "minor": "0",
-    "patch": "0"
-  },
-  "os": {
-    "family": "Mac OS X",
-    "major": "10",
-    "minor": "15",
-    "patch": "7"
-  },
-  "device": {
-    "family": "Mac"
-  }
-}
-```
-
-**Example:**
-
-```bash
-%{data:user_agent_info:useragent}
-# Input:  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
-# Output: {"user_agent_info": {"userAgent": {"family": "Chrome", "major": "120", ...}, "os": {...}, "device": {...}}}
-```
-
-## Value transformers [#grok-value-transformers]
-
-{/* Uncomment when ENGT-3480 is resolved:
-**`nullIf("value")`**: Returns `null` if the matched value equals the specified value, otherwise returns the matched value unchanged.
-
-**Parameters:**
-- `value`: The value to compare against
-
-**Example:**
-
-```bash
-%{word:status:nullIf("none")}
-# Input:  none
-# Output: {"status": null}
-# Input:  active
-# Output: {"status": "active"}
-```
-*/}
-
-**`scale(factor)`**: Multiplies the matched numeric value by the specified factor.
-
-**Parameters:**
-- `factor`: The multiplication factor
-
-**Examples:**
-
-```bash
-# Convert bytes to kilobytes
-%{number:size_kb:scale(0.001)}
-# Input:  1024
-# Output: {"size_kb": 1.024}
-
-# Convert milliseconds to seconds
-%{number:duration_seconds:scale(0.001)}
-# Input:  5000
-# Output: {"duration_seconds": 5}
-
-# Convert percentage to decimal
-%{number:ratio:scale(0.01)}
-# Input:  75
-# Output: {"ratio": 0.75}
-```
-
-**`isoDateTimeToMillis`**: Converts an ISO 8601 formatted date-time string to milliseconds since epoch.
-
-**Example:**
-
-```bash
-%{data:timestamp:isoDateTimeToMillis}
-# Input:  2024-03-15T14:30:45Z
-# Output: {"timestamp": 1710512445000}
-# Input:  2024-03-15T14:30:45.123Z
-# Output: {"timestamp": 1710512445123}
-```
-
-## The key-value transformer [#grok-key-value-transformer]
-
-The `keyvalue` transformer parses key-value pairs from strings into structured attributes. For example, `user=john email=john@example.com` becomes `{"user": "john", "email": "john@example.com"}`.
-
-**Syntax:** `keyvalue([separatorStr[, characterAllowList[, quotingStr[, delimiter]]]])`
-
-**Parameters:**
-- `separatorStr`: Character between key and value (default: `=`).
-- `characterAllowList`: Additional characters allowed in unquoted values beyond `\w.-_@`.
-- `quotingStr`: Custom quote pairs as opening and closing character pairs (default: `<>`, `""`, `''`).
-- `delimiter`: Separator between key-value pairs (default: ` `, `,`, `;`).
-
-When you use the `keyvalue` transformer:
-
-- Empty values (`key=`) and null values (`key=null`) are skipped.
-- If there's a duplicate key in the input to the `keyvalue` transformer, the value that's added to the output attributes is from the last occurrence of the key.
-- Whitespace around separators is ignored.
-- To include special characters like `/` or `:` in values, add them to `characterAllowList`.
-
-**Examples:**
-
-```bash
-# Basic usage with default separator
-%{data::keyvalue}
-# Input:  user=john email=john@example.com
-# Output: {"user": "john", "email": "john@example.com"}
-
-# Custom separator
-%{data::keyvalue(":")}
-# Input:  user:john email:john@example.com
-# Output: {"user": "john", "email": "john@example.com"}
-
-# Character allowlist for special characters
-%{data::keyvalue("=", "/:@")}
-# Input:  path=/home/user email=test@example.com
-# Output: {"path": "/home/user", "email": "test@example.com"}
-
-# Custom delimiter
-%{data::keyvalue("=", "", "", "|")}
-# Input:  key1=value1|key2=value2
-# Output: {"key1": "value1", "key2": "value2"}
-
-# Custom quote pairs
-%{data::keyvalue(":=", "", "{}")}
-# Input:  key:={value with spaces}
-# Output: {"key": "value with spaces"}
-
-# Multiple delimiters
-%{data::keyvalue}
-# Input:  user=john, email=john@example.com; role=admin
-# Output: {"user": "john", "email": "john@example.com", "role": "admin"}
-```
-
-<HiddenFAQ
-  faqs={[
-    {
-      q: "What are Grok transformers and how do they work?",
-      a: "Grok transformers are applied after a matcher extracts a value. They convert or process the matched value before adding it to the output. For example, the number transformer converts a matched string to a double, and the lowercase transformer converts text to lowercase. Transformers use the syntax %{matcher:field:transformer}."
-    },
-    {
-      q: "What type conversion transformers are available?",
-      a: "Available type conversion transformers are: number (converts to double-precision float), integer (converts to integer), and boolean (converts true/false strings to booleans, case-insensitive). These allow you to change the data type of matched values."
-    },
-    {
-      q: "When should I use lowercase vs uppercase transformers?",
-      a: "Use lowercase to convert text to all lowercase characters, useful for normalizing usernames or other case-insensitive data. Use uppercase to convert text to all uppercase characters. This is often used for standardizing data before filtering or matching."
-    },
-    {
-      q: "How does the json transformer work?",
-      a: "The json transformer parses a properly formatted JSON string into a structured JSON object. Use this when a matched value contains JSON data. For example, %{data:metadata:json} would parse a JSON string and output the parsed object structure."
-    },
-    {
-      q: "What is the keyvalue transformer and when is it used?",
-      a: "The keyvalue transformer parses key-value pairs from strings into structured attributes. For example, user=john email=john@example.com becomes {user: john, email: john@example.com}. It supports custom separators, character allowlists, quote pairs, and delimiters. Use it when data contains key=value formatted content."
-    },
-    {
-      q: "How do I use the keyvalue transformer with custom separators?",
-      a: "Specify the separator as the first parameter: keyvalue(':') uses colons instead of equals signs. You can also add a character allowlist as the second parameter: keyvalue('=', '/:@') allows slashes, colons, and at-signs in values. Optional parameters let you customize quote pairs and delimiters between pairs."
-    },
-    {
-      q: "What does the useragent transformer extract?",
-      a: "The useragent transformer parses user-agent strings and returns structured data with userAgent (family, major, minor, patch), os (family, major, minor, patch), and device (family) information. It's useful for parsing browser and OS information from log data. It supports optional URL-decoding with the decodeuricomponent parameter."
-    },
-    {
-      q: "How does the scale transformer work?",
-      a: "The scale transformer multiplies a numeric value by a specified factor. For example, scale(0.001) converts 1024 bytes to 1.024 kilobytes. Use this for unit conversion, percentage calculations, or other scaling operations on numeric fields."
-    },
-    {
-      q: "What is the isoDateTimeToMillis transformer?",
-      a: "The isoDateTimeToMillis transformer converts ISO 8601 formatted date-time strings to milliseconds since epoch. For example, 2024-03-15T14:30:45Z becomes 1710512445000. Use this to normalize timestamp formats from ISO 8601 to millisecond epoch timestamps."
-    },
-    {
-      q: "Can I combine multiple transformers on a single matcher?",
-      a: "Yes, you can chain transformers together. For example, %{data:value:lowercase:json} would first convert text to lowercase, then parse it as JSON. However, practical chaining is limited - most transformers expect specific input types. Check documentation to ensure transformers are compatible in sequence."
-    }
-  ]}
-/>

package/build/dist/docs-index/abce3ed4-66b9-4a5f-b562-ba51e678c31d.json

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

package/build/dist/docs-index/abce3ed4-66b9-4a5f-b562-ba51e678c31d.txt

@@ -1,20 +0,0 @@
-# List all Data Warehouse integrations
-
-**GET** `/v1/integrations/data-warehouse`
-
-**Operation ID**: `list_1`
-**Summary**: List all Data Warehouse integrations
-Retrieves all Data Warehouse integrations for the organization.
-
-## Tags
-- Grepr-hosted Data Warehouse Integration
-## Responses
-
-### 200
-
-Data Warehouse integrations retrieved successfully
-
-- **Content-Type**: `application/json` / `ItemsCollectionReadDataWarehouse`
-### 401
-
-Unauthorized

package/build/dist/docs-index/ac4af805-6114-46eb-8a56-6af3fac9711f.json

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

package/build/dist/docs-index/ac4af805-6114-46eb-8a56-6af3fac9711f.txt

@@ -1,22 +0,0 @@
-# IntegrationExceptionsList
-
-Paginated list of vendor imported exceptions for an integration
-
-**Type**: `object`
-
-## Properties
-
-- name: exceptions (optional)
-  type: `ItemsCollectionVendorImportedException`
-
-- name: page (optional)
-  type: integer
-  description: Current page number (0-based)
-
-- name: pageSize (optional)
-  type: integer
-  description: Number of items per page
-
-- name: hasMore (optional)
-  type: boolean
-  description: Whether there are more pages available

package/build/dist/docs-index/acaba58b-589f-4577-85c6-33ac32e531e9.json

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

package/build/dist/docs-index/acaba58b-589f-4577-85c6-33ac32e531e9.txt

@@ -1,16 +0,0 @@
-# SplunkLogAgentSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: integrationId (required)
-  type: string
-  description: The integration id for the observability vendor.
-
-- name: type (required)
-  type: enum: `splunk-log-agent-source`
-  description: Reads log events from Splunk HEC collector. This is used to pre-process logs before being sent to Splunk.

package/build/dist/docs-index/ad8669b6-1b86-490d-80fb-29c70be6fcb5.json

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

package/build/dist/docs-index/ad8669b6-1b86-490d-80fb-29c70be6fcb5.txt

@@ -1,14 +0,0 @@
-# QueryJobToken
-
-Token issued for a submitted query job. This is used to retrieve the job details and results.
-
-**Type**: `object`
-
-## Properties
-
-- name: sessionToken (required)
-  type: string
-  description: Token to verify the user's session.
-
-- name: jobInfo (required)
-  type: `QueryJobInfo`

package/build/dist/docs-index/ae2d8d97-2e7a-4531-b5d1-c407844dd942.json

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

package/build/dist/docs-index/ae2d8d97-2e7a-4531-b5d1-c407844dd942.txt

@@ -1,15 +0,0 @@
-# TeamAssignment
-
-Team assignment for an invitation
-
-**Type**: `object`
-
-## Properties
-
-- name: teamId (required)
-  type: string
-  description: The ID of the team
-
-- name: role (required)
-  type: enum: `LEADER`, `MEMBER`
-  description: The role within the team

package/build/dist/docs-index/af3700de-06eb-486b-afd7-9a51ab375d0e.json

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

package/build/dist/docs-index/af3700de-06eb-486b-afd7-9a51ab375d0e.txt

@@ -1,29 +0,0 @@
-# Get a Splunk integration
-
-**GET** `/v1/integrations/splunk/{id}`
-
-**Operation ID**: `get_5`
-**Summary**: Get a Splunk integration
-Get an integration to connect to Splunk.
-
-## Tags
-- Splunk Integration
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Integration retrieved successfully
-
-- **Content-Type**: `application/json` / `ReadSplunk`
-### 401
-
-Unauthorized
-
-### 404
-
-Integration not found.

package/build/dist/docs-index/b15f5227-a29a-4127-8850-34132d1ca1b1.json

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

package/build/dist/docs-index/b15f5227-a29a-4127-8850-34132d1ca1b1.txt

@@ -1,43 +0,0 @@
-# GreprRawLogsSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: start (required)
-  type: string
-  description: Start of time interval to query data for.
-
-- name: end (required)
-  type: string
-  description: End of time interval to query data for.
-
-- name: query (required)
-  type: `query`
-
-- name: variables (optional)
-  type: object
-  description: Variables that can be used to modify the query while parsed
-
-- name: offset (optional)
-  type: integer
-  description: Offset on the number of rows to process
-
-- name: limit (optional)
-  type: integer
-  description: The maximum number of rows to process
-
-- name: sortOrder (optional)
-  type: enum: `ASCENDING`, `DESCENDING`, `UNSORTED`
-  description: The order in which the rows should be sorted by
-
-- name: datasetId (required)
-  type: string
-  description: The ID of the dataset to read data from.
-
-- name: type (required)
-  type: enum: `grepr-raw-log-source`
-  description: Reads raw log events using Grepr's internal query system from an Iceberg Table without pattern enrichment.