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

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

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

This endpoint creates a new Tag in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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 endpoint.

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 endpoint.

This endpoint creates a new Config in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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 endpoint.

This endpoint creates a new Environment in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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 endpoint.

This endpoint creates a new Permission Group in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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 endpoint.

This endpoint creates a new Integration in a specified Product identified by the productId parameter, which can be obtained from the 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 where the integration should post messages.

  • includeSensitiveData: Set to "true" to include sensitive (hashed) comparison values. 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)

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 endpoint.

This endpoint creates a new Segment in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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

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.

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.

If neither fromUtcDateTime nor toUtcDateTime is set, the audit logs for the last 7 days will be returned.

The distance between fromUtcDateTime and toUtcDateTime cannot exceed 30 days.

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

Get References for Feature Flag or Setting

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

This endpoint updates a Config identified by the configId parameter.

This endpoint removes a Config identified by the configId parameter.

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

This endpoint updates an Environment identified by the environmentId parameter.

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).

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

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

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

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

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 where the integration should post messages.

  • includeSensitiveData: Set to "true" to include sensitive (hashed) comparison values. 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)

This endpoint removes a Integration identified by the integrationId parameter.

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

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.

If neither fromUtcDateTime nor toUtcDateTime is set, the audit logs for the last 7 days will be returned.

The distance between fromUtcDateTime and toUtcDateTime cannot exceed 30 days.

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.

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

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

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

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.

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

This endpoint updates a Product identified by the productId parameter.

This endpoint removes a Product identified by the productId parameter.

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

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

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

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

This endpoint updates a Segment identified by the segmentId parameter.

This endpoint removes a Segment identified by the segmentId parameter.

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

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.

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

This endpoint updates the metadata of a Feature Flag or Setting with a collection of JSON Patch 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 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.

{
  "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):

[
  {
    "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:

{
  "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"
    }
  ]
}

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

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.

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.

{
  "rolloutPercentageItems": [
    {
      "percentage": 30,
      "value": true
    },
    {
      "percentage": 70,
      "value": false
    }
  ],
  "rolloutRules": [],
  "value": false
}

If we send a replace request body as below:

{
  "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:

{
  "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.

This endpoint updates the value of a Feature Flag or Setting with a collection of JSON Patch 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.

{
  "rolloutPercentageItems": [
    {
      "percentage": 30,
      "value": true
    },
    {
      "percentage": 70,
      "value": false
    }
  ],
  "rolloutRules": [],
  "value": false
}

If we send an update request body as below:

[
  {
    "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:

{
  "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.

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.

The percentageEvaluationAttribute represents the custom User Object attribute that must be used for percentage evaluation of the Feature Flag or 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.

{
  "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:

{
  "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:

{
  "defaultValue": {
    "boolValue": true
  },
  "targetingRules": []
}

This endpoint updates the value of a Feature Flag or Setting with a collection of JSON Patch 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.

{
  "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:

[
  {
    "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:

{
  "defaultValue": {
    "boolValue": false
  },
  "targetingRules": [
    {
      "conditions": [
        {
          "userCondition": {
            "comparisonAttribute": "Email",
            "comparator": "sensitiveTextEquals",
            "comparisonValue": {
              "stringValue": "test@example.com"
            }
          }
        }
      ],
      "percentageOptions": [],
      "value": {
        "boolValue": false
      }
    }
  ]
}

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.

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.

{
  "settingValues": [
    {
      "rolloutPercentageItems": [
        {
          "percentage": 30,
          "value": true
        },
        {
          "percentage": 70,
          "value": false
        }
      ],
      "rolloutRules": [],
      "value": false,
      "settingId": 1
    }
  ]
}

If we send a replace request body as below:

{ 
  "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:

{
  "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.

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.

The percentageEvaluationAttribute represents the custom User Object attribute that must be used for percentage evaluation of the Feature Flag or Setting.

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.

{
  "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:

{ 
  "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:

{
  "settingFormulas": [
    {
      "defaultValue": {
        "boolValue": false
      },
      "targetingRules": [],
      "setting": 
      {
        "settingId": 1
      }
    }
  ]
}

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

This endpoint updates a Tag identified by the tagId parameter.

This endpoint deletes a Tag identified by the tagId parameter. To remove a Tag from a Feature Flag or Setting use the Update Flag endpoint.

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

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.

This endpoint removes a Webhook identified by the webhookId parameter.

This endpoint updates a Webhook identified by the webhookId parameter with a collection of JSON Patch 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.

{
  "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):

[
  {
    "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:

{
  "webhookId": 6,
  "url": "https://example.com/hook",
  "httpMethod": "post", 
  "content": "Some webhook content.", 
  "webHookHeaders": [
    {
      "key": "X-Custom-Header", 
      "value": "Custom header value", 
      "isSecure": false
    }
  ]
}

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.

This endpoint creates a new Product in a specified Organization identified by the organizationId parameter, which can be obtained from the List Organizations endpoint.

This endpoint creates a new Webhook in a specified Product identified by the productId parameter, which can be obtained from the List Products endpoint.

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

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.

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

This endpoint removes an Invitation identified by the invitationId parameter.

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

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: 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: ConfigCat package for Laravel. Implement feature flags within your PHP Laravel application using ConfigCat.

• ConfigCat SDK for Vue.js: Unofficial Vue SDK for ConfigCat Feature Flags. Based on ConfigCat's JavaScript SDK.

• C++ SDK Reference: 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: 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: ConfigCat .NET SDK Reference. This is a step-by-step guide on how to use feature flags in your .NET application.

• Elixir SDK Reference: ConfigCat Elixir SDK Reference. This is a step-by-step guide on how to use feature flags in your Elixir project.

• Go SDK Reference: 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: 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: ConfigCat Java SDK Reference. This is a step-by-step guide on how to use feature flags in your Java application.

• Legacy JavaScript SDK Reference: ConfigCat Legacy JavaScript SDK Reference. This is a step-by-step guide on how to use feature flags in your JavaScript applications.

• Browser (JavaScript) SDK: 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: ConfigCat Bun SDK Reference. This is a step-by-step guide on how to use feature flags in your Bun applications.

• Chromium Extension SDK: 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: ConfigCat Cloudflare Worker SDK Reference. This is a step-by-step guide on how to use feature flags in your Cloudflare Workers.

• Deno SDK: ConfigCat Deno SDK Reference. This is a step-by-step guide on how to use feature flags in your Deno applications.

• Node.js SDK: 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: ConfigCat SDK for JavaScript Reference. This is a step-by-step guide on how to use feature flags in your JavaScript applications.

• Legacy JavaScript (SSR) SDK Reference: ConfigCat Legacy JavaScript (SSR) SDK Reference. This is a step-by-step guide on how to use feature flags in your Server-Side-Rendered (SSR) JavaScript application.

• Kotlin Multiplatform SDK Reference: ConfigCat Kotlin Multiplatform SDK Reference. This is a step-by-step guide on how to use feature flags in your Kotlin Multiplatform apps.

• Legacy Node.js SDK Reference: ConfigCat Legacy Node.js SDK Reference. This is a step-by-step guide on how to use feature flags in your Node.js applications.

• OpenFeature Providers: 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: This is a step-by-step guide on how to use ConfigCat with the OpenFeature Angular SDK.

• OpenFeature Provider for .NET: 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: 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: 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: 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: 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: This is a step-by-step guide on how to use ConfigCat with the OpenFeature NestJS SDK.

• OpenFeature Provider for Node.js: 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: 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: 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: This is a step-by-step guide on how to use ConfigCat with the OpenFeature React SDK.

• OpenFeature Provider for Ruby: 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: 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: 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: 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: ConfigCat PHP SDK Reference. This is a step-by-step guide on how to use feature flags in your PHP application.

• Python SDK Reference: ConfigCat Python SDK Reference. This is a step-by-step guide on how to use feature flags in your Python application.

• React SDK Reference: ConfigCat React SDK Reference. This is a step-by-step guide on how to use feature flags in your React applications.

• Ruby SDK Reference: ConfigCat Ruby SDK Reference. This is a step-by-step guide on how to use feature flags in your Ruby application.

• Rust SDK Reference: 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: 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: ConfigCat Unreal Engine SDK Reference. This is a step-by-step guide on how to use feature flags in your Unreal Engine project.