@grepr/cli 1.2.0 → 1.3.0-94fe60c

package/build/dist/docs-index/dcd11a4b-c142-4192-aedb-430fc359d5aa.txt

@@ -1,14 +0,0 @@
-# DatabaseUserInfo
-
-**Type**: `object`
-
-## Properties
-
-- name: email (required)
-  type: string
-
-- name: firstName (required)
-  type: string
-
-- name: lastName (required)
-  type: string

package/build/dist/docs-index/de94354d-e6a6-4172-8f13-891e7f9a366c.json

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

package/build/dist/docs-index/de94354d-e6a6-4172-8f13-891e7f9a366c.txt

@@ -1,20 +0,0 @@
-# LogsValuesSource
-
-**Type**: `object`
-
-## Properties
-
-- name: name (required)
-  type: string
-
-- name: loop (optional)
-  type: boolean
-  description: If true, the source will loop over the values indefinitely when processing is STREAMING. In BATCH mode, this flag is ignored.
-
-- name: values (optional)
-  type: array of `LogEvent`
-  description: List of log events to be generated by the source.
-
-- name: type (required)
-  type: enum: `logs-values-source`
-  description: Generates log events with constant values.

package/build/dist/docs-index/decc59f9-e281-4704-bb3f-4aaf2537dc1c.json

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

package/build/dist/docs-index/decc59f9-e281-4704-bb3f-4aaf2537dc1c.txt

@@ -1,113 +0,0 @@
----
-description: Learn how to use filters in a Grepr pipeline to include or exclude events, configure multiple processing paths, or transform events based on specific conditions.
----
-
-import { Callout } from 'nextra/components'
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Filter events in a Grepr pipeline
-
-You can use filter transforms in a Grepr pipeline to include or exclude log events based on specific conditions. Filters are configured using familiar query interfaces, such as SQL or Datadog, SPL, and New Relic-like query syntaxes.
-
-The filtering configuration options allow you to create simple to complex event routing scenarios, including selective application of transformations to a subset of events or routing different types of events to appropriate processing stages using flexible configuration options.
-
-## Filtering options
-
-The following is a summary of the options available when configuring filters in a Grepr pipeline:
-
-- Drop late-arriving events.
-- Pass all or only some events to the next step.
-- Process all or only some events using SQL before passing to a configurable pipeline step.
-- Pass all records to the next pipeline step and also through the SQL processing path.
-
-### Drop late-arriving data
-
-You can configure a maximum threshold for the difference between the event and received timestamps. The threshold is configured using a duration in the ISO-8601 format. Events that exceed this threshold are dropped from the pipeline. This is useful for scenarios where timely data is critical, and late-arriving events could affect analysis or reporting.
-
-### Pass events to the next pipeline step
-
-You can configure filters to pass events to the next step in the pipeline. You can pass all events through to the next pipeline step, use a filter query to pass only events that meet specific conditions, or disable the passthrough of events with the option of passing the events for SQL processing.
-
-Filter queries use familiar query syntax similar to that of popular observability platforms, such as Datadog, Splunk, and New Relic. To learn more about the supported query syntaxes, see [Query log data in Grepr](/queries).
-
-### Process events with SQL
-
-The SQL processing path allows you to define complex transformations using ANSI standard SQL queries. You define the SQL query to process events and the name of a view to contain the results of query processing. You can create multiple queries and views that process data sequentially, with each view able to reference input events through the `logs` input table or previously defined views. Based on the filter's location in the pipeline, the results of SQL processing can be routed to specific pipeline steps, such as the JSON or Grok parsers, the Data Lake, the Reducer, or directly to the pipeline Sinks.
-
-You can choose to process all events or only events that don't meet the criteria for passthrough to the next pipeline step. You can further select specific events for SQL processing using a filter query. This feature provides flexibility to apply SQL transformations only to relevant events.
-
-You can also choose to materialize the results of query processing for reuse in subsequent views, improving performance for complex transformation scenarios.
-
-<Callout>
-  When you transform events using SQL, the results of processing replace the original event. If you want to retain all fields from the original event, include the wildcard character (`*`) in your `SELECT` statement. For example, to transform the severity while keeping all other fields: `SELECT *, CASE WHEN severity > 16 THEN 21 ELSE severity END as severity FROM logs`.
-</Callout>
-
-To learn more about using SQL in Grepr pipelines, see [Transform events with SQL](/transforms/sql-transform).
-
-## Configure filters in the Grepr pipelines UI
-
-In the Grepr pipelines UI, filters are available in predefined locations in a pipeline. To add one of these filters to your pipeline:
-
-1. In the Grepr pipelines UI, in the left-hand navigation menu, select the **Pre-parsing**, **Post-parsing**, or **Post-warehouse** filter to open the filter detail pane.
-1. In the filter detail pane, click the pencil icon to display the filter configuration form.
-
-   ![The pre-parsing filter configuration form with the default settings.](/images/pipelines/filter-edit-config.png)
-
-1. Configure the filtering and routing of events:
-   - In the **Max Lateness** field, optionally enter a duration in ISO-8601 format to drop late-arriving data.
-   - In the **Next Step Passthrough** section, to pass events to the next pipeline step, ensure that **Enable data passthrough to next step** is selected. To optionally select events for passthrough based on specific criteria, enter a query in the **Filter Query** field.
-   - To process events using SQL, select **Enable SQL processing** and select whether to process all events or only events that are not passed to the next step. Optionally enter a query in the **Filter Query** field to conditionally select events for SQL processing. This screenshot shows a filter configuration that passes events associated with `host-1` and `host-4` to the next pipeline step. All other events are processed using SQL.
-
-    ![The filter configuration form with settings to pass specific events to the next pipeline step, and process all other events using SQL.](/images/pipelines/filter-edit-config-passthrough.png)
-
-1. Configure how to process events with SQL:
-   - To optionally apply SQL processing to events that meet specific criteria, enter a query in the **SQL Filter Query** field.
-   - In the **SQL Views** section, click the plus sign to add one or more **SQL Input** definitions. In the **View name** field, enter a name for the view to contain the results of processing, and in the **SQL** field, enter the SQL query to process input events.
-   - Optionally select **Reuse calculation** to materialize the results of query processing for reuse in subsequent views.
-   - In the **Outputs** section, configure one or more pipeline steps to receive the results of SQL processing. This screenshot shows a configuration that selects events where the message includes `No data received` and saves them to a view named `no_data_messages`. The view is then routed to the pipeline sinks, which forward it to your observability platform or other destinations.
-
-    ![The filter configuration form with a SQL view that selects log events based on message content.](/images/pipelines/filter-edit-config-sqltransform.png)
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is event filtering and why would I use it?",
-    a: "Event filtering allows you to include or exclude log events from pipeline processing based on specific conditions. Use filtering to remove unwanted events, focus processing on relevant data, reduce volume, prevent sensitive data from flowing through the pipeline, or route different event types to different processing stages."
-  },
-  {
-    q: "Where are filters located in a Grepr pipeline?",
-    a: "Filters are available in predefined locations throughout a pipeline: Pre-parsing filter (before initial processing), Post-parsing filter (after Grok parsing), and Post-warehouse filter (after data lake storage). Each location allows you to filter at different stages of log processing."
-  },
-  {
-    q: "What filtering options are available in Grepr?",
-    a: "Grepr provides options to drop late-arriving events, pass all or some events to the next pipeline step using query filters, process events with SQL before passing to a pipeline step, or pass all records to the next step while also routing some through SQL processing for enrichment."
-  },
-  {
-    q: "How do I filter out late-arriving events?",
-    a: "In the filter configuration, enter a Max Lateness value in ISO-8601 duration format. Events that arrive later than this duration after their timestamp are dropped from the pipeline. This is useful when timely data is critical and late data could affect analysis."
-  },
-  {
-    q: "What query languages does Grepr support for filtering?",
-    a: "Grepr supports multiple query syntaxes including Datadog query language, Splunk Processing Language (SPL), New Relic-like syntax, and standard SQL. Choose the query language that matches your observability platform or preference."
-  },
-  {
-    q: "How do I create a simple filter to exclude events?",
-    a: "In the Pre-parsing, Post-parsing, or Post-warehouse filter, ensure 'Enable data passthrough to next step' is selected. Enter a filter query that matches events you want to keep. Events matching the query pass to the next step, while others are excluded or processed separately."
-  },
-  {
-    q: "Can I route different event types to different pipeline paths?",
-    a: "Yes. Use multiple SQL views in the filter's SQL processing path to route different events to different destinations. Each view can contain a different SQL query that processes a specific event type and routes it to appropriate pipeline steps."
-  },
-  {
-    q: "What is the difference between passthrough and SQL processing?",
-    a: "Passthrough sends events directly to the next pipeline step based on a filter query. SQL processing allows you to transform events using SQL statements before routing them to different pipeline steps. You can enable both to handle events in different ways simultaneously."
-  },
-  {
-    q: "How do I use SQL to transform events in a filter?",
-    a: "Enable SQL processing in the filter configuration, then create SQL views with names and SQL queries. Each view can process events and the results can be routed to pipeline steps like the Data Lake, Reducer, or Sinks. Reference input events using the 'logs' input table."
-  },
-  {
-    q: "What does the shouldMaterialize option do in filters?",
-    a: "When enabled, shouldMaterialize caches the results of a SQL view so subsequent SQL views can reuse the cached results instead of re-running the query. This improves performance when multiple views need the results of the same transformation."
-  }
-]} />
-

package/build/dist/docs-index/df1fe6b2-0a41-4a75-98de-91a3793d88db.json

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

package/build/dist/docs-index/df1fe6b2-0a41-4a75-98de-91a3793d88db.txt

@@ -1,20 +0,0 @@
-# List all OTLP integrations
-
-**GET** `/v1/integrations/otlp`
-
-**Operation ID**: `list_4`
-**Summary**: List all OTLP integrations
-Get all OTLP integrations.
-
-## Tags
-- OpenTelemetry Integration
-## Responses
-
-### 200
-
-Integrations retrieved successfully
-
-- **Content-Type**: `application/json` / `ItemsCollectionReadOtlp`
-### 401
-
-Unauthorized

package/build/dist/docs-index/df8f3e33-fc59-4774-b6bd-d412050a2ed6.json

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

package/build/dist/docs-index/df8f3e33-fc59-4774-b6bd-d412050a2ed6.txt

@@ -1,498 +0,0 @@
----
-description: Search logs using Datadog syntax with support for message searches, tag filtering, attribute queries, and boolean operators.
----
-
-import { HiddenFAQ } from '@/components/HiddenFAQ'
-
-# Search logs using a Datadog-like syntax
-
-The Grepr platform supports searching logs using a syntax similar to Datadog's log query syntax. This support allows you to filter and search log data using familiar Datadog queries and eases migration from or integration with existing Datadog-based workflows.
-
-For the complete reference to Datadog query syntax, see [Query Syntax](https://docs.datadoghq.com/tracing/trace_explorer/query_syntax).
-
-By default, queries search the message field of log entries, but you can also query specific tags and attributes.
-
-## Basic query structure
-
-```sql
--- Simple text search (searches message field by default)
-error
-
--- Explicit message field search
-message:error
-
--- Tag search
-service:web-app
-
--- Attribute search
-@user.id:12345
-```
-
-## Case sensitivity rules
-
-- **Message searches** are case-insensitive.
-- **Tag searches** are case-sensitive.
-- **Attribute searches** are case-sensitive.
-
-## Search message fields
-
-Message field queries perform full-text searches across the `message` field of log entries. These searches are case-insensitive and use word boundary matching.
-
-### Perform full-text searches
-
-```sql
--- Search for "error" in message field (case-insensitive)
-error
-
--- Explicit message field syntax
-message:error
-
--- Both queries above are equivalent
-```
-
-### Search for phrases
-
-Use double quotes to search for exact phrases:
-
-```sql
--- Search for exact phrase
-message:"connection timeout"
-
--- Without quotes, this would search for logs containing both "connection" AND "timeout"
-message:connection timeout
-```
-
-### Examples
-
-```sql
--- Find all error messages
-error
-
--- Find specific error types
-message:"database connection failed"
-
--- Find logs mentioning specific components
-message:authentication
-
--- Case-insensitive matching
-message:ERROR  -- matches "error", "Error", "ERROR", etc.
-```
-
-## Wildcard queries
-
-Wildcard queries allow flexible pattern matching using `*` (zero or more characters) and `?` (single character).
-
-### Asterisk wildcard (`*`)
-
-```sql copy
--- Contains pattern - matches any characters before/after
-*timeout*
-
--- Prefix pattern - matches anything starting with "auth"
-auth*
-
--- Suffix pattern - matches anything ending with "error"
-*error
-```
-
-### Question mark wildcard (`?`)
-
-```sql copy
--- Single character wildcard
-f?o  -- matches "foo", "fao", "f1o", etc.
-
--- Multiple single character wildcards
-te?t  -- matches "test", "text", "tent", etc.
-```
-
-### Complex patterns
-
-```sql copy
--- Mixed wildcards
-*f?OO?  -- matches "afOOd", "1fOOx", etc.
-
--- Multiple asterisks
-*auth*service*  -- matches logs containing "auth" followed by "service"
-```
-
-### Escape wildcards
-
-You generally cannot search for special characters in the message field. If you need to search for a literal `*` or `?`, you'll need to extract the value into an attribute and then search in that attribute.
-
-## Tag queries
-
-Tags in Grepr are key-value pairs that provide structured metadata about log entries. Tag searches are case-sensitive.
-
-### Search tag values
-
-```sql
--- Search for specific tag value
-service:web-app
-
--- Search for tag with dotted notation
-service.version:1.2.3
-
--- Search for tag values with spaces (use quotes)
-environment:"staging environment"
-```
-
-### Check tag key existence
-
-Check if a tag key exists regardless of its value:
-
-```sql
--- Check if 'service' tag exists
-tags:service
-
--- Check if nested tag key exists
-tags:service.version
-```
-
-### Use wildcards with tag values
-
-```sql
--- Tag values starting with "web"
-service:web-*
-
--- Tag values ending with "app"
-service:*-app
-
--- Tag values containing "prod"
-environment:*prod*
-```
-
-### Use wildcards with tag keys
-
-```sql
--- Tag keys starting with "serv"
-tags:serv*
-
--- Tag keys ending with "id"
-tags:*id
-```
-
-### Examples
-
-```sql
--- Find logs from specific service
-service:user-authentication
-
--- Find logs from production environment
-environment:production
-
--- Find logs from any web service
-service:web-*
-
--- Find logs that have a user ID tag
-tags:user.id
-
--- Find logs from services in staging
-environment:staging AND service:*
-```
-
-## Attribute queries
-
-Attributes are structured data fields extracted from log messages. Attribute searches are case-sensitive and use the `@` prefix.
-
-### Basic attribute search
-
-```sql
--- Search for specific attribute value
-@user.id:12345
-
--- Search for nested attributes
-@request.method:GET
-
--- Search for attributes with special characters
-@error.code:"AUTH_001"
-```
-
-### Search phrase attributes
-
-```sql
--- Search for exact phrase in attribute
-@error.message:"database connection failed"
-
--- Search for attribute containing spaces
-@user.name:"John Smith"
-```
-
-### Use wildcards with attributes
-
-```sql
--- Attribute values starting with pattern
-@request.path:/api/*
-
--- Attribute values ending with pattern
-@file.name:*.log
-
--- Attribute values containing pattern
-@error.message:*timeout*
-```
-
-### Query nested attributes
-
-Attributes can contain complex nested structures:
-
-```sql
--- Search in arrays
-@tags.environment:production
-
--- Search in nested objects
-@metadata.request.user_id:12345
-
--- Search for string values
-@response.body:"success"
-```
-
-### Examples
-
-```sql
--- Find logs from specific user
-@user.id:user123
-
--- Find HTTP errors
-@response.status_code:500
-
--- Find slow requests
-@request.duration:*slow*
-
--- Find logs with specific error codes
-@error.code:AUTH_*
-
--- Find logs from specific IP addresses
-@client.ip:192.168.*
-```
-
-## Boolean operators
-
-Combine multiple query conditions using boolean operators.
-
-### AND operator
-
-```sql
--- Explicit AND
-service:web-app AND @user.id:12345
-
--- Implicit AND (space-separated terms)
-service:web-app @user.id:12345
-
--- Multiple conditions
-error AND service:auth AND @response.status:500
-```
-
-### OR operator
-
-```sql
--- Search for either condition
-service:web-app OR service:api-gateway
-
--- Multiple OR conditions
-@response.status:500 OR @response.status:502 OR @response.status:503
-
--- Combine with other operators
-(service:web OR service:api) AND error
-```
-
-### NOT operator
-
-```sql
--- Exclude with minus sign
-service:web-app -@user.id:12345
-```
-
-### Group conditions with parentheses
-
-```sql
--- Group OR conditions
-(service:web-app OR service:api) AND error
-
--- Complex grouping
-(error OR warning) AND (service:auth OR service:payment)
-
--- Nested grouping
-((service:web OR service:api) AND error) OR @priority:high
-```
-
-### Must and must not operators
-
-```sql
--- Must have (equivalent to AND)
-+service:web-app +@user.id:12345
-
--- Must not have (equivalent to NOT)
-+service:web-app -@user.id:12345
-
--- Complex requirements
-+error +service:auth -@user.type:admin
-```
-
-### Range queries
-```sql
--- Inclusive range
-@response.time:[100 TO 500]
-
--- Exclusive range
-@response.time:{100 TO 500}
-
--- Open-ended range
-@response.time:[* TO 300]
-@response.time:[200 TO *]
-
--- On tags, range queries are lexicographical
-hostname:[jimmy TO tom]
-```
-
-### Comparison operators
-
-```sql
--- Greater than
-@response.time:>300
--- Less than
-@response.time:<100
--- Greater than or equal to
-@response.time:>=200
--- Less than or equal to
-@response.time:<=400
-
--- On tags, comparisons are lexicographical
-hostname:>=jimmy
-hostname:<tom
-```
-
-## Special characters and escaping
-
-### Use quotes
-
-```sql copy
--- Attributes with special characters
-@error.message:"Invalid input: user@domain.com"
-
--- Tags with special characters
-component:"web-app@v1.2.3"
-```
-
-## Optimize query performance
-
-- **Minimize time range** to the smallest time window necessary for the query to optimize the amount of data scanned.
-- **Always specify the `service` tag** when applicable to reduce the search space and use the `host` tag where possible. This significantly improves performance and reduces query costs.
-- **Use specific tags and attributes** instead of broad message searches when possible.
-- **Combine multiple conditions** to narrow results effectively.
-- **Use wildcards judiciously** - they can be slower than exact matches.
-- **Use phrase searches** for multi-word terms to avoid unnecessary matches. Otherwise a query like `failed login` will match any log containing both "failed" and "login" anywhere in the message, which may produce many irrelevant results and is twice as expensive as `"failed login"`.
-
-## Limitations
-
-While Grepr supports most common Datadog query patterns, some advanced features are not available:
-
-### Fuzzy Search
-
-```sql
--- NOT SUPPORTED: Fuzzy matching
-foobar~2
-
--- ALTERNATIVE: Use wildcards
-*foobar* OR *fobar*
-```
-
-### Regular expressions
-```sql
--- NOT SUPPORTED: Regex patterns
-/foo|bar/
-
--- ALTERNATIVE: Use boolean operators
-foo OR bar
-```
-
-### Proximity searches
-```sql
--- NOT SUPPORTED: Word proximity
-"foo bar"~2
-
--- ALTERNATIVE: Use phrase search
-"foo bar"
-```
-
-### Alternative approaches
-
-For unsupported patterns, consider these alternatives:
-
-- **Instead of fuzzy search**: Use wildcards with common variations.
-- **Instead of regex**: Use boolean operators with multiple terms.
-- **Instead of proximity**: Use phrase searches or multiple terms.
-
-## Debug query results
-
-1. **Start simple**: Begin with basic queries and add complexity.
-2. **Check field names**: Verify tag and attribute names exist.
-3. **Test case sensitivity**: Remember tags and attributes are case-sensitive.
-4. **Use parentheses**: Group conditions clearly.
-
-## Reference
-
-### Syntax cheat sheet
-
-| Query Type | Syntax | Example |
-|------------|--------|---------|
-| Message search | `text` or `message:text` | `error` |
-| Phrase search | `"exact phrase"` | `"connection timeout"` |
-| Tag search | `tag:value` | `service:web-app` |
-| Tag existence | `tags:key` | `tags:service` |
-| Attribute search | `@attr:value` | `@user.id:123` |
-| Wildcard | `*` or `?` | `service:web-*` |
-| AND | `AND` or space | `error AND service:auth` |
-| OR | `OR` | `error OR warning` |
-| NOT | `NOT`, `-`, or `!` | `NOT @user.type:admin` |
-| Grouping | `(condition)` | `(error OR warning)` |
-
-### Operator precedence
-
-1. **Parentheses**: `()`.
-2. **NOT operators**: `NOT`, `-`, `!`.
-3. **AND operators**: `AND`, implicit space.
-4. **OR operators**: `OR`.
-
-Use parentheses to explicitly control precedence in complex queries.
-
-<HiddenFAQ faqs={[
-  {
-    q: "What is the default search field in Datadog-like queries?",
-    a: "By default, queries search the message field of log entries. Simple text queries like 'error' search across the entire message field. You can explicitly specify the field using message:error or search other fields using tag:value or @attribute:value syntax."
-  },
-  {
-    q: "How do I search for exact phrases in messages?",
-    a: "Use double quotes around your phrase to search for exact matches. For example, \"connection timeout\" searches for logs containing that exact phrase. Without quotes, the query would search for logs containing both 'connection' AND 'timeout' separately, which may return unrelated results."
-  },
-  {
-    q: "Are message searches case-sensitive?",
-    a: "No, message searches are case-insensitive. A query like message:ERROR will match 'error', 'Error', 'ERROR', and all other case variations. However, tag and attribute searches are case-sensitive, so service:web-app will not match service:Web-App."
-  },
-  {
-    q: "What wildcards are supported in Datadog-like queries?",
-    a: "Grepr supports two wildcard types: asterisk (*) matches zero or more characters, and question mark (?) matches a single character. For example, service:web-* matches any service starting with 'web', and f?o matches 'foo', 'fao', etc. Wildcards work with tags, attributes, and message searches."
-  },
-  {
-    q: "How do I check if a tag exists without matching a specific value?",
-    a: "Use the tags: syntax to check for key existence. For example, tags:service checks if a 'service' tag exists regardless of its value. You can also use tags:service.version to check for nested tag keys."
-  },
-  {
-    q: "What are attributes and how are they different from tags?",
-    a: "Attributes are structured data fields extracted from log messages and are searched using the @ prefix (e.g., @user.id:12345). Tags are key-value metadata pairs searched without the @ prefix (e.g., service:web-app). Attributes and tags support different query patterns and have different case sensitivity rules."
-  },
-  {
-    q: "Can I use range queries with attributes?",
-    a: "Yes, Datadog-like syntax supports range queries on attributes using [value1 TO value2] syntax. Use square brackets for inclusive ranges ([100 TO 500]) and curly braces for exclusive ranges ({100 TO 500}). You can also use [* TO 300] for open-ended ranges."
-  },
-  {
-    q: "What boolean operators are available?",
-    a: "You can use AND (explicit or implicit with space), OR, and NOT (using -, !, or NOT keyword) to combine conditions. AND has higher precedence than OR. Use parentheses to group conditions and control precedence explicitly. For example, (error OR warning) AND service:auth requires either error or warning AND the service tag must be 'auth'."
-  },
-  {
-    q: "How do I exclude logs from my search?",
-    a: "Use the NOT operator with the minus sign (-) prefix, exclamation mark (!), or the NOT keyword. For example, service:web-app -@user.id:12345 returns logs from web-app service that don't have user.id of 12345. You can also use !(service:api) to exclude an entire condition."
-  },
-  {
-    q: "Which Datadog query features are not supported in Grepr?",
-    a: "Grepr does not support fuzzy search (foobar~2), regular expressions (/foo|bar/), or proximity searches (\"foo bar\"~2). For these patterns, use alternative approaches like wildcards instead of fuzzy search, boolean operators instead of regex, and phrase searches instead of proximity."
-  }
-]} />

package/build/dist/docs-index/dfa93b96-65e8-4cc2-af5a-f1586cca9623.json

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

package/build/dist/docs-index/dfa93b96-65e8-4cc2-af5a-f1586cca9623.txt

@@ -1,8 +0,0 @@
-# UserProvisionInfo
-
-**Type**: `object`
-
-## Properties
-
-- name: invitationTicketId (optional)
-  type: string