add-change-request-comment

Adds a new comment to the Change Request.

The identifier of the Change Request.

The comment body.

apply-change-request

Applies the Change Request. The proposed changes will be applied and published immediately.

The identifier of the Change Request.

approve-change-request

Adds your approval to the Change Request.

The identifier of the Change Request.

claim-change-request-ownership

Claims ownership of the Change Request.

The identifier of the Change Request.

close-change-request

Closes the Change Request without applying it.

The identifier of the Change Request.

create-change-request

Creates a new Change Request for the specified Config and Environment.

The identifier of the Config.

The identifier of the Environment.

The optional UTC date and time when the scheduled Change Request should be applied automatically.

When true, bypasses required approval checks for scheduled changes.

The list of models describing the proposed changes to the Settings included in the new Change Request.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The user attribute used for percentage evaluation. If not set, it defaults to the `Identifier` user object attribute.

The identifier of the feature flag or setting.

Prerequisite flag comparison operator used during the evaluation process.

The served Variation's identifier.

The prerequisite flag's identifier.

Describes a condition that is based on a prerequisite flag.

The segment comparison operator used during the evaluation process.

The segment's identifier.

Describes a condition that is based on a segment.

The comparison operator which defines the relation between the comparison attribute and the comparison value.

isOneOf isNotOneOf containsAnyOf doesNotContainAnyOf semVerIsOneOf semVerIsNotOneOf semVerLess semVerLessOrEquals semVerGreater semVerGreaterOrEquals numberEquals numberDoesNotEqual numberLess numberLessOrEquals numberGreater numberGreaterOrEquals sensitiveIsOneOf sensitiveIsNotOneOf dateTimeBefore dateTimeAfter sensitiveTextEquals sensitiveTextDoesNotEqual sensitiveTextStartsWithAnyOf sensitiveTextNotStartsWithAnyOf sensitiveTextEndsWithAnyOf sensitiveTextNotEndsWithAnyOf sensitiveArrayContainsAnyOf sensitiveArrayDoesNotContainAnyOf textEquals textDoesNotEqual textStartsWithAnyOf textNotStartsWithAnyOf textEndsWithAnyOf textNotEndsWithAnyOf arrayContainsAnyOf arrayDoesNotContainAnyOf

The User Object attribute that the condition is based on. Can be "User ID", "Email", "Country" or any custom attribute.

The value that the user object's attribute is compared to.

The number representation of the comparison value.

An optional hint for the comparison value.

The actual comparison value.

The list representation of the comparison value.

The string representation of the comparison value.

Describes a condition that is based on user attributes.

The list of conditions that are combined with logical AND operators.
It can be one of the following:
- User condition
- Segment condition
- Prerequisite flag condition

A number between 0 and 100 that represents a randomly allocated fraction of the users.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The percentage options from where the evaluation process will choose a value based on the flag's percentage evaluation attribute.

The served Variation's identifier.

The targeting rules of the Feature Flag or Setting.

The optional notes describing the purpose of the Change Request. This will appear in the Audit Log (in the Notes section when you expand the corresponding entry) upon applying the change request.

The title of the Change Request.

create-config

This endpoint creates a new Config in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

The description of the Config.

Determines the evaluation version of a Config.
Using `v2` enables the new features of Config V2 (https://configcat.com/docs/advanced/config-v2).

The name of the Config.

The order of the Config represented on the ConfigCat Dashboard.
Determined from an ascending sequence of integers.

create-environment

This endpoint creates a new Environment in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

The color of the Environment. RGB or HTML color codes are allowed.

The description of the Environment.

The name of the Environment.

The order of the Environment represented on the ConfigCat Dashboard.
Determined from an ascending sequence of integers.

create-integration

This endpoint creates a new Integration in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The Parameters dictionary differs for each IntegrationType:
- Datadog
  - `apikey`: Required. Datadog API key.
  - `site`: Datadog site. Available values: `Us`, `Eu`, `Us1Fed`, `Us3`, `Us5`. Default: `Us`.
- Slack
  Connecting the Slack integration through the Public Management API will not post messages with the ConfigCat Feature Flags Slack app but with an incoming webhook.
  - `incoming_webhook.url`: Required. The [incoming webhook URL](https://api.slack.com/messaging/webhooks) where the integration should post messages.
  - `includeSensitiveData`: Set to "true" to include [sensitive (hashed) comparison values](https://configcat.com/docs/targeting/targeting-rule/user-condition/#confidential-text-comparators). By default, the integration will mask these values in the posted messages. We recommend hiding sensitive comparison values for shared or public Slack channels.
- Amplitude
  - `apiKey`: Required. Amplitude API Key.
  - `secretKey`: Required. Amplitude Secret Key.
- Mixpanel
  - `serviceAccountUserName`: Required. Mixpanel Service Account Username.
  - `serviceAccountSecret`: Required. Mixpanel Service Account Secret.
  - `projectId`: Required. Mixpanel Project ID.
  - `server`: Mixpanel Server. Available values: `StandardServer`, `EUResidencyServer`. Default: `StandardServer`.
- Twilio Segment
  - `writeKey`: Required. Twilio Segment Write Key.
  - `server`: Twilio Segment Server. Available values: `Us`, `Eu`. Default: `Us`.
- PubNub (work in progress)

The identifier of the Product.

List of Config IDs that are connected with this Integration. If the list is empty, all the Configs are connected.

List of Environment IDs that are connected with this Integration. If the list is empty, all the Environments are connected.

The type of the Integration.

dataDog slack amplitude mixPanel segment pubNub

Name of the Integration.

Parameters of the Integration.

integrationType name parameters environmentIds configIds

create-permission-group

This endpoint creates a new Permission Group in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

Represent the Feature Management permission.

Represents the permission group level change request approval permission.

cannotApprove canApproveOthers canBypassApproval custom

Group members can create/update Configs.

Group members can create/update Environments.

Group members can create/update Segments.

Group members can create/update Feature Flags and Settings.

Group members can create/update Tags.

Group members can delete Configs.

Group members can delete Environments.

Group members can delete Segments.

Group members can delete Feature Flags and Settings.

Group members can delete Tags.

Group members can disable two-factor authentication for other members.

Group members can add and configure integrations.

Group members can manage team members.

Group members can update Product preferences.

Group members can create/update/delete Webhooks.

Group members can rotate SDK keys.

Group members can attach/detach Tags to Feature Flags and Settings.

Group members can use the export/import feature.

Group members has access to audit logs.

Group members has access to product statistics.

Group members has access to SDK keys.

Represent the environment specific Feature Management permission.

Identifier of the Environment.

List of environment specific permissions.

Represents the environment specific change request approval permission.

Identifier of the Environment.

List of environment specific change request approval permissions.

Name of the Permission Group.

create-product

This endpoint creates a new Product in a specified Organization
identified by the `organizationId` parameter, which can be obtained from the [List Organizations](#operation/list-organizations) endpoint.

The identifier of the Organization.

The description of the Product.

The name of the Product.

The order of the Product represented on the ConfigCat Dashboard. Determined from an ascending sequence of integers.

create-segment

This endpoint creates a new Segment in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

The comparison operator the evaluation process must use when it compares the given user attribute's value with the comparison value.

isOneOf isNotOneOf contains doesNotContain semVerIsOneOf semVerIsNotOneOf semVerLess semVerLessOrEquals semVerGreater semVerGreaterOrEquals numberEquals numberDoesNotEqual numberLess numberLessOrEquals numberGreater numberGreaterOrEquals sensitiveIsOneOf sensitiveIsNotOneOf

The user's attribute the evaluation process must take into account.

The value to compare with the given user attribute's value.

Description of the Segment.

Name of the Segment.

name comparisonAttribute comparator comparisonValue

create-setting

This endpoint creates a new Feature Flag or Setting in a specified Config
identified by the `configId` parameter.

**Important:** The `key` attribute must be unique within the given Config.

The identifier of the Config.

A short description for the setting, shown on the Dashboard UI.

The ID of the Environment where the initial value must be set.

The initial value in the given Environment. It must respect the setting type. In some generated clients for strictly typed languages, you may use double/float properties to handle integer values. In case of a Feature Flag with predefined variations, the value must match one of the predefined variations' value.

Optional, initial value of the Feature Flag or Setting in the given Environments. Only one of the SettingIdToInitFrom or the InitialValues properties can be set.

Indicates whether this setting should validate string values as JSON values.

The key of the Feature Flag or Setting.

The name of the Feature Flag or Setting.

The order of the Setting represented on the ConfigCat Dashboard.
Determined from an ascending sequence of integers.

A Predefined Variation.

The name of the Predefined Variation, shown on the Dashboard UI. If not set, the Value will be shown.

Represents the value of a Predefined Variation.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served value in case of a text Setting.

The Feature Flag or Setting's Variations.

Optional, the SettingId to initialize the values and tags of the Feature Flag or Setting from. Only can be set if you have at least ReadOnly access in all the Environments. Only one of the SettingIdToInitFrom or the InitialValues properties can be set.

The type of the Feature Flag or Setting.

The IDs of the tags which are attached to the setting.

create-tag

This endpoint creates a new Tag in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Organization.

Color of the Tag. Possible values: `panther`, `whale`, `salmon`, `lizard`, `canary`, `koala`, or any HTML color code.

Name of the Tag.

create-webhook

This endpoint creates a new Webhook in a specified Product
identified by the `productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Config.

The identifier of the Environment.

The HTTP body content.

The URL of the Webhook.

Indicates whether the header value is sensitive.

List of HTTP headers.

delete-change-request-comment

Deletes a Change Request comment.

The identifier of the Change Request comment.

delete-change-request-proposed-change

Removes a setting from a Change Request.

The identifier of the Change Request.

The identifier of the Setting.

delete-config

This endpoint removes a Config identified by the `configId` parameter.

The identifier of the Config.

delete-environment

This endpoint removes an Environment identified by the `environmentId` parameter.
If the `cleanupAuditLogs` flag is set to true, it also deletes the audit log records related to the environment
(except for the `Created a new environment` and `Deleted an environment` records).

An optional flag which indicates whether the audit log records related to the environment should be deleted or not.

The identifier of the Environment.

delete-integration

This endpoint removes a Integration identified by the `integrationId` parameter.

The identifier of the Integration.

delete-invitation

This endpoint removes an Invitation identified by the `invitationId` parameter.

The identifier of the Invitation.

delete-organization-member

This endpoint removes a Member identified by the `userId` from the
given Organization identified by the `organizationId` parameter.

The identifier of the Organization.

The identifier of the Member.

delete-permission-group

This endpoint removes a Permission Group identified by the `permissionGroupId` parameter.

The identifier of the Permission Group.

delete-product

This endpoint removes a Product identified by the `productId` parameter.

The identifier of the Product.

delete-product-member

This endpoint removes a Member identified by the `userId` from the
given Product identified by the `productId` parameter.

The identifier of the Product.

The identifier of the Member.

delete-segment

This endpoint removes a Segment identified by the `segmentId` parameter.

The identifier of the Segment.

delete-setting

This endpoint removes a Feature Flag or Setting from a specified Config,
identified by the `configId` parameter.

The identifier of the Setting.

delete-tag

This endpoint deletes a Tag identified by the `tagId` parameter. To remove a Tag from a Feature Flag or Setting use the [Update Flag](#operation/update-setting) endpoint.

The identifier of the Tag.

delete-webhook

This endpoint removes a Webhook identified by the `webhookId` parameter.

The identifier of the Webhook.

get-change-request

Returns the details of a specific Change Request.

The identifier of the Change Request.

get-change-request-proposed-changes

Returns the proposed changes to the Settings included in a Change Request.

The identifier of the Change Request.

The optional identifier of the Setting.

get-code-references

Get References for Feature Flag or Setting

The identifier of the Feature Flag or Setting.

get-config

This endpoint returns the metadata of a Config
identified by the `configId`.

The identifier of the Config.

get-environment

This endpoint returns the metadata of an Environment
identified by the `environmentId`.

The identifier of the Environment.

get-integration

This endpoint returns the metadata of an Integration
identified by the `integrationId`.

The identifier of the Integration.

get-permission-group

This endpoint returns the metadata of a Permission Group
identified by the `permissionGroupId`.

The identifier of the Permission Group.

get-product

This endpoint returns the metadata of a Product
identified by the `productId`.

The identifier of the Product.

get-product-preferences

This endpoint returns the preferences of a Product
identified by the `productId`.

The identifier of the Product.

get-sdk-keys

This endpoint returns the SDK Key for your Config in a specified Environment.

The identifier of the Config.

The identifier of the Environment.

get-segment

This endpoint returns the metadata of a Segment
identified by the `segmentId`.

The identifier of the Segment.

get-setting

This endpoint returns the metadata attributes of a Feature Flag or Setting
identified by the `settingId` parameter.

The identifier of the Setting.

get-setting-value

This endpoint returns the value of a Feature Flag or Setting
in a specified Environment identified by the `environmentId` parameter.

The most important attributes in the response are the `value`, `rolloutRules` and `percentageRules`.
The `value` represents what the clients will get when the evaluation requests of our SDKs
are not matching to any of the defined Targeting or Percentage Rules, or when there are no additional rules to evaluate.

The `rolloutRules` and `percentageRules` attributes are representing the current
Targeting and Percentage Rules configuration of the actual Feature Flag or Setting
in an **ordered** collection, which means the order of the returned rules is matching to the
evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview).

The identifier of the Environment.

The id of the Setting.

This endpoint returns the value of a Feature Flag or Setting
in a specified Environment identified by the `environmentId` parameter.

The most important fields in the response are the `defaultValue`, `targetingRules`, and `percentageEvaluationAttribute`.
The `defaultValue` represents what the clients will get when the evaluation requests of our SDKs
are not matching to any of the defined Targeting Rules, or when there are no additional rules to evaluate.

The `targetingRules` represents the current
Targeting Rule configuration of the actual Feature Flag or Setting
in an **ordered** collection, which means the order of the returned rules is matching to the
evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/).

The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/targeting/user-object/) attribute that must be used for [percentage evaluation](https://configcat.com/docs/targeting/percentage-options/) of the Feature Flag or Setting.

The identifier of the Environment.

The id of the Setting.

get-setting-values

This endpoint returns the value of a specified Config's Feature Flags or Settings identified by the `configId` parameter
in a specified Environment identified by the `environmentId` parameter.

The most important attributes in the response are the `value`, `rolloutRules` and `percentageRules`.
The `value` represents what the clients will get when the evaluation requests of our SDKs
are not matching to any of the defined Targeting or Percentage Rules, or when there are no additional rules to evaluate.

The `rolloutRules` and `percentageRules` attributes are representing the current
Targeting and Percentage Rules configuration of the actual Feature Flag or Setting
in an **ordered** collection, which means the order of the returned rules is matching to the
evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/).

The identifier of the Config.

The identifier of the Environment.

This endpoint returns all Feature Flag and Setting values of a Config identified by the `configId` parameter
in a specified Environment identified by the `environmentId` parameter.

The most important fields in the response are the `defaultValue`, `targetingRules`.
The `defaultValue` represents what the clients will get when the evaluation requests of our SDKs
are not matching to any of the defined Targeting Rules, or when there are no additional rules to evaluate.

The `targetingRules` represents the current
Targeting Rule configuration of the actual Feature Flag or Setting
in an **ordered** collection, which means the order of the returned rules is matching to the
evaluation order. You can read more about these rules [here](https://configcat.com/docs/targeting/targeting-overview/).

The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/targeting/user-object/) attribute that must be used for [percentage evaluation](https://configcat.com/docs/targeting/percentage-options/) of the Feature Flag or Setting.

The identifier of the Config.

The identifier of the Environment.

get-tag

This endpoint returns the metadata of a Tag
identified by the `tagId`.

The identifier of the Tag.

get-webhook

This endpoint returns the metadata of a Webhook
identified by the `webhookId`.

The identifier of the Webhook.

get-webhook-signing-keys

This endpoint returns the signing keys of a Webhook
identified by the `webhookId`.

Signing keys are used for ensuring the Webhook requests you receive are actually sent by ConfigCat.

Here you can read more about Webhook request verification.

The identifier of the Webhook.

invite-member

This endpoint invites a Member into the given Product identified by the `productId` parameter.

The identifier of the Product.

List of email addresses to invite.

Identifier of the Permission Group to where the invited users should be added.

list-auditlogs

This endpoint returns the list of Audit log items for a given Product and the result can be optionally filtered by Config and/or Environment.

Filter Audit logs by Audit log type.

The identifier of the Config.

The identifier of the Environment.

Filter Audit logs by starting UTC date.

Page number (min: 1).

Page size (min: 1, max: 100).

The identifier of the Product.

Filter Audit logs by ending UTC date.

list-change-requests

Returns Change Requests of a Product with optional filtering and pagination.

Filter Change Requests by approval requirement.

Filter Change Requests by status values.

The lifecycle status of a Change Request.

Filter Change Requests by Config identifier.

Filter Change Requests by Environment identifier.

Filter Change Requests by whether they need attention.

Page number (min: 1).

Page size (min: 1, max: 100).

The identifier of the Product.

Filter Change Requests by schedule state.

Filter Change Requests by Setting identifier.

list-configs

This endpoint returns the list of the Configs that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

list-environments

This endpoint returns the list of the Environments that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

list-integrations

This endpoint returns the list of the Integrations that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

list-organization-auditlogs

This endpoint returns the list of Audit log items for a given Organization and the result can be optionally filtered by Product and/or Config and/or Environment.

Filter Audit logs by Audit log type.

The identifier of the Config.

The identifier of the Environment.

Filter Audit logs by starting UTC date.

The identifier of the Organization.

Page number (min: 1).

Page size (min: 1, max: 100).

The identifier of the Product.

Filter Audit logs by ending UTC date.

list-organization-members

This endpoint returns the list of Members that belongs
to the given Organization, identified by the `organizationId` parameter.

The results may vary based on the access level of the user who calls the endpoint:
- When it's called with Organization Admin privileges, the result will contain each member in the Organization.
- When it's called without Organization Admin privileges, the result will contain each Organization Admin along with members
  of those products where the caller has `Team members and permission groups` (`canManageMembers`) permission.

The identifier of the Organization.

list-organizations

This endpoint returns the list of the Organizations that belongs to the user.

list-pending-invitations

This endpoint returns the list of pending invitations within the
given Product identified by the `productId` parameter.

The identifier of the Product.

list-pending-invitations-org

This endpoint returns the list of pending invitations within the
given Organization identified by the `organizationId` parameter.

The identifier of the Organization.

list-permission-groups

This endpoint returns the list of the Permission Groups that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

list-predefined-variations

This endpoint returns the predefined variations along with their usages in the Environments for a Feature Flag or Setting identified by the `settingId` parameter.

The identifier of the Setting.

list-product-members

This endpoint returns the list of Members that belongs
to the given Product, identified by the `productId` parameter.

The identifier of the Product.

list-products

This endpoint returns the list of the Products that belongs to the user.

list-segments

This endpoint returns the list of the Segments that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

list-settings

This endpoint returns the list of the Feature Flags and Settings defined in a
specified Config, identified by the `configId` parameter.

The identifier of the Config.

list-settings-by-tag

This endpoint returns the list of the Settings that
has the specified Tag, identified by the `tagId` parameter.

The identifier of the Tag.

list-staleflags

This endpoint returns the list of Zombie (stale) flags for a given Product
and the result can be optionally filtered by various parameters.

Ignore environment identifiers from the report.

Ignore feature flags from the report based on their tag identifiers.

The identifier of the Product.

The scope of the report.

The inactivity in days after a feature flag should be considered stale.

Consider a feature flag as stale if the feature flag is stale in all/any of the environments.

list-tags

This endpoint returns the list of the Tags in a
specified Product, identified by the `productId` parameter.

The identifier of the Product.

list-webhooks

This endpoint returns the list of the Webhooks that belongs to the given Product identified by the
`productId` parameter, which can be obtained from the [List Products](#operation/list-products) endpoint.

The identifier of the Product.

post-setting-values

This endpoint replaces the values of a specified Config's Feature Flags or Settings identified by the `configId` parameter
in a specified Environment identified by the `environmentId` parameter.

Only the `value`, `rolloutRules` and `percentageRules` attributes are modifiable by this endpoint.

**Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't
want to change in its original state. Not listing one means it will reset.

For example: We have the following resource.
```json
{
  "settingValues": [
    {
      "rolloutPercentageItems": [
        {
          "percentage": 30,
          "value": true
        },
        {
          "percentage": 70,
          "value": false
        }
      ],
      "rolloutRules": [],
      "value": false,
      "settingId": 1
    }
  ]
}
```
If we send a replace request body as below:
```json
{
  "settingValues": [
    {
      "value": true,
      "settingId": 1
    }
  ]
}
```
Then besides that the default value is set to `true`, all the Percentage Rules are deleted.
So we get a response like this:
```json
{
  "settingValues": [
    {
      "rolloutPercentageItems": [],
      "rolloutRules": [],
      "value": true,
      "setting":
      {
        "settingId": 1
      }
    }
  ]
}
```

The `rolloutRules` property describes two types of rules:

- **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required.
- **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required.

The identifier of the Config.

The identifier of the Environment.

The reason note for the Audit Log if the Product's "Config changes require a reason" preference is turned on.

The values to update.

The percentage rule collection.

The percentage value for the rule.

The value to serve when the user falls in the percentage rule. It must respect the setting type. In some generated clients for strictly typed languages you may use double/float properties to handle integer values.

The targeting rule collection.

The comparison operator the evaluation process must use when it compares the given user attribute's value with the comparison value.

The user attribute to compare.

The value to compare against.

The segment comparison operator used during the evaluation process.

The segment to compare against.

The value to serve when the comparison matches. It must respect the setting type. In some generated clients for strictly typed languages you may use double/float properties to handle integer values.

The identifier of the Setting.

The value to serve. It must respect the setting type. In some generated clients for strictly typed languages you may use double/float properties to handle integer values.

This endpoint batch updates the Feature Flags and Settings of a Config identified by the `configId` parameter
in a specified Environment identified by the `environmentId` parameter.

Only those Feature Flags and Settings are updated which are part of the request, all the others are left untouched.

**Important:** As this endpoint is doing a complete replace on those Feature Flags and Settings, which are set in the request.
It's important to set every other field that you don't want to change in its original state. Not listing a field means that it will reset.

For example: We have the following resource of a Feature Flag.
```json
{
  "settingFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "targetingRules": [
        {
          "conditions": [
            {
              "userCondition": {
                "comparisonAttribute": "Email",
                "comparator": "sensitiveTextEquals",
                "comparisonValue": {
                  "stringValue": "test@example.com"
                }
              }
            }
          ],
          "percentageOptions": [],
          "value": {
            "boolValue": true
          }
        }
      ],
      "settingId": 1
    }
  ]
}
```
If we send a batch replace request body as below:
```json
{
  "updateFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "settingId": 1
    }
  ]
}
```
Then besides that the default value is set to `true`, all Targeting Rules of the related Feature Flag are deleted.
So we get a response like this:
```json
{
  "settingFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "targetingRules": [],
      "setting":
      {
        "settingId": 1
      }
    }
  ]
}
```

Whether to bypass the approval process and directly apply the change. This is only applicable for users with bypass approval permission.

The identifier of the Config.

The identifier of the Environment.

Optional. The version identifier of the last change made to the Feature Flag or Setting in the Environment. It can be used to make sure concurrent updates are not overwriting each other. If provided and the version identifier does not match the current version, the update will be rejected with a 409 Conflict response. The latest version id can be acquired from the `LastVersionId` property of the response models.

Evaluation descriptors of each updated Feature Flag and Setting.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The user attribute used for percentage evaluation. If not set, it defaults to the `Identifier` user object attribute.

The identifier of the feature flag or setting.

Prerequisite flag comparison operator used during the evaluation process.

The served Variation's identifier.

The prerequisite flag's identifier.

Describes a condition that is based on a prerequisite flag.

The segment's identifier.

Describes a condition that is based on a segment.

The comparison operator which defines the relation between the comparison attribute and the comparison value.

The User Object attribute that the condition is based on. Can be "User ID", "Email", "Country" or any custom attribute.

The value that the user object's attribute is compared to.

The number representation of the comparison value.

An optional hint for the comparison value.

The actual comparison value.

The list representation of the comparison value.

The string representation of the comparison value.

Describes a condition that is based on user attributes.

A number between 0 and 100 that represents a randomly allocated fraction of the users.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The percentage options from where the evaluation process will choose a value based on the flag's percentage evaluation attribute.

The served Variation's identifier.

The targeting rules of the Feature Flag or Setting.

remove-change-request-approval

Removes your existing approval from the Change Request.

The identifier of the Change Request.

replace-setting

This endpoint replaces the whole value of a Feature Flag or Setting
identified by the `settingId` parameter.

**Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't
want to change in its original state. Not listing one means it will reset.

A short description for the setting, shown on the Dashboard UI.

Indicates whether this setting should validate string values as JSON values.

The name of the Feature Flag or Setting.

The order of the Setting represented on the ConfigCat Dashboard.
Determined from an ascending sequence of integers.

The IDs of the tags which are attached to the setting.

The identifier of the Setting.

replace-setting-value

This endpoint replaces the whole value of a Feature Flag or Setting in a specified Environment.

Only the `value`, `rolloutRules` and `percentageRules` attributes are modifiable by this endpoint.

**Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't
want to change in its original state. Not listing one means it will reset.

For example: We have the following resource.
```json
{
  "rolloutPercentageItems": [
    {
      "percentage": 30,
      "value": true
    },
    {
      "percentage": 70,
      "value": false
    }
  ],
  "rolloutRules": [],
  "value": false
}
```
If we send a replace request body as below:
```json
{
  "value": true
}
```
Then besides that the default value is set to `true`, all the Percentage Rules are deleted.
So we get a response like this:
```json
{
  "rolloutPercentageItems": [],
  "rolloutRules": [],
  "value": true
}
```

The `rolloutRules` property describes two types of rules:

- **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required.
- **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required.

The identifier of the Environment.

The reason note for the Audit Log if the Product's "Config changes require a reason" preference is turned on.

The percentage rule collection.

The percentage value for the rule.

The targeting rule collection.

The comparison operator the evaluation process must use when it compares the given user attribute's value with the comparison value.

The user attribute to compare.

The value to compare against.

The segment comparison operator used during the evaluation process.

The segment to compare against.

comparisonAttribute comparator comparisonValue value segmentComparator segmentId

The id of the Setting.

This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting
in a specified Environment identified by the SDK key passed in the `X-CONFIGCAT-SDKKEY` header.

Only the `defaultValue`, `targetingRules`, and `percentageEvaluationAttribute` fields are modifiable by this endpoint.

**Important:** As this endpoint is doing a complete replace, it's important to set every other field that you don't
want to change to its original state. Not listing one means it will reset.

For example: We have the following resource of a Feature Flag.
```json
{
  "defaultValue": {
    "boolValue": false
  },
  "targetingRules": [
    {
      "conditions": [
        {
          "userCondition": {
            "comparisonAttribute": "Email",
            "comparator": "sensitiveTextEquals",
            "comparisonValue": {
              "stringValue": "test@example.com"
            }
          }
        }
      ],
      "percentageOptions": [],
      "value": {
        "boolValue": true
      }
    }
  ]
}
```
If we send a replace request body as below:
```json
{
  "defaultValue": {
    "boolValue": true
  }
}
```
Then besides that the default served value is set to `true`, all the Targeting Rules are deleted.
So we get a response like this:
```json
{
  "defaultValue": {
    "boolValue": true
  },
  "targetingRules": []
}
```

Whether to bypass the approval process and directly apply the change. This is only applicable for users with bypass approval permission.

The identifier of the Environment.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The user attribute used for percentage evaluation. If not set, it defaults to the `Identifier` user object attribute.

Prerequisite flag comparison operator used during the evaluation process.

The served Variation's identifier.

The prerequisite flag's identifier.

Describes a condition that is based on a prerequisite flag.

The segment's identifier.

Describes a condition that is based on a segment.

The comparison operator which defines the relation between the comparison attribute and the comparison value.

The User Object attribute that the condition is based on. Can be "User ID", "Email", "Country" or any custom attribute.

The value that the user object's attribute is compared to.

The number representation of the comparison value.

An optional hint for the comparison value.

The actual comparison value.

The list representation of the comparison value.

The string representation of the comparison value.

Describes a condition that is based on user attributes.

A number between 0 and 100 that represents a randomly allocated fraction of the users.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The percentage options from where the evaluation process will choose a value based on the flag's percentage evaluation attribute.

The served Variation's identifier.

The targeting rules of the Feature Flag or Setting.

The id of the Setting.

replace-webhook

This endpoint replaces the whole value of a Webhook identified by the `webhookId` parameter.

**Important:** As this endpoint is doing a complete replace, it's important to set every other attribute that you don't
want to change in its original state. Not listing one means it will reset.

The HTTP body content.

The URL of the Webhook.

Indicates whether the header value is sensitive.

List of HTTP headers.

The identifier of the Webhook.

Updates the proposed changes to a Setting included in the Change Request to resolve conflicts caused by concurrently published changes.

The identifier of the Change Request.

The served Variation's identifier.

The user attribute used for percentage evaluation. If not set, it defaults to the `Identifier` user object attribute.

The identifier of the feature flag or setting.

Prerequisite flag comparison operator used during the evaluation process.

The served Variation's identifier.

The prerequisite flag's identifier.

Describes a condition that is based on a prerequisite flag.

The segment comparison operator used during the evaluation process.

The segment's identifier.

Describes a condition that is based on a segment.

The comparison operator which defines the relation between the comparison attribute and the comparison value.

The User Object attribute that the condition is based on. Can be "User ID", "Email", "Country" or any custom attribute.

The value that the user object's attribute is compared to.

The number representation of the comparison value.

An optional hint for the comparison value.

The actual comparison value.

The list representation of the comparison value.

The string representation of the comparison value.

Describes a condition that is based on user attributes.

A number between 0 and 100 that represents a randomly allocated fraction of the users.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The percentage options from where the evaluation process will choose a value based on the flag's percentage evaluation attribute.

The served Variation's identifier.

The targeting rules of the Feature Flag or Setting.

The identifier of the Setting.

update-change-request

Updates the metadata of a Change Request, such as title, note, schedule, etc.

The identifier of the Change Request.

The JSON request body.

The updated optional UTC date and time when the Change Request should be applied automatically.

The updated bypass-approval flag for scheduled changes.

The updated optional notes describing the purpose of the Change Request.

The updated title of the Change Request.

update-change-request-comment

Updates an existing Change Request comment.

The identifier of the Change Request comment.

The updated comment body.

update-change-request-proposed-changes

Updates the proposed changes to the Settings included in a Change Request.

The identifier of the Change Request.

When true, skips conflict (LatestVersionId) checking.

The setting values to update on the Change Request.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The user attribute used for percentage evaluation. If not set, it defaults to the `Identifier` user object attribute.

The identifier of the feature flag or setting.

Prerequisite flag comparison operator used during the evaluation process.

The served Variation's identifier.

The prerequisite flag's identifier.

Describes a condition that is based on a prerequisite flag.

The segment comparison operator used during the evaluation process.

The segment's identifier.

Describes a condition that is based on a segment.

Describes a condition that is based on user attributes.

The comparison operator which defines the relation between the comparison attribute and the comparison value.

The User Object attribute that the condition is based on. Can be "User ID", "Email", "Country" or any custom attribute.

The value that the user object's attribute is compared to.

The number representation of the comparison value.

An optional hint for the comparison value.

The actual comparison value.

The list representation of the comparison value.

The string representation of the comparison value.

A number between 0 and 100 that represents a randomly allocated fraction of the users.

Represents the value of a Feature Flag or Setting.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served Variation's identifier.

The served value in case of a text Setting.

The percentage options from where the evaluation process will choose a value based on the flag's percentage evaluation attribute.

The served Variation's identifier.

The targeting rules of the Feature Flag or Setting.

The optional identifier of the Setting.

update-config

This endpoint updates a Config identified by the `configId` parameter.

The identifier of the Config.

The description of the Config.

The name of the Config.

The order of the Config represented on the ConfigCat Dashboard. Determined from an ascending sequence of integers.

update-environment

This endpoint updates an Environment identified by the `environmentId` parameter.

The identifier of the Environment.

The JSON request body.

The color of the Environment. RGB or HTML color codes are allowed.

The description of the Environment.

The name of the Environment.

The order of the Environment represented on the ConfigCat Dashboard.
Determined from an ascending sequence of integers.

update-integration

This endpoint updates a Config identified by the `integrationId` parameter.

The Parameters dictionary differs for each IntegrationType:
- Datadog
  - `apikey`: Required. Datadog API key.
  - `site`: Datadog site. Available values: `Us`, `Eu`, `Us1Fed`, `Us3`, `Us5`. Default: `Us`.
- Slack
  Connecting the Slack integration through the Public Management API will not post messages with the ConfigCat Feature Flags Slack app but with an incoming webhook.
  - `incoming_webhook.url`: Required. The [incoming webhook URL](https://api.slack.com/messaging/webhooks) where the integration should post messages.
  - `includeSensitiveData`: Set to "true" to include [sensitive (hashed) comparison values](https://configcat.com/docs/targeting/targeting-rule/user-condition/#confidential-text-comparators). By default, the integration will mask these values in the posted messages. We recommend hiding sensitive comparison values for shared or public Slack channels.
- Amplitude
  - `apiKey`: Required. Amplitude API Key.
  - `secretKey`: Required. Amplitude Secret Key.
- Mixpanel
  - `serviceAccountUserName`: Required. Mixpanel Service Account Username.
  - `serviceAccountSecret`: Required. Mixpanel Service Account Secret.
  - `projectId`: Required. Mixpanel Project ID.
  - `server`: Mixpanel Server. Available values: `StandardServer`, `EUResidencyServer`. Default: `StandardServer`.
- Twilio Segment
  - `writeKey`: Required. Twilio Segment Write Key.
  - `server`: Twilio Segment Server. Available values: `Us`, `Eu`. Default: `Us`.
- PubNub (work in progress)

The identifier of the Integration.

List of Config IDs that are connected with this Integration. If the list is empty, all the Configs are connected.

List of Environment IDs that are connected with this Integration. If the list is empty, all the Environments are connected.

Name of the Integration.

Parameters of the Integration.

name parameters environmentIds configIds

update-member-permissions

This endpoint updates the permissions of a Member identified by the `userId`.
This endpoint can also be used to move a Member between Permission Groups within a Product.
Only a single Permission Group can be set per Product.

The identifier of the Organization.

Indicates that the member must be Organization Admin.

Indicates that the member must be Billing Manager.

List of Permission Group identifiers to where the Member should be added.

When `true`, the member will be removed from those Permission Groups that are not listed in the `permissionGroupIds` field.

The identifier of the Member.

update-permission-group

This endpoint updates a Permission Group identified by the `permissionGroupId` parameter.

The identifier of the Permission Group.

Represent the Feature Management permission.

Represents the permission group level change request approval permission.

Group members can create/update Configs.

Group members can create/update Environments.

Group members can create/update Segments.

Group members can create/update Feature Flags and Settings.

Group members can create/update Tags.

Group members can delete Configs.

Group members can delete Environments.

Group members can delete Segments.

Group members can delete Feature Flags and Settings.

Group members can delete Tags.

Group members can disable two-factor authentication for other members.

Group members can add and configure integrations.

Group members can manage team members.

Group members can update Product preferences.

Group members can create/update/delete Webhooks.

Group members can rotate SDK keys.

Group members can attach/detach Tags to Feature Flags and Settings.

Group members can use the export/import feature.

Group members has access to audit logs.

Group members has access to product statistics.

Group members has access to SDK keys.

Represent the environment specific Feature Management permission.

Identifier of the Environment.

List of environment specific permissions.

Represents the environment specific change request approval permission.

Identifier of the Environment.

List of environment specific change request approval permissions.

Name of the Permission Group.

update-predefined-variations

This endpoint updates the predefined variations for a Feature Flag or Setting identified by the `settingId` parameter.
**Important:** You can only update a predefined variation's value if it is not used anywhere in your feature flags.

A collection of Predefined Variations.

A Predefined Variation.

The name of the Predefined Variation, shown on the Dashboard UI. If not set, the Value will be shown.

The Predefined Variation's identifier to update. Omit the value if you want to add a new predefined variation.

Represents the value of a Predefined Variation.

The served value in case of a boolean Feature Flag.

The served value in case of a decimal number Setting.

The served value in case of a whole number Setting.

The served value in case of a text Setting.

The identifier of the Setting.

update-product

This endpoint updates a Product identified by the `productId` parameter.

The identifier of the Product.

The description of the Product.

The name of the Product.

The order of the Product represented on the ConfigCat Dashboard. Determined from an ascending sequence of integers.

update-product-preferences

This endpoint updates the preferences of a Product identified by the `productId` parameter.

The identifier of the Product.

Indicates that a mandatory approval is required before changes are applied.

Indicates that a mandatory approval is required in this Environment before changes are applied.

Identifier of the Environment.

List of Environments where mandatory approval must be given before changes are applied.

camelCase lowerCase upperCase pascalCase kebabCase

Determines the Feature Flag key generation mode.

Indicates whether Feature flags and Settings must have a hint.

Indicates that a mandatory note is required for saving and publishing.

Identifier of the Environment.

Indicates that a mandatory note is required in this Environment for saving and publishing.

List of Environments where mandatory note must be set before saving and publishing.

Indicates whether a variation ID's must be shown on the ConfigCat Dashboard.

update-sdk-documentation

If the user asks for coding related to a feature flag (such as integrating the ConfigCat SDK, adding a feature flag, or removing a feature flag),
    always call the tool "update-sdk-documentation" first to download the latest ConfigCat SDK documentation.

    1. Analyze the SDK URLs listed in the following SDK Reference list.
    2. Then call the tool "update-sdk-documentation" with specific URL from the SDK Reference list to fetch relevant documentation page.

    ## SDK Reference

- [Android (Java) SDK Reference](https://configcat.com/docs/sdk-reference/android.md): ConfigCat Android SDK Reference. This is a step-by-step guide on how to use feature flags in your Android Java application.
- [ConfigCat package for Laravel](https://configcat.com/docs/sdk-reference/community/laravel.md): ConfigCat package for Laravel. Implement feature flags within your PHP Laravel application using ConfigCat.
- [ConfigCat SDK for Vue.js](https://configcat.com/docs/sdk-reference/community/vue.md): Unofficial Vue SDK for ConfigCat feature flags. Based on ConfigCat's JavaScript SDK.
- [C++ SDK Reference](https://configcat.com/docs/sdk-reference/cpp.md): ConfigCat C++ SDK Reference. This is a step-by-step guide on how to use feature flags in your C++ application.
- [Dart (Flutter) SDK Reference](https://configcat.com/docs/sdk-reference/dart.md): ConfigCat Dart (Flutter) SDK Reference. This is a step-by-step guide on how to use feature flags in your Dart (Flutter) apps.
- [.NET SDK Reference](https://configcat.com/docs/sdk-reference/dotnet.md): ConfigCat .NET SDK Reference. This is a step-by-step guide on how to use feature flags in your .NET application.
- [Using the ConfigCat SDK in DI‑Based .NET Applications](https://configcat.com/docs/sdk-reference/dotnet/generic-host.md): Using the ConfigCat SDK in DI-based .NET applications. This is a step-by-step guide on how to use feature flags in your ASP.NET Core applications and other modern .NET applications built on .NET Generic Host or .NET's standard dependency injection.
- [Elixir SDK Reference](https://configcat.com/docs/sdk-reference/elixir.md): ConfigCat Elixir SDK Reference. This is a step-by-step guide on how to use feature flags in your Elixir project.
- [Go SDK Reference](https://configcat.com/docs/sdk-reference/go.md): ConfigCat Go SDK Reference. This is a step-by-step guide on how to use feature flags in your Go applications.
- [Swift (iOS) SDK Reference](https://configcat.com/docs/sdk-reference/ios.md): ConfigCat Swift (iOS) SDK Reference. This is a step-by-step guide on how to use feature flags in your iOS mobile application.
- [Java SDK reference](https://configcat.com/docs/sdk-reference/java.md): ConfigCat Java SDK Reference. This is a step-by-step guide on how to use feature flags in your Java application.
- [Browser (JavaScript) SDK](https://configcat.com/docs/sdk-reference/js/browser.md): ConfigCat Browser (JavaScript) SDK Reference. This is a step-by-step guide on how to use feature flags in your frontend applications and Web Workers running in the browser.
- [Bun SDK](https://configcat.com/docs/sdk-reference/js/bun.md): ConfigCat Bun SDK Reference. This is a step-by-step guide on how to use feature flags in your Bun applications.
- [Chromium Extension SDK](https://configcat.com/docs/sdk-reference/js/chromium-extension.md): ConfigCat Chromium Extension SDK Reference. This is a step-by-step guide on how to use feature flags in your extensions for Chromium-based browsers (Chrome, Edge, etc.)
- [Cloudflare Worker SDK](https://configcat.com/docs/sdk-reference/js/cloudflare-worker.md): ConfigCat Cloudflare Worker SDK Reference. This is a step-by-step guide on how to use feature flags in your Cloudflare Workers.
- [Deno SDK](https://configcat.com/docs/sdk-reference/js/deno.md): ConfigCat Deno SDK Reference. This is a step-by-step guide on how to use feature flags in your Deno applications.
- [Node.js SDK](https://configcat.com/docs/sdk-reference/js/node.md): ConfigCat Node.js SDK Reference. This is a step-by-step guide on how to use feature flags in your Node.js applications.
- [ConfigCat SDK for JavaScript](https://configcat.com/docs/sdk-reference/js/overview.md): ConfigCat SDK for JavaScript Reference. This is a step-by-step guide on how to use feature flags in your JavaScript applications.
- [Kotlin Multiplatform SDK Reference](https://configcat.com/docs/sdk-reference/kotlin.md): ConfigCat Kotlin Multiplatform SDK Reference. This is a step-by-step guide on how to use feature flags in your Kotlin Multiplatform apps.
- [OpenFeature Providers](https://configcat.com/docs/sdk-reference/openfeature.md): Integrate feature flags using OpenFeature's vendor-agnostic API with ConfigCat OpenFeature providers. Supported for .NET, Java, Python, Go, JavaScript, React, Node.js, and more.
- [Using ConfigCat's OpenFeature Provider in Angular](https://configcat.com/docs/sdk-reference/openfeature/angular.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature Angular SDK.
- [OpenFeature Provider for .NET](https://configcat.com/docs/sdk-reference/openfeature/dotnet.md): ConfigCat OpenFeature Provider for .NET. This is a step-by-step guide on how to use ConfigCat with the OpenFeature .NET SDK.
- [OpenFeature Provider for Go](https://configcat.com/docs/sdk-reference/openfeature/go.md): ConfigCat OpenFeature Provider for Go. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Go SDK.
- [OpenFeature Provider for Java](https://configcat.com/docs/sdk-reference/openfeature/java.md): ConfigCat OpenFeature Provider for Java. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Java SDK.
- [OpenFeature Provider for JavaScript](https://configcat.com/docs/sdk-reference/openfeature/js.md): ConfigCat OpenFeature Provider for JavaScript. This is a step-by-step guide on how to use ConfigCat with the OpenFeature JavaScript SDK.
- [OpenFeature Provider for Kotlin](https://configcat.com/docs/sdk-reference/openfeature/kotlin.md): ConfigCat OpenFeature Provider for Kotlin. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Kotlin SDK.
- [Using ConfigCat's OpenFeature Provider in NestJS](https://configcat.com/docs/sdk-reference/openfeature/nestjs.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature NestJS SDK.
- [OpenFeature Provider for Node.js](https://configcat.com/docs/sdk-reference/openfeature/node.md): ConfigCat OpenFeature Provider for Node.js. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Node.js SDK.
- [OpenFeature Provider for PHP](https://configcat.com/docs/sdk-reference/openfeature/php.md): ConfigCat OpenFeature Provider for PHP. This is a step-by-step guide on how to use ConfigCat with the OpenFeature PHP SDK.
- [OpenFeature Provider for Python](https://configcat.com/docs/sdk-reference/openfeature/python.md): ConfigCat OpenFeature Provider for Python. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Python SDK.
- [Using ConfigCat's OpenFeature Provider in React](https://configcat.com/docs/sdk-reference/openfeature/react.md): This is a step-by-step guide on how to use ConfigCat with the OpenFeature React SDK.
- [OpenFeature Provider for Ruby](https://configcat.com/docs/sdk-reference/openfeature/ruby.md): ConfigCat OpenFeature Provider for Ruby. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Ruby SDK.
- [OpenFeature Provider for Rust](https://configcat.com/docs/sdk-reference/openfeature/rust.md): ConfigCat OpenFeature Provider for Rust. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Rust SDK.
- [OpenFeature Provider for Swift](https://configcat.com/docs/sdk-reference/openfeature/swift.md): ConfigCat OpenFeature Provider for Swift. This is a step-by-step guide on how to use ConfigCat with the OpenFeature Swift SDK.
- [ConfigCat SDK Overview](https://configcat.com/docs/sdk-reference/overview.md): List of all supported technologies like .NET, Java, JavaScript, Node.js, Deno, Bun, Cloudflare Worker, PHP, Python, Ruby, Go, Android, Swift, iOS, Elixir, Dart, Flutter, Angular, React, Vue.js, Chromium Extension, Kotlin Multiplatform, Laravel, Server-Side Rendered apps, etc.
- [PHP SDK Reference](https://configcat.com/docs/sdk-reference/php.md): ConfigCat PHP SDK Reference. This is a step-by-step guide on how to use feature flags in your PHP application.
- [Python SDK Reference](https://configcat.com/docs/sdk-reference/python.md): ConfigCat Python SDK Reference. This is a step-by-step guide on how to use feature flags in your Python application.
- [React SDK Reference](https://configcat.com/docs/sdk-reference/react.md): ConfigCat React SDK Reference. This is a step-by-step guide on how to use feature flags in your React applications.
- [Ruby SDK Reference](https://configcat.com/docs/sdk-reference/ruby.md): ConfigCat Ruby SDK Reference. This is a step-by-step guide on how to use feature flags in your Ruby application.
- [Rust SDK Reference](https://configcat.com/docs/sdk-reference/rust.md): ConfigCat Rust SDK Reference. This is a step-by-step guide on how to use feature flags in your Rust applications.
- [Using the ConfigCat SDK in Unity](https://configcat.com/docs/sdk-reference/unity.md): Using the ConfigCat SDK in Unity. This is a step-by-step guide on how to use feature flags in your Unity project.
- [Unreal Engine SDK Reference](https://configcat.com/docs/sdk-reference/unreal.md): ConfigCat Unreal Engine SDK Reference. This is a step-by-step guide on how to use feature flags in your Unreal Engine project.

The URL to fetch SDK documentation from.

update-segment

This endpoint updates a Segment identified by the `segmentId` parameter.

The comparison operator the evaluation process must use when it compares the given user attribute's value with the comparison value.

The user's attribute the evaluation process must take into account.

The value to compare with the given user attribute's value.

Description of the Segment.

Name of the Segment.

The identifier of the Segment.

update-setting

This endpoint updates the metadata of a Feature Flag or Setting
with a collection of [JSON Patch](https://jsonpatch.com) operations in a specified Config.

Only the `name`, `hint` and `tags` attributes are modifiable by this endpoint.
The `tags` attribute is a simple collection of the [tag IDs](#operation/list-tags) attached to the given setting.

The advantage of using JSON Patch is that you can describe individual update operations on a resource
without touching attributes that you don't want to change.

For example: We have the following resource.
```json
{
  "settingId": 5345,
  "key": "myGrandFeature",
  "name": "Tihs is a naem with soem typos.",
  "hint": "This flag controls my grandioso feature.",
  "settingType": "boolean",
  "tags": [
    {
      "tagId": 0,
      "name": "sample tag",
      "color": "whale"
    }
  ]
}
```
If we send an update request body as below (it changes the `name` and adds the already existing tag with the id `2`):
```json
[
  {
    "op": "replace",
    "path": "/name",
    "value": "This is the name without typos."
  },
  {
    "op": "add",
    "path": "/tags/-",
    "value": 2
  }
]
```
Only the `name` and `tags` are updated and all the other attributes remain unchanged.
So we get a response like this:
```json
{
  "settingId": 5345,
  "key": "myGrandFeature",
  "name": "This is the name without typos.",
  "hint": "This flag controls my grandioso feature.",
  "settingType": "boolean",
  "tags": [
    {
      "tagId": 0,
      "name": "sample tag",
      "color": "whale"
    },
    {
      "tagId": 2,
      "name": "another tag",
      "color": "koala"
    }
  ]
}
```

The target path.

The operation type.

unknown add remove replace move copy test

The source path.

The discrete value.

The identifier of the Setting.

update-setting-value

This endpoint updates the value of a Feature Flag or Setting
with a collection of [JSON Patch](https://jsonpatch.com) operations in a specified Environment.

Only the `value`, `rolloutRules` and `percentageRules` attributes are modifiable by this endpoint.

The advantage of using JSON Patch is that you can describe individual update operations on a resource
without touching attributes that you don't want to change. It supports collection reordering, so it also
can be used for reordering the targeting rules of a Feature Flag or Setting.

For example: We have the following resource.
```json
{
  "rolloutPercentageItems": [
    {
      "percentage": 30,
      "value": true
    },
    {
      "percentage": 70,
      "value": false
    }
  ],
  "rolloutRules": [],
  "value": false
}
```
If we send an update request body as below:
```json
[
  {
    "op": "replace",
    "path": "/value",
    "value": true
  }
]
```
Only the default value is going to be set to `true` and all the Percentage Rules are remaining unchanged.
So we get a response like this:
```json
{
  "rolloutPercentageItems": [
    {
      "percentage": 30,
      "value": true
    },
    {
      "percentage": 70,
      "value": false
    }
  ],
  "rolloutRules": [],
  "value": true
}
```

The `rolloutRules` property describes two types of rules:

- **Targeting rules**: When you want to add or update a targeting rule, the `comparator`, `comparisonAttribute`, and `comparisonValue` members are required.
- **Segment rules**: When you want to add add or update a segment rule, the `segmentId` which identifies the desired segment and the `segmentComparator` members are required.

The identifier of the Environment.

The reason note for the Audit Log if the Product's "Config changes require a reason" preference is turned on.

The target path.

The operation type.

The source path.

The discrete value.

The identifier of the Setting.

This endpoint updates the value of a Feature Flag or Setting
with a collection of [JSON Patch](https://jsonpatch.com) operations in a specified Environment.

Only the `defaultValue`, `targetingRules`, and `percentageEvaluationAttribute` fields are modifiable by this endpoint.

The advantage of using JSON Patch is that you can describe individual update operations on a resource
without touching attributes that you don't want to change. It supports collection reordering, so it also
can be used for reordering the targeting rules of a Feature Flag or Setting.

For example: We have the following resource of a Feature Flag.
```json
{
  "defaultValue": {
    "boolValue": false
  },
  "targetingRules": [
    {
      "conditions": [
        {
          "userCondition": {
            "comparisonAttribute": "Email",
            "comparator": "sensitiveTextEquals",
            "comparisonValue": {
              "stringValue": "test@example.com"
            }
          }
        }
      ],
      "percentageOptions": [],
      "value": {
        "boolValue": true
      }
    }
  ]
}
```
If we send an update request body as below:
```json
[
  {
    "op": "replace",
    "path": "/targetingRules/0/value/boolValue",
    "value": true
  }
]
```
Only the first Targeting Rule's `value` is going to be set to `false` and all the other fields are remaining unchanged.

So we get a response like this:
```json
{
  "defaultValue": {
    "boolValue": false
  },
  "targetingRules": [
    {
      "conditions": [
        {
          "userCondition": {
            "comparisonAttribute": "Email",
            "comparator": "sensitiveTextEquals",
            "comparisonValue": {
              "stringValue": "test@example.com"
            }
          }
        }
      ],
      "percentageOptions": [],
      "value": {
        "boolValue": false
      }
    }
  ]
}
```

Whether to bypass the approval process and directly apply the change. This is only applicable for users with bypass approval permission.

The identifier of the Environment.

The target path.

The operation type.

The source path.

The discrete value.

The id of the Setting.

update-tag

This endpoint updates a Tag identified by the `tagId` parameter.

Color of the Tag. Possible values: `panther`, `whale`, `salmon`, `lizard`, `canary`, `koala`, or any HTML color code.

The name of the Tag.

update-webhook

This endpoint updates a Webhook identified by the `webhookId` parameter with a collection of [JSON Patch](https://jsonpatch.com) operations.

The advantage of using JSON Patch is that you can describe individual update operations on a resource without touching attributes that you don't want to change.

For example: We have the following resource.
```json
{
  "webhookId": 6,
  "url": "https://example.com/hook",
  "httpMethod": "post",
  "content": "null",
  "webHookHeaders": []
}
```
If we send an update request body as below (it changes the `content` field and adds a new HTTP header):
```json
[
  {
    "op": "replace",
    "path": "/content",
    "value": "Some webhook content."
  },
  {
    "op": "add",
    "path": "/webHookHeaders/-",
    "value": {
      "key": "X-Custom-Header",
      "value": "Custom header value"
    }
  }
]
```
Only the `content` and `webHookHeaders` are updated and all the other attributes remain unchanged.
So we get a response like this:
```json
{
  "webhookId": 6,
  "url": "https://example.com/hook",
  "httpMethod": "post",
  "content": "Some webhook content.",
  "webHookHeaders": [
    {
      "key": "X-Custom-Header",
      "value": "Custom header value",
      "isSecure": false
    }
  ]
}
```

The target path.

The operation type.

The source path.

The discrete value.

The identifier of the Webhook.


Search Tyler Forge components by name, description, or functionality with enhanced fuzzy matching. Supports multi-term queries like "app bar drawer". Returns all components when no query provided.

Optional: include related components in results (default: false)

Optional: maximum number of results to return (default: 10 for search, unlimited for list all)

Optional: require all search terms to match (default: false - match any term)

Search query to find components by name, description, or features. Leave empty to list all components.

Optional: specify what to search in (default: all)

name description properties methods events slots css-parts all

Search Tyler Icons using semantic/fuzzy search with natural language queries. Finds the closest matching icons by name and keywords.

Maximum number of results to return (default: 10)

Space-separated search terms to find matching icons (e.g., "user profile", "arrow left", "check mark")

Emit a machine-checkable UI plan (scaffold block, regions, typography roles, icons) before writing composition-scale Forge markup. Returns the empty plan template and the enums the plan must use. Call validate_ui_plan on the composed plan before writing any <forge-*> markup. See references/ui-plan.md.

What the user is asking you to build. A sentence or two is enough; the plan is composed from the description plus the current session context.

Framework in use (angular, react, vue, svelte, lit, or plain). Optional — only affects framework-specific plan hints.

Optional page type if the caller already knows it. Otherwise leave blank and pick during plan composition.

dashboard list-detail form settings wizard landing single-feature

Get the API contract (properties, attributes, events, slots, CSS parts, CSS vars) for a Tyler Forge component. Call list_components first if you need to discover available components. For HTML usage code, call `get_forge_blocks` instead — blocks are the sole source of Forge markup.

Component tag name (e.g., "forge-button", "forge-card"). Required — call list_components first if you don't know the tag name.

Documentation format: full (default) or summary (brief overview). For HTML usage code, call `get_forge_blocks` — this tool returns API contract only.

Optional: specific documentation sections to include. Only applies to full format.

properties methods events slots css-custom-properties css-parts css-classes states

Get Tyler Forge design tokens for consistent styling. Access color palettes, spacing scales, typography, animation, and other design system values.

Optional: specific design token category (default: all categories overview)

color spacing typography animation border elevation layering shape all

Get Forge UI code blocks - pre-built patterns and examples that demonstrate correct Forge component usage. Use this FIRST before generating any Forge UI code to ensure accurate patterns. Can list/search blocks or fetch specific block content.

Specific block ID to fetch the full HTML content for (e.g., "src/blocks/forms/login").

Filter blocks by category (e.g., "forms", "tables", "application-layout").

Filter blocks by Forge component usage. Returns all blocks that use the specified component (e.g., "forge-card", "forge-table", "forge-button"). Use this to see how a component is used across different contexts and patterns.

Maximum number of blocks to return when listing (default: 20).

Describe the UI functionality you need (e.g., "form with validation", "data table with sorting", "user profile card"). Searches block descriptions to find matching functionality. Results are ranked by relevance - top results may be usable directly, while lower-ranked results can serve as starting points.

Get comprehensive Tyler Forge guides including installation instructions, framework-specific integration, and general usage patterns

Framework for installation or framework guides. Required for type=framework.

Type of guide: general (default - usage patterns), installation (setup instructions), or framework (framework-specific integration)

Get comprehensive migration guides for upgrading between Tyler Forge versions, including breaking changes, API mappings, and upgrade instructions

Source version to migrate from (default: "v2")

Target version to migrate to (default: "v3")

Browse all available Tyler Forge components with descriptions. Returns a comprehensive table of all components with their purpose and capabilities.

Get complete framework-specific setup instructions for Tyler Forge components including installation, configuration, and best practices.

Target framework for Tyler Forge setup and integration

Access Tyler Forge icons system including installation, registration, and usage patterns for the forge-icon component.

Access Tyler Forge typography setup instructions including font families, type scales, weights, and practical usage guidelines for consistent text styling.

Validate Tyler Forge component-specific API usage after code generation. Supports both core components (@tylertech/forge) and extended components (@tylertech/forge-extended). DO NOT use this tool to validate standard HTML attributes (id, class, style, etc.), ARIA attributes (aria-*), or data attributes (data-*) - these are valid on all elements. Only validate component-specific properties, attributes, events, methods, slots, CSS properties, parts, and classes.

APIs to validate for the component

Attribute names to validate (e.g., ["disabled", "aria-label"])

CSS class names to validate (e.g., ["forge-button--raised"])

CSS part names to validate (e.g., ["button", "label"])

CSS custom property names to validate (e.g., ["--forge-button-background"])

Event names to validate (e.g., ["change", "click"])

Method names to validate (e.g., ["focus", "click"])

Property names to validate (e.g., ["disabled", "value"])

Slot names to validate (e.g., ["default", "header"])

Component tag name - supports core (e.g., "forge-button", "forge-card") and extended components (e.g., "forge-user-profile", "forge-app-launcher")

Validate a UI plan produced by generate_ui_plan. Checks: page_type enum, region components exist in the CEM, block IDs exist in the block catalogue, typography roles are legal, spacing_scale is tokens-only, icons exist in @tylertech/tyler-icons, and composition rules (no page_title inside card, no hand-rolled tables). Returns pass/fail with per-error hints. Markup must not be written until this returns valid=true.

The plan object emitted by generate_ui_plan, either as an object or a JSON string.


Read the latest Anime News Network stories from their RSS feeds. 'all' mixes news, reviews and features; 'news' and 'reviews' are the narrower feeds. Filter with 'category' to keep only stories the feed tags a given way, such as Manga or Anime. The feed is the whole window available: there is no way to reach older stories through this tool. When you repeat a story, cite Anime News Network and link the article.

Keep only items tagged this way, matched case-insensitively.

Regional edition. They differ mostly in release and licensing coverage.

Which feed to read. 'all' is the busiest.

How many stories to return.

Article URL. Show this when citing the story.

ISO 8601 when the feed date could be parsed.

title link summary published_at category

Items in the feed after 'category' was applied, before 'limit'.

feed edition items total_available notes

Read the news wire

Read one Anime News Network encyclopedia entry by id. Get the id and kind from search_titles first. Sections are opt-in because a full record is very large: ask only for what you need. 'basic' covers type, vintage, genres, themes, episode count, ratings and the plot summary. Long plot summaries are paginated: when 'truncated' is true, call again with 'offset' set to 'next_offset'.

Encyclopedia id, from search_titles.

Which lookup the id belongs to, from search_titles.

Character budget for the plot summary.

Where to resume the plot summary.

Which parts to return. 'basic' is usually enough. Adding 'cast' or 'news' can multiply the size of the answer.

basic cast staff episodes releases related news reviews

Language of this credit, such as 'JA' for the Japanese cast of a Japanese production or 'FR' for the French dub. Null when the site records none, which is not a claim that the credit is the original one.

Every language the site records a cast in, with its full credit count, so a trimmed 'cast' still shows what exists. Ask again with a narrower question if a language you need was cut.

Pass as 'offset' to read the rest.

'prev' is what this came from, 'next' what came out of it.

Encyclopedia id. Pass this to get_title, together with 'kind'.

Which get_title lookup this id belongs to.

Disambiguator the site shows next to the name, such as 'TV 2'.

Encyclopedia page. Show this when citing the entry.

TV, movie, OAV, ONA, special, manga or novel.

Original release date or range, as published.

id kind type name precision vintage source_url

Length of the full plot summary.

Read an encyclopedia entry

List what was added to the Anime News Network encyclopedia most recently: anime, manga, people or companies. Pass 'starts_with' to browse titles alphabetically instead, which only applies to anime and manga. Rows carry an id you can pass to get_title when the kind is anime or manga. This is a listing, not a search: use search_titles when you know what you are looking for.

Which catalogue to list.

How many rows to return.

How many rows to skip, for paging.

Single letter. Switches to an alphabetical browse of titles. Anime and manga only.

'recent' is by date added, 'browse' is alphabetical.

Pass as 'offset' for the next page. Null when the last page came back short.

id kind name type precision vintage date_added source_url

List recent or browse alphabetically

Search the Anime News Network encyclopedia for anime and manga by title. Returns one compact row per match: id, kind, type, name, precision and vintage. Use the id and kind with get_title to read the full entry. Matching is on substring, so a short query returns a lot: narrow the query rather than raising 'limit'. This searches titles only. It cannot find an entry from a plot detail, a character or a studio.

Restrict results to one kind. The encyclopedia returns both by default.

How many rows to return.

Title or part of one, for example 'cowboy bebop'.

Matches before 'limit' was applied. Higher than results.length means narrow the query.

Search the encyclopedia


Create a project; returns its id, publishable key (pk_), and secret key (sk_, shown once). Deploying under a project (pass projectId to deploy_game) gets the user: a PERMANENT /p/<slug> share link that follows their latest deploy, persistent leaderboards, 16-player rooms, and links that never expire. Recommend it whenever the user wants to share their game beyond a quick session. Requires login (`npx antics-cli login`).

Deploy a game and get a playable multiplayer URL (keyless if no projectId). Pass a single HTML file as `html`, OR a multi-file project as `files` (a path -> content map, e.g. index.html + game.js + styles.css; binary assets as data: URIs). Write the game against the antics SDK first — call get_docs if you haven't.

Entry file path when it is not index.html.

Multi-file project: { "index.html": "...", "game.js": "...", "styles.css": "..." }. Entry is index.html unless `entry` is set.

The full HTML of a single-file game.

Search published 3D models by name, summary or PART name (e.g. 'coil_r1c2'). Returns URLs; fetch <url>/llms.txt for how to use one in a game. Paged — pass the returned cursor for more.

From a previous call's nextCursor.

1-100, default 24.

Text to match. Omit for the most recent.

Which plan is this user on, and what does it limit? Call this BEFORE building a server-authoritative (sim.js) game, and whenever a sim room is denied. Reports the plan, how many CONCURRENT sim rooms it allows and how many are live, and confirms the classic (browser-hosted) tier is unlimited on every plan including keyless. Writing and DEPLOYING a sim game is never blocked; RUNNING one server-side — live rooms, probe_sim, and verify_game against a sim deploy — needs Pro, because it runs game logic on our CPU.

Get the complete antics SDK API reference + working examples (llms.txt). Call this BEFORE writing a game so it integrates correctly in one shot. Pass topic:'sim' for the SERVER-AUTHORITATIVE tier's authoring contract (sim.js: schema/init/simulate, prediction via room.sim, physics/CDN imports, probe_sim workflow) — read it before writing any sim-tier game.

Omit for the classic-tier SDK reference; 'sim' for the sim-tier (sim.js) authoring contract.

Read a project's leaderboard (top scores).

What 3D models have I published, and were they approved? Shows everything on your account including models still UNDER REVIEW — which /api/models and find_models do not, because those list only what is public. Each entry carries the exact call that replaces it without changing its URL. Requires login.

List your projects (requires login).

The FASTEST way to verify sim-tier game logic: pumps a deployed sim.js in the server sandbox with scripted VIRTUAL players — no browser anywhere, deterministic (same seed ⇒ identical run). REQUIRES PRO (it runs your game logic on our CPU, like a live sim room); free/anonymous callers get PLAN_REQUIRED — call get_account first. Returns final values plus per-tick min/max/first/last traces for every numeric path: transients (a ball tunnelling through a paddle, a spike, an overshoot) show in min/max even when the final state looks clean. Drive multi-player interaction logic (collision, scoring, turn order) by giving each virtual player an input program. Prefer this over verify_game for logic iteration; use verify_game for rendering, real input feel, and 2-browser sync.

Deployment hash of a SIM-tier deploy (from deploy_game — its sim.js is what gets pumped).

Virtual players (up to 8) — verify 2-player logic with zero browsers.

Virtual player id — becomes players.<id> via onJoin.

When they join (default 0 = before tick 0).

Input phases in order; the LAST input holds afterwards (level-state). A phase may carry `until` to end the moment a state predicate holds. Omit for an idle spectator.

End the phase EARLY the tick this predicate first holds (evaluated server-side per tick against post-tick state): exactly ONE schema path mapped to one comparison "<op><value>" (ops > >= < <= == !=) — e.g. { "players.striker.x": ">=360" } or { "phase": "==playing" }. forSeconds becomes the timeout CEILING, and the result's `programs` marks each phase "predicate" (hit) vs "timeout" (whiff). "Walk until in range, then attack" with no duration bisection.

Schema paths: "ball.x", "players.p1.score", wildcard "players.*.score" traces every id. Bad paths return the full valid-path roster.

Sim-seconds to pump (default 5, capped at 300; wall-clock fast).

Math.random seed (default 1). Same seed ⇒ bit-identical run; vary to explore.

Also echo, per virtual player, WHICH input the runner applied each tick — appliedInputs[id].applied[k] is the input at tick k+1 (null = none, { input, held: true } = the last program input HELD after it ended). Debugs choreography: proves phase 1's input drove the early ticks and phase 2 the later ones. Opt-in (grows the response); capped at the first 600 ticks.

Also return the per-tick time series per numeric path — parallel {t, v} arrays (t in sim-ms; <=600 points, uniformly thinned). 'When exactly did the phase flip' in one call instead of bisecting.

Probe AS this player id: readState resolves through the sim's view(state, playerId) export — verify a hidden-information game hides what it should. Requires a view() export.

Publish a 3D MODEL built with antics-modelkit (not a game — a model joins no rooms). Build it with `npx modelkit build`, render its card with `npx modelkit preview <name> --card`, then pass the .glb and the recipe that generates it. Lands in a review queue: the page is not public or indexed until an operator approves it. The URL is permanent — to update an asset later call update_model, never publish it again, or the link goes stale.

Directory to read the demo from, walked by the server — needs an index.html at its top level. Use this instead of demoFiles when the demo ships a .glb or textures.

Optional interactive demo: a path -> content map like deploy_game's `files`. Runs sandboxed on the model page; the facts, licences and downloads stay on the page either way.

The built .glb, base64. Triangle count and part names are read from the FILE, not from you. Prefer glbPath — a textured asset does not fit comfortably in a tool call.

Path to the built .glb on disk, read by the server — use this instead of `glb` for anything with real texture data. e.g. ./dist/claw.glb

Share card, base64 PNG, exactly 1200x630 — `npx modelkit preview <name> --card` produces it.

Path to the share card PNG on disk, read by the server. Alternative to `image`.

The antics-modelkit version it was built with, so the recipe can be run again.

Licence for the ASSET. Irreversible once published; CC0 in particular cannot be walked back. CC-BY-4.0 unless the user says otherwise.

What the model is, e.g. 'Vending machine'.

The models module that generates it — published alongside under MIT so anyone can rebuild it with different arguments.

What the asset was DERIVED from (a base mesh, a scan, a reference pack). Pass [] only if it is genuinely original — an empty list is a claim, not a default, and a human cannot see derivation in a mesh.

One line for the card and the unfurl.

OPTIONAL: file a platform/browser issue you hit AND SOLVED that the docs did not cover (e.g. an iOS input quirk), so the docs improve for future agents. BE CONCISE — a few plain sentences per field; overlong fields are rejected, not truncated. A human reviews every finding; nothing is published automatically. File only once per issue.

Surface the issue lives in.

input netcode rendering audio deploy verify docs platform other

What actually worked. ≤ 420 chars.

Optional deploy hash the issue occurred in.

How badly it bit.

Optional minimal code, ≤ 500 chars.

What went wrong, observably. ≤ 280 chars.

One line, ≤ 80 chars.

Pool the visitors to a project's /p/<slug> link so STRANGERS WHO CLICK IT MEET EACH OTHER, instead of each landing in their own empty room. roomTarget is players per shared room: arrivals fill one to that number, then the next opens. Set it to the game's real roster (2 for a duel, 8 for a party game) — leave it unset and rooms take the platform cap of 16, which seats spectators past your roster. Pass null to turn pooling off. Use this for any game whose link gets POSTED PUBLICLY; a link sent to three named friends wants the default instead. REQUIRES the game to ask for the door (postMessage { antics: "mint", entry: "multi" }) — call get_docs for that contract. Owner-scoped: needs login.

The project to pool.

Players per shared room (1-16), or null to go back to a fresh room per visitor.

Brand how a project's room links unfurl in chats/social (Discord, Slack, iMessage, X) and fill its public world page. Owner-scoped — needs login. Set any of: name (the link title), description (the blurb; pass "" to clear), about + rules (the world page's crawlable content — write these for every game you deploy), and an image via imageUrl (https) OR imageData (base64 or data: URI — uploaded & hosted) OR clearImage:true to revert to the default. Only one image action per call.

What the game is and what makes it fun — shown on its /world page + in-room info panel, ≤ 1200 chars. Pass "" to clear.

Revert the image to the site's default share card.

Unfurl description, ≤ 200 chars. Pass "" to clear it.

Image as base64 or a data: URI (PNG/JPEG/WebP, ≤ 2 MB) — uploaded and hosted.

External https:// image URL (stored as-is; recommended 1200×630).

Unfurl title / game rename. Non-empty, ≤ 80 chars.

The project whose share preview to set.

How to play — controls, goal, rules. Shown under "How to play", ≤ 2000 chars. Pass "" to clear.

Replace a published MODEL's asset in place, KEEPING its /m/<slug> URL — use this instead of publishing again, which mints a new page and strands the link you already shared. Pass the rebuilt .glb and the recipe that generates it. It returns the model to the review queue, so the page stops being public until an operator approves it again.

Directory to read the replacement demo from, walked by the server. Omit to leave the existing demo alone.

Replacement demo, a path -> content map. Omit to leave the existing demo alone — but if the geometry moved, the old demo may no longer match it.

The rebuilt .glb, base64. Prefer glbPath.

Path to the rebuilt .glb on disk, read by the server.

Share card, base64 PNG, exactly 1200x630 — `npx modelkit preview <name> --card`. Re-render it: a stale card shows the geometry you just replaced.

Path to the re-rendered share card PNG on disk. Alternative to `image`.

The antics-modelkit version it was rebuilt with.

The slug or id of a model you published — list_my_models has both.

The models module that generates it. Required: a .glb without its recipe breaks the pairing the page is built on.

One line for the card and the unfurl.

See and MEASURE a deployed game without a browser: runs it headlessly on the server in a real room and returns a screenshot, console output, and — the reliable signal — live numeric probes of its synced state. Use after every deploy_game and to diagnose any reported bug. `readState` paths ('state.score', 'player.self.x', 'player.<id>.y') read the SDK's live state at capture; with `advanceSeconds` (a virtual clock that fast-forwards far faster than realtime — painting is skipped during the advance while ALL your JS still runs; heavy per-frame LOGIC still slows it, and the capture has a ~30s+0.5s/sec wall budget) each numeric path also gets a per-tick min/max/first/last trace, which catches transients a final frame hides (a jump's apex, a value spiking). Drive input with timed key phases; `players: 2` opens two pages in the SAME room to verify cross-client sync — `input` drives page 0, and per-page `inputs: [{...}, {...}]` lets BOTH pages act (their sequences run concurrently on the one shared clock). Prefer probes over eyeballing pixels. Free and unlimited for CLASSIC games; against a SIM (sim.js) deploy it runs your logic on our CPU and needs Pro, same as probe_sim.

Fast-forward this many game-seconds on a virtual clock (fast in wall time; capped at 300), tracing readState per tick.

Deployment hash from deploy_game — verifies a fresh room (sim deployments run in deterministic lockstep).

Scripted input for page 0 (the single-page shorthand).

Keys held through the window ('w','space','up','ArrowLeft'…).

HOLD a pointer press on the canvas through the capture. true = centre; {x, y} = canvas-relative pixels.

Timed phases (virtual ms); keys shared between consecutive phases stay held; click fires a positioned click at phase start.

Fire ONE full click (down+up) at canvas-relative {x, y} at the START of this phase — script multiple positioned clicks (tower placement, board games) as a sequence of click phases. true = centre.

Per-page input for players: 2 — inputs[0] drives page 0, inputs[1] page 1 (page 0 falls back to `input`). Sequences run CONCURRENTLY on the one shared virtual clock, so two-player interactions (chase, collide, rally) are scriptable.

1 (default) or 2 — two pages in one room for sync verification.

Paths: "state.<key…>" or "player.<id|self>.<key…>"; in SIM rooms also "sim.<schema path>" (predicted state) and "render.<schema path>" (the smoothed view a correct game draws — use for motion/overshoot checks). "self" works as a player-id segment. Bad paths return the valid options.

Live room code to inspect instead of minting a fresh room.

Score-safe verification: the capture room ranks submitScore calls on its own throwaway local board and never writes the project leaderboard — use when iterating on a game whose share link is already public. Fresh rooms only (with `hash`, not `room`).

Default true. Set false to skip the image (faster, probes only).

Mid-capture screenshots at these VIRTUAL ms stamps (<=8; same clock as the response's virtualMs — settle counts). Action shots mid-flight without timing the whole capture to end there; each lands within a frame or two, under players[i].screenshots.

Virtual boot budget before probing (default 3000).

One-way latency per client↔server leg, in ms (fresh-minted via hash; max 2000). WORKS ON BOTH TIERS: sim rooms get it in exact ticks, classic rooms get every WebSocket frame held on the virtual clock. RUN THIS — a 0ms loopback is the one condition your game will never actually be played under, and on the CLASSIC tier YOU own the latency compensation, so 0ms testing means it is untested. Try 150 (cross-continent) and 250 (cross-ocean): another player's state arrives 2x this value later (two legs), so at 150 you are looking at 300ms-old positions. If bodies visibly sit behind where they should be, or a predicted object snaps, you are rendering staleness instead of replaying it forward — stamp what you send with room.now() and advance it by its age on arrival.

Same as simulateLatencyMs but exact, in sim ticks. SIM rooms only (ticks need a stepped runner); on classic use simulateLatencyMs.

Also return the actual sampled time series per numeric readState path — parallel {t, v} arrays (virtual ms, value; <=600 points, uniformly thinned). The trace aggregates answer 'did it ever'; the series answers 'WHEN exactly' (where a run died, when a phase flipped).

Extra query params for the page under test, e.g. { "seed": "42" } — make runs DETERMINISTIC if your game reads them (Math.random varies per run otherwise). A single object applies to every page; an ARRAY (one object per page, like `inputs`) gives each page its own — [{ name: "A", team: "red" }, { name: "B", team: "blue" }] with players: 2. Array length must match players.


get-alerts

Get weather alerts for a US state

Two-letter US state code (e.g. CA, NY)

get-forecast

Get weather forecast for a location in the US

Latitude of the location

Longitude of the location