@grepr/cli 1.11.5-17c35fd → 1.11.5-1b47e00

package/build/dist/docs-index/26354ad4-2115-4014-81bf-7ce14aeb9906.txt

@@ -1,218 +0,0 @@
-Aggregate logs in the Grepr data lake with Analyze mode, using Grepr SQL expressions over log fields, tags, and parsed attributes.
-
-# Aggregate logs with Analyze mode
-
-Log Explorer's Analyze mode groups and aggregates the logs your search returns instead of listing them. You describe the analysis as a set of Grepr SQL expressions, and Grepr runs it against the logs in the data lake.
-
-## Create an analysis
-
-1. Go to Log Explorer and select a dataset and a time range.
-2. Enter a search query to filter the logs you want to analyze. Analyze mode accepts the same [Datadog-like syntax](/queries/datadog) and [New Relic log query-like syntax](/queries/new-relic) as searching.
-3. Open the **Analyze...** drawer under the search controls.
-4. Under **SELECT**, enter one expression per result column, and name it in the **Alias** field beside it. An alias is optional; a column you leave unnamed is named for you, after the field or function it computes.
-5. Under **GROUP BY**, add the expressions whose distinct combinations you want as rows. Each grouping expression also becomes a result column, so the rows show the values they are grouped on. Without a grouping expression, an analysis made only of aggregates returns a single row.
-6. Under **HAVING**, enter a condition over the aggregates to keep only some of the groups. Leave it empty to keep every group.
-7. Under **ORDER BY**, add the expressions to sort by and pick ascending or descending for each one.
-8. Set **Row limit**, the maximum number of rows to return. An analysis returns 2,500 rows by default, up to the largest limit your deployment allows.
-9. Set **Scan budget** to cap how much of the lake the query may read, then run the analysis.
-
-The drawer's clauses are the SQL ones, so an analysis reads the way the query does: SELECT computes, GROUP BY collapses, HAVING filters the groups, ORDER BY and the row limit choose which of them you see. GROUP BY, HAVING and ORDER BY can refer to a result by its alias.
-
-Every SELECT column is either an aggregate or one of the grouping expressions. To count events by a field, add the field under SELECT and group by it.
-
-## Log fields
-
-Expressions address the stored log columns by the following names:
-
-| Field | Type | Description |
-| --- | --- | --- |
-| `message` | VARCHAR | The log line. |
-| `severity` | INTEGER | The numeric severity level, where a higher number is more severe. |
-| `event_timestamp` | TIMESTAMP | When the event happened. |
-| `received_timestamp` | TIMESTAMP | When Grepr received the event. |
-| `id` | VARCHAR | The identifier of the event. |
-| `tags` | MAP | The tag values, keyed by tag name. |
-| `attributes` | VARIANT | The whole parsed attribute document. |
-
-> These are the Grepr SQL column names, which use `snake_case`. They are not the camelCase field names of the log event JSON that the search and export APIs return.
-
-A tag holds an array of values, so picking a tag key from the suggestions groups by the sorted, comma-joined set of its values — two events tagged with the same values in a different order land in one group:
-
-```sql
-ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
-```
-
-Index a single value with `[1]` when you want only the first:
-
-```sql
-tags['service'][1]
-```
-
-## Attribute values
-
-Grepr parses structured logs into an attribute document. Address a single attribute with the `@` form, which takes a dotted path through that document:
-
-```sql
-@duration_ms
-@http.status_code
-@kubernetes.labels.app
-```
-
-The shorthand reads one value out of the parsed document. The `attributes` column is the whole document, so use `@` when you want a field and `attributes` when you want the object itself.
-
-An attribute has no declared type, because two logs in the same dataset can carry different types under the same name. Grepr infers a type from how you use the value, so `SUM(@duration_ms)` reads it as a number and `LOWER(@user.email)` reads it as a string.
-
-Cast the attribute when you need a specific type or precision, and when you sort:
-
-```sql
--- Read the attribute as a whole number
-CAST(@duration_ms AS BIGINT)
-
--- Or aggregate the cast value
-MIN(CAST(@duration_ms AS DOUBLE))
-```
-
-> Sorting by an attribute you have not cast sorts it as text, so `100` sorts before `99`. Cast it to sort numerically.
-
-A path segment is a name or a number, and the segments are separated by dots.
-
-## Expressions
-
-Expressions are Grepr SQL, so aggregates, `CASE`, `CAST` and scalar functions are all available.
-
-Every function an analysis can call is listed in the [Analyze function reference](/queries/analyze/functions), with its arguments and a worked example. Focus an expression box or start typing to find fields, functions, sampled tag and attribute keys, and result aliases.
-
-> The [SQL transform function reference](/transforms/sql-transform/sql-functions) does **not** describe Analyze. A SQL transform runs inside a pipeline on Flink SQL; an analysis runs on the query engine over the data lake. The two support different functions, so a function listed there may not exist here, and the autocomplete offers functions that page does not list.
-
-```sql
--- Log count by service: the first line goes under SELECT, the second under GROUP BY
-COUNT(*)
-ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')
-
--- 95th percentile request duration by endpoint, the same way
-APPROX_PERCENTILE(@duration_ms, 0.95)
-@http.route
-
--- A SELECT column that buckets rather than aggregates
-CASE WHEN severity >= 4 THEN 'error' ELSE 'ok' END
-```
-
-`SEVERITY_TEXT` names the OpenTelemetry severity bucket a severity number falls in: `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR` or `FATAL`, and nothing for a log with no severity. It takes a whole number, so cast an attribute before passing it. Grouping by it is the usual way to count logs per level:
-
-```sql
--- Under SELECT
-COUNT(*)
-
--- Under GROUP BY
-SEVERITY_TEXT(severity)
-```
-
-## Name the results
-
-Every SELECT column takes an optional alias, entered in the **Alias** field beside the expression. The alias becomes the result column's name. Leave it empty and Grepr names the column after the expression itself:
-
-| Expression | Alias | Result column |
-| --- | --- | --- |
-| `COUNT(*)` | empty | `count0` |
-| `APPROX_PERCENTILE(@duration_ms, 0.95)` | `p95` | `p95` |
-| `ARRAY_TO_STRING(SORT_ARRAY(tags['service']), ',')` | `service`, filled in for you | `service` |
-| `severity` | empty | `severity` |
-| `@http.route` | `route` | `route` |
-
-An alias can then be referred to under GROUP BY, HAVING or ORDER BY, anywhere inside that expression rather than only as the whole of it:
-
-```sql
--- Under HAVING
-count0 > 100
-
--- Under ORDER BY
-p95 / 1000
-```
-
-Aliases are lowercase, made of letters, digits and underscores, up to 128 characters, and a reference has to match exactly.
-
-> Enter the alias in its own field, not in the expression: `AS p95` inside an expression is not valid. An alias is available to GROUP BY, HAVING and ORDER BY, and to the SELECT columns after the one that defines it.
-
-Reserved SQL words cannot be aliases, because the query engine would read them as syntax. That is why the default first column is `count0` rather than `count`, and why a name Grepr derives for you gains a `0` when it lands on a reserved word.
-
-> `count`, `max`, `min`, `sum`, `value`, `date` and `year` are reserved. Ordinary field names such as `level`, `name`, `type`, `path`, `service`, `host` and `user` are not.
-
-## Window by time
-
-To see how an aggregate changes over time, add a time window under the grouping expressions. Every result row then carries a `window_start` and a `window_end` column, and the other grouping keys and aggregates are computed per window. The analysis is sorted by `window_start` descending, so the newest window leads.
-
-| Kind | Meaning |
-| --- | --- |
-| Tumbling | Fixed windows that do not overlap. A 5 minute window puts each log in exactly one bucket. |
-| Sliding | Windows of one size that start every *slide*. A 5 minute window sliding every 1 minute counts each log in five overlapping windows. The size must be a whole multiple of the slide, and a window can cover at most 100 slides. |
-
-Each duration is a whole number of milliseconds, seconds, minutes, hours, or days. Windows bucket by event time by default; choose receive time to bucket by when Grepr received each log instead. The time range you searched selects logs by event time either way.
-
-Windows are aligned to the clock rather than to the start of your time range, so the first and last windows of a range can be partial.
-
-In the API, the window is the `window` object of the structured analytics query, with ISO-8601 durations:
-
-```json
-{ "kind": "SLIDING", "timestamp": "EVENT_TIMESTAMP", "size": "PT5M", "slide": "PT1M" }
-```
-
-## Read the results table
-
-Click a column header to sort the rows you already have. No second run happens and no scan budget is spent; Shift-click adds a second sort instead of replacing the first.
-
-When an analysis comes back at its row limit, the rows you have are only the top of the ranking, so sorting them on the page can put the wrong rows first. **Sort on the server** puts the sort into ORDER BY and runs the analysis again, so the engine ranks every matching row.
-
-## Share an analysis
-
-The whole analysis lives in the page URL, so copying the link from the address bar is enough to share it. The link carries the dataset, the time range, the search query, every SELECT expression and its alias, every GROUP BY expression, the HAVING condition, the ORDER BY, the time window, the row limit, the scan budget, and the way you arranged the results table — its column order, column widths and sort.
-
-Opening such a link seats every control and runs the analysis once, so the recipient sees the rows rather than a filled-in form waiting for a click. Back and Forward move between analyses you have already run, restoring the controls without re-running and spending scan budget again.
-
-## Result values
-
-Each result row is a JSON object keyed by column name, so a column holds whatever the underlying attribute held, such as a number, a string, a boolean, or a nested object. Timestamps are returned as UTC ISO 8601 strings.
-
-## Limitations
-
-* An analysis reads one dataset at a time. Joins across datasets are not supported.
-* Sorting by an attribute that you have not cast sorts it by its stored text, so `100` sorts before `99`. Cast the attribute to sort numerically, as in `CAST(@http.status_code AS BIGINT)`.
-* A result alias cannot be a reserved SQL word, and a reference to one has to match its lowercase spelling exactly.
-* A sort you set from the result headers sorts the rows already on the page. When the analysis returned its row limit, use **Sort on the server** to rank every matching row instead.
-* An analysis too long to fit in the address bar cannot be shared as a link.
-* An analysis can compute at most 128 values, group by at most 64 expressions, and sort by at most 64 expressions. Each expression can be at most 4,096 characters long.
-* A time window's size and slide are whole milliseconds, and a sliding window covers at most 100 slides. `window_start` and `window_end` cannot be used as result aliases while a window is set.
-* Row, array, and map values are converted to nested JSON automatically. A value whose type has no JSON representation at all, or a constructed row with two fields of the same name, cannot be returned.
-
-## Frequently Asked Questions
-
-### How do I aggregate logs in Grepr?
-
-Go to Log Explorer, select a dataset and time range, enter a search query, then open the Analyze... drawer under the search controls. Enter Grepr SQL expressions under SELECT for the result columns, under GROUP BY for the grouping keys, and under ORDER BY for the sort.
-
-### What are the log field names in Grepr SQL?
-
-message, severity, event_timestamp, received_timestamp, id, tags, and attributes. Read the whole set of a tag's values as ARRAY_TO_STRING(SORT_ARRAY(tags\['service']), ','), index a single value as tags\['service']\[1], and address an attribute as @http.status_code.
-
-### How do I bucket an analysis by time?
-
-Add a time window under the grouping expressions in Analyze mode. Choose tumbling or sliding, a size, and for sliding windows a slide. Results gain window_start and window_end columns.
-
-### How many rows can an analysis return?
-
-An analysis returns 2,500 rows by default. The largest limit you can ask for is set by your deployment.
-
-### How do I share a Grepr analysis?
-
-Copy the page URL. The link carries the dataset, time range, query, every expression and alias, the window, the row limit, the scan budget and the column order, widths and sort, and opening it runs the analysis once.
-
-### Why can't I name a result column count?
-
-count is a reserved SQL word, so the query engine would read it as syntax rather than as an alias. Name the column count0 or anything else that is not reserved; that is why the default first column is named count0.
-
-### How do I turn severity numbers into names in Grepr?
-
-Use SEVERITY_TEXT(severity), which names the OpenTelemetry bucket: TRACE, DEBUG, INFO, WARN, ERROR or FATAL. It takes a whole number, so cast an attribute before passing it.
-
-### How do I sort an analysis by a result column?
-
-Click the column header in the results table. The rows on the page reorder immediately, without a second run. If the analysis returned its row limit, use Sort on the server, which puts the sort into ORDER BY and runs the analysis again.

package/build/dist/docs-index/2f89a060-0af2-4ec3-b2b4-467199a29a64.txt

@@ -1,111 +0,0 @@
-Process data in Grepr pipelines using built-in tools for parsing, filtering, enrichment, and transformation of log events.
-
-# Transform data in a Grepr pipeline
-
-A Grepr transform is a processing step that modifies, enriches, or restructures data as it flows through a pipeline. As records move through a pipeline, transforms allow you to parse structured and semi-structured data, filter records, and use a familiar SQL interface to perform more complex transformation of records as they move through a pipeline. Transforms are configured as pipeline steps that process data sequentially. Each transform receives input data, applies its logic, and passes the result to the next step in the pipeline.
-
-Most transforms are available in the Grepr pipelines UI. Some transforms are available only in the Grepr REST API or provide more capabilities when used with the API, such as [filters](#filter) and [branching the processing of records](#message-routing) based on query matches.
-
-The following sections describe the transforms available in Grepr pipelines.
-
-## Transform semi-structured records with the Grok parser \[#grok-parser]
-
-The Grok transform parses unstructured text using pattern matching with regular expressions and named capture groups. Use this transform to extract fields from log lines, error messages, and other text-based data where you need to identify specific patterns and convert them to structured fields.
-
-See [Grok parser](/transforms/grok).
-
-## Convert JSON messages into structured objects \[#json-parser]
-
-The JSON parser transforms JSON strings into structured JSON objects. This transform handles nested objects, arrays, and various data types, making it useful for processing API responses, configuration data, and structured log entries.
-
-See [Transform JSON strings into JSON objects](/transforms/json-parsing).
-
-## Restructure JSON objects with a remapper \[#remapper]
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. You can also use rename rules to move attribute values from one path to another within the same event. In the pipelines UI, a remapper with customizable default attributes is automatically added to a pipeline.
-
-See [Remap JSON attribute fields to top-level log event fields](/transforms/remapper).
-
-## Transform records with SQL \[#sql-transform]
-
-The SQL transform allows you to use ANSI standard SQL queries to filter, transform, and enrich data records. The SQL transform provides a familiar SQL interface to perform a number of data processing and transformation tasks.
-
-You can use the SQL transform in the Grepr UI or REST API. In the UI, the SQL transform is available when you configure filters.
-
-To learn about using the SQL transform in the Grepr API, see the [SQL Operation specification](/apis/api-spec#schema/SQLOperation).
-
-For a complete reference and examples, see [Transform events with SQL](/transforms/sql-transform).
-
-## Filter records based on conditions \[#filter]
-
-The Filter transform includes or excludes data records based on specified conditions. You can create filters using familiar query interfaces, such as SQL, as well as Datadog and New Relic log query-like syntaxes.
-
-In the Grepr pipelines UI, filters are located in predefined locations in the pipeline. To learn how to configure filters, see [Filter events in a Grepr pipeline](/transforms/filter-events).
-
-To have more flexibility for where filters are included in a pipeline, use the REST API. See [LogsFilter](/apis/api-spec#schema/LogsFilter).
-
-## Reduce log volumes with dynamic aggregation \[#reducer]
-
-The Grepr log reducer uses clustering algorithms to identify patterns in your log data and aggregate similar log messages. The output of this aggregation includes summaries and samples of similar messages. The log reducer is a core step in a log reduction pipeline, where it runs before processed log events are sent to your configured sinks. By sending summaries of similar messages rather than multiple events with redundant information, Grepr significantly reduces the volume of shipped logs and your observability costs. The log reduction pipeline also persists the complete set of raw logs to a low-cost data lake, enabling you to analyze and troubleshoot issues when necessary.
-
-To learn more about how Grepr reduces log volumes with dynamic aggregation, see [Reduce noise and improve the usability of your logs with the log reducer](/transforms/reducer).
-
-To learn how to create a log reduction pipeline, see [Tutorial: Build your first Grepr pipeline](/tutorials/first-pipeline).
-
-To learn how to use the resulting summarized log events in your observability platform along with raw logs stored in Grepr, see [Troubleshoot incidents with Grepr-processed data and your observability tool](/tutorials/troubleshooting-example).
-
-## Transform and enrich log messages with the REST API \[#log-transform-action]
-
-You can use the LogTransformAction in the REST API to specify actions that transform log messages, such as adding or removing attributes and tags. See [LogTransformAction](/apis/api-spec#schema/LogTransformAction).
-
-## Route the processing of messages based on query matches \[#message-routing]
-
-You can route log messages to be processed by different pipelines based on query matches. Because the pipelines UI doesn't support branching, Grepr recommends creating multiple pipelines that ingest data using the same source, and then use filters to route data to the correct pipeline.
-
-You can also use the REST API to create more complex pipeline configurations. See [LogsBranch](/apis/api-spec#schema/LogsBranch).
-
-## Frequently Asked Questions
-
-### What transforms are available in Grepr pipelines?
-
-Grepr provides several transform types: Grok parser for parsing unstructured text with pattern matching, JSON parser for converting JSON strings into structured objects, remapper for restructuring JSON fields and attributes, SQL transform for complex filtering and enrichment using SQL queries, and Filter transform for conditional record processing. Most transforms are available in the UI, while some advanced options are available via REST API.
-
-### When should I use the Grok parser transform?
-
-Use the Grok parser when you need to extract structured data from unstructured text logs. It's ideal for parsing error messages, application logs, system logs, and other text-based data where you need to identify specific patterns and convert them into structured fields using regular expressions and named capture groups.
-
-### When should I use the JSON parser transform?
-
-Use the JSON parser when your log messages contain JSON strings that need to be converted into structured JSON objects. This is useful for processing API responses, configuration data, and structured log entries. The JSON parser handles nested objects, arrays, and various data types automatically.
-
-### What is the remapper transform and when is it used?
-
-The remapper transform moves or copies attributes to top-level fields or to tags in a JSON object. It's useful for standardizing log event structure by moving well-known fields like message, severity, and host from nested attributes to top-level fields. You can configure whether the source attribute is preserved or removed after remapping. The remapper also supports rename rules for moving attribute values from one path to another. The remapper is automatically added to pipelines in the UI with customizable default attributes.
-
-### When should I use the SQL transform?
-
-Use the SQL transform when you need complex filtering, transformation, or enrichment of log records. SQL provides a familiar interface for advanced operations like conditional logic, string manipulation, aggregations, and joining data. It's available in the UI for filters and via REST API for more flexibility.
-
-### Can I combine multiple transforms in a pipeline?
-
-Yes, transforms are configured as sequential pipeline steps. Each transform receives input from the previous step, applies its logic, and passes the result to the next step. This allows you to create complex data processing workflows by combining parsing (Grok), restructuring (remapper), and filtering/enrichment (SQL) transforms.
-
-### What is the Filter transform used for?
-
-The Filter transform includes or excludes data records based on specified conditions. You can use filters with SQL, Datadog, and New Relic-like query syntaxes. In the UI, filters are located in predefined pipeline positions, while the REST API provides more flexibility for filter placement.
-
-### Can I use the REST API for more advanced transform options?
-
-Yes, the REST API provides access to advanced transform options not available in the UI. For example, you can use LogTransformAction to add or remove attributes and tags, LogsBranch for complex message routing based on query matches, and more flexible filter placement. See the API specification for complete details on transform capabilities.
-
-### How do I choose between Grok and SQL transforms?
-
-Use Grok when you need pattern-based parsing of unstructured text to extract specific fields. Use SQL when you need complex conditional logic, calculations, string transformations, or filtering. Grok is specialized for text parsing, while SQL is more general-purpose for data manipulation and enrichment.
-
-### How does Grepr reduce log volumes and observability costs?
-
-Grepr uses clustering algorithms to identify patterns in log data and aggregates similar log messages. Instead of sending multiple redundant log events, Grepr sends summaries and samples of similar messages to your observability platform. This significantly reduces the volume of shipped logs while retaining the ability to analyze and troubleshoot issues. Raw logs are retained in a low-cost data lake for future reference.
-
-### What happens if a transform fails on a record?
-
-Transform behavior depends on the specific transform type and configuration. Parsing errors (like Grok or JSON parsing) typically skip records or add error attributes depending on your configuration. SQL transforms filter out records that don't match conditions. Review transform-specific documentation for error handling details.

package/build/dist/docs-index/3e919530-12b0-4e4f-a02a-811ba33b9c03.txt

@@ -1,43 +0,0 @@
-# Submit a webhook event
-
-**POST** `/v1/integrations/webhooks/{id}/events`
-
-**Operation ID**: `postEvent`
-**Summary**: Submit a webhook event
-Accepts one JSON event from the sending system and starts an investigation on each target agent of the integration. The org is taken from the Grepr API key and the integration id from the path. Returns 202 with the started investigation ids. Retries after a 5xx may start duplicate investigations.
-
-## Tags
-- Webhook Events
-## Parameters
-
-- **id** (required) - path
-  - The webhook integration id.
-  - Type: string
-
-## Request Body
-
-**Content-Type**: `application/json`
-
-**Schema**: string
-
-## Responses
-
-### 202
-
-Investigation(s) started
-
-### 400
-
-Body is not valid JSON
-
-### 401
-
-API key is invalid
-
-### 404
-
-No such webhook integration
-
-### 413
-
-Body exceeds the size limit

package/build/dist/docs-index/3fb9a8c6-6a48-4531-bb3b-e606ea5cb956.txt

@@ -1,33 +0,0 @@
-# Get integration exception impacts for a pipeline
-
-**GET** `/v1/pipelines/{pipelineId}/exceptions/integrations/{integrationId}/impacts`
-
-**Operation ID**: `getIntegrationExceptionImpacts`
-**Summary**: Get integration exception impacts for a pipeline
-Returns the per-exception impact percentages the runtime auto-sync threshold filter would compare against for this pipeline/integration pair. The pipeline's sink dataset scopes the lookup; exceptions without an estimation row are absent from the response.
-
-## Tags
-- Pipeline Exceptions
-## Parameters
-
-- **pipelineId** (required) - path
-  - Pipeline ID providing the dataset scope
-  - Type: string
-- **integrationId** (required) - path
-  - Integration whose exceptions to look up impacts for
-  - Type: string
-
-## Responses
-
-### 200
-
-Impact percentages retrieved
-
-- **Content-Type**: `application/json` / object
-### 401
-
-Unauthorized
-
-### 404
-
-Not Found - Pipeline not found.

package/build/dist/docs-index/519c1c49-9942-48c2-96b9-db0830821559.txt

@@ -1,143 +0,0 @@
-A reference for the permission types in the Grepr platform, and which permissions are assigned to different roles.
-
-# Permissions in the Grepr platform
-
-This page is a reference to the permissions available in the Grepr platform. These permissions are assigned to users based on the user's role:
-
-* Organization-level roles: Admin, Member, and Reader
-* Team-level roles: Leader and Member
-
-A user can be assigned both an organization-level role and a team-level role. For example, an organization Member can also be a team Leader, giving them view access organization-wide and edit access to their team's resources.
-
-You can also create custom roles with a specific subset of Grepr platform permissions. To learn more about roles, including custom roles, see [Manage users in the Grepr platform](/admin/manage-users).
-
-At both the organization and team levels, there are three types of permissions:
-
-* View: Grants read-only access to specified resources.
-* Edit: Grants edit permissions over specified resources, including creating, editing, and deleting those resources.
-* Write: Grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill job that writes data to a vendor integration. Edit permission on an integration controls the integration's configuration. Write permission on an integration controls whether you can send data through it.
-
-Resources in the Grepr platform include your organization, vendor, and storage integrations, datasets, templates, users, teams, and jobs.
-
-The following sections provide more details on permissions in the Grepr platform and the permissions for each role type.
-
-## Available permissions in the Grepr platform
-
-This table lists all available permissions for organization and team-level roles:
-
-| Permission | Resource | Scope |
-| --- | --- | --- |
-| Edit | Organization settings | Organization |
-| View | Organization settings | Organization or Team |
-| Edit | Integrations | Organization or Team |
-| View | Integrations | Organization or Team |
-| Write | Integrations | Organization or Team |
-| Edit | Jobs | Organization or Team |
-| View | Jobs | Organization or Team |
-| Edit | Users | Organization |
-| View | Users | Organization or Team |
-| Edit | Teams | Organization or Team |
-| View | Teams | Organization or Team |
-| Edit | Templates | Organization or Team |
-| View | Templates | Organization or Team |
-| Edit | Datasets | Organization or Team |
-| View | Datasets | Organization or Team |
-
-## Permissions by role
-
-The following are the permissions granted to each role type in the Grepr platform:
-
-* Organization Admins have full control over all resources in the organization, including all team-scoped resources, and can write to any vendor integration.
-* Organization Members have view-only permissions to all resources in the organization, and have write permission on all vendor integrations so they can run backfill jobs.
-* Organization Readers have view-only permissions to all resources in the organization. Readers can query logs, but cannot create or edit any resources and cannot run backfill jobs that send data to a vendor integration.
-* Team Leaders have edit permissions for all resources scoped to their specific team or teams. This includes permissions to create and edit jobs, integrations, templates, and datasets assigned to the team, and to write to integrations assigned to the team. Team Leaders can also view all organization resources but only edit resources scoped to their team or teams.
-* Team Members have view-only permissions to resources scoped to their specific team or teams, plus write permission on integrations assigned to the team so they can run backfill jobs. A team Member can view resources assigned to the team and query logs, but does not have permission to create or edit resources, such as jobs, integrations, templates, or datasets, assigned to the team.
-* Teams can be granted access to resources, such as integrations, datasets, or templates, scoped at the organization level. When a team is granted access to a resource, team Leaders have edit permissions on the resource, and team Members have view-only permissions. However, to create or edit a job, such as a pipeline, a team Leader must have view permissions on all the integrations and datasets used by the job, and write permission on every vendor integration the job uses as a sink. For example, if a job is assigned to the `DevOps` team, but the team hasn't been granted access to an integration used in the job, a `DevOps` team Leader cannot edit or run the job.
-* To create a dataset, you must have edit permission on the integration the dataset belongs to.
-
-For each resource in the Grepr platform, this table shows the specific permissions granted to each role type at both the organization and team levels:
-
-| Permission | Resource | Access Scope | Organization Admin | Organization Member | Organization Reader | Team Leader | Team Member |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| View | Organization Settings | Organization | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Organization Settings | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Users | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Users | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Teams | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Teams | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Integrations | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Integrations | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| Write | Integrations | Organization | ✅ | ✅ | ❌ | ❌ | ❌ |
-| View | Datasets | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Datasets | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Jobs | Organization | ✅ | ✅ | ✅ | ❌ | ❌ |
-| Edit | Jobs | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Templates | Organization | ✅ | ✅ | ✅ | ✅ | ❌ |
-| Edit | Templates | Organization | ✅ | ❌ | ❌ | ❌ | ❌ |
-| View | Teams | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Teams | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Integrations | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Integrations | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| Write | Integrations | Team | ✅ | ✅ | ❌ | ✅ | ✅ |
-| View | Datasets | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Datasets | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Jobs | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Jobs | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-| View | Templates | Team | ✅ | ✅ | ✅ | ✅ | ✅ |
-| Edit | Templates | Team | ✅ | ❌ | ❌ | ✅ | ❌ |
-
-## Organization roles vs. team roles
-
-This table describes the difference between organization-level and team-level roles. Users can have both types of roles:
-
-\| | Organization roles | Team roles | | :-------- | :----------------------------------------------------- | :------------------------------------------ | | Scope | Entire organization | A specific team | | Types | Admin, Member, Reader, or Custom Roles | Leader or Member | | Examples | - Admin: Full access to all resources and settings.\
-\- Member: View organization resources and run backfill jobs.\
-\- Reader: View organization resources and query logs only; no backfills to vendor integrations.\
-\- Custom role, such as "Developer": Specific permissions like "view all jobs, edit templates". | - Leader: Manage team members, create team-scoped integrations.\
-\- Member: View team resources and run backfill jobs to team integrations. |
-
-## Frequently Asked Questions
-
-### What are the main permission types in Grepr?
-
-The main permission types are View (grants read-only access to specified resources), Edit (grants permissions to create, edit, and delete specified resources), and Write (grants permission to send data through an integration when the integration is used as a sink in a job, such as a backfill). These permissions are assigned based on user roles at both organization and team levels.
-
-### What are organization-level roles?
-
-Organization-level roles control access across the entire organization. The standard roles are Admin (full control over all resources), Member (view access plus permission to run backfill jobs), and Reader (view-only access; no backfills to vendor integrations). You can also create custom roles with specific subsets of permissions tailored to your organization's needs.
-
-### What are team-level roles?
-
-Team-level roles control access to resources within a specific team. There are two team roles: Leader (edit permissions for team-scoped resources and view permissions for organization resources) and Member (view-only permissions for team resources). A user can be assigned to multiple teams with different roles.
-
-### Can a user have both organization and team roles?
-
-Yes, users can have both organization-level and team-level roles simultaneously. For example, a user can be an organization Member for organization-wide access while also being a Team Leader for a specific team, granting them edit access to that team's resources.
-
-### What resources can be controlled with Grepr permissions?
-
-Grepr permissions can control access to: organization settings, integrations (observability and storage), jobs, users, teams, templates, and datasets. Each resource can have view or edit permissions assigned at organization or team scope.
-
-### What permissions does an Organization Admin have?
-
-Organization Admins have full control over all resources in the organization, including all team-scoped resources. They can create, edit, and delete any resource, manage users, configure organization settings, and manage all integrations and datasets.
-
-### What permissions does an Organization Member have?
-
-Organization Members have view permissions to all resources in the organization, plus write permission on integrations so they can run backfill jobs. They can view integrations, datasets, jobs, users, and teams and write data through any vendor integration, but cannot create, edit, or delete any resources at the organization level.
-
-### What permissions does an Organization Reader have?
-
-Organization Readers have view-only permissions to all resources in the organization and can query logs. Readers cannot create, edit, or delete any resources, and cannot run backfill jobs that send data to a vendor integration. Use the Reader role for users who need to investigate data without incurring vendor write costs.
-
-### What permissions does a Team Leader have?
-
-Team Leaders have edit permissions for all resources scoped to their specific team(s), including creating and editing jobs, integrations, templates, and datasets. They can also view all organization resources but can only edit resources scoped to their team. Team Leaders can also manage team members.
-
-### What permissions does a Team Member have?
-
-Team Members have view permissions to resources scoped to their team, plus write permission on integrations assigned to the team so they can run backfill jobs. They can view jobs, integrations, templates, and datasets assigned to the team, query logs, and run backfills to team integrations, but cannot create or edit any resources.
-
-### What is a custom role in Grepr?
-
-Custom roles allow you to create roles with a specific subset of Grepr platform permissions tailored to your organization's needs. Instead of using standard roles, you can create custom roles like 'Developer' with permissions such as 'view all jobs' and 'edit templates' to match your team's responsibilities and access requirements.

package/build/dist/docs-index/543bd3c3-253e-4b2e-871a-8d2604a00c01.txt

@@ -1,18 +0,0 @@
-# Get a skill
-
-**GET** `/v1/skills/{id}`
-
-**Operation ID**: `get_3`
-**Summary**: Get a skill
-## Parameters
-
-- **id** (required) - path
-  - Type: string
-
-## Responses
-
-### 200
-
-Skill retrieved successfully
-
-- **Content-Type**: `application/json` / `SkillView`

package/build/dist/docs-index/630d28fd-2ddd-496d-a9ec-4618ff645cf2.txt

@@ -1,47 +0,0 @@
-# Datadog
-
-The payload containing integration data.
-
-**Type**: `object`
-
-## Properties
-
-- name: additionalTags (required)
-  type: array of string
-  description: Tags to add when writing data to Datadog
-
-- name: apiKey (optional)
-  type: string
-  description: Masked API key for Datadog
-
-- name: apiKeys (optional)
-  type: array of `IngestKeyView`
-  description: The API keys configured for this integration (masked).
-
-- name: appKey (optional)
-  type: string
-  description: Masked App key for Datadog
-
-- name: clientToken (optional)
-  type: string
-  description: Client token for Datadog
-
-- name: exceptions (optional)
-  type: object
-  description: The imported exceptions from Datadog. This is a map from the vendor resource Id to the exception.
-
-- name: filterQuery (required)
-  type: string
-  description: Filter to apply when reading any data from the Datadog API
-
-- name: sendKeyId (optional)
-  type: string
-  description: Identifier of the API key used to send data back to Datadog. Defaults to the only key when unset.
-
-- name: site (required)
-  type: string
-  description: Datadog site URL
-
-- name: validateKeysOnSave (optional)
-  type: boolean
-  description: Indicates whether to validate the API and App keys when saving the keys.

package/build/dist/docs-index/63cfa89e-b597-4cf5-82ef-492b618f9b61.txt

@@ -1,16 +0,0 @@
-# JobID
-
-The Flink job ID for the query job.
-
-**Type**: `object`
-
-## Properties
-
-- name: bytes (optional)
-  type: string
-
-- name: lowerPart (optional)
-  type: integer
-
-- name: upperPart (optional)
-  type: integer