# ConfigCat Docs > Learn more on how to use ConfigCat Feature Flags. ## HomePage Documentation for ConfigCat Feature Flags. ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag. - [ConfigCat Docs](https://configcat.com/docs/index.md): Documentation for ConfigCat Feature Flags. ConfigCat is a developer-centric feature flag service with unlimited team size, awesome support, and a reasonable price tag. ### Getting Started This is a step-by-step guide on how to get started with ConfigCat feature flags and on how to implement feature flags in an application. - [Getting Started](https://configcat.com/docs/getting-started.md): This is a step-by-step guide on how to get started with ConfigCat feature flags and on how to implement feature flags in an application. ### Main Concepts This page explains the basics of feature flags and how to use them. Displays how configs, products and settings are organized within the feature flag service. - [Main Concepts](https://configcat.com/docs/main-concepts.md): This page explains the basics of feature flags and how to use them. Displays how configs, products and settings are organized within the feature flag service. ### Targeting - [Feature Flag Evaluation](https://configcat.com/docs/targeting/feature-flag-evaluation.md): This document offers an in-depth explanation of how the ConfigCat SDK determines the value of a feature flag. - [Percentage Options](https://configcat.com/docs/targeting/percentage-options.md): Using Percentage Options, you can define that a certain percentage of users should receive a specific value for a feature flag or setting. This way, you can gradually release a new feature to a subset of users. - [Targeting Overview](https://configcat.com/docs/targeting/targeting-overview.md): Overview of the ConfigCat targeting feature with examples. - [Flag Condition (Prerequisite)](https://configcat.com/docs/targeting/targeting-rule/flag-condition.md): A Flag Condition is a condition that is based on the comparison of another feature flag's value and a preset value (comparison value). - [Segment Condition](https://configcat.com/docs/targeting/targeting-rule/segment-condition.md): Segments allow you to define user groups based on any user attributes. Ideal for beta testing on a certain group of users. - [Targeting Rule](https://configcat.com/docs/targeting/targeting-rule/targeting-rule-overview.md): Targeting Rules allow you to set different feature flag or setting values for specific users or groups of users in your application. - [User Condition](https://configcat.com/docs/targeting/targeting-rule/user-condition.md): A User Condition is a condition that is based on the comparison of a user attribute and a preset value (comparison value). It allows you to define Targeting Rules which target users based on their properties. - [User Object](https://configcat.com/docs/targeting/user-object.md): The User Object is a collection of *user attributes* that describe the properties of a user. The User Object is essential for targeting. ### What is a JSON download? Learn how the usage & quota works, how the number of config JSON downloads is counted and how to lower your monthly usage. - [What is a config JSON download?](https://configcat.com/docs/requests.md): Learn how the usage & quota works, how the number of config JSON downloads is counted and how to lower your monthly usage. ### Network Traffic Network Traffic refers to the data transmitted between your applications and ConfigCat servers. - [Network Traffic](https://configcat.com/docs/network-traffic.md): Network Traffic refers to the data transmitted between your applications and ConfigCat servers. ### Service Status & Monitoring - [Service Status & Monitoring](https://configcat.com/docs/service/status.md): To check the current health and status of the service visit//status.configcat.com. ### Plans, Purchase & Billing This page explains how to purchase ConfigCat plans, how to manage your billing information and how to pay your bill. - [Plans, Purchase & Billing](https://configcat.com/docs/purchase.md): This page explains how to purchase ConfigCat plans, how to manage your billing information and how to pay your bill. ### Subscription Plan Limits This page lists the limits of the different ConfigCat subscription plans. - [Subscription Plan Limits](https://configcat.com/docs/subscription-plan-limits.md): This page lists the limits of the different ConfigCat subscription plans. ### Organization & Roles You can invite an unlimited number of people to your organization in ConfigCat. Learn how to manage your organization and its roles. - [Organization & Roles](https://configcat.com/docs/organization.md): You can invite an unlimited number of people to your organization in ConfigCat. Learn how to manage your organization and its roles. ### News & Product Updates Instead of spamming your mailbox, we're posting news and product updates here. - [News & Product Updates](https://configcat.com/docs/news.md): Instead of spamming your mailbox, we're posting news and product updates here. ### FAQ This is a collection of frequently asked questions and the most typical answers from the ConfigCat Support Team. - [FAQ - Frequently Asked Questions](https://configcat.com/docs/faq.md): This is a collection of frequently asked questions and the most typical answers from the ConfigCat Support Team. ### Glossary A alphabetical list of terms used around feature management in the context of ConfigCat. - [Glossary of Terms](https://configcat.com/docs/glossary.md): A alphabetical list of terms used around feature management in the context of ConfigCat. - [Alpha Testing - The Unsung Hero of Product Development](https://configcat.com/docs/glossary/alpha-testing.md): Let's delve into the nuances of alpha testing and understand its significance in the product development lifecycle. - [Beta Testing - Navigating the Road to Market Readiness](https://configcat.com/docs/glossary/beta-testing.md): Explore the pivotal role of beta testing in software development and understand how it shapes software for better user experiences and market success. - [Blue/Green Deployment - Streamlining Software Releases](https://configcat.com/docs/glossary/blue-green-deployment.md): Discover the essence of Blue/Green Deployment and its pivotal role in seamless software updates and rollbacks. - [CI/CD Pipeline - Streamlining Software Delivery](https://configcat.com/docs/glossary/ci-cd-pipeline.md): Dive into the world of CI/CD pipelines and discover how they revolutionize the software development and deployment process. - [Continuous Integration - The Backbone of Modern Software Development](https://configcat.com/docs/glossary/continuous-integration.md): Dive into the world of Continuous Integration and discover how it revolutionizes the way code is built and tested in the software development process. - [DevOps Engineer - The Backbone of Efficient Software Deployment](https://configcat.com/docs/glossary/devops-engineer.md): Discover the pivotal role of a DevOps Engineer in harmonizing software development, deployment, and maintenance for optimal performance and agility. - [Feature Testing - Tailoring the Ultimate User Experience](https://configcat.com/docs/glossary/feature-testing.md): Explore feature testing, where each version of a feature is thoroughly tested to ensure it delivers the optimal user experience. - [Multi-Armed Bandit - Optimizing Decisions in Real-Time](https://configcat.com/docs/glossary/multi-armed-bandit.md): Uncover the strategies behind Multi-Armed Bandit algorithms and how they can drive decision-making processes in complex environments. - [Product Lifecycle Manager – Steering Projects to Success](https://configcat.com/docs/glossary/product-lifecycle-manager.md): Learn how a Product Lifecycle Manager orchestrates the journey of a project from inception to completion, ensuring every phase meets its milestones. - [Release Manager – Orchestrating Successful Software Deployments](https://configcat.com/docs/glossary/release-manager.md): Discover the pivotal role of a Release Manager in steering the complex software release process towards a seamless and high-quality delivery. - [Remote Configuration - Agile Adjustments at Your Fingertips](https://configcat.com/docs/glossary/remote-configuration.md): Uncover how remote configuration empowers teams to tweak app features swiftly and securely without the need for new deployments. - [Smoke Testing - Ensuring the Core of Your Software Stands Strong](https://configcat.com/docs/glossary/smoke-testing.md): Unveil the essentials of smoke testing and its vital role in maintaining the integrity of your application's core functionality. - [Navigating Type I & Type II Errors in Software Testing](https://configcat.com/docs/glossary/type-i-and-type-ii-errors.md): Understand the implications of Type I and Type II errors in software testing and their importance in delivering reliable applications. - [Version Control - The Backbone of Successful Software Development](https://configcat.com/docs/glossary/version-control.md): Uncover the critical role of version control in managing and safeguarding your codebase throughout the development lifecycle. - [What Is a Staging Environment?](https://configcat.com/docs/glossary/what-is-a-staging-environment.md): Understanding Staging Environments for Testing Code, Catching Bugs, and Scaling ### Advanced Guides - [Polling modes & Caching](https://configcat.com/docs/advanced/caching.md): This section describes how to use the SDK's caching feature. There are three different polling modes available in the ConfigCat SDKs. - [Command Line Interface (CLI)](https://configcat.com/docs/advanced/cli.md): The ConfigCat Command Line Interface (CLI) connect and match feature flags in your source code with feature flags on the Dashboard. - [Azure DevOps - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/azure-devops.md): This section describes how to use the ConfigCat CLI in Azure DevOps Pipelines - [Bitbucket Pipe - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/bitbucket-pipe.md): This section describes how to use ConfigCat's Bitbucket Pipe - [Bitrise - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/bitrise-step.md): This section describes how to use ConfigCat's Bitrise Step - [CircleCI Orb - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/circleci-orb.md): This section describes how to use ConfigCat's CircleCI Orb - [GitHub Action - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/github-action.md): This section describes how to use ConfigCat's GitHub Action - [GitLab - Scan your source code for feature flags](https://configcat.com/docs/advanced/code-references/gitlab-ci.md): This section describes how to use the ConfigCat CLI in GitLab CI/CD - [CLI - Add to CI/CD pipelines manually](https://configcat.com/docs/advanced/code-references/manual.md): This section describes how to use the ConfigCat CLI - [Scan & Upload Code References Overview](https://configcat.com/docs/advanced/code-references/overview.md): You can integrate the CLI into your CI/CD pipeline or use it with other execution mechanisms like scheduled jobs or VCS push triggered workflows. - [Config V2 Migration Guide](https://configcat.com/docs/advanced/config-v2-migration-guide.md): A detailed guide on how to migrate from Config V1 to Config V2. - [Config V2 SDK Compatibility](https://configcat.com/docs/advanced/config-v2-sdk-compatibility.md): This table shows which SDK versions support Config V2. - [Config V2 Overview](https://configcat.com/docs/advanced/config-v2.md): Config V2 is the next generation of ConfigCat. It comes with a new Dashboard, Public Management API, SDKs and features. - [Data Governance - CDN](https://configcat.com/docs/advanced/data-governance.md): ConfigCat customers can control the geographic location where their data will be published to. Helps to stay compliant with GDPR and other data protection regulations. - [Details of LaunchDarkly to ConfigCat Translation](https://configcat.com/docs/advanced/migration-from-launchdarkly-translation.md): Details of the LaunchDarkly to ConfigCat translation performed by the "Import from LaunchDarkly" tool. - [Migration from LaunchDarkly](https://configcat.com/docs/advanced/migration-from-launchdarkly.md): A guide to migration from LaunchDarkly to ConfigCat. - [Notifications - Webhooks](https://configcat.com/docs/advanced/notifications-webhooks.md): Webhooks are a way to send notifications to your applications about feature flag value changes so you can react to changes quickly. - [Endpoints](https://configcat.com/docs/advanced/proxy/endpoints.md): HTTP endpoints of the ConfigCat Proxy. - [gRPC](https://configcat.com/docs/advanced/proxy/grpc.md): gRPC related functionalities of the ConfigCat Proxy. - [Monitoring](https://configcat.com/docs/advanced/proxy/monitoring.md): Monitoring options of the ConfigCat Proxy. - [ConfigCat Proxy](https://configcat.com/docs/advanced/proxy/proxy-overview.md): The ConfigCat Proxy allows you to host a feature flag evaluation service in your own infrastructure. - [Auto-assign Users](https://configcat.com/docs/advanced/team-management/auto-assign-users.md): New users will be automatically added to your organization if you have a verified domain. Here is how to set it up. - [Domain Verification](https://configcat.com/docs/advanced/team-management/domain-verification.md): In order to use the SAML feature in ConfigCat, you need to verify your domain. Here is a step-by-step guide on how to do that. - [ADFS Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/adfs.md): This is a step-by-step guide on how to set up and configure ADFS as a SAML Identity Provider for your organization. - [Auth0 Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/auth0.md): This is a step-by-step guide on how to set up and configure Auth0 as a SAML Identity Provider for your organization. - [Entra ID (Azure AD) Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/azure-ad.md): This is a step-by-step guide on how to set up and configure Entra ID (Azure AD) as a SAML Identity Provider for your organization. - [Cloudflare Zero Trust](https://configcat.com/docs/advanced/team-management/saml/identity-providers/cloudflare.md): This is a step-by-step guide on how to set up and configure Cloudflare Zero Trust as a SAML Identity Provider for your organization. - [Google Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/google.md): This is a step-by-step guide on how to set up and configure Google as a SAML Identity Provider for your organization. - [Okta Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/okta.md): This is a step-by-step guide on how to set up and configure Okta as a SAML Identity Provider for your organization. - [OneLogin Identity Provider](https://configcat.com/docs/advanced/team-management/saml/identity-providers/onelogin.md): This is a step-by-step guide on how to set up and configure OneLogin as a SAML Identity Provider for your organization. - [SAML SSO Overview](https://configcat.com/docs/advanced/team-management/saml/saml-overview.md): This section is a step-by-step guide on how you can enable SAML Single Sign-On (SSO) for your organization in ConfigCat. - [(Beta) User Provisioning (SCIM) with Entra ID (Azure AD)](https://configcat.com/docs/advanced/team-management/scim/identity-providers/entra-id.md): This is a step-by-step guide on how to set up and configure Entra ID (Azure AD) as a User provisioning (SCIM) provider for your organization. - [(Beta) User Provisioning (SCIM) with Okta](https://configcat.com/docs/advanced/team-management/scim/identity-providers/okta.md): This is a step-by-step guide on how to set up and configure Okta as a User provisioning (SCIM) provider for your organization. - [(Beta) User Provisioning (SCIM) with Onelogin](https://configcat.com/docs/advanced/team-management/scim/identity-providers/onelogin.md): This is a step-by-step guide on how to set up and configure Onelogin as a User provisioning (SCIM) provider for your organization. - [(Beta) User provisioning (SCIM) Overview](https://configcat.com/docs/advanced/team-management/scim/scim-overview.md): This section is a step-by-step guide on how to configure User provisioning (SCIM) for your Organization in ConfigCat. - [SSO (Single Sign-On)](https://configcat.com/docs/advanced/team-management/single-sign-on-sso.md): Let you organization members sign in to ConfigCat using 3rd party SSO (Single Sign-On) providers. - [Team Management Basics](https://configcat.com/docs/advanced/team-management/team-management-basics.md): ConfigCat provides an unlimited number of team members for every subscription plan, even the free one. Here is how to manage your team. - [Troubleshooting](https://configcat.com/docs/advanced/troubleshooting.md): This section helps you troubleshoot your issues. It's a good idea to double check these before contacting support. ### Zombie Flags This page explains how to identify and manage Zombie Flags in ConfigCat through the dashboard, email reports, or the Zombie Flags API. - [Zombie Flags](https://configcat.com/docs/zombie-flags.md): This page explains how to identify and manage Zombie Flags in ConfigCat through the dashboard, email reports, or the Zombie Flags API. ### 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. - [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. - [Legacy JavaScript (SSR) SDK Reference](https://configcat.com/docs/sdk-reference/js-ssr.md): 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. - [Legacy JavaScript SDK Reference](https://configcat.com/docs/sdk-reference/js.md): 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](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. - [Legacy Node.js SDK Reference](https://configcat.com/docs/sdk-reference/node.md): ConfigCat Legacy Node.js SDK Reference. This is a step-by-step guide on how to use feature flags in your Node.js applications. - [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 Providers](https://configcat.com/docs/sdk-reference/openfeature/overview.md): List of all supported OpenFeature Providers. - [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. ### Integrations - [Amplitude - Add feature flag changes to your charts](https://configcat.com/docs/integrations/amplitude.md): ConfigCat Amplitude integration reference. This is a step-by-step guide on how to use feature flags in your Amplitude project. - [Bitbucket - Scan your code for feature flag usages](https://configcat.com/docs/integrations/bitbucket.md): ConfigCat Bitbucket Pipe integration. This is a step-by-step guide on how to use the ConfigCat Bitbucket integration to eliminate tech debt in your project. - [Bitrise - Scan your code for feature flag usages](https://configcat.com/docs/integrations/bitrise.md): ConfigCat Bitrise Step integration. This is a step-by-step guide on how to use the ConfigCat Bitrise integration to eliminate tech debt in your project. - [CircleCI - Scan your code for feature flag usages](https://configcat.com/docs/integrations/circleci.md): ConfigCat CircleCI Orb. This is a step-by-step guide on how to use the ConfigCat CircleCI Orb to eliminate tech debt in your project. - [Datadog - Monitor your feature flags events](https://configcat.com/docs/integrations/datadog.md): ConfigCat Datadog integration. This is a step-by-step guide on how to connect the ConfigCat feature flag service events to Datadog. - [GitHub Action - Scan your code for feature flag usages](https://configcat.com/docs/integrations/github.md): ConfigCat GitHub Action. This is a step-by-step guide on how to use the ConfigCat GitHub Action to eliminate tech debt in your project. - [Google Analytics - Send feature flag analytics to Google Analytics](https://configcat.com/docs/integrations/google-analytics.md): ConfigCat Google Analytics integration. This is a step-by-step guide on how to send feature flag analytics events to Google Analytics. - [JetBrains/IntelliJ Plugin - Manage your feature flags from JetBrains/IntelliJ IDEs](https://configcat.com/docs/integrations/intellij.md): ConfigCat IntelliJ IDE Plugin. This is a step-by-step guide on how to use the ConfigCat JetBrains/IntelliJ Plugin to manage feature flags in your IDEs. - [Jira Cloud Plugin - Manage feature flags from Jira](https://configcat.com/docs/integrations/jira.md): ConfigCat Jira Cloud Plugin. This is a step-by-step guide on how to connect and manage feature flags from Jira Cloud boards. - [Mixpanel - Monitor your feature flag change events and feature flag analytics](https://configcat.com/docs/integrations/mixpanel.md): ConfigCat Mixpanel integration. This is a step-by-step guide on how to connect the ConfigCat feature flag service events to Mixpanel. - [monday.com - Manage feature flags from monday](https://configcat.com/docs/integrations/monday.md): ConfigCat monday app. This is a step-by-step guide on how to connect and manage feature flags from monday.com boards and items. - [Integrations Overview](https://configcat.com/docs/integrations/overview.md): Overview of ConfigCat integrations with platforms like Amplitude, GitHub, Slack, and more. - [Twilio Segment - Monitor your feature flag change events and feature flag analytics](https://configcat.com/docs/integrations/segment.md): ConfigCat Twilio Segment integration. This is a step-by-step guide on how to connect the ConfigCat feature flag service events to Twilio Segment. - [Slack - Get notified when a feature flag changes](https://configcat.com/docs/integrations/slack.md): ConfigCat Feature Flags app for Slack. This is a step-by-step guide on how to connect the ConfigCat feature flag service to Slack. - [Terraform - Manage feature flags from HCL scripts](https://configcat.com/docs/integrations/terraform.md): ConfigCat Terraform provider. This is a step-by-step guide on how to manage feature flags from Terraform using the ConfigCat Terraform provider. - [Trello Power-Up - Manage feature flags from Trello](https://configcat.com/docs/integrations/trello.md): ConfigCat Trello Power-Up. This is a step-by-step guide on how to connect and manage feature flags from Trello boards and cards. - [Visual Studio Code - Manage your feature flags from VSCode](https://configcat.com/docs/integrations/vscode.md): ConfigCat Visual Studio Code extension. This is a step-by-step guide on how to use the ConfigCat Visual Studio Code extension to manage feature flags in your project. - [Zapier Zap - Build feature flag workflows](https://configcat.com/docs/integrations/zapier.md): ConfigCat Zapier integration. This is a step-by-step guide on how to use the ConfigCat Zapier integration to connect manage features from thousands of Zapier apps. - [Zoho Flow - Automate your feature flag workflows](https://configcat.com/docs/integrations/zoho-flow.md): ConfigCat Zoho Flow integration. This is a step-by-step guide on how to use the ConfigCat Zoho Flow integration to manage features using Zoho Flow apps. ### Public Management API - [Groups](https://configcat.com/docs/api/category/scim/groups.md) - [Service provider config](https://configcat.com/docs/api/category/scim/service-provider-config.md) - [Users](https://configcat.com/docs/api/category/scim/users.md) - [Update Member Permissions](https://configcat.com/docs/api/reference/add-member-to-group.md): This endpoint updates the permissions of a Member identified by the `userId`. - [Audit logs](https://configcat.com/docs/api/reference/audit-logs.md): Audit logs - [Code References](https://configcat.com/docs/api/reference/code-references.md): Code References - [ConfigCat Public Management API](https://configcat.com/docs/api/reference/configcat-public-management-api.md): The purpose of this API is to access the ConfigCat platform programmatically. - [Configs](https://configcat.com/docs/api/reference/configs.md): Configs - [Create Config](https://configcat.com/docs/api/reference/create-config.md): This endpoint creates a new Config in a specified Product - [Create Environment](https://configcat.com/docs/api/reference/create-environment.md): This endpoint creates a new Environment in a specified Product - [Create Integration](https://configcat.com/docs/api/reference/create-integration.md): This endpoint creates a new Integration in a specified Product - [Create Permission Group](https://configcat.com/docs/api/reference/create-permission-group.md): This endpoint creates a new Permission Group in a specified Product - [Create Product](https://configcat.com/docs/api/reference/create-product.md): This endpoint creates a new Product in a specified Organization - [Create Segment](https://configcat.com/docs/api/reference/create-segment.md): This endpoint creates a new Segment in a specified Product - [Create Flag](https://configcat.com/docs/api/reference/create-setting.md): This endpoint creates a new Feature Flag or Setting in a specified Config - [Create Tag](https://configcat.com/docs/api/reference/create-tag.md): This endpoint creates a new Tag in a specified Product - [Create Webhook](https://configcat.com/docs/api/reference/create-webhook.md): This endpoint creates a new Webhook in a specified Product - [Delete Config](https://configcat.com/docs/api/reference/delete-config.md): This endpoint removes a Config identified by the `configId` parameter. - [Delete Environment](https://configcat.com/docs/api/reference/delete-environment.md): This endpoint removes an Environment identified by the `environmentId` parameter. - [Delete Integration](https://configcat.com/docs/api/reference/delete-integration.md): This endpoint removes a Integration identified by the `integrationId` parameter. - [Delete Invitation](https://configcat.com/docs/api/reference/delete-invitation.md): This endpoint removes an Invitation identified by the `invitationId` parameter. - [Delete Member from Organization](https://configcat.com/docs/api/reference/delete-organization-member.md): This endpoint removes a Member identified by the `userId` from the - [Delete Permission Group](https://configcat.com/docs/api/reference/delete-permission-group.md): This endpoint removes a Permission Group identified by the `permissionGroupId` parameter. - [Delete Member from Product](https://configcat.com/docs/api/reference/delete-product-member.md): This endpoint removes a Member identified by the `userId` from the - [Delete Product](https://configcat.com/docs/api/reference/delete-product.md): This endpoint removes a Product identified by the `productId` parameter. - [Delete Reference reports](https://configcat.com/docs/api/reference/delete-reference-reports.md) - [Delete Segment](https://configcat.com/docs/api/reference/delete-segment.md): This endpoint removes a Segment identified by the `segmentId` parameter. - [Delete Flag](https://configcat.com/docs/api/reference/delete-setting.md): This endpoint removes a Feature Flag or Setting from a specified Config, - [Delete Tag](https://configcat.com/docs/api/reference/delete-tag.md): This endpoint deletes a Tag identified by the `tagId` parameter. To remove a Tag from a Feature Flag or Setting use the [Update Flag](/docs/api/reference/update-setting) endpoint. - [Delete Webhook](https://configcat.com/docs/api/reference/delete-webhook.md): This endpoint removes a Webhook identified by the `webhookId` parameter. - [Environments](https://configcat.com/docs/api/reference/environments.md): Environments - [Feature Flag & Setting values using SDK Key V2](https://configcat.com/docs/api/reference/feature-flag-setting-values-using-sdk-key-v-2.md): Feature Flag & Setting values using SDK Key V2 - [Feature Flag & Setting values using SDK Key](https://configcat.com/docs/api/reference/feature-flag-setting-values-using-sdk-key.md): Feature Flag & Setting values using SDK Key - [Feature Flag & Setting values V2](https://configcat.com/docs/api/reference/feature-flag-setting-values-v-2.md): Feature Flag & Setting values V2 - [Feature Flag & Setting values](https://configcat.com/docs/api/reference/feature-flag-setting-values.md): Feature Flag & Setting values - [Feature Flags & Settings](https://configcat.com/docs/api/reference/feature-flags-settings.md): Feature Flags & Settings - [List Audit log items for Product](https://configcat.com/docs/api/reference/get-auditlogs.md): This endpoint returns the list of Audit log items for a given Product - [Get Config](https://configcat.com/docs/api/reference/get-config.md): This endpoint returns the metadata of a Config - [List Configs](https://configcat.com/docs/api/reference/get-configs.md): This endpoint returns the list of the Configs that belongs to the given Product identified by the - [List Deleted Settings](https://configcat.com/docs/api/reference/get-deleted-settings.md): This endpoint returns the list of Feature Flags and Settings that were deleted from the given Config. - [Get Environment](https://configcat.com/docs/api/reference/get-environment.md): This endpoint returns the metadata of an Environment - [List Environments](https://configcat.com/docs/api/reference/get-environments.md): This endpoint returns the list of the Environments that belongs to the given Product identified by the - [Get Integration](https://configcat.com/docs/api/reference/get-integration.md): This endpoint returns the metadata of an Integration - [List Integrations](https://configcat.com/docs/api/reference/get-integrations.md): This endpoint returns the list of the Integrations that belongs to the given Product identified by the - [Get authenticated user details](https://configcat.com/docs/api/reference/get-me.md) - [List Audit log items for Organization](https://configcat.com/docs/api/reference/get-organization-auditlogs.md): This endpoint returns the list of Audit log items for a given Organization - [List Organization Members](https://configcat.com/docs/api/reference/get-organization-members-v-2.md): This endpoint returns the list of Members that belongs - [List Organization Members](https://configcat.com/docs/api/reference/get-organization-members.md): This endpoint returns the list of Members that belongs - [List Organizations](https://configcat.com/docs/api/reference/get-organizations.md): This endpoint returns the list of the Organizations that belongs to the user. - [List Pending Invitations in Organization](https://configcat.com/docs/api/reference/get-pending-invitations-org.md): This endpoint returns the list of pending invitations within the - [List Pending Invitations in Product](https://configcat.com/docs/api/reference/get-pending-invitations.md): This endpoint returns the list of pending invitations within the - [Get Permission Group](https://configcat.com/docs/api/reference/get-permission-group.md): This endpoint returns the metadata of a Permission Group - [List Permission Groups](https://configcat.com/docs/api/reference/get-permission-groups.md): This endpoint returns the list of the Permission Groups that belongs to the given Product identified by the - [List Product Members](https://configcat.com/docs/api/reference/get-product-members.md): This endpoint returns the list of Members that belongs - [Get Product Preferences](https://configcat.com/docs/api/reference/get-product-preferences.md): This endpoint returns the preferences of a Product - [Get Product](https://configcat.com/docs/api/reference/get-product.md): This endpoint returns the metadata of a Product - [List Products](https://configcat.com/docs/api/reference/get-products.md): This endpoint returns the list of the Products that belongs to the user. - [Get References for Feature Flag or Setting](https://configcat.com/docs/api/reference/get-references-for-feature-flag-or-setting.md) - [Get SDK Key](https://configcat.com/docs/api/reference/get-sdk-keys.md): This endpoint returns the SDK Key for your Config in a specified Environment. - [Get Segment](https://configcat.com/docs/api/reference/get-segment.md): This endpoint returns the metadata of a Segment - [List Segments](https://configcat.com/docs/api/reference/get-segments.md): This endpoint returns the list of the Segments that belongs to the given Product identified by the - [Get value](https://configcat.com/docs/api/reference/get-setting-value-by-sdkkey-v-2.md): This endpoint returns the value of a Feature Flag or Setting - [Get value](https://configcat.com/docs/api/reference/get-setting-value-by-sdkkey.md): This endpoint returns the value of a Feature Flag or Setting - [Get value](https://configcat.com/docs/api/reference/get-setting-value-v-2.md): This endpoint returns the value of a Feature Flag or Setting - [Get value](https://configcat.com/docs/api/reference/get-setting-value.md): This endpoint returns the value of a Feature Flag or Setting - [Get values](https://configcat.com/docs/api/reference/get-setting-values-v-2.md): This endpoint returns all Feature Flag and Setting values of a Config identified by the `configId` parameter - [Get values](https://configcat.com/docs/api/reference/get-setting-values.md): This endpoint returns the value of a specified Config's Feature Flags or Settings identified by the `configId` parameter - [Get Flag](https://configcat.com/docs/api/reference/get-setting.md): This endpoint returns the metadata attributes of a Feature Flag or Setting - [List Settings by Tag](https://configcat.com/docs/api/reference/get-settings-by-tag.md): This endpoint returns the list of the Settings that - [List Flags](https://configcat.com/docs/api/reference/get-settings.md): This endpoint returns the list of the Feature Flags and Settings defined in a - [List Zombie (stale) flags for Product](https://configcat.com/docs/api/reference/get-staleflags.md): This endpoint returns the list of Zombie (stale) flags for a given Product - [Get Tag](https://configcat.com/docs/api/reference/get-tag.md): This endpoint returns the metadata of a Tag - [List Tags](https://configcat.com/docs/api/reference/get-tags.md): This endpoint returns the list of the Tags in a - [Get Webhook Signing Keys](https://configcat.com/docs/api/reference/get-webhook-signing-keys.md): This endpoint returns the signing keys of a Webhook - [Get Webhook](https://configcat.com/docs/api/reference/get-webhook.md): This endpoint returns the metadata of a Webhook - [List Webhooks](https://configcat.com/docs/api/reference/get-webhooks.md): This endpoint returns the list of the Webhooks that belongs to the given Product identified by the - [Integrations](https://configcat.com/docs/api/reference/integrations.md): Integrations - [Invite Member](https://configcat.com/docs/api/reference/invite-member.md): This endpoint invites a Member into the given Product identified by the `productId` parameter. - [Me](https://configcat.com/docs/api/reference/me.md): Me - [Members](https://configcat.com/docs/api/reference/members.md): Members - [Organizations](https://configcat.com/docs/api/reference/organizations.md): Organizations - [Permission Groups](https://configcat.com/docs/api/reference/permission-groups.md): Permission Groups - [Post values](https://configcat.com/docs/api/reference/post-setting-values-v-2.md): This endpoint batch updates the Feature Flags and Settings of a Config identified by the `configId` parameter - [Post values](https://configcat.com/docs/api/reference/post-setting-values.md): This endpoint replaces the values of a specified Config's Feature Flags or Settings identified by the `configId` parameter - [Products](https://configcat.com/docs/api/reference/products.md): Products - [Replace value](https://configcat.com/docs/api/reference/replace-setting-value-by-sdkkey-v-2.md): This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting - [Replace value](https://configcat.com/docs/api/reference/replace-setting-value-by-sdkkey.md): This endpoint replaces the value of a Feature Flag or Setting - [Replace value](https://configcat.com/docs/api/reference/replace-setting-value-v-2.md): This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting - [Replace value](https://configcat.com/docs/api/reference/replace-setting-value.md): This endpoint replaces the whole value of a Feature Flag or Setting in a specified Environment. - [Replace Flag](https://configcat.com/docs/api/reference/replace-setting.md): This endpoint replaces the whole value of a Feature Flag or Setting - [Replace Webhook](https://configcat.com/docs/api/reference/replace-webhook.md): This endpoint replaces the whole value of a Webhook identified by the `webhookId` parameter. - [SDK Keys](https://configcat.com/docs/api/reference/sdk-keys.md): SDK Keys - [Segments](https://configcat.com/docs/api/reference/segments.md): Segments - [Tags](https://configcat.com/docs/api/reference/tags.md): Tags - [Update Config](https://configcat.com/docs/api/reference/update-config.md): This endpoint updates a Config identified by the `configId` parameter. - [Update Environment](https://configcat.com/docs/api/reference/update-environment.md): This endpoint updates an Environment identified by the `environmentId` parameter. - [Update Integration](https://configcat.com/docs/api/reference/update-integration.md): This endpoint updates a Config identified by the `integrationId` parameter. - [Update Permission Group](https://configcat.com/docs/api/reference/update-permission-group.md): This endpoint updates a Permission Group identified by the `permissionGroupId` parameter. - [Update predefined variations (Beta)](https://configcat.com/docs/api/reference/update-predefined-variations.md): This endpoint updates the predefined variations for a Feature Flag or Setting identified by the `settingId` parameter. - [Update Product Preferences](https://configcat.com/docs/api/reference/update-product-preferences.md): This endpoint updates the preferences of a Product identified by the `productId` parameter. - [Update Product](https://configcat.com/docs/api/reference/update-product.md): This endpoint updates a Product identified by the `productId` parameter. - [Update Segment](https://configcat.com/docs/api/reference/update-segment.md): This endpoint updates a Segment identified by the `segmentId` parameter. - [Update value](https://configcat.com/docs/api/reference/update-setting-value-by-sdkkey-v-2.md): This endpoint updates the value of a Feature Flag or Setting - [Update value](https://configcat.com/docs/api/reference/update-setting-value-by-sdkkey.md): This endpoint updates the value of a Feature Flag or Setting - [Update value](https://configcat.com/docs/api/reference/update-setting-value-v-2.md): This endpoint updates the value of a Feature Flag or Setting - [Update value](https://configcat.com/docs/api/reference/update-setting-value.md): This endpoint updates the value of a Feature Flag or Setting - [Update Flag](https://configcat.com/docs/api/reference/update-setting.md): This endpoint updates the metadata of a Feature Flag or Setting - [Update Tag](https://configcat.com/docs/api/reference/update-tag.md): This endpoint updates a Tag identified by the `tagId` parameter. - [Update Webhook](https://configcat.com/docs/api/reference/update-webhook.md): This endpoint updates a Webhook identified by the `webhookId` parameter with a collection of [JSON Patch](https://jsonpatch.com) operations. - [Upload References](https://configcat.com/docs/api/reference/upload-references.md) - [Webhooks](https://configcat.com/docs/api/reference/webhooks.md): Webhooks - [Zombie (stale) flags](https://configcat.com/docs/api/reference/zombie-stale-flags.md): Zombie (stale) flags - [ConfigCat User Provisioning (SCIM) API](https://configcat.com/docs/api/scim/configcat-user-provisioning-scim-api.md): The purpose of this API is to allow user and group synchronization from your Identity Provider into a ConfigCat Organization via the SCIM protocol. - [Create Group](https://configcat.com/docs/api/scim/create-group.md): This endpoint creates a new group with the given attributes. - [Create User](https://configcat.com/docs/api/scim/create-user.md): This endpoint creates a new user with the given attributes. - [Delete Group](https://configcat.com/docs/api/scim/delete-group.md): This endpoint deletes an existing group. - [Delete User](https://configcat.com/docs/api/scim/delete-user.md): This endpoint deletes an existing user. - [Get Group](https://configcat.com/docs/api/scim/get-group.md): This endpoint returns a group. - [Get Groups](https://configcat.com/docs/api/scim/get-groups.md): This endpoint returns a list of groups. - [Get Resource Type](https://configcat.com/docs/api/scim/get-resource-type.md): This endpoint returns a resource type. - [Get Resource Types](https://configcat.com/docs/api/scim/get-resource-types.md): This endpoint returns the supported resource types. - [Get Schema](https://configcat.com/docs/api/scim/get-schema.md): This endpoint returns a schema. - [Get Schemas](https://configcat.com/docs/api/scim/get-schemas.md): This endpoint returns the supported schema list. - [Get Service Provider Config](https://configcat.com/docs/api/scim/get-service-provider-config.md): This endpoint returns the service provider config. - [Get User](https://configcat.com/docs/api/scim/get-user.md): This endpoint returns a user. - [Get Users](https://configcat.com/docs/api/scim/get-users.md): This endpoint returns a list of users. - [Replace Group](https://configcat.com/docs/api/scim/replace-group.md): This endpoint updates an existing group by replacing all attributes present in the request. - [Replace User](https://configcat.com/docs/api/scim/replace-user.md): This endpoint updates an existing user by replacing all attributes present in the request. - [Update Group](https://configcat.com/docs/api/scim/update-group.md): This endpoint updates an existing group by applying JSON Patch operations. - [Update User](https://configcat.com/docs/api/scim/update-user.md): This endpoint updates an existing user by applying JSON Patch operations. --- # Full Documentation Content ## [📄️ Get Groups](https://configcat.com/docs/docs/api/scim/get-groups/.md) [This endpoint returns a list of groups.](https://configcat.com/docs/docs/api/scim/get-groups/.md) --- ## [📄️ Get Service Provider Config](https://configcat.com/docs/docs/api/scim/get-service-provider-config/.md) [This endpoint returns the service provider config.](https://configcat.com/docs/docs/api/scim/get-service-provider-config/.md) --- ## [📄️ Get Users](https://configcat.com/docs/docs/api/scim/get-users/.md) [This endpoint returns a list of users.](https://configcat.com/docs/docs/api/scim/get-users/.md) --- # Update Member Permissions ``` POST /v1/organizations/:organizationId/members/:userId ``` 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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the update was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Audit logs Access audit log entries. ## [📄️ List Audit log items for Product](https://configcat.com/docs/docs/api/reference/get-auditlogs/.md) [This endpoint returns the list of Audit log items for a given Product](https://configcat.com/docs/docs/api/reference/get-auditlogs/.md) ## [📄️ List Deleted Settings](https://configcat.com/docs/docs/api/reference/get-deleted-settings/.md) [This endpoint returns the list of Feature Flags and Settings that were deleted from the given Config.](https://configcat.com/docs/docs/api/reference/get-deleted-settings/.md) ## [📄️ List Audit log items for Organization](https://configcat.com/docs/docs/api/reference/get-organization-auditlogs/.md) [This endpoint returns the list of Audit log items for a given Organization](https://configcat.com/docs/docs/api/reference/get-organization-auditlogs/.md) --- # Code References With this endpoint you can upload Feature Flag and Setting usage references that will be shown on the ConfigCat Dashboard. [Here](https://configcat.com/docs/docs/advanced/code-references/overview/.md) you can read more about the concept of Code References. ## [📄️ Get References for Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-references-for-feature-flag-or-setting/.md) ## [📄️ Delete Reference reports](https://configcat.com/docs/docs/api/reference/delete-reference-reports/.md) ## [📄️ Upload References](https://configcat.com/docs/docs/api/reference/upload-references/.md) --- Version: v1 # ConfigCat Public Management API The purpose of this API is to access the ConfigCat platform programmatically. You can **Create**, **Read**, **Update** and **Delete** any entities like **Feature Flags, Configs, Environments** or **Products** within ConfigCat. **Base API URL**: If you prefer the swagger documentation, you can find it here: [Swagger UI](https://api.configcat.com/swagger). The API is based on HTTP REST, uses resource-oriented URLs, status codes and supports JSON format. **Important:** Do not use this API for accessing and evaluating feature flag values. Use the [SDKs](https://configcat.com/docs/docs/sdk-reference/overview/.md) or the [ConfigCat Proxy](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md) instead. ## OpenAPI Specification[​](#openapi-specification "Direct link to OpenAPI Specification") The complete specification is publicly available in the following formats: * [OpenAPI v3](https://api.configcat.com/docs/v1/swagger.json) * [Swagger v2](https://api.configcat.com/docs/v1/swagger.v2.json) You can use it to generate client libraries in various languages with [OpenAPI Generator](https://github.com/OpenAPITools/openapi-generator) or [Swagger Codegen](https://swagger.io/tools/swagger-codegen/) to interact with this API. ## Throttling and rate limits[​](#throttling-and-rate-limits "Direct link to Throttling and rate limits") All the rate limited API calls are returning information about the current rate limit period in the following HTTP headers: | Header | Description | | ---------------------- | -------------------------------------------------------------------------- | | X-Rate-Limit-Remaining | The maximum number of requests remaining in the current rate limit period. | | X-Rate-Limit-Reset | The time when the current rate limit period resets. | When the rate limit is exceeded by a request, the API returns with a `HTTP 429 - Too many requests` status along with a `Retry-After` HTTP header. ## Authentication[​](#authentication "Direct link to Authentication") * HTTP: Basic Auth To authenticate with the API you have to fill the `Authorization` HTTP request header with your Public API credentials. You can create your credentials on the [Public API credentials management page](https://app.configcat.com/my-account/public-api-credentials). | Security Scheme Type: | http | | -------------------------- | ----- | | HTTP Authorization Scheme: | basic | ### Contact ConfigCat: URL: ### Terms of Service --- # Configs With these endpoints you can manage your Configs. This also can be used to manage [Feature Flags and Settings](https://configcat.com/docs/docs/api/reference/feature-flags-settings/.md) and their [served values](https://configcat.com/docs/docs/api/reference/feature-flag-setting-values/.md) through this API. [Here](https://configcat.com/docs/docs/main-concepts/.md#config) you can read more about the concept of Configs. ## [📄️ List Configs](https://configcat.com/docs/docs/api/reference/get-configs/.md) [This endpoint returns the list of the Configs that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-configs/.md) ## [📄️ Create Config](https://configcat.com/docs/docs/api/reference/create-config/.md) [This endpoint creates a new Config in a specified Product](https://configcat.com/docs/docs/api/reference/create-config/.md) ## [📄️ Get Config](https://configcat.com/docs/docs/api/reference/get-config/.md) [This endpoint returns the metadata of a Config](https://configcat.com/docs/docs/api/reference/get-config/.md) ## [📄️ Update Config](https://configcat.com/docs/docs/api/reference/update-config/.md) [This endpoint updates a Config identified by the \`configId\` parameter.](https://configcat.com/docs/docs/api/reference/update-config/.md) ## [📄️ Delete Config](https://configcat.com/docs/docs/api/reference/delete-config/.md) [This endpoint removes a Config identified by the \`configId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-config/.md) --- # Create Config ``` POST /v1/products/:productId/configs ``` This endpoint creates a new Config in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Environment ``` POST /v1/products/:productId/environments ``` This endpoint creates a new Environment in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Integration ``` POST /v1/products/:productId/integrations ``` This endpoint creates a new Integration in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) 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. * 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) ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Permission Group ``` POST /v1/products/:productId/permissions ``` This endpoint creates a new Permission Group in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Product ``` POST /v1/organizations/:organizationId/products ``` This endpoint creates a new Product in a specified Organization identified by the `organizationId` parameter, which can be obtained from the [List Organizations](https://configcat.com/docs/docs/api/reference/get-organizations/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Segment ``` POST /v1/products/:productId/segments ``` This endpoint creates a new Segment in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Flag ``` POST /v1/configs/:configId/settings ``` 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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Tag ``` POST /v1/products/:productId/tags ``` This endpoint creates a new Tag in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Create Webhook ``` POST /v1/configs/:configId/environments/:environmentId/webhooks ``` This endpoint creates a new Webhook in a specified Product identified by the `productId` parameter, which can be obtained from the [List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 404 * 429 When the creation was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Config ``` DELETE /v1/configs/:configId ``` This endpoint removes a Config identified by the `configId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Environment ``` DELETE /v1/environments/:environmentId ``` 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). ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Integration ``` DELETE /v1/integrations/:integrationId ``` This endpoint removes a Integration identified by the `integrationId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Invitation ``` DELETE /v1/invitations/:invitationId ``` This endpoint removes an Invitation identified by the `invitationId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Member from Organization ``` DELETE /v1/organizations/:organizationId/members/:userId ``` This endpoint removes a Member identified by the `userId` from the given Organization identified by the `organizationId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Permission Group ``` DELETE /v1/permissions/:permissionGroupId ``` This endpoint removes a Permission Group identified by the `permissionGroupId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Member from Product ``` DELETE /v1/products/:productId/members/:userId ``` This endpoint removes a Member identified by the `userId` from the given Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Product ``` DELETE /v1/products/:productId ``` This endpoint removes a Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Reference reports ``` POST /v1/code-references/delete-reports ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 OK Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Segment ``` DELETE /v1/segments/:segmentId ``` This endpoint removes a Segment identified by the `segmentId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Flag ``` DELETE /v1/settings/:settingId ``` This endpoint removes a Feature Flag or Setting from a specified Config, identified by the `configId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Tag ``` DELETE /v1/tags/:tagId ``` This endpoint deletes a Tag identified by the `tagId` parameter. To remove a Tag from a Feature Flag or Setting use the [Update Flag](https://configcat.com/docs/docs/api/reference/update-setting/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Webhook ``` DELETE /v1/webhooks/:webhookId ``` This endpoint removes a Webhook identified by the `webhookId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 400 * 404 * 429 When the delete was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Environments With these endpoints you can update existing Environments or add new ones into your selected [Product](https://configcat.com/docs/docs/api/reference/products/.md). [Here](https://configcat.com/docs/docs/main-concepts/.md#environment) you can read more about the concept of Environments. ## [📄️ List Environments](https://configcat.com/docs/docs/api/reference/get-environments/.md) [This endpoint returns the list of the Environments that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-environments/.md) ## [📄️ Create Environment](https://configcat.com/docs/docs/api/reference/create-environment/.md) [This endpoint creates a new Environment in a specified Product](https://configcat.com/docs/docs/api/reference/create-environment/.md) ## [📄️ Get Environment](https://configcat.com/docs/docs/api/reference/get-environment/.md) [This endpoint returns the metadata of an Environment](https://configcat.com/docs/docs/api/reference/get-environment/.md) ## [📄️ Update Environment](https://configcat.com/docs/docs/api/reference/update-environment/.md) [This endpoint updates an Environment identified by the \`environmentId\` parameter.](https://configcat.com/docs/docs/api/reference/update-environment/.md) ## [📄️ Delete Environment](https://configcat.com/docs/docs/api/reference/delete-environment/.md) [This endpoint removes an Environment identified by the \`environmentId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-environment/.md) --- # Feature Flag & Setting values using SDK Key V2 *These endpoints are exclusive for [**Config V2**](https://configcat.com/docs/docs/advanced/config-v2/.md) Feature Flags.*
*They can only be used on a Config that has `evaluationVersion` set to `v2`.*

With these endpoints you can control how your existing Feature Flags and Settings should serve their values. You can turn Feature Flags on or off, update Setting values and change Targeting Rules. These endpoints are determining the Environment and Config by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` request header. To identify the desired Feature Flag or Setting to change, you can use either its `settingId` or `key` attribute. You can get those attributes from the [Feature Flag & Setting](https://configcat.com/docs/docs/api/reference/feature-flags-settings/.md) endpoints. ## [📄️ Get value](https://configcat.com/docs/docs/api/reference/get-setting-value-by-sdkkey-v-2/.md) [This endpoint returns the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-setting-value-by-sdkkey-v-2/.md) ## [📄️ Replace value](https://configcat.com/docs/docs/api/reference/replace-setting-value-by-sdkkey-v-2/.md) [This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/replace-setting-value-by-sdkkey-v-2/.md) ## [📄️ Update value](https://configcat.com/docs/docs/api/reference/update-setting-value-by-sdkkey-v-2/.md) [This endpoint updates the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/update-setting-value-by-sdkkey-v-2/.md) --- # Feature Flag & Setting values using SDK Key With these endpoints you can control how your existing Feature Flags and Settings should serve their values. You can turn Feature Flags on or off, update Setting values and also add, remove or change the order of Percentage and Targeting Rules. These endpoints are determining the Environment and Config by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` request header. To identify the desired Feature Flag or Setting to change, you can use either its `settingId` or `key` attribute. You can get those attributes from the [Feature Flag & Setting](https://configcat.com/docs/docs/api/reference/feature-flags-settings/.md) endpoints. ## [📄️ Get value](https://configcat.com/docs/docs/api/reference/get-setting-value-by-sdkkey/.md) [This endpoint returns the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-setting-value-by-sdkkey/.md) ## [📄️ Replace value](https://configcat.com/docs/docs/api/reference/replace-setting-value-by-sdkkey/.md) [This endpoint replaces the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/replace-setting-value-by-sdkkey/.md) ## [📄️ Update value](https://configcat.com/docs/docs/api/reference/update-setting-value-by-sdkkey/.md) [This endpoint updates the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/update-setting-value-by-sdkkey/.md) --- # Feature Flag & Setting values V2 *These endpoints are exclusive for [**Config V2**](https://configcat.com/docs/docs/advanced/config-v2/.md) Feature Flags.*
*They can only be used on a Config that has `evaluationVersion` set to `v2`.*

With these endpoints you can control how your existing Feature Flags and Settings should serve their values. You can turn Feature Flags on or off, update Setting values and change Targeting Rules. To determine which Feature Flag or Setting you want to work with you have to pass its `settingId`. It can be obtained from the [Feature Flag & Setting](https://configcat.com/docs/docs/api/reference/feature-flags-settings/.md) endpoints. You also have to specify in which Environment you want to change the served value configuration by its `environmentId` which can be obtained from the [List Environments](https://configcat.com/docs/docs/api/reference/get-environments/.md) endpoint. ## [📄️ Get value](https://configcat.com/docs/docs/api/reference/get-setting-value-v-2/.md) [This endpoint returns the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-setting-value-v-2/.md) ## [📄️ Replace value](https://configcat.com/docs/docs/api/reference/replace-setting-value-v-2/.md) [This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/replace-setting-value-v-2/.md) ## [📄️ Update value](https://configcat.com/docs/docs/api/reference/update-setting-value-v-2/.md) [This endpoint updates the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/update-setting-value-v-2/.md) ## [📄️ Get values](https://configcat.com/docs/docs/api/reference/get-setting-values-v-2/.md) [This endpoint returns all Feature Flag and Setting values of a Config identified by the \`configId\` parameter](https://configcat.com/docs/docs/api/reference/get-setting-values-v-2/.md) ## [📄️ Post values](https://configcat.com/docs/docs/api/reference/post-setting-values-v-2/.md) [This endpoint batch updates the Feature Flags and Settings of a Config identified by the \`configId\` parameter](https://configcat.com/docs/docs/api/reference/post-setting-values-v-2/.md) --- # Feature Flag & Setting values With these endpoints you can control how your existing Feature Flags and Settings should serve their values. You can turn Feature Flags on or off, update Setting values and also add, remove or reorder Percentage and Targeting Rules. To determine which Feature Flag or Setting you want to work with you have to pass its `settingId`. It can be obtained from the [Feature Flag & Setting](https://configcat.com/docs/docs/api/reference/feature-flags-settings/.md) endpoints. You also have to specify in which Environment you want to change the served value configuration by its `environmentId` which can be obtained from the [List Environments](https://configcat.com/docs/docs/api/reference/get-environments/.md) endpoint. ## [📄️ Get value](https://configcat.com/docs/docs/api/reference/get-setting-value/.md) [This endpoint returns the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-setting-value/.md) ## [📄️ Replace value](https://configcat.com/docs/docs/api/reference/replace-setting-value/.md) [This endpoint replaces the whole value of a Feature Flag or Setting in a specified Environment.](https://configcat.com/docs/docs/api/reference/replace-setting-value/.md) ## [📄️ Update value](https://configcat.com/docs/docs/api/reference/update-setting-value/.md) [This endpoint updates the value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/update-setting-value/.md) ## [📄️ Get values](https://configcat.com/docs/docs/api/reference/get-setting-values/.md) [This endpoint returns the value of a specified Config's Feature Flags or Settings identified by the \`configId\` parameter](https://configcat.com/docs/docs/api/reference/get-setting-values/.md) ## [📄️ Post values](https://configcat.com/docs/docs/api/reference/post-setting-values/.md) [This endpoint replaces the values of a specified Config's Feature Flags or Settings identified by the \`configId\` parameter](https://configcat.com/docs/docs/api/reference/post-setting-values/.md) --- # Feature Flags & Settings With these endpoints you can manage your Feature Flags or Settings within a Config. However you can't use them for manipulating the values of your Feature Flags and Settings, to do that please visit the [Feature Flag & Setting values using SDK Key](https://configcat.com/docs/docs/api/reference/feature-flag-setting-values-using-sdk-key/.md) and [Feature Flag & Setting values](https://configcat.com/docs/docs/api/reference/feature-flag-setting-values/.md) sections of the API. For using these endpoints, first you have to select which Config you want to work with by its `configId` which can be obtained from the [List Configs](https://configcat.com/docs/docs/api/reference/get-configs/.md) endpoint. Then you can use it to create new Feature Flags or to get information about existing ones. Then you can obtain the `settingId` or `key` of your desired Feature Flag or Setting to use them for further operations in this API. [Here](https://configcat.com/docs/docs/main-concepts/.md#setting) you can read more about the concept of Settings. ## [📄️ List Flags](https://configcat.com/docs/docs/api/reference/get-settings/.md) [This endpoint returns the list of the Feature Flags and Settings defined in a](https://configcat.com/docs/docs/api/reference/get-settings/.md) ## [📄️ Create Flag](https://configcat.com/docs/docs/api/reference/create-setting/.md) [This endpoint creates a new Feature Flag or Setting in a specified Config](https://configcat.com/docs/docs/api/reference/create-setting/.md) ## [📄️ Get Flag](https://configcat.com/docs/docs/api/reference/get-setting/.md) [This endpoint returns the metadata attributes of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/get-setting/.md) ## [📄️ Replace Flag](https://configcat.com/docs/docs/api/reference/replace-setting/.md) [This endpoint replaces the whole value of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/replace-setting/.md) ## [📄️ Update Flag](https://configcat.com/docs/docs/api/reference/update-setting/.md) [This endpoint updates the metadata of a Feature Flag or Setting](https://configcat.com/docs/docs/api/reference/update-setting/.md) ## [📄️ Delete Flag](https://configcat.com/docs/docs/api/reference/delete-setting/.md) [This endpoint removes a Feature Flag or Setting from a specified Config,](https://configcat.com/docs/docs/api/reference/delete-setting/.md) ## [📄️ Update predefined variations (Beta)](https://configcat.com/docs/docs/api/reference/update-predefined-variations/.md) [This endpoint updates the predefined variations for a Feature Flag or Setting identified by the \`settingId\` parameter.](https://configcat.com/docs/docs/api/reference/update-predefined-variations/.md) --- # List Audit log items for Product ``` GET /v1/products/:productId/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. 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**. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Config ``` GET /v1/configs/:configId ``` This endpoint returns the metadata of a Config identified by the `configId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the config data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Configs ``` GET /v1/products/:productId/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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Deleted Settings ``` GET /v1/configs/:configId/deleted-settings ``` This endpoint returns the list of Feature Flags and Settings that were deleted from the given Config. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Environment ``` GET /v1/environments/:environmentId ``` This endpoint returns the metadata of an Environment identified by the `environmentId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the environment data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Environments ``` GET /v1/products/:productId/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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Integration ``` GET /v1/integrations/:integrationId ``` This endpoint returns the metadata of an Integration identified by the `integrationId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the integration data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Integrations ``` GET /v1/products/:productId/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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get authenticated user details ``` GET /v1/me ``` ## Responses[​](#responses "Direct link to Responses") * 200 * 429 Too many requests. In case of the request rate exceeds the rate limits. --- # List Audit log items for Organization ``` GET /v1/organizations/:organizationId/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. 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**. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Organization Members ``` GET /v2/organizations/:organizationId/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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Organization Members ``` GET /v1/organizations/:organizationId/members ``` deprecated This endpoint has been deprecated and may be replaced or removed in future versions of the API. 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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Organizations ``` GET /v1/organizations ``` This endpoint returns the list of the Organizations that belongs to the user. ## Responses[​](#responses "Direct link to Responses") * 200 * 429 Too many requests. In case of the request rate exceeds the rate limits. --- # List Pending Invitations in Organization ``` GET /v1/organizations/:organizationId/invitations ``` This endpoint returns the list of pending invitations within the given Organization identified by the `organizationId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Pending Invitations in Product ``` GET /v1/products/:productId/invitations ``` This endpoint returns the list of pending invitations within the given Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Permission Group ``` GET /v1/permissions/:permissionGroupId ``` This endpoint returns the metadata of a Permission Group identified by the `permissionGroupId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the permission group data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Permission Groups ``` GET /v1/products/:productId/permissions ``` 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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Product Members ``` GET /v1/products/:productId/members ``` This endpoint returns the list of Members that belongs to the given Product, identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Product Preferences ``` GET /v1/products/:productId/preferences ``` This endpoint returns the preferences of a Product identified by the `productId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the product preferences data is returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Product ``` GET /v1/products/:productId ``` This endpoint returns the metadata of a Product identified by the `productId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the product data is returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Products ``` GET /v1/products ``` This endpoint returns the list of the Products that belongs to the user. ## Responses[​](#responses "Direct link to Responses") * 200 * 429 Too many requests. In case of the request rate exceeds the rate limits. --- # Get References for Feature Flag or Setting ``` GET /v1/settings/:settingId/code-references ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get SDK Key ``` GET /v1/configs/:configId/environments/:environmentId ``` This endpoint returns the SDK Key for your Config in a specified Environment. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Segment ``` GET /v1/segments/:segmentId ``` This endpoint returns the metadata of a Segment identified by the `segmentId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the config data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Segments ``` GET /v1/products/:productId/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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get value ``` GET /v2/settings/:settingKeyOrId/value ``` This endpoint returns the value of a Feature Flag or Setting in a specified Environment identified by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` header. 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/docs/targeting/targeting-overview/.md). The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/docs/targeting/user-object/.md) attribute that must be used at the [percentage evaluation](https://configcat.com/docs/docs/targeting/percentage-options/.md) of the Feature Flag or Setting. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get value ``` GET /v1/settings/:settingKeyOrId/value ``` This endpoint returns the value of a Feature Flag or Setting in a specified Environment identified by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` header. 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/docs/targeting/targeting-overview/.md). ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get value ``` GET /v2/environments/:environmentId/settings/:settingId/value ``` 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/docs/targeting/targeting-overview/.md). The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/docs/targeting/user-object/.md) attribute that must be used for [percentage evaluation](https://configcat.com/docs/docs/targeting/percentage-options/.md) of the Feature Flag or Setting. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the setting value data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get value ``` GET /v1/environments/:environmentId/settings/:settingId/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/docs/targeting/targeting-overview/.md). ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the setting value data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get values ``` GET /v2/configs/:configId/environments/:environmentId/values ``` 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/docs/targeting/targeting-overview/.md). The `percentageEvaluationAttribute` represents the custom [User Object](https://configcat.com/docs/docs/targeting/user-object/.md) attribute that must be used for [percentage evaluation](https://configcat.com/docs/docs/targeting/percentage-options/.md) of the Feature Flag or Setting. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the setting values returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get values ``` GET /v1/configs/:configId/environments/:environmentId/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/docs/targeting/targeting-overview/.md). ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the setting values returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Flag ``` GET /v1/settings/:settingId ``` This endpoint returns the metadata attributes of a Feature Flag or Setting identified by the `settingId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the setting data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Settings by Tag ``` GET /v1/tags/:tagId/settings ``` This endpoint returns the list of the Settings that has the specified Tag, identified by the `tagId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the settings data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Flags ``` GET /v1/configs/:configId/settings ``` This endpoint returns the list of the Feature Flags and Settings defined in a specified Config, identified by the `configId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Zombie (stale) flags for Product ``` GET /v1/products/:productId/staleflags ``` This endpoint returns the list of Zombie (stale) flags for a given Product and the result can be optionally filtered by various parameters. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Tag ``` GET /v1/tags/:tagId ``` This endpoint returns the metadata of a Tag identified by the `tagId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the tag data returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Tags ``` GET /v1/products/:productId/tags ``` This endpoint returns the list of the Tags in a specified Product, identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 429 Too many requests. In case of the request rate exceeds the rate limits. --- # Get Webhook Signing Keys ``` GET /v1/webhooks/:webhookId/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](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md#verifying-webhook-requests) you can read more about Webhook request verification. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the webhook signing keys are returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Webhook ``` GET /v1/webhooks/:webhookId ``` This endpoint returns the metadata of a Webhook identified by the `webhookId`. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the webhook data is returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # List Webhooks ``` GET /v1/products/:productId/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](https://configcat.com/docs/docs/api/reference/get-products/.md) endpoint. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 429 Too many requests. In case of the request rate exceeds the rate limits. --- # Integrations With these endpoints you can manage your Integrations. * [Datadog](https://configcat.com/docs/docs/integrations/datadog/.md) * [Slack](https://configcat.com/docs/docs/integrations/slack/.md) * [Amplitude](https://configcat.com/docs/docs/integrations/amplitude/.md) * [MixPanel](https://configcat.com/docs/docs/integrations/mixpanel/.md) * [Segment](https://configcat.com/docs/docs/integrations/segment/.md) * PubNub (work in progress) ## [📄️ List Integrations](https://configcat.com/docs/docs/api/reference/get-integrations/.md) [This endpoint returns the list of the Integrations that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-integrations/.md) ## [📄️ Create Integration](https://configcat.com/docs/docs/api/reference/create-integration/.md) [This endpoint creates a new Integration in a specified Product](https://configcat.com/docs/docs/api/reference/create-integration/.md) ## [📄️ Get Integration](https://configcat.com/docs/docs/api/reference/get-integration/.md) [This endpoint returns the metadata of an Integration](https://configcat.com/docs/docs/api/reference/get-integration/.md) ## [📄️ Update Integration](https://configcat.com/docs/docs/api/reference/update-integration/.md) [This endpoint updates a Config identified by the \`integrationId\` parameter.](https://configcat.com/docs/docs/api/reference/update-integration/.md) ## [📄️ Delete Integration](https://configcat.com/docs/docs/api/reference/delete-integration/.md) [This endpoint removes a Integration identified by the \`integrationId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-integration/.md) --- # Invite Member ``` POST /v1/products/:productId/members/invite ``` This endpoint invites a Member into the given Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the invite was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Me Information about the current user. ## [📄️ Get authenticated user details](https://configcat.com/docs/docs/api/reference/get-me/.md) --- # Members With these endpoints you can manage your Members. [Here](https://configcat.com/docs/docs/advanced/team-management/team-management-basics/.md) you can read more about Team Management. ## [📄️ List Organization Members](https://configcat.com/docs/docs/api/reference/get-organization-members/.md) [This endpoint returns the list of Members that belongs](https://configcat.com/docs/docs/api/reference/get-organization-members/.md) ## [📄️ List Organization Members](https://configcat.com/docs/docs/api/reference/get-organization-members-v-2/.md) [This endpoint returns the list of Members that belongs](https://configcat.com/docs/docs/api/reference/get-organization-members-v-2/.md) ## [📄️ List Pending Invitations in Organization](https://configcat.com/docs/docs/api/reference/get-pending-invitations-org/.md) [This endpoint returns the list of pending invitations within the](https://configcat.com/docs/docs/api/reference/get-pending-invitations-org/.md) ## [📄️ List Pending Invitations in Product](https://configcat.com/docs/docs/api/reference/get-pending-invitations/.md) [This endpoint returns the list of pending invitations within the](https://configcat.com/docs/docs/api/reference/get-pending-invitations/.md) ## [📄️ List Product Members](https://configcat.com/docs/docs/api/reference/get-product-members/.md) [This endpoint returns the list of Members that belongs](https://configcat.com/docs/docs/api/reference/get-product-members/.md) ## [📄️ Invite Member](https://configcat.com/docs/docs/api/reference/invite-member/.md) [This endpoint invites a Member into the given Product identified by the \`productId\` parameter.](https://configcat.com/docs/docs/api/reference/invite-member/.md) ## [📄️ Update Member Permissions](https://configcat.com/docs/docs/api/reference/add-member-to-group/.md) [This endpoint updates the permissions of a Member identified by the \`userId\`.](https://configcat.com/docs/docs/api/reference/add-member-to-group/.md) ## [📄️ Delete Member from Organization](https://configcat.com/docs/docs/api/reference/delete-organization-member/.md) [This endpoint removes a Member identified by the \`userId\` from the](https://configcat.com/docs/docs/api/reference/delete-organization-member/.md) ## [📄️ Delete Invitation](https://configcat.com/docs/docs/api/reference/delete-invitation/.md) [This endpoint removes an Invitation identified by the \`invitationId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-invitation/.md) ## [📄️ Delete Member from Product](https://configcat.com/docs/docs/api/reference/delete-product-member/.md) [This endpoint removes a Member identified by the \`userId\` from the](https://configcat.com/docs/docs/api/reference/delete-product-member/.md) --- # Organizations With these endpoints you can get useful information about your Organizations. This also can be used to manage your [Products](https://configcat.com/docs/docs/api/reference/products/.md). [Here](https://configcat.com/docs/docs/organization/.md) you can read more about the Organizations. ## [📄️ List Organizations](https://configcat.com/docs/docs/api/reference/get-organizations/.md) [This endpoint returns the list of the Organizations that belongs to the user.](https://configcat.com/docs/docs/api/reference/get-organizations/.md) --- # Permission Groups With these endpoints you can manage your Permission Groups. [Here](https://configcat.com/docs/docs/advanced/team-management/team-management-basics/.md) you can read more about Permissions. ## [📄️ List Permission Groups](https://configcat.com/docs/docs/api/reference/get-permission-groups/.md) [This endpoint returns the list of the Permission Groups that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-permission-groups/.md) ## [📄️ Create Permission Group](https://configcat.com/docs/docs/api/reference/create-permission-group/.md) [This endpoint creates a new Permission Group in a specified Product](https://configcat.com/docs/docs/api/reference/create-permission-group/.md) ## [📄️ Get Permission Group](https://configcat.com/docs/docs/api/reference/get-permission-group/.md) [This endpoint returns the metadata of a Permission Group](https://configcat.com/docs/docs/api/reference/get-permission-group/.md) ## [📄️ Update Permission Group](https://configcat.com/docs/docs/api/reference/update-permission-group/.md) [This endpoint updates a Permission Group identified by the \`permissionGroupId\` parameter.](https://configcat.com/docs/docs/api/reference/update-permission-group/.md) ## [📄️ Delete Permission Group](https://configcat.com/docs/docs/api/reference/delete-permission-group/.md) [This endpoint removes a Permission Group identified by the \`permissionGroupId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-permission-group/.md) --- # Post values ``` POST /v2/configs/:configId/environments/:environmentId/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. ``` { "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 } } ] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the updated setting values returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Post values ``` POST /v1/configs/:configId/environments/:environmentId/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. ``` { "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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When everything is ok, the updated setting values returned. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Products With these endpoints you can manage your Products. By gathering the right `productId`, you can also manage [Environments](https://configcat.com/docs/docs/api/reference/environments/.md), [Configs](https://configcat.com/docs/docs/api/reference/configs/.md), [Tags](https://configcat.com/docs/docs/api/reference/tags/.md), [Webhooks](https://configcat.com/docs/docs/api/reference/webhooks/.md), and [Permission Groups](https://configcat.com/docs/docs/api/reference/permission-groups/.md) through the API. [Here](https://configcat.com/docs/docs/main-concepts/.md#product) you can read more about the concept of Products. ## [📄️ List Products](https://configcat.com/docs/docs/api/reference/get-products/.md) [This endpoint returns the list of the Products that belongs to the user.](https://configcat.com/docs/docs/api/reference/get-products/.md) ## [📄️ Get Product](https://configcat.com/docs/docs/api/reference/get-product/.md) [This endpoint returns the metadata of a Product](https://configcat.com/docs/docs/api/reference/get-product/.md) ## [📄️ Update Product](https://configcat.com/docs/docs/api/reference/update-product/.md) [This endpoint updates a Product identified by the \`productId\` parameter.](https://configcat.com/docs/docs/api/reference/update-product/.md) ## [📄️ Delete Product](https://configcat.com/docs/docs/api/reference/delete-product/.md) [This endpoint removes a Product identified by the \`productId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-product/.md) ## [📄️ Get Product Preferences](https://configcat.com/docs/docs/api/reference/get-product-preferences/.md) [This endpoint returns the preferences of a Product](https://configcat.com/docs/docs/api/reference/get-product-preferences/.md) ## [📄️ Update Product Preferences](https://configcat.com/docs/docs/api/reference/update-product-preferences/.md) [This endpoint updates the preferences of a Product identified by the \`productId\` parameter.](https://configcat.com/docs/docs/api/reference/update-product-preferences/.md) ## [📄️ Create Product](https://configcat.com/docs/docs/api/reference/create-product/.md) [This endpoint creates a new Product in a specified Organization](https://configcat.com/docs/docs/api/reference/create-product/.md) --- # Replace value ``` PUT /v2/settings/:settingKeyOrId/value ``` This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting in a specified Environment identified by the [SDK key](https://app.configcat.com/sdkkey) 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": [] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace value ``` PUT /v1/settings/:settingKeyOrId/value ``` This endpoint replaces the value of a Feature Flag or Setting in a specified Environment identified by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` header. 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 to 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 served value is set to `true`, all the Percentage Rules are deleted. So we get a response like this: ``` { "rolloutPercentageItems": [], "rolloutRules": [], "value": true } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace value ``` PUT /v2/environments/:environmentId/settings/:settingId/value ``` This endpoint replaces the value and the Targeting Rules of a Feature Flag or Setting in a specified Environment identified by the [SDK key](https://app.configcat.com/sdkkey) 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": [] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace value ``` PUT /v1/environments/:environmentId/settings/:settingId/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. ``` { "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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace Flag ``` PUT /v1/settings/:settingId ``` 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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the replace was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace Webhook ``` PUT /v1/webhooks/: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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the replace was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # SDK Keys With these endpoints you can manage your SDK Keys. ## [📄️ Get SDK Key](https://configcat.com/docs/docs/api/reference/get-sdk-keys/.md) [This endpoint returns the SDK Key for your Config in a specified Environment.](https://configcat.com/docs/docs/api/reference/get-sdk-keys/.md) --- # Segments With these endpoints you can manage your Segments. Segments allow you to group your users based on any of their properties. Define user segments and add them to multiple feature flags. ## [📄️ List Segments](https://configcat.com/docs/docs/api/reference/get-segments/.md) [This endpoint returns the list of the Segments that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-segments/.md) ## [📄️ Create Segment](https://configcat.com/docs/docs/api/reference/create-segment/.md) [This endpoint creates a new Segment in a specified Product](https://configcat.com/docs/docs/api/reference/create-segment/.md) ## [📄️ Get Segment](https://configcat.com/docs/docs/api/reference/get-segment/.md) [This endpoint returns the metadata of a Segment](https://configcat.com/docs/docs/api/reference/get-segment/.md) ## [📄️ Update Segment](https://configcat.com/docs/docs/api/reference/update-segment/.md) [This endpoint updates a Segment identified by the \`segmentId\` parameter.](https://configcat.com/docs/docs/api/reference/update-segment/.md) ## [📄️ Delete Segment](https://configcat.com/docs/docs/api/reference/delete-segment/.md) [This endpoint removes a Segment identified by the \`segmentId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-segment/.md) --- # Tags With these endpoints you can manage Tags. Tags are stored under a Product. You can and add a Tag to a Feature Flag or Setting using the [Update Flag](https://configcat.com/docs/docs/api/reference/update-setting/.md) endpoint. ## [📄️ List Tags](https://configcat.com/docs/docs/api/reference/get-tags/.md) [This endpoint returns the list of the Tags in a](https://configcat.com/docs/docs/api/reference/get-tags/.md) ## [📄️ Create Tag](https://configcat.com/docs/docs/api/reference/create-tag/.md) [This endpoint creates a new Tag in a specified Product](https://configcat.com/docs/docs/api/reference/create-tag/.md) ## [📄️ List Settings by Tag](https://configcat.com/docs/docs/api/reference/get-settings-by-tag/.md) [This endpoint returns the list of the Settings that](https://configcat.com/docs/docs/api/reference/get-settings-by-tag/.md) ## [📄️ Get Tag](https://configcat.com/docs/docs/api/reference/get-tag/.md) [This endpoint returns the metadata of a Tag](https://configcat.com/docs/docs/api/reference/get-tag/.md) ## [📄️ Update Tag](https://configcat.com/docs/docs/api/reference/update-tag/.md) [This endpoint updates a Tag identified by the \`tagId\` parameter.](https://configcat.com/docs/docs/api/reference/update-tag/.md) ## [📄️ Delete Tag](https://configcat.com/docs/docs/api/reference/delete-tag/.md) [This endpoint deletes a Tag identified by the \`tagId\` parameter. To remove a Tag from a Feature Flag or Setting use the \[Update Flag\](/docs/api/reference/update-setting) endpoint.](https://configcat.com/docs/docs/api/reference/delete-tag/.md) --- # Update Config ``` PUT /v1/configs/:configId ``` This endpoint updates a Config identified by the `configId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Environment ``` PUT /v1/environments/:environmentId ``` This endpoint updates an Environment identified by the `environmentId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Integration ``` PUT /v1/integrations/: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](https://api.slack.com/messaging/webhooks) where the integration should post messages. * 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) ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Permission Group ``` PUT /v1/permissions/:permissionGroupId ``` This endpoint updates a Permission Group identified by the `permissionGroupId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update predefined variations (Beta) ``` PUT /v1/settings/:settingId/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. **Beta feature:** The feature is currently in closed beta state and cannot be used. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the update was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Product Preferences ``` POST /v1/products/:productId/preferences ``` This endpoint updates the preferences of a Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the update was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Product ``` PUT /v1/products/:productId ``` This endpoint updates a Product identified by the `productId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Segment ``` PUT /v1/segments/:segmentId ``` This endpoint updates a Segment identified by the `segmentId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update value ``` PATCH /v2/settings/:settingKeyOrId/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 `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 } } ] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 404 * 429 When no change applied on the resource. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update value ``` PATCH /v1/settings/:settingKeyOrId/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 identified by the [SDK key](https://app.configcat.com/sdkkey) passed in the `X-CONFIGCAT-SDKKEY` header. 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 served 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 } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 404 * 429 When no change applied on the resource. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update value ``` PATCH /v2/environments/:environmentId/settings/:settingId/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 `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 } } ] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 404 * 429 When the patch was successful. When no change applied on the resource. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update value ``` PATCH /v1/environments/:environmentId/settings/:settingId/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. ``` { "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. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 404 * 429 When the patch was successful. When no change applied on the resource. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Flag ``` PATCH /v1/settings/:settingId ``` 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](https://configcat.com/docs/docs/api/reference/get-tags/.md) 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" } ] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the update was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Tag ``` PUT /v1/tags/:tagId ``` This endpoint updates a Tag identified by the `tagId` parameter. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Webhook ``` PATCH /v1/webhooks/:webhookId ``` 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. ``` { "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 } ] } ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 When the update was successful. Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Upload References ``` POST /v1/code-references ``` ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 404 * 429 OK Bad request. Not found. Too many requests. In case of the request rate exceeds the rate limits. --- # Webhooks With these endpoints you can manage Webhooks. [Here](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md) you can read more about the concept of Webhooks. ## [📄️ List Webhooks](https://configcat.com/docs/docs/api/reference/get-webhooks/.md) [This endpoint returns the list of the Webhooks that belongs to the given Product identified by the](https://configcat.com/docs/docs/api/reference/get-webhooks/.md) ## [📄️ Get Webhook](https://configcat.com/docs/docs/api/reference/get-webhook/.md) [This endpoint returns the metadata of a Webhook](https://configcat.com/docs/docs/api/reference/get-webhook/.md) ## [📄️ Replace Webhook](https://configcat.com/docs/docs/api/reference/replace-webhook/.md) [This endpoint replaces the whole value of a Webhook identified by the \`webhookId\` parameter.](https://configcat.com/docs/docs/api/reference/replace-webhook/.md) ## [📄️ Update Webhook](https://configcat.com/docs/docs/api/reference/update-webhook/.md) [This endpoint updates a Webhook identified by the \`webhookId\` parameter with a collection of \[JSON Patch\](https://jsonpatch.com) operations.](https://configcat.com/docs/docs/api/reference/update-webhook/.md) ## [📄️ Delete Webhook](https://configcat.com/docs/docs/api/reference/delete-webhook/.md) [This endpoint removes a Webhook identified by the \`webhookId\` parameter.](https://configcat.com/docs/docs/api/reference/delete-webhook/.md) ## [📄️ Get Webhook Signing Keys](https://configcat.com/docs/docs/api/reference/get-webhook-signing-keys/.md) [This endpoint returns the signing keys of a Webhook](https://configcat.com/docs/docs/api/reference/get-webhook-signing-keys/.md) ## [📄️ Create Webhook](https://configcat.com/docs/docs/api/reference/create-webhook/.md) [This endpoint creates a new Webhook in a specified Product](https://configcat.com/docs/docs/api/reference/create-webhook/.md) --- # Zombie (stale) flags List Zombie (stale) flags ## [📄️ List Zombie (stale) flags for Product](https://configcat.com/docs/docs/api/reference/get-staleflags/.md) [This endpoint returns the list of Zombie (stale) flags for a given Product](https://configcat.com/docs/docs/api/reference/get-staleflags/.md) --- Version: v1 # ConfigCat User Provisioning (SCIM) API The purpose of this API is to allow user and group synchronization from your Identity Provider into a ConfigCat Organization via the SCIM protocol. [Here](https://configcat.com/docs/advanced/team-management/scim/scim-overview/) you can read more about the user provisioning process. **Base API URL**: `https://scim-api.configcat.com` ## OpenAPI Specification[​](#openapi-specification "Direct link to OpenAPI Specification") The complete specification is publicly available in the following formats: * [OpenAPI v3](https://scim-api.configcat.com/openapi/v1/openapi.json) ## Throttling and rate limits[​](#throttling-and-rate-limits "Direct link to Throttling and rate limits") All the rate limited API calls are returning information about the current rate limit period in the following HTTP headers: | Header | Description | | ---------------------- | -------------------------------------------------------------------------- | | X-Rate-Limit-Remaining | The maximum number of requests remaining in the current rate limit period. | | X-Rate-Limit-Reset | The time when the current rate limit period resets. | When the rate limit is exceeded by a request, the API returns with a `HTTP 429 - Too many requests` status along with a `Retry-After` HTTP header. ## Authentication[​](#authentication "Direct link to Authentication") * HTTP: Bearer Auth To authenticate with the API you have to fill the `Authorization` HTTP request header with your SCIM token. You can retrieve your credentials on the [Authentication & Provisioning page](https://app.configcat.com/organization/authentication). Example: `Bearer 12345abcdef` | Security Scheme Type: | http | | -------------------------- | ------ | | HTTP Authorization Scheme: | bearer | ### Contact ConfigCat: URL: ### Terms of Service --- # Create Group ``` POST /v2/:organizationId/Groups ``` This endpoint creates a new group with the given attributes. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 401 * 409 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Create User ``` POST /v2/:organizationId/Users ``` This endpoint creates a new user with the given attributes. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 201 * 400 * 401 * 409 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete Group ``` DELETE /v2/:organizationId/Groups/:groupId ``` This endpoint deletes an existing group. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 401 * 404 * 429 No content. Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Delete User ``` DELETE /v2/:organizationId/Users/:userId ``` This endpoint deletes an existing user. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 204 * 401 * 404 * 429 No content. Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Group ``` GET /v2/:organizationId/Groups/:groupId ``` This endpoint returns a group. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Groups ``` GET /v2/:organizationId/Groups ``` This endpoint returns a list of groups. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Resource Type ``` GET /v2/:organizationId/ResourceTypes/:resourceTypeId ``` This endpoint returns a resource type. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Resource Types ``` GET /v2/:organizationId/ResourceTypes ``` This endpoint returns the supported resource types. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Schema ``` GET /v2/:organizationId/Schemas/:schemaId ``` This endpoint returns a schema. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Schemas ``` GET /v2/:organizationId/Schemas ``` This endpoint returns the supported schema list. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Service Provider Config ``` GET /v2/:organizationId/ServiceProviderConfig ``` This endpoint returns the service provider config. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get User ``` GET /v2/:organizationId/Users/:userId ``` This endpoint returns a user. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Get Users ``` GET /v2/:organizationId/Users ``` This endpoint returns a list of users. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace Group ``` PUT /v2/:organizationId/Groups/:groupId ``` This endpoint updates an existing group by replacing all attributes present in the request. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Replace User ``` PUT /v2/:organizationId/Users/:userId ``` This endpoint updates an existing user by replacing all attributes present in the request. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 400 * 401 * 404 * 429 Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Update Group ``` PATCH /v2/:organizationId/Groups/:groupId ``` This endpoint updates an existing group by applying JSON Patch operations. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 401 * 404 * 429 No content. Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- # Update User ``` PATCH /v2/:organizationId/Users/:userId ``` This endpoint updates an existing user by applying JSON Patch operations. ## Request[​](#request "Direct link to Request") ## Responses[​](#responses "Direct link to Responses") * 200 * 204 * 400 * 401 * 404 * 429 No content. Unauthorized. In case of the SCIM token is invalid. Too many requests. In case of the request rate exceeds the rate limits. --- ### Basics Familiarize with ConfigCat basics. * [Getting started](https://configcat.com/docs/docs/getting-started/.md) * [Main Concepts](https://configcat.com/docs/docs/main-concepts/.md) * [Targeting](https://configcat.com/docs/docs/targeting/targeting-overview/.md) * [What is a config JSON download?](https://configcat.com/docs/docs/requests/.md) * [Network Traffic](https://configcat.com/docs/docs/network-traffic/.md) * [Plans, Purchase & Billing](https://configcat.com/docs/docs/purchase/.md) * [Organization & Roles](https://configcat.com/docs/docs/organization/.md) * [News & Product Updates](https://configcat.com/docs/docs/news/.md) * [FAQ](https://configcat.com/docs/docs/faq/.md) * [Glossary](https://configcat.com/docs/docs/glossary/.md) --- # Polling modes & Caching There are 3 different ways (polling modes) to control caching. ## Auto polling (default)[​](#auto-polling-default "Direct link to Auto polling (default)") In auto polling mode, the ConfigCat SDK downloads the latest feature flags and settings from the ConfigCat CDN automatically and stores them in the cache. By default, this happens every 60 seconds. You can set the polling interval to any value between 1 and 2,147,483 seconds. ## Lazy loading[​](#lazy-loading "Direct link to Lazy loading") In lazy loading mode, the ConfigCat SDK downloads the latest feature flags and settings from the ConfigCat CDN only if they are not already present in the cache, or if the cache has expired. By default, the cache Time To Live (TTL) value is 60 seconds. You can set it to any value between 1 and 2,147,483,647 seconds. ## Manual polling[​](#manual-polling "Direct link to Manual polling") Manual polling gives you full control over when the feature flags and settings are downloaded from the ConfigCat CDN. The ConfigCat SDK will not download them automatically. You can (and should) update the cache manually, by calling a `forceRefresh()` - this will download the latest feature flags and settings and update the cache. This animation explains the different polling modes: ## Caching[​](#caching "Direct link to Caching") ConfigCat SDKs in their default setup store all the information they need for feature flag evaluation in memory. This behavior is extendable with custom cache implementations that you can use for pointing the SDK to your own data storage. The main reason for caching is to accelerate serving feature flag evaluation requests when your application is in a stateless environment or frequently restarts. When the SDK notices that it has a valid cache entry to work with, it will use the data from the cache rather than initiating a new HTTP request towards ConfigCat. The cache's validity is based on the polling interval in case of [auto polling](#auto-polling-default) or on the TTL in case of [lazy loading](#lazy-loading). info See the [SDK specific docs](https://configcat.com/docs/docs/sdk-reference/overview/.md) for your desired platform to learn how to use custom cache implementations. ### Offline mode[​](#offline-mode "Direct link to Offline mode") ConfigCat SDKs have the capability to go offline. In offline mode, they work only from the configured cache and never communicate with ConfigCat over HTTP. This allows you to set up a centralized cache that only one online ConfigCat SDK writes, but serves many offline ones. info See the [SDK specific docs](https://configcat.com/docs/docs/sdk-reference/overview/.md) for your desired platform to learn how to enable offline mode. ### Shared cache[​](#shared-cache "Direct link to Shared cache") As of certain versions, ConfigCat SDKs support using a shared cache. To achieve that, each SDK constructs the key for identifying a specific cache entry based on the SDK key passed at initialization. This means each platform specific SDK that uses the same SDK key will use the same cache entry. Mixing this behavior with [offline mode](#offline-mode), you can have a centralized shared cache that serves many SDKs regardless of what platform they run on. Support for shared caching was introduced in these SDK versions: | SDK | Version | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | .NET | >= [v8.1.0](https://github.com/configcat/.net-sdk/releases) | | Android (Java) | >= [v9.0.0](https://github.com/configcat/android-sdk/releases) | | C++ | >= [v3.0.0](https://github.com/configcat/cpp-sdk/releases) | | Dart (Flutter) | >= [v3.0.0](https://github.com/configcat/dart-sdk/releases) | | Elixir | >= [v3.0.0](https://github.com/configcat/elixir-sdk/releases) | | Go | >= [v8.0.0](https://github.com/configcat/go-sdk/releases) | | Java | >= [v8.2.0](https://github.com/configcat/java-sdk/releases) | | JavaScript (Browser, Bun, Chromium Extension, Cloudflare Worker, Deno, Node.js) | >= [v1.0.0](https://github.com/configcat/js-unified-sdk/releases) | | JS - Legacy | >= [v8.0.0](https://github.com/configcat/js-sdk/releases) | | JS SSR - Legacy | >= [v7.0.0](https://github.com/configcat/js-ssr-sdk/releases) | | Kotlin | >= [v2.0.0](https://github.com/configcat/kotlin-sdk/releases) | | Node.js - Legacy | >= [v10.0.0](https://github.com/configcat/node-sdk/releases) | | PHP | >= [v8.0.0](https://github.com/configcat/php-sdk/releases) | | Python | >= [v8.0.0](https://github.com/configcat/python-sdk/releases) | | React | >= [v3.0.0](https://github.com/configcat/react-sdk/releases) | | Ruby | >= [v7.0.0](https://github.com/configcat/ruby-sdk/releases) | | Rust | >= [v0.1.0](https://github.com/configcat/rust-sdk/releases) | | Swift (iOS) | >= [v10.0.0](https://github.com/configcat/swift-sdk/releases) | --- # Command Line Interface (CLI) The [ConfigCat Command Line Interface (CLI)](https://github.com/configcat/cli) allows you to interact with the [Public Management API](https://configcat.com/docs/docs/api/reference/configcat-public-management-api/.md) via the command line. It supports most functionality found on the ConfigCat Dashboard. You can manage ConfigCat resources like Feature Flags, Targeting / Percentage rules, Products, Configs, Environments, and more. The CLI also has the ability to [scan your source code](https://configcat.com/docs/docs/advanced/code-references/overview/.md) for feature flag and setting usage and upload the found code references to ConfigCat. Finally, the CLI provides a few useful utilities, such as validating a config JSON file, downloading one from the ConfigCat CDN by SDK Key, etc. These can come in handy when you use [flag overrides](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#flag-overrides) in your application. ``` configcat This is the Command Line Tool of ConfigCat. ConfigCat is a hosted feature flag service: https://configcat.com For more information, see the documentation here: https://configcat.com/docs/advanced/cli Usage: configcat [command] [options] Options: -v, --verbose Print detailed execution information -ni, --non-interactive Turn off progress rendering and interactive features --version Show version information -?, -h, --help Show help and usage information Commands: setup Setup the CLI with Public Management API host and credentials ls List all Product, Config, and Environment IDs p, product Manage Products c, config Manage Configs webhook, wh Manage Webhooks e, environment Manage Environments f, flag, s, setting Manage Feature Flags & Settings f2, flag-v2, s2, setting-v2 Manage V2 Feature Flags & Settings seg, segment Manage Segments permission-group, pg Manage Permission Groups m, member Manage Members t, tag Manage Tags k, sdk-key List SDK Keys scan Scan files for Feature Flag & Setting usages config-json Config JSON-related utilities w, workspace Manage the CLI workspace. When set, the CLI's interactive mode filters Product and Config selectors by the values set in the workspace Use "configcat [command] -?" for more information about a command. ``` ## Reference[​](#reference "Direct link to Reference") See the [command reference documentation](https://configcat.github.io/cli/) for more information about each available command. ## Getting started[​](#getting-started "Direct link to Getting started") The following instructions will guide you through the first steps to start using this tool. ### Installation[​](#installation "Direct link to Installation") You can install the CLI on multiple operating systems using the following sources. **Homebrew (macOS / Linux)** Install the CLI with [Homebrew](https://brew.sh) from [ConfigCat's tap](https://github.com/configcat/homebrew-tap) by executing the following command: ``` brew tap configcat/tap brew install configcat ``` **Snap (Linux)** Install the CLI with [Snapcraft](https://snapcraft.io) by executing the following command: ``` sudo snap install configcat ``` **Scoop (Windows)** Install the CLI with [Scoop](https://scoop.sh) from [ConfigCat's bucket](https://github.com/configcat/scoop-configcat) by executing the following command: ``` scoop bucket add configcat https://github.com/configcat/scoop-configcat scoop install configcat ``` **Chocolatey (Windows)** Install the CLI with [Chocolatey](https://chocolatey.org/) by executing the following command: ``` choco install configcat ``` **.NET tool / NuGet.org** The CLI can be installed as a [.NET tool](https://learn.microsoft.com/en-us/dotnet/core/tools/global-tools) via the .NET SDK. ``` dotnet tool install -g configcat-cli ``` After installing, you can execute the CLI using the `configcat` command: ``` configcat scan "/repository" --print --config-id ``` **Docker** The CLI can be executed from a [Docker](https://www.docker.com/) image. ``` docker pull configcat/cli ``` An example of how to scan a repository for feature flag & setting references with the docker image. ``` docker run --rm \ --env CONFIGCAT_API_HOST= \ --env CONFIGCAT_API_USER= \ --env CONFIGCAT_API_PASS= \ -v /path/to/repository:/repository \ configcat/cli scan "/repository" --print --config-id ``` **Install Script** On Unix platforms, you can install the CLI by executing an install script. ``` curl -fsSL "https://raw.githubusercontent.com/configcat/cli/main/scripts/install.sh" | bash ``` By default, the script downloads the OS specific artifact from the latest [GitHub Release](https://github.com/configcat/cli/releases) with `curl` and moves it into the `/usr/local/bin` directory. It might happen that you don't have permissions to write into `/usr/local/bin`, then you should execute the install script with `sudo`. ``` curl -fsSL "https://raw.githubusercontent.com/configcat/cli/main/scripts/install.sh" | sudo bash ``` The script accepts the following input parameters: | Parameter | Description | Default value | | ----------------- | ------------------------------------------------ | ---------------- | | `-d`, `--dir` | The directory where the CLI should be installed. | `/usr/local/bin` | | `-v`, `--version` | The desired version to install. | `latest` | | `-a`, `--arch` | The desired architecture to install. | `x64` | Available **architecture** values for Linux: `x64`, `musl-x64`, `arm`, `arm64`. Available **architecture** values for macOS: `x64`, `arm64`. **Script usage examples**: *Custom installation directory*: ``` curl -fsSL "https://raw.githubusercontent.com/configcat/cli/main/scripts/install.sh" | bash -s -- -d=/path/to/install ``` *Install a different version*: ``` curl -fsSL "https://raw.githubusercontent.com/configcat/cli/main/scripts/install.sh" | bash -s -- -v=1.4.2 ``` *Install with custom architecture*: ``` curl -fsSL "https://raw.githubusercontent.com/configcat/cli/main/scripts/install.sh" | bash -s -- -a=arm ``` **Standalone executables** You can download the executables directly from [GitHub Releases](https://github.com/configcat/cli/releases) for your desired platform. ### Setup[​](#setup "Direct link to Setup") After a successful installation, the CLI must be set up with your [ConfigCat Public Management API credentials](https://app.configcat.com/my-account/public-api-credentials). You can do this by using the `configcat setup` command. ![interactive](/docs/assets/cli/cli-setup.gif) #### Environment variables[​](#environment-variables "Direct link to Environment variables") Besides the `setup` command above, the CLI can read your credentials from the following environment variables. | Name | Description | | -------------------- | ---------------------------------------- | | `CONFIGCAT_API_HOST` | API host (default: `api.configcat.com`). | | `CONFIGCAT_API_USER` | API basic auth user name. | | `CONFIGCAT_API_PASS` | API basic auth password. | caution When any of these environment variables are set, the CLI will use them over the local values set by the `configcat setup` command. ## Modes[​](#modes "Direct link to Modes") The CLI supports both interactive and argument driven execution. When no arguments provided for a command and user input is enabled (stdout is not redirected), the CLI automatically activates interactive mode. ### Interactive[​](#interactive "Direct link to Interactive") ![interactive](/docs/assets/cli/cli-flag-create.gif) ### With arguments[​](#with-arguments "Direct link to With arguments") The same operation with command arguments would look like this: ``` configcat flag-v2 create \ --config-id \ --name "My awesome feature" \ --hint "This is my awesome feature" \ --key my_awesome_feature --type boolean \ --tag-ids \ --init-values-per-environment : \ ``` info Each `create` command writes the newly created resource's ID to the standard output so you can save that for further operations. Example: ``` #!/bin/bash ORGANIZATION_ID="" PRODUCT_ID=$(configcat product create -o $ORGANIZATION_ID -n "") CONFIG_ID=$(configcat config create -p $PRODUCT_ID -n "") ``` info You can change the output format of several commands' result to JSON with the `--json` option, like: `configcat flag ls --json`. See more about these commands in the [command reference documentation](https://configcat.github.io/cli/). ## Scan & upload code references[​](#scan--upload-code-references "Direct link to Scan & upload code references") The CLI has the ability to scan your source code for feature flag and setting usage and upload the found code references to ConfigCat. You can read more about this feature [here](https://configcat.com/docs/docs/advanced/code-references/overview/.md). ## Examples[​](#examples "Direct link to Examples") Here are a few examples showing the true power of the CLI. ### Create a feature flag[​](#create-a-feature-flag "Direct link to Create a feature flag") The following example shows how you can create a feature flag in a specific config. ![create flag](/docs/assets/cli/cli-flag-create.gif) ### Value update[​](#value-update "Direct link to Value update") The following example shows how you can update the value of a feature flag in a specific environment. ![flag value update](/docs/assets/cli/cli-flag-update.gif) ### Add targeting rules[​](#add-targeting-rules "Direct link to Add targeting rules") The following example shows how you can add targeting rules to a feature flag. ![flag targeting add](/docs/assets/cli/cli-flag-targeting-add.gif) ### Add percentage options[​](#add-percentage-options "Direct link to Add percentage options") The following example shows how you can set percentage options in a feature flag. ![flag percentage add](/docs/assets/cli/cli-flag-targeting-percentage.gif) --- # Azure DevOps - Scan your source code for feature flags This section describes how to use the [ConfigCat CLI](https://configcat.com/docs/docs/advanced/cli/.md) in [Azure DevOps Pipelines](https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in Azure DevOps [Pipeline Variables](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables) with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![Azure secrets](/docs/assets/cli/scan/azure_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Create a new or open your existing `azure-pipelines.yml` file, and add the following [job](https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema#job) to your `jobs` definition. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` - job: configcat_scan_and_upload container: configcat/cli:azure-devops-2.4.2 pool: vmImage: ubuntu-latest steps: - checkout: self persistCredentials: true - script: configcat scan $(Build.Repository.LocalPath) --config-id=PASTE-YOUR-CONFIG-ID-HERE --repo=$(Build.Repository.Name) --branch=$(Build.SourceBranchName) --file-url-template="$(Build.Repository.Uri)?path={filePath}&version=GC{commitHash}&line={lineNumber}&lineStartColumn=1&lineEndColumn=1" --commit-url-template="$(Build.Repository.Uri)/commit/{commitHash}" --runner="ConfigCat Azure DevOps Job" --upload --non-interactive name: scan_repository env: CONFIGCAT_API_PASS: $(CONFIGCAT_API_PASS) CONFIGCAT_API_USER: $(CONFIGCAT_API_USER) ``` info If you are using a different VCS than Azure DevOps' Git, you should set the `--file-url-template` and `--commit-url-template` according to your VCS provider. 4. Commit & push your changes. Scan reports are uploaded for each branch of your repository that triggers the job. --- # Bitbucket Pipe - Scan your source code for feature flags This section describes how to use ConfigCat's [Bitbucket Pipe](https://bitbucket.org/product/features/pipelines/integrations?p=configcat/scan-repository-pipe) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. You can find more information about Bitbucket Pipelines [here](https://bitbucket.org/product/features/pipelines). ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in secure pipeline variables with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![Bitbucket Pipe secrets](/docs/assets/cli/scan/pipe_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Add the following snippet to the script section of your `bitbucket-pipelines.yml` file. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` - pipe: configcat/scan-repository-pipe:1.8.1 variables: CONFIG_ID: 'PASTE-YOUR-CONFIG-ID-HERE' # LINE_COUNT: '3' # optional # TIMEOUT: '1800' # optional # SUB_FOLDER: '/src' # optional # EXCLUDE_KEYS: > # optional # flag_key_to_exclude_1 # flag_key_to_exclude_2 # ALIAS_PATTERNS: (\w+) = :CC_KEY,const (\w+) = feature_flags\.enabled\(:CC_KEY\) # optional # USAGE_PATTERNS: feature_flags\.enabled\(:CC_KEY\) # VERBOSE: 'true' # optional ``` 4. Commit & push your changes. Scan reports are uploaded for each branch of your repository that triggers the job. ## Available Options[​](#available-options "Direct link to Available Options") | Parameter | Description | Required | Default | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------- | | `CONFIG_ID` | ID of the ConfigCat config to scan against. | ☑ | | | `CONFIGCAT_API_HOST` | ConfigCat Management API host. | | `api.configcat.com` | | `LINE_COUNT` | Context line count before and after the reference line. (min: 1, max: 10) | | 4 | | `TIMEOUT` | Scan timeout in seconds (default: 1800, min: 60). If the scan does not finish within this time, it is aborted. No partial results are returned. The command exits with a timeout error. | | 1800 | | `SUB_FOLDER` | Sub-folder to scan, relative to the repository root folder. | | | | `EXCLUDE_KEYS` | List of feature flag keys that must be excluded from the scan report. | | | | `ALIAS_PATTERNS` | Comma delimited list of custom regex patterns used to search for additional aliases. | | | | `USAGE_PATTERNS` | Comma delimited list of custom regex patterns that describe additional feature flag key usages. | | | | `VERBOSE` | Turns on detailed logging. | | false | --- # Bitrise - Scan your source code for feature flags This section describes how to use ConfigCat's [Bitrise Step](https://www.bitrise.io/integrations/steps/configcat-feature-flag-sync) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. [Bitrise](https://www.bitrise.io/) is full-featured mobile CI/CD platform. You can find more information about Bitrise Steps [here](https://devcenter.bitrise.io/en/steps-and-workflows/introduction-to-steps.html). ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in secure pipeline variables with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![Bitrise secrets](/docs/assets/cli/scan/bitrise_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Add the following step to the workflows section of your `bitrise.yml` file. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` - configcat-feature-flag-sync@0: inputs: - configcat_config_id: 'PASTE-YOUR-CONFIG-ID-HERE' # required # - line-count: 3 # optional # - sub-folder: 'src' # optional # - exclude-keys: > # optional # flag_key_to_exclude_1 # flag_key_to_exclude_2 # - alias-patterns: "(\w+) = :CC_KEY,const (\w+) = feature_flags\.enabled\(:CC_KEY\)" # optional # - usage-patterns: feature_flags\.enabled\(:CC_KEY\) # optional # - verbose: true # optional ``` 4. Commit & push your changes. Scan reports are uploaded for each branch of your repository that triggers the job. ## Available Options[​](#available-options "Direct link to Available Options") | Parameter | Description | Required | Default | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------- | | `configcat_config_id` | The [config ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id) tells the step which feature flags it should search for in your source code. | ☑ | | | `configcat_api_host` | ConfigCat Management API host. | | `api.configcat.com` | | `line_count` | Code snippet line count before and after the reference line. (min: 1, max: 10) | | 4 | | `sub_folder` | Sub-folder to scan, relative to the repository root folder. | | | | `exclude-keys` | List of feature flag keys that must be excluded from the scan report. | | | | `alias-patterns` | Comma delimited list of custom regex patterns used to search for additional aliases. | | | | `usage-patterns` | Comma delimited list of custom regex patterns that describe additional feature flag key usages. | | | | `verbose` | Turns on detailed logging. | | false | --- # CircleCI Orb - Scan your source code for feature flags This section describes how to use ConfigCat's [CircleCI Orb](https://circleci.com/developer/orbs/orb/configcat/scan-repository) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. You can find more information about CircleCI Orbs [here](https://circleci.com/orbs/). ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in [CircleCI Environment Variables](https://circleci.com/docs/2.0/env-vars/#setting-an-environment-variable-in-a-project) with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![CircleCI Orb secrets](/docs/assets/cli/scan/cco_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Create a new CircleCI YAML config in your repository under the `.circleci` folder, and put the following snippet into it. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` version: 2.1 orbs: configcat: configcat/scan-repository@1.11.1 workflows: main: jobs: - configcat/scan: config-id: PASTE-YOUR-CONFIG-ID-HERE # required file-url-template: 'https://github.com/your/repo/blob/{commitHash}/{filePath}#L{lineNumber}' # optional commit-url-template: 'https://github.com/your/repo/commit/{commitHash}' # optional # line-count: 3 # optional # timeout: 1800 # optional # sub-folder: 'src' # optional # exclude-keys: > # optional # flag_key_to_exclude_1 # flag_key_to_exclude_2 # alias-patterns: (\w+) = :CC_KEY,const (\w+) = feature_flags\.enabled\(:CC_KEY\) # optional # usage-patterns: feature_flags\.enabled\(:CC_KEY\) # optional # verbose: true # optional ``` 4. Commit & push your changes. The above example configures a workflow that executes the scan and code reference upload on every git `push` event. Scan reports are uploaded for each branch of your repository that triggers the workflow. ## Available Options[​](#available-options "Direct link to Available Options") | Parameter | Description | Required | Default | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------- | | `config-id` | ID of the ConfigCat config to scan against. | ☑ | | | `api-host` | ConfigCat Management API host. | | `api.configcat.com` | | `api-user` | Name of the environment variable where the [ConfigCat Management API basic authentication username](https://app.configcat.com/my-account/public-api-credentials) is stored. | | CONFIGCAT\_API\_USER | | `api-pass` | Name of the environment variable where the [ConfigCat Management API basic authentication password](https://app.configcat.com/my-account/public-api-credentials) is stored. | | CONFIGCAT\_API\_PASS | | `file-url-template` | Template url used to generate VCS file links. Available template parameters: `commitHash`, `filePath`, `lineNumber`. Example: `https://github.com/my/repo/blob/{commitHash}/{filePath}#L{lineNumber}` | | | | `commit-url-template` | Template url used to generate VCS commit links. Available template parameters: `commitHash`. Example: `https://github.com/my/repo/commit/{commitHash}` | | | | `line-count` | Context line count before and after the reference line. (min: 1, max: 10) | | 4 | | `timeout` | Scan timeout in seconds (default: 1800, min: 60). If the scan does not finish within this time, it is aborted. No partial results are returned. The command exits with a timeout error. | | 1800 | | `sub-folder` | Sub-folder to scan, relative to the repository root folder. | | | | `exclude-keys` | List of feature flag keys that must be excluded from the scan report. | | | | `alias-patterns` | Comma delimited list of custom regex patterns used to search for additional aliases. | | | | `usage-patterns` | Comma delimited list of custom regex patterns that describe additional feature flag key usages. | | | | `verbose` | Turns on detailed logging. | | false | --- # GitHub Action - Scan your source code for feature flags This section describes how to use ConfigCat's [GitHub Action](https://github.com/marketplace/actions/configcat-scan-repository) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. You can find more information about GitHub Actions [here](https://github.com/features/actions). ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in your repository's [GitHub Secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![Github Action secrets](/docs/assets/cli/scan/gh_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Create a new Actions workflow in your GitHub repository under the `.github/workflows` folder, and put the following snippet into it. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` on: [push] name: Code references jobs: scan-repo: runs-on: ubuntu-latest name: Scan repository for code references steps: - name: Checkout uses: actions/checkout@v3 - name: Scan & upload uses: configcat/scan-repository@v2 with: api-user: ${{ secrets.CONFIGCAT_API_USER }} api-pass: ${{ secrets.CONFIGCAT_API_PASS }} config-id: PASTE-YOUR-CONFIG-ID-HERE # line-count: 5 # optional # timeout: 1800 # optional # sub-folder: src # optional # exclude-keys: > # optional # flag_key_to_exclude_1 # flag_key_to_exclude_2 # alias-patterns: (\w+) = :CC_KEY,const (\w+) = feature_flags\.enabled\(:CC_KEY\) #optional # usage-patterns: feature_flags\.enabled\(:CC_KEY\) # optional, comma delimited flag key usage patterns # verbose: true # optional ``` 4. Commit & push your action. The above example configures a workflow that executes the scan and code references upload on every git `push` event. Scan reports are uploaded for each branch of your repository that triggers the workflow. ## Available Options[​](#available-options "Direct link to Available Options") | Parameter | Description | Required | Default | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------- | | `config-id` | ID of the ConfigCat config to scan against. | ☑ | | | `api-user` | [ConfigCat Management API basic authentication username](https://app.configcat.com/my-account/public-api-credentials). | ☑ | | | `api-pass` | [ConfigCat Management API basic authentication password](https://app.configcat.com/my-account/public-api-credentials). | ☑ | | | `api-host` | ConfigCat Management API host. | | `api.configcat.com` | | `line-count` | Context line count before and after the reference line. (min: 1, max: 10) | | 4 | | `timeout` | Scan timeout in seconds (default: 1800, min: 60). If the scan does not finish within this time, it is aborted. No partial results are returned. The command exits with a timeout error. | | 1800 | | `sub-folder` | Sub-folder to scan, relative to the repository root folder. | | | | `exclude-keys` | List of feature flag keys that must be excluded from the scan report. | | | | `alias-patterns` | Comma delimited list of custom regex patterns used to search for additional aliases. | | | | `usage-patterns` | Comma delimited list of custom regex patterns that describe additional feature flag key usages. | | | | `verbose` | Turns on detailed logging. | | false | --- # GitLab - Scan your source code for feature flags This section describes how to use the [ConfigCat CLI](https://configcat.com/docs/docs/advanced/cli/.md) in [GitLab CI/CD](https://docs.gitlab.com/ee/ci/) to automatically scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. ## Setup[​](#setup "Direct link to Setup") 1. Create a new [ConfigCat Management API credential](https://app.configcat.com/my-account/public-api-credentials) and store its values in GitLab's [CI/CD Variables](https://docs.gitlab.com/ee/ci/variables/) with the following names: `CONFIGCAT_API_USER`, `CONFIGCAT_API_PASS`. ![GitLab secrets](/docs/assets/cli/scan/gl_secrets.png) 2. Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). 3. Create a new or open your existing `.gitlab-ci.yml` file, and put the following job into it. Don't forget to replace the `PASTE-YOUR-CONFIG-ID-HERE` value with your actual Config ID. ``` configcat-scan-repository: stage: deploy # the job will run in the deploy phase, but you can choose from any other phases you have image: name: configcat/cli:2.4.2 entrypoint: [''] script: - configcat scan $CI_PROJECT_DIR --config-id=PASTE-YOUR-CONFIG-ID-HERE --repo=${CI_PROJECT_NAME} --branch=${CI_COMMIT_REF_NAME} --file-url-template=https://gitlab.com/${CI_PROJECT_PATH}/blob/{commitHash}/{filePath}#L{lineNumber} --commit-url-template=https://gitlab.com/${CI_PROJECT_PATH}/commit/{commitHash} --runner="ConfigCat GitLab Job" --upload --non-interactive ``` 4. Commit & push your changes. Scan reports are uploaded for each branch of your repository that triggers the job. --- # CLI - Add to CI/CD pipelines manually This section describes how to use the [ConfigCat CLI](https://configcat.com/docs/docs/advanced/cli/.md) to scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. ## Prerequisites[​](#prerequisites "Direct link to Prerequisites") * [Install](https://configcat.com/docs/docs/advanced/cli/.md#installation) the CLI in your CI/CD or local environment. * [Setup](https://configcat.com/docs/docs/advanced/cli/.md#setup) the CLI with your ConfigCat Management API credentials. * Get your selected [Config's ID](https://configcat.com/docs/docs/advanced/code-references/overview/.md#config-id). ## Scan & Upload[​](#scan--upload "Direct link to Scan & Upload") To initiate the scanning with uploading the results, you can use the `scan` command with the `--upload` option. ### With Git VCS[​](#with-git-vcs "Direct link to With Git VCS") The scan command detects when it's being executed on a Git repository and automatically [extracts additional information](https://configcat.com/docs/docs/advanced/code-references/overview/.md#scanning-git-repositories). The following snippet shows a minimal example that uses only the required parameters in the case of a Git repository. ``` configcat scan /path/to/your/repo \ --config-id YOUR-CONFIG-ID \ # required --repo YOUR-REPOSITORY-NAME \ # required --upload # upload the scan report ``` You can use the optional template URL parameters for generating VCS links to your source code. ``` configcat scan /path/to/your/repo \ --config-id YOUR-CONFIG-ID \ # required --repo YOUR-REPOSITORY-NAME \ # required --file-url-template "https://github.com/my/repo/blob/{commitHash}/{filePath}#L{lineNumber}" \ # optional, used to generate VCS file links --commit-url-template "https://github.com/my/repo/commit/{commitHash}" \ # optional, used to generate VCS commit links --upload # upload the scan report ``` info The template parameters (`filePath`, `lineNumber`, and `commitHash`) are automatically replaced by the CLI based on the collected information from the Git repository. ### With Non-Git VCS[​](#with-non-git-vcs "Direct link to With Non-Git VCS") As the `scan` command cannot determine such information as `branch` and `commitHash` when you execute it on a non-Git repository, you have to set these parameters manually. ``` configcat scan /path/to/your/repo \ --config-id YOUR-CONFIG-ID \ # required --repo YOUR-REPOSITORY-NAME \ # required --branch BRANCH-NAME \ # required in case of non-git repository --commit-hash \ # optional, used to show it on the report and generate commit links --file-url-template "https://github.com/my/repo/blob/{commitHash}/{filePath}#L{lineNumber}" \ # optional, used to generate VCS file links --commit-url-template "https://github.com/my/repo/commit/{commitHash}" \ # optional, used to generate VCS commit links --upload # upload the scan report ``` ### Docker[​](#docker "Direct link to Docker") After [installing](https://configcat.com/docs/docs/advanced/cli/.md#installation) the ConfigCat CLI with Docker, you can scan your repository by mounting its folder as a volume and setting the [ConfigCat Management API credentials](https://app.configcat.com/my-account/public-api-credentials) as environment variables on the executing container. ``` docker run --rm \ -v /path/to/your/repo:/repository \ # mount the repository as volume -e CONFIGCAT_API_USER=YOUR-API-USER \ # Management API username -e CONFIGCAT_API_PASS=YOUR-API-PASS \ # Management API password configcat/cli scan /repository \ # scan the mounted volume --config-id YOUR-CONFIG-ID \ # required --repo YOUR-REPOSITORY-NAME \ # required --upload # upload the scan report ``` ## Reference[​](#reference "Direct link to Reference") See the `scan` command's [reference documentation](https://configcat.github.io/cli/configcat-scan.html) for all available command parameters. --- # Scan & Upload Code References Overview ConfigCat's [CLI](https://configcat.com/docs/docs/advanced/cli/.md) has the ability to scan your source code for feature flag and setting usages and upload the found code references to ConfigCat. This feature makes the elimination of the technical debt easier, as it can show which repositories reference your feature flags and settings in one centralized place on your [Dashboard](https://app.configcat.com). You can integrate the CLI into your CI/CD pipeline or use it with other execution mechanisms like scheduled jobs or VCS push triggered workflows. ## Scan[​](#scan "Direct link to Scan") The following example shows a simple scan execution that prints the scan result to the console. The `scan` command searches for every feature flag and setting key defined within a selected Config. ![ConfigCat scan command in action](/docs/assets/cli/cli-scan.gif) If you want to see this in action on your project, run the following command in its root folder: ``` configcat scan . --print ``` See the `scan` command's [reference documentation](https://configcat.github.io/cli/configcat-scan.html) for all available command parameters. ### Deleted Flags[​](#deleted-flags "Direct link to Deleted Flags") As part of the scanning operation, the CLI gathers all deleted feature flags and settings from the last 180 days and looks for their usage in your source code. When it finds a reference to a deleted feature flag or setting, it prints a warning that lists their keys. ``` [warning]: 5 deleted feature flag/setting reference(s) found in 4 file(s). Keys: [featureThatWasDeleted1, featureThatWasDeleted2] ``` ### Exclude Flags from Scanning[​](#exclude-flags-from-scanning "Direct link to Exclude Flags from Scanning") There's an option to exclude feature flags or settings from the scanning operation by their keys. ``` configcat scan --exclude-flag-keys featureFlagToExclude1 featureFlagToExclude2 ``` ## Config ID[​](#config-id "Direct link to Config ID") In non-interactive environments, like in a CI/CD pipeline, you have to pass the ID of your ConfigCat Config that you want to scan against. The scanner will use this ID to determine which feature flags & settings to search for in your source code. To get the ID of a Config, follow the steps below: 1. Go to your [ConfigCat Dashboard](https://app.configcat.com), select the desired Config, and click the code references icon on one of your feature flags. ![ConfigCat code references button](/docs/assets/cli/scan/code_ref.png) 2. Copy the Config ID from the highlighted box. ![ConfigCat Config ID](/docs/assets/cli/scan/config_id.png) ## How Scanning Works[​](#how-scanning-works "Direct link to How Scanning Works") The scanner looks for feature flag and setting keys between quotation marks (`'` `"` `` ` ``) in the first place. info There's an option to extend the feature flag and setting key usage regex patterns with the `--usage-patterns` argument of the `scan` command. ``` configcat scan --usage-patterns "" "" ``` Usage patterns can also be set via the `CONFIGCAT_USAGE_PATTERNS` environment variable as a comma delimited list. ``` export CONFIGCAT_USAGE_PATTERNS=","; ``` The regex pattern must include the `CC_KEY` placeholder that represents the actual feature flag or setting key in your code. For example, the following pattern allows the recognition of Ruby symbols as flag key usages: ``` configcat scan --usage-patterns ":CC_KEY" ``` It will match the following usage: ``` if FeatureFlags.enabled(:my_feature_key) #... end ``` ### Aliases[​](#aliases "Direct link to Aliases") The found keys' context is examined for **aliases**, like variables, constants, or enumerations used to store these keys. **Aliases** are treated as indirect references and are included in the searching process. For example, the following `C#` constant's name (`MyAwesomeFeature`) will be recognized as an alias: ``` public static class FeatureFlagKeys { public const string MyAwesomeFeature = "my_awesome_feature"; } ``` The scanner will treat this constant's usage as an indirect reference to the flag. ``` if (await configCatClient.GetValueAsync(FeatureFlagKeys.MyAwesomeFeature, false)) { // the feature is on. } ``` info The alias recognition **adapts to the characteristics of different languages**.
For example, it can find aliases in `Go` constants/variable assignments: ``` const ( myAwesomeFeature string = "my_awesome_feature" ) myAwesomeFeature := "my_awesome_feature" ``` And in `Swift` enums/variable assignments as well: ``` enum FlagKeys : String { case MyAwesomeFeature = "my_awesome_feature" } let myAwesomeFeature: String = "my_awesome_feature" ``` You can check [here](https://raw.githubusercontent.com/configcat/cli/main/test/ConfigCat.Cli.Tests/alias.txt) a bunch of other samples that we tested. info An alias must be at least **30% identical to the feature flag/setting key**. The similarity check is case insensitive and ignores `_` characters. This behavior prevents false recognitions in expressions like `` where `value` shouldn't be treated as alias. ### Custom alias match patterns[​](#custom-alias-match-patterns "Direct link to Custom alias match patterns") There's an option to set custom regex patterns for identifying additional aliases. The `scan` command accepts a list of patterns via the `--alias-patterns` argument. ``` configcat scan --alias-patterns "" "" ``` The CLI also accepts patterns from the `CONFIGCAT_ALIAS_PATTERNS` environment variable as a comma delimited list. ``` export CONFIGCAT_ALIAS_PATTERNS=","; ``` #### Match pattern format[​](#match-pattern-format "Direct link to Match pattern format") The regex pattern must include at least one capture group that represents the actual alias. When more than one group is defined, the first one is selected. To bind the actual flag keys to aliases, the CLI uses a `CC_KEY` placeholder to inject the known keys into the pattern. For example, the following pattern allows to find aliases that point to Ruby symbols: ``` configcat scan --alias-patterns "(\w+) = client\.get_value\(:CC_KEY" ``` It will match to the following usage: ``` # 'my_feature_enabled' is now treated as an alias to the 'my_feature_key' flag. my_feature_enabled = client.get_value(:my_feature_key, false) ``` note The CLI implicitly adds the optional `` ` ``, `'`, `"` wrapping around flag keys, so you don't have to wrap the `CC_KEY` placeholder manually. For example, the pattern `(\w+) = CC_KEY` will either match to `alias = flag_key`, `alias = "flag_key"`, `alias = 'flag_key'`, or ``alias = `flag_key` ``. ### Wrappers[​](#wrappers "Direct link to Wrappers") In addition to aliases, the scanner also looks for different feature flag/setting key usage patterns. This helps to recognize functions and properties used to wrap direct ConfigCat SDK calls as indirect references. Aliases are also included in this search. For example, the scanner will treat the `IsMyAwesomeFeatureEnabled` function of the following `C#` wrapper class as an indirect reference: ``` public class FeatureFlagProvider { public async Task IsMyAwesomeFeatureEnabled(bool defaultValue = false) { return await configCatClient.GetValueAsync("my_awesome_feature", defaultValue); } } ``` And will include its usage in the scan report: ``` if (await featureFlagProvider.IsMyAwesomeFeatureEnabled()) { // the feature is on. } ``` info The scanner uses the following patterns to look for wrapper usages (case insensitive): * `[.|->|::]{settingKeyOrAlias}` * `[.|->|::]get{settingKeyOrAlias}` * `[.|->|::]is{settingKeyOrAlias}` * `[.|->|::]is{settingKeyOrAlias}enabled` Given the key/alias `my_awesome_feature`, the scanner will find any of the following usage examples: * `.my_awesome_feature` (also: `->my_awesome_feature` / `::my_awesome_feature`) * `.MY_AWESOME_FEATURE` (also: `->MY_AWESOME_FEATURE` / `::MY_AWESOME_FEATURE`) * `.get_my_awesome_feature` (also: `->get_my_awesome_feature` / `::get_my_awesome_feature`) * `.GET_MY_AWESOME_FEATURE` (also: `->GET_MY_AWESOME_FEATURE` / `::GET_MY_AWESOME_FEATURE`) * `.is_my_awesome_feature` (also: `->is_my_awesome_feature` / `::is_my_awesome_feature`) * `.is_my_awesome_feature_enabled` (also: `->is_my_awesome_feature_enabled` / `::is_my_awesome_feature_enabled`) * `.myAwesomeFeature` (also: `->myAwesomeFeature` / `::myAwesomeFeature`) * `.getMyAwesomeFeature` (also: `->getMyAwesomeFeature` / `::getMyAwesomeFeature`) * `.isMyAwesomeFeature` (also: `->isMyAwesomeFeature` / `::isMyAwesomeFeature`) * `.isMyAwesomeFeatureEnabled` (also: `->isMyAwesomeFeatureEnabled` / `::isMyAwesomeFeatureEnabled`) * `.IsMyAwesomeFeatureEnabled` (also: `->IsMyAwesomeFeatureEnabled` / `::IsMyAwesomeFeatureEnabled`) ## Upload Scan Reports[​](#upload-scan-reports "Direct link to Upload Scan Reports") You have the option to upload scan reports for each branch of your repository to ConfigCat. Each scan report is associated to one of these branches. The following screenshot shows how an uploaded report looks like. ![ConfigCat code references report](/docs/assets/cli/scan/scan_report.png) ### Scanning Git Repositories[​](#scanning-git-repositories "Direct link to Scanning Git Repositories") The `scan` command automatically detects when it's being executed on a git repository. It collects additional information from Git like the current **branch name**, the actual **commit hash**, and each active **remote branch**. These extra details are used to enrich the uploaded report on the ConfigCat Dashboard with links to your actual source code. info If you are not using Git as VCS, you have to set at least the `--branch` parameter of the `scan` command. ### Template URLs[​](#template-urls "Direct link to Template URLs") The `scan` command's `--file-url-template` and `--commit-url-template` parameters are used for generating links to your repository. Based on the information available during the scanning, the CLI replaces the corresponding template parameters to generate the actual links. * **File URL template**: Used to generate VCS file links.
Available template parameters: * `commitHash` * `filePath` * `lineNumber` With the following example template URL: `https://github.com/my/repo/blob/{commitHash}/{filePath}#L{lineNumber}`
For the file `src/example.js`, the result is: `https://github.com/my/repo/blob/4451d61b63a4b4499ed5c607be6c40ce9eeadb9c/src/example.js#L69` * **Commit URL template**: Used to generate VCS commit links.
Available template parameters: * `commitHash` With the following example template URL: `https://github.com/my/repo/commit/{commitHash}`
For the commit hash `4451d61b63a4b4499ed5c607be6c40ce9eeadb9c`, the result is: `https://github.com/my/repo/commit/4451d61b63a4b4499ed5c607be6c40ce9eeadb9c` info When these template URLs are not set, the uploaded report will not contain VCS links. ### Stale Branches[​](#stale-branches "Direct link to Stale Branches") When the scan is executed on a Git repository, the CLI attaches the currently active remote branches to the uploaded report. This information is used for cleaning up each stale report that belongs to a deleted branch. ### CI/CD Integrations[​](#cicd-integrations "Direct link to CI/CD Integrations") We prepared the following integrations to simplify the usage of the scanner in your CI/CD workflow: * [GitHub Action](https://configcat.com/docs/docs/advanced/code-references/github-action/.md) * [CircleCI Orb](https://configcat.com/docs/docs/advanced/code-references/circleci-orb/.md) * [GitLab CI/CD](https://configcat.com/docs/docs/advanced/code-references/gitlab-ci/.md) * [Azure DevOps](https://configcat.com/docs/docs/advanced/code-references/azure-devops/.md) * [Bitbucket Pipe](https://configcat.com/docs/docs/advanced/code-references/bitbucket-pipe/.md) * [Bitrise Step](https://configcat.com/docs/docs/advanced/code-references/bitrise-step/.md) ### Manual Integration[​](#manual-integration "Direct link to Manual Integration") If your workflow doesn't have an integration, you can follow the instructions [here](https://configcat.com/docs/docs/advanced/code-references/manual/.md) to set scan executions directly with the ConfigCat CLI. ## Ignore Files[​](#ignore-files "Direct link to Ignore Files") The `scan` command respects all include and exclude patterns listed inside `.gitignore` and `.ignore` files within the scanned directory. In addition, you can create an extra `.ccignore` file with patterns that the scanner must take into account. Each pattern must follow the [gitignore pattern format](https://git-scm.com/docs/gitignore#_pattern_format). --- # Config V2 Migration Guide This guide will help you migrate from Config V1 to Config V2. ## What is Config V2?[​](#what-is-config-v2 "Direct link to What is Config V2?") **Config V2 is the next generation of ConfigCat.** It comes with a new Dashboard, Public Management API and SDKs. **Config V2 supports all the features of V1**, so you can continue using those, but **it offers interesting new features as well**. However, you won't be able to use the new features with the V1 versions of the Dashboard, Public Management API and SDKs. Read more about the new features in the [Config V2 Overview](https://configcat.com/docs/docs/advanced/config-v2/.md). ## A few things to consider before migration[​](#a-few-things-to-consider-before-migration "Direct link to A few things to consider before migration") * **Migration from Config V1 means that a V2 config will be copied from the V1 config. The V1 config will remain unchanged and accessible.** The V2 version will have a new SDK key for each environment. * **Config V2 and V1 are completely separate.** They don't affect each other in any way. You can use them side by side. * **There is no automatic sync between the V1 and V2 configs.** If you want to keep them in sync, you have to manually update the V2 config when you make changes to the V1 config and vice versa. * There is no pressure to migrate. Although we have plans to phase out V1 eventually, you can stay on it for a long time. * Once the migration process is started, it's recommended to migrate your V1 configs to V2 as quickly as possible to avoid confusion. * Keep in mind that the [integrations](https://app.configcat.com/integrations) and [webhooks](https://app.configcat.com/product/webhooks) connected to V1 configs are not migrated automatically and you have to set them up manually for the migrated V2 configs. * Every newly created config will be a V2 config by default. ## Migrating from Config V1 to Config V2[​](#migrating-from-config-v1-to-config-v2 "Direct link to Migrating from Config V1 to Config V2") The migration process starts with copying your V1 config to a new V2 one and updating your applications to use the new config. The complete process is the following: ### Step 1: Create the V2 config[​](#step-1-create-the-v2-config "Direct link to Step 1: Create the V2 config") 1. Open the ConfigCat Dashboard and click on the `Start migration` button on top of a V1 config. 2. Click `Create V2 config` to create a new config with the same settings as the V1 config. It's important to note that the V2 config will be created with the same settings as the V1 config and the V1 config will still be accessible and unchanged. ### Step 2: Upgrade the ConfigCat SDK version[​](#step-2-upgrade-the-configcat-sdk-version "Direct link to Step 2: Upgrade the ConfigCat SDK version") In your application, upgrade the ConfigCat SDK to the latest version. Old versions of the SDK will not be able to access the new config. Make sure you upgrade every application that uses the migrated V2 config. Here is a list of the SDKs that support Config V2: [See the supported SDK versions.](https://configcat.com/docs/docs/advanced/config-v2-sdk-compatibility/.md) ### Step 3: Update the ConfigCat SDK Key[​](#step-3-update-the-configcat-sdk-key "Direct link to Step 3: Update the ConfigCat SDK Key") In your application, replace the old ConfigCat SDK Key with the new one (i.e. with the one that belongs to the V2 version of the config) in every environment. The new key can be found on the ConfigCat Dashboard on the V2 config's page. ### Step 4: Deploy your application[​](#step-4-deploy-your-application "Direct link to Step 4: Deploy your application") Deploy your application to production and wait until all your users upgrade to the new version. You can check the migration status on the ConfigCat Dashboard under the migration status page that is available from a config's context menu in the sidebar. ### Step 5: Clean up[​](#step-5-clean-up "Direct link to Step 5: Clean up") After confirming that all your users have transitioned to the latest version of your application, you can finalize the migration by removing the V1 config. To verify that the V1 configs haven't been accessed for a significant period, check the migration status page accessible via a config's context menu in the sidebar. This step helps eliminate any mix-ups and prevents the unintended use of outdated configurations. caution Once you delete the V1 config, you won't be able to restore it. --- # Config V2 SDK Compatibility This table shows which SDK versions support Config V2. Read more about [Config V2](https://configcat.com/docs/docs/advanced/config-v2/.md) | SDK | Version | Release Notes | | ------------------------------------------------------------------------------- | ---------- | ----------------------------------------------------------------- | | .NET | >= v9.1.0 | | | Android (Java) | >= v10.1.0 | | | C++ | >= v4.0.0 | | | Dart (Flutter) | >= v4.1.0 | | | Elixir | >= v4.0.0 | | | Go | >= v9.0.3 | | | Java | >= v9.1.0 | | | JavaScript (Browser, Bun, Chromium Extension, Cloudflare Worker, Deno, Node.js) | >= v1.0.0 | | | JavaScript - Legacy | >= v9.5.0 | | | JavaScript (Chromium Extension) - Legacy | >= v2.4.0 | | | JavaScript (SSR) - Legacy | >= v8.4.0 | | | Kotlin Multiplatform | >= v3.0.0 | | | Node.js - Legacy | >= v11.3.0 | | | PHP 8.1+ | >= v9.1.0 | | | PHP 7.1+ | >= v3.0.0 | | | Python | >= v9.0.3 | | | React | >= v4.6.0 | | | Ruby | >= v8.0.0 | | | Rust | >= v0.1.0 | | | Swift (iOS) | >= v11.0.0 | | | Unreal Engine | >= v2.0.0 | | --- # Config V2 Overview Config V2 is a new version of ConfigCat. It comes with a new Dashboard, Public Management API, SDKs, and features. ## What's new?[​](#whats-new "Direct link to What's new?") * A bunch of new features and improvements listed below. * New config editor UI on the Dashboard. * [New and improved config JSON schema.](https://github.com/configcat/config-json) * New API: [See the API Docs.](https://configcat.com/docs/docs/api/reference/configcat-public-management-api/.md) * New SDKs: [See the supported SDK versions.](https://configcat.com/docs/docs/advanced/config-v2-sdk-compatibility/.md) ## How to migrate from Config V1 to Config V2?[​](#how-to-migrate-from-config-v1-to-config-v2 "Direct link to How to migrate from Config V1 to Config V2?") See the [Config V2 Migration Guide](https://configcat.com/docs/docs/advanced/config-v2-migration-guide/.md). If you get stuck or have any questions about the migration, feel free to [contact us](https://configcat.com/support/). ## New features[​](#new-features "Direct link to New features") ### AND conditions[​](#and-conditions "Direct link to AND conditions") With AND conditions, you can define more complex Targeting Rules, such as "serve this value for the users who use my Android app AND whose email domain is '@example.com'". You can add multiple conditions to a Targeting Rule and they will be evaluated with an AND connection between them. ![AND conditions](/docs/assets/images/and-conditions-3486049a2ab21410deac017b9e3c8aa0.png) ### New comparators[​](#new-comparators "Direct link to New comparators") With the new comparators, you can create Targeting Rules based on date comparisons, array comparisons, and more. * New text and confidential text comparators: `EQUALS`, `NOT EQUALS`, `STARTS WITH ANY OF`, `ENDS WITH ANY OF`, `NOT STARTS WITH ANY OF`, `NOT ENDS WITH ANY OF`. * New array comparators: `ARRAY CONTAINS ANY OF`, `ARRAY NOT CONTAINS ANY OF`. * New date comparators: `BEFORE`, `AFTER`. ![New comparators](/docs/assets/images/new-comparators-774a0ecc871817868db9a4e3f5ceb974.png) ### Prerequisite flags[​](#prerequisite-flags "Direct link to Prerequisite flags") With prerequisite flags, you can create feature flags that depend on other feature flags. Prerequisite feature flags (aka. master feature flag, inter-dependent feature flag, global toggle) are particularly useful for managing complex feature dependencies and ensuring a smooth user experience during feature rollouts. ![Prerequisite flags](/docs/assets/images/prerequisite-flags-926e8a2d5f41f533c7604a8bb3639daa.png) ### Comparison value hints[​](#comparison-value-hints "Direct link to Comparison value hints") With comparison value hints, you can associate arbitrary text with your comparison values. This way you can add a description to your comparison value list items that helps you remember what they are for. ### Percentage Options within Targeting Rules[​](#percentage-options-within-targeting-rules "Direct link to Percentage Options within Targeting Rules") You can add Percentage Options to your Targeting Rules. This is useful if you want to create more complex Targeting Rules, such as "turn on the feature for 20% of the users who are on iOS, and off for 80%". ![Percentage Options within Targeting Rules](/docs/assets/images/percentage-options-within-targeting-rules-836ec813790fbc4d28bcb6e65dbeac9e.png) ### Custom Percentage Attributes[​](#custom-percentage-attributes "Direct link to Custom Percentage Attributes") With custom Percentage Attributes, you can create Percentage Options based on custom attributes. This way you can create Percentage Options based on any of your user attributes. For example, you can create a Percentage Option that is based on the user's company or organization. So you can serve a value for 20% of the users from company A and serve another value for 80% of the users from company B. ![Custom Percentage Attributes](/docs/assets/images/custom-percentage-attributes-0b919593188cac4a7a92a3060bfc389d.png) --- # Data Governance - CDN ConfigCat's Data Governance feature gives you control over how and where your config JSONs are published and served from. This helps you comply with regional data handling requirements such as GDPR. ## CDN - Data Centers[​](#cdn---data-centers "Direct link to CDN - Data Centers") To ensure high availability and low response times worldwide, ConfigCat provides multiple global data centers, each with multiple CDN nodes for built-in redundancy and failover. ### ConfigCat Data Center locations[​](#configcat-data-center-locations "Direct link to ConfigCat Data Center locations") ConfigCat uses Cloudflare Edge Cache Network to deliver the configuration JSONs to the SDKs. Read more about Cloudflare data centers [here](https://www.cloudflare.com/network/). ## How to govern the data?[​](#how-to-govern-the-data "Direct link to How to govern the data?") Currently available geographical areas: ### Global \[Default][​](#global-default "Direct link to Global \[Default]") Provides geo-location based load balancing on all nodes around the globe to ensure the lowest response times. ### EU Only[​](#eu-only "Direct link to EU Only") Compliant with GDPR. This way your data will never leave the EU. ## Set preferences on the Dashboard[​](#set-preferences-on-the-dashboard "Direct link to Set preferences on the Dashboard") Open [Data Governance page](https://app.configcat.com/organization/data-governance) and follow the steps to set preferences. > Only team members with Organization Admin role can access Data Governance preferences. ## Set up the ConfigCat SDK in your application code[​](#set-up-the-configcat-sdk-in-your-application-code "Direct link to Set up the ConfigCat SDK in your application code") Make sure the `dataGovernance` option is specified when initializing the ConfigCat SDK in your application code. > The `dataGovernance` option's value must be in sync with the selected option on the Dashboard. ## Troubleshooting[​](#troubleshooting "Direct link to Troubleshooting") #### What if I forget to specify the `dataGovernance` option?[​](#what-if-i-forget-to-specify-the-datagovernance-option "Direct link to what-if-i-forget-to-specify-the-datagovernance-option") By default, the ConfigCat SDK contacts the ConfigCat Global CDN. However, if you switch to the EU CDN on the Dashboard, your config JSONs will only be published to the EU CDN nodes. Therefore, if you forget to specify the `dataGovernance` option when initializing the ConfigCat SDK, feature flag data download requests will need to be redirected to the EU CDN. To avoid this, it's recommended to specify the correct `dataGovernance` option, otherwise response times can be significantly longer. #### `Warning: The dataGovernance parameter specified at the client initialization is not in sync with the preferences on the ConfigCat Dashboard....`[​](#warning-the-datagovernance-parameter-specified-at-the-client-initialization-is-not-in-sync-with-the-preferences-on-the-configcat-dashboard "Direct link to warning-the-datagovernance-parameter-specified-at-the-client-initialization-is-not-in-sync-with-the-preferences-on-the-configcat-dashboard") **Don't worry,** your feature flags will still be served. See above example. --- # Details of LaunchDarkly to ConfigCat Translation This document discusses the details of how [ConfigCat's "Import from LaunchDarkly" tool](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly/.md#migrate-launchdarkly-feature-flags-and-segments-to-configcat) translates LaunchDarkly projects to ConfigCat products (i.e., how, in practice, the import tool converts the project data fetched fromLaunchDarkly's REST API to ConfigCat's Export/Import JSON format). You need this information if you want to understand * why the import tool produces the result that it does, * what issues can arise during translation, and how to solve them, * what the limitations of translation are. ## Mapping between LaunchDarkly and ConfigCat entities[​](#mapping-between-launchdarkly-and-configcat-entities "Direct link to Mapping between LaunchDarkly and ConfigCat entities") The table below shows how LaunchDarkly entities are mapped to ConfigCat entities. | LaunchDarkly entity | Corresponding ConfigCat entity | Notes | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | project | [product](https://configcat.com/docs/docs/main-concepts/.md#product) | | | environment | [environment](https://configcat.com/docs/docs/main-concepts/.md#environment) | | | segment | [segment](https://configcat.com/docs/docs/targeting/targeting-rule/segment-condition/.md#what-is-a-segment-condition-what-is-a-segment) | LaunchDarkly segments are specific to an environment, but ConfigCat segments are specific to a product, so mapped segment names are prefixed with the environment name to avoid ambiguity. | | feature flag | [feature flag / setting](https://configcat.com/docs/docs/targeting/targeting-overview/.md#feature-flag--setting) | LaunchDarkly feature flags are directly contained by a project, but ConfigCat feature flags are organized into [configs](https://configcat.com/docs/docs/main-concepts/.md#config), so a config named "Main Config" is created to contain them. | | targeting toggle | - | No direct translation is possible. More on this [here](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly/.md#targeting-toggle-translation-mode). | | prerequisites | - | Each prerequisite is translated to a [Targeting Rule](https://configcat.com/docs/docs/targeting/targeting-overview/.md#targeting-rule) containing a [Flag Condition](https://configcat.com/docs/docs/targeting/targeting-rule/flag-condition/.md). | | individual targets | - | Each target group is translated to a [Targeting Rule](https://configcat.com/docs/docs/targeting/targeting-overview/.md#targeting-rule) containing an IS ONE OF [User Condition](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md). | | custom rule | [Targeting Rule](https://configcat.com/docs/docs/targeting/targeting-overview/.md#targeting-rule) | Multiple clauses (i.e. [AND conditions](https://configcat.com/docs/docs/targeting/targeting-rule/targeting-rule-overview/.md#and-and-or-relationships) in ConfigCat's terminology) are not supported for segments, only for feature flags at the moment. | | custom rule clause | [User Condition](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md) or [Segment Condition](https://configcat.com/docs/docs/targeting/targeting-rule/segment-condition/.md) | Some LaunchDarkly clauses cannot be translated to ConfigCat conditions with the same evaluation behavior, or at all. See also [translation issues](#translation-issues) | | clause attribute reference | [comparison attribute](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md#comparison-attribute) | LaunchDarkly context attribute paths don't always translate to ConfigCat user attribute names directly. See also [this section](#mapping-between-launchdarkly-contexts-and-configcat-user-objects). | | clause operator | [comparator](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md#comparator) | Most LaunchDarkly operators have their counterparts in ConfigCat (there can be minor or major differences between them though), but a few operators are not supported by ConfigCat at all (e.g. "matches" / "does not match"). | | clause values | [comparison value](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md#comparison-value) | As opposed to LaunchDarkly, not all counterparts of operators support multiple values. | | percentage rollout | [Percentage Options](https://configcat.com/docs/docs/targeting/percentage-options/.md) | In LaunchDarkly, the basis of the grouping can be set for each percentage rollout, while in ConfigCat [Percentage Evaluation Attribute](https://configcat.com/docs/docs/targeting/percentage-options/.md#percentage-evaluation-attribute) can only be set at the feature flag level. | | default rule | [trivial / fallback rule](https://configcat.com/docs/docs/targeting/targeting-overview/.md#to-all-users--to-all-other--to-unidentified-value) | | ## Mapping between LaunchDarkly contexts and ConfigCat User Objects[​](#mapping-between-launchdarkly-contexts-and-configcat-user-objects "Direct link to Mapping between LaunchDarkly contexts and ConfigCat User Objects") Both LaunchDarkly and ConfigCat support passing user and/or session-related contextual information to feature flag evaluation, which is essential for targeting: LaunchDarkly offers [contexts](https://launchdarkly.com/docs/home/observability/contexts), while ConfigCat offers [User Objects](https://configcat.com/docs/docs/targeting/user-object/.md) for this purpose. However, the data structure of these is different: * In LaunchDarkly, in addition to the default user context, it is possible to define and use other, arbitrary contexts (e.g. device, application, etc.). [Multi-contexts](https://launchdarkly.com/docs/home/flags/multi-contexts) and nested objects are also possible. * On the contrary, ConfigCat's User Object is a simpler data structure, primarily designed for storing user-related information. However, via custom attributes it's still able to store arbitrary information. On top of that, LaunchDarkly context attributes are identified by the combination of a context kind and a path expression, while ConfigCat uses simple attribute names. For this reason, it is necessary to define an unambiguous mapping between the two. This is done as shown in the following table: | LaunchDarkly context kind | LaunchDarkly context attribute path | Corresponding ConfigCat user attribute name | | ------------------------- | ----------------------------------- | ------------------------------------------- | | not specified or `user` | empty string or `/` | `/` | | not specified or `user` | `key` or `/key` | `Identifier` | | not specified or `user` | `email` or `/email` | `Email` | | not specified or `user` | `country` or `/country` | `Country` | | not specified or `user` | `Identifier` or `/Identifier` | `/Identifier` | | not specified or `user` | `Email` or `/Email` | `/Email` | | not specified or `user` | `Country` or `/Country` | `/Country` | | not specified or `user` | `name` or `/name` | `name` | | not specified or `user` | `/address/city` | `/address/city` | | `device` | empty string or `/` | `device:/` | | `device` | `name` or `/name` | `device:name` | | `organization` | `name` or `/name` | `organization:name` | | `organization` | `/address/city` | `organization:/address/city` | | any | `kind` or `/kind` | `/kind` | Please note that: * Both LaunchDarkly context attribute paths and ConfigCat user attribute names are case-sensitive. * In ConfigCat, `Identifier`, `Email` and `Country` are predefined attributes. Everything else qualifies as custom attributes. * One-component LaunchDarkly attribute path expressions are always normalized to their unescaped form if possible. E.g. `/~0~1x` → `~/x`, but `/~1~00` → `/~1~00` (as `/~0` would be an ambiguous mapping). * Multi-component LaunchDarkly attribute path expressions are kept as is (unless they contain `:` characters - see below). * Context kinds other than `user` are included as a prefix in the mapped ConfigCat user attribute name, with `:` as the separator. Because of this, LaunchDarkly context attribute paths containing `:` characters needs to be escaped to avoid ambiguity. E.g. `a:b` -> `/a~;b`, `/a:b` -> `/a~;b`. ## Translation issues[​](#translation-issues "Direct link to Translation issues") There are technical differences between LaunchDarkly and ConfigCat, therefore it's not always possible to translate all entities accurately, i.e. so that they are represented identically in ConfigCat, and provide equivalent behavior to the original. (By equivalent behaviour we primarily mean equivalent evaluation behaviour, i.e. that the evaluation of a feature flag or segment produces the same result for the same input parameters.) Such problematic cases are called *translation issues*, and a *severity level* is assigned to them as follows. 🔴 HIGH - The imported entity cannot provide equivalent behavior to the original at all.
🟡 MEDIUM - The imported entity may not provide equivalent behavior to the original in every case.
🔵 LOW - The imported entity does not exactly reflect the original in some way, but it is expected to provide equivalent behavior to the original. The tables below show the possible translation issues. ### Limitations[​](#limitations "Direct link to Limitations") info Usually these issues arise when you are on a lower plan, and hitting a subscription limit. If that's the case, feel free to [contact us](https://configcat.com/support/?prefilled=ld-import-limit), we are happy to raise your limits temporarily so you can fully explore the product and evaluate it at your pace. | Code | Level | Issue | What can be the cause? | How is it handled? | | ---- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | L001 | 🔴 HIGH | The number of Targeting Rules resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | There are too many rules in the original feature flag. | As many LaunchDarkly rules as the limit allows are imported, but the rest is omitted. | | L002 | 🔴 HIGH | The number of conditions resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | There are too many clauses in a rule of the original feature flag. | As many LaunchDarkly clauses as the limit allows are imported, but the rest is omitted. | | L003 | 🔴 HIGH | The number of percentage options resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | There are too many percentage rollout variations in the original feature flag. | As many LaunchDarkly percentage rollout variations as the limit allows are imported, but the rest is omitted. The percentage of the last imported item is adjusted so that the sum of percentages equals 100%. | | L004 | 🔴 HIGH | The length of a comparison value resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | The value(s) of a LaunchDarkly clause translate to a string comparison value that would be too long. | The comparison value is truncated so that it fits within the limit. | | L005 | 🔴 HIGH | The number of items in a comparison value list resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | The values of a clause translate to a comparison value list that would have too many items. | The comparison value list is truncated so that it fits within the limit. | | L006 | 🔴 HIGH | The length of an item in a comparison value list resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | One or more values of a clause translate to a comparison value item that would be too long. | The comparison value item is truncated so that it fits within the limit. | | L007 | 🔴 HIGH | The length of a text setting value resulting from the translation would exceed the [subscription / technical limit](https://configcat.com/docs/docs/subscription-plan-limits/.md). | A feature flag variation value translates to a text setting value that would be too long. | The text setting value is truncated so that it fits within the limit. | ### Technical differences[​](#technical-differences "Direct link to Technical differences") | Code | Level | Issue | What can be the cause? | How is it handled? | | ---- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | T001 | 🔵 LOW | A project, environment, segment or feature flag was imported under a different name than the original. | 1. LaunchDarkly project, environment and segment names do not have to be unique (since those items always have a unique key in LaunchDarkly too). The corresponding ConfigCat entities, however, must have a case-insensitive unique name.
2. LaunchDarkly allows longer names than ConfigCat. | 1. In the case of identical names, the LaunchDarkly unique key is included in the name. If this is still not unique, then a number suffix is added as well.
2. Names that are too long are truncated at the maximum length. If this results in a conflicting name, it is made unique by adding a number suffix. | | T002 | 🟡 MEDIUM | A feature flag was imported with a different key than the original. | 1. Feature flag keys are unique in both systems, but they must be case sensitive in LaunchDarkly and case insensitive in ConfigCat.
2. As opposed to LaunchDarkly, ConfigCat feature flag keys are not allowed to start with a number or contain dots.
3. Depending on the Targeting Toggle Translation Mode option, the targeting toggle may be emulated using an extra prerequisite flag. The key for this is generated by adding the suffix `_tt` to the key of the main flag. | 1. Conflicts are resolved by adding a number suffix.
2. Characters that are invalid in ConfigCat are replaced with `_`. If the first character is not a letter, the prefix `x_` is also added to the key. If this results in a conflicting key, it is made unique by adding a number suffix.
3. Conflicts are resolved by adding a number suffix. (But always the uniqueness of the the actually imported flags' keys are ensured first.) | | T003 | 🔵 LOW | A feature flag tag name was truncated. | LaunchDarkly may allow longer tag names than ConfigCat. | Names that are too long are truncated at the maximum length. If this results in a conflicting name, no effort is made to make it unique. | | T004 | 🔵 LOW | A JSON feature flag was encountered. | LaunchDarkly allows feature flags with JSON values, but ConfigCat doesn't support that directly at the moment. | A text setting is created in ConfigCat, with values containing the JSON variation values serialized to text. It is your responsibility to deserialize the text once returned by feature flag evaluation. | | T005 | 🟡 MEDIUM | A comparison attribute name was truncated. | A context attribute name is mapped to a user attribute name that is too long. | The comparison attribute name is truncated so that it fits within the limit. If this results in a conflicting name, no effort is made to make it unique. | | T006 | 🔴 HIGH | Unset off variation was encountered. | In LaunchDarkly, it is not required to set a variation for the case when targeting is turned off. In that case, feature flag evaluation will return the default value you pass to the LaunchDarkly SDK. There is no way to reproduce this behavior in ConfigCat. | There is no way to emulate this behavior in ConfigCat, so a placeholder value is used as follows:- boolean flag: `false`
- string flag: `""` (empty string)
- json flag: `"null"`
- number flag: 0 | | T007 | 🔵 LOW | Targeting is turned off, and the targeting toggle was respected. | Targeting Toggle Translation Mode option was set to "Respect targeting toggle and don't import rules", and1. targeting is turned off for the feature flag in the specific environment,
2. or targeting is turned off for one or more prerequisites in the specific environment (see also the "Prerequisite flags must be on" section in [this article](https://launchdarkly.com/docs/home/flags/prereqs)). | A single Targeting Rule that returns the off variation is created in ConfigCat, and the actual rules are not imported for the specific environment. (The imported feature flag will work as it does in LaunchDarkly at the time of import.) | | T008 | 🟡 MEDIUM | Targeting is turned off, and the targeting toggle was ignored. | Targeting Toggle Translation Mode option was set to "Ignore targeting toggle and import rules anyway", and1. targeting is turned off for the feature flag in the specific environment,
2. or targeting is turned off for one or more prerequisites in the specific environment (see also the "Prerequisite flags must be on" section in [this article](https://launchdarkly.com/docs/home/flags/prereqs)). | The off variation is ignored, and the actual rules are imported for the specific environment. (The imported feature flag will not work as it does in LaunchDarkly at the time of import.) | | T009 | 🔴 HIGH | A segment clause references multiple segments, but cannot be translated due to subscription / technical limit. | ConfigCat doesn't support referencing multiple segments in Segment Conditions. There is a workaround though: non-negated LaunchDarkly clauses can be expanded into multiple ConfigCat Targeting Rules, negated LaunchDarkly clauses can be expanded into multiple ConfigCat conditions. However, in the specific case the expansion is not possible because of subscription / technical limits. | A Segment Condition is created in ConfigCat but it references the first segment only. The rest of the segment references are omitted. | | T010 | 🔴 HIGH | A segment that references another segment was encountered. | ConfigCat segments do not support targeting segments. | A placeholder condition is created in ConfigCat. | | T011 | 🔴 HIGH | An untranslatable clause was encountered in a feature flag or segment rule. | The LaunchDarkly clause is not translatable to a ConfigCat condition, not even via a workaround. Such cases are:1. Feature flag or segment rule clause uses the "matches" / "does not match" operators.
2. Feature flag rule clause is based on Context kind but cannot be translated to an ARRAY IS (NOT) ONE OF condition.
3. Segment rule clause is based on Context kind.
4. Segment rule clause uses the "starts with" / "does not start with" / "ends with" / "does not end with" operators.
5. Segment rule clause uses the "before" or "after" operator.
6. Feature flag or segment rule targets application versions (no such feature in ConfigCat). | A placeholder condition is created in ConfigCat. | | T012 | 🔵 LOW | A clause was translated to multiple Targeting Rules or conditions. | Some LaunchDarkly clauses like segment clauses referencing multiple segments cannot be directly translated to a single ConfigCat condition. However, in the specific case, a workaround that provides logically equivalent evaluation behavior is possible. | If the LaunchDarkly clause is non-negated, it is expanded into multiple ConfigCat Targeting Rules, otherwise it is expanded into multiple ConfigCat conditions. | | T013 | 🔴 HIGH | A "contains" / "does not contain" segment clause with multiple values was encountered. | In segments, the ConfigCat counterparts of the "contains" / "does not contain" operators only accept a single comparison value at the moment. | The clause is translated to a CONTAINS / DOES NOT CONTAIN segment, however only the first clause value is preserved. The rest of the values are omitted. | | T014 | 🔵 LOW | A "<", "<=", ">", ">=", "SemVer <", "SemVer <=", "SemVer >", "SemVer >=" or "before" / "after" clause with multiple values was encountered. | The ConfigCat counterpart of these operators allows a single comparison value only. | Multiple comparison values are reduced to a single one. (This can be done in such a way that the clause remains logically accurate.) The rest of the values are omitted though.
It is also worth noting that the evaluation behavior of "SemVer <=" and "SemVer >=" clauses with multiple values is inconsistent with similar operators in LaunchDarkly. So, since translation preserves the inconsistent behavior, it may produce surprising results in such cases. | | T015 | 🟡 MEDIUM | A "Context kind is (not) one of" clause was encountered. | In ConfigCat, there is no such concept as contexts and context kinds. ConfigCat SDKs won't automatically provide context kinds as an attribute via the User Object. | An ARRAY IS (NOT) ONE OF condition is created in ConfigCat, but it is your responsibility to pass the context kind values to the ConfigCat SDK via the custom user attribute named `/kind`. | | T016 | 🟡 MEDIUM | A mobile targeting-related clause was encountered. | For mobile apps, LaunchDarkly allows targeting special, [automatically provided context attributes](https://launchdarkly.com/docs/sdk/features/environment-attributes) of context kinds `ld_application` and `ld_device`. ConfigCat SDKs won't automatically provide these attributes via the User Object. | The clause is translated, but it is your responsibility to pass the attribute values to the ConfigCat SDK via custom user attributes. | | T017 | 🟡 MEDIUM | A not accurately translatable "is (not) one of" clause was encountered. | In LaunchDarkly, "is (not) one of" clauses can work with string, boolean and number values, but their ConfigCat counterparts can work with strings only. This can be a problem in two cases:1. "is (not) one of" clauses with boolean comparison values cannot be translated accurately as ConfigCat offers no comparators that work with boolean values at the moment,
2. "is (not) one of" clauses with number comparison values may be translated accurately using the = (number) / != (number) comparators. These accept a single comparison value though, so clauses with multiple values must be expanded into multiple targeting rules or conditions, depending on negation. However, in the specific case the expansion is not possible because of subscription / technical limits. | An IS (NOT) ONE OF condition is created in ConfigCat and the non-string values are converted to string.
From the perspective of feature flag evaluation this means the following: the ConfigCat SDK will convert non-string user attributes to string, and do case-sensitive string comparisons when evaluating the feature flag. In the case of boolean and decimal number values this can lead to undesired behavior. E.g. on some platforms, the ConfigCat SDK may convert the false boolean value to the string `False`, which won't be matched by an IS ONE OF condition having a comparison value `false`. Similarly, there could be subtle differences in decimal number to string conversion across various platforms. | | T018 | 🔵 LOW | One or more variations of a percentage rollout had to be omitted. | LaunchDarkly includes all the feature flag variations in a percentage rollout even if most of them are set 0%. However, this could lead to exceeding the subscription limit on Percentage Options in ConfigCat (especially, on lower plans). | As variations set to 0% don't affect the evaluation of the imported Percentage Options, translation omits as many of them as needed to fit within the limit. | | T019 | 🟡 MEDIUM | One or more percentage values of a percentage rollout had to be adjusted. | As opposed to LaunchDarkly, ConfigCat doesn't allow fractional percentage values in Percentage Options. | Non-integer percentage values are rounded. This may also cause the sum of the percentage values to over or undershoot 100%. In such cases, further adjustments are performed to make the sum exactly 100%. | | T020 | 🔴 HIGH | There are multiple percentage rollout rules in the feature flag, but they do not use the same attribute as the basis of the rollout. | In LaunchDarkly, it is possible to set different attributes as the basis of the rollout for each percentage rollout rule. In ConfigCat, this can only be set at the feature flag level. | There is no workaround. The attribute that occurs the most times is set as the flag's Percentage Evaluation Attribute. | | T021 | 🔴 HIGH | A segment with no rules was encountered. | LaunchDarkly allows segments to have no rules, while ConfigCat segments specify exactly one rule. | A segment with a placeholder condition is created in ConfigCat. | | T022 | 🔴 HIGH | A segment with multiple rules was encountered. | LaunchDarkly allows segments to have multiple rules, while ConfigCat segments specify exactly one rule. | A segment is created in ConfigCat, with a translation of the first rule only. The rest of the rules are omitted. | | T023 | 🔴 HIGH | A segment rule with multiple clauses was encountered. | LaunchDarkly allows multiple clauses in segment rules, while ConfigCat doesn't support AND conditions in segments at the moment. | There is no workaround. Clauses except for the first one are omitted. | | T024 | 🔴 HIGH | A segment rule with percentage targeting was encountered. | LaunchDarkly allows segment rules to include a percentage of targets only. ConfigCat segments doesn't offer such feature. | There is no workaround. The percentage targeting part is ignored. | | T025 | 🔴 HIGH | A segment rule was only partially translated. | Translating the segment rule would require multiple rules in ConfigCat, which is not supported. | The segment rule is only partially imported. | | T026 | 🔴 HIGH | A big segment was encountered. | Big segments are not supported by ConfigCat. | A normal segment with a hint about the issue is created in ConfigCat. | | T027 | 🔴 HIGH | Comparison value list item contains comma. | In the case of segments, multiple clause values translate to a comma separated comparison value list. There is no way to escape the comma, so it must be replaced with another character, otherwise values containing a comma would be interpreted as multiple items. | Comma is replaced with semicolon in comparison value list items. | ### Data consistency[​](#data-consistency "Direct link to Data consistency") | Code | Level | Issue | What can be the cause? | How is it handled? | | ---- | --------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | D001 | 🔴 HIGH | The data model fetched from LaunchDarkly contains invalid, inconsistent or unexpected data. | In theory, such a thing cannot happen, but in practice it cannot be excluded. | Obviously, the import tool cannot produce a correct result from an inherently incorrect input. As a best effort, it generates a valid import model so that the import operation can go through, and you can review and fix the problematic entities. | | D002 | 🟡 MEDIUM | The feature flag was modified in LaunchDarkly while the feature flag data was being fetched. | Due to the peculiarities of the LaunchDarkly REST API, the full data model of a feature flag can only be queried for a single environment per a single request. So, it may happen that some non-environment-related properties of the feature flag are modified while fetching the feature flag data (e.g. name, variations, etc.) In such cases, inconsistencies across environments are possible in the retrieved data. | The import tool can only detect inconsistencies, but cannot do anything about them. Please check whether the imported feature flag is set correctly in each environment. Alternatively, you may try to re-import the specific feature flag. | ## Further technical differences[​](#further-technical-differences "Direct link to Further technical differences") * As opposed to LaunchDarkly, ConfigCat distinguishes between integer and decimal number feature flags. Therefore, when translating number feature flags, the ConfigCat setting type is guessed based on the variation values specified at the time of the import. * For percentage rollouts, LaunchDarkly and ConfigCat use different algorithms to split users into groups. That is, even if the percentage values are the same, the distribution of users will be different. In other words, [stickiness](https://configcat.com/docs/docs/targeting/percentage-options/.md#stickiness) of percentage rollouts cannot be transferred to ConfigCat. * In the case of percentage rollouts within custom rules, evaluation behavior is different between the two services when the attribute used as the basis of the percentage rollout is not provided (i.e. not passed to the SDK on evaluation): * LaunchDarkly will serve the value of the first variation whose percentage value is not 0%. * ConfigCat will skip the targeting rule and continue evaluation with the next rule. * In LaunchDarkly, all clause operators can work with context attribute value lists. In ConfigCat, most of the comparators (counterparts of operators) can work with a single user attribute only. The only exceptions is ARRAY IS (NOT) ONE OF. * In LaunchDarkly, it is possible to control whether or not specific feature flags are visible to mobile and/or client-side SDKs ([Client-side SDK availability](https://launchdarkly.com/docs/home/flags/new#make-flags-available-to-client-side-and-mobile-sdks)). There is no such feature in ConfigCat, so this preference is ignored. All the feature flags are imported into a single config which can be accessed by all kinds of ConfigCat SDKs. * In LaunchDarkly, it is possible to mark a feature flag as temporary or permanent. There is no such feature in ConfigCat. Yet translation preserves this piece of information by adding a tag to the feature flag. * In LaunchDarkly, it is possible to assign a name to the variations (possible outcomes of the feature flag). There is no such feature in ConfigCat at the moment, so these pieces of information are not transferred. --- # Migration from LaunchDarkly This document is for current LaunchDarkly users who want to migrate to ConfigCat. It guides you through the migration process while providing information on the technical differences between the two services that you need to be aware of. Migration can be done on a LaunchDarkly project basis, and migration of a project usually consists of the following three steps: 1. Migrating LaunchDarkly feature flags and segments to ConfigCat 2. Adjusting the code of your applications to use ConfigCat instead of LaunchDarkly 3. Migrating LaunchDarkly teams and permissions to ConfigCat ConfigCat provides a wizard-like tool that is able to do the heavy lifting for step 1. However, there is currently no automation for step 2 and 3. So please expect these steps to require some manual work. However, before diving into it all, please check [this list](https://configcat.com/docs/docs/sdk-reference/overview/.md) to see if ConfigCat supports the platform your applications are running on. If not, feel free to [contact us](https://configcat.com/support). Maybe we can still figure out a way for you to migrate to ConfigCat. ## Getting started[​](#getting-started "Direct link to Getting started") To be able to perform the migration, it's essential that you have a basic understanding of ConfigCat's main concepts and hierarchy. So, as the very first step, please read through [this brief guide](https://configcat.com/docs/docs/main-concepts/.md). LaunchDarkly projects correspond to ConfigCat products in the ConfigCat hierarchy. However, as you already know, products are not standalone entities, they are contained by a ConfigCat organization. So, to get started with migration, you will need to have a ConfigCat account and be a member of the ConfigCat organization that you want to host the products corresponding to the projects you plan to migrate from LaunchDarkly. You will also need to have the Organization Admin permission in that ConfigCat organization to be able to create products. * If the target ConfigCat organization does not exist yet, you can create one by [signing up](https://app.configcat.com/auth/signup). During the signup process, you will have the opportunity to create your own organization, in which you will have the Organization Admin permission by default. * Otherwise, you will need to get an invitation to the target ConfigCat organization, and after joining, you will need to request the Organization Admin permission. Once the target ConfigCat organization is set up and you have the necessary permissions in it, you can start the actual migration. ## Migrate LaunchDarkly feature flags and segments to ConfigCat[​](#migrate-launchdarkly-feature-flags-and-segments-to-configcat "Direct link to Migrate LaunchDarkly feature flags and segments to ConfigCat") It is recommended to migrate your LaunchDarkly feature flags and segments to ConfigCat first, using ConfigCat's official import tool, which was designed for this specific purpose. The tool also takes care of creating the corresponding ConfigCat products and environments, and it does everything possible to reproduce your LaunchDarkly feature flags and segments in ConfigCat so they match the original evaluation behavior as closely as possible. ### Using the import tool[​](#using-the-import-tool "Direct link to Using the import tool") To launch the import tool, open the dropdown menu in the top left corner of the [ConfigCat Dashboard](https://app.configcat.com/organization), navigate to the Organization Overview page, then click the card labeled "Import from LaunchDarkly". ![Launching the import tool](/docs/assets/migration-from-launchdarkly/launch-import-tool_192dpi.png) This will take you to a page with a wizard-like UI: ![The import tool](/docs/assets/migration-from-launchdarkly/import-tool_192dpi.png) Follow the instructions and go through the steps to perform the import. Feel free to experiment with the import tool. You can't really cause any irreversible damage by doing so. After finishing an import, you can delete the imported products in ConfigCat and start over if you are not satisfied with the result. It is also possible to re-import products or specific parts of those without having to delete the products created previously. The import tool is able to update the existing entities with fresh data. However, this may involve undoable overwriting of existing data, so please be careful. The import tool will warn you if something like this is about to happen. ### Targeting toggle translation mode[​](#targeting-toggle-translation-mode "Direct link to Targeting toggle translation mode") In step 3 of the wizard, you may need to make a decision that might not be self-evident. LaunchDarkly feature flags have a [toggle](https://docs.launchdarkly.com/home/flags/toggle) that allows you to enable or disable targeting for the specific feature flag. However, there is no similar feature in ConfigCat. So, in case the LaunchDarkly projects you selected for import contain feature flags where the targeting toggle is turned off in some of the environments, you need to decide how to work around such cases. Your options are the following: #### Ignore targeting toggle and import rules anyway[​](#ignore-targeting-toggle-and-import-rules-anyway "Direct link to Ignore targeting toggle and import rules anyway") This will result in an evaluation behavior different from LaunchDarkly. Choose this option if you want to keep your targeting rules even if the targeting toggle is off. Please consider the following consequences: * The state of targeting toggles will be ignored. * The *off variation* values won't be served. * The targeting rules will be imported and evaluated as if the targeting toggle was on. #### Respect targeting toggle and don't import rules[​](#respect-targeting-toggle-and-dont-import-rules "Direct link to Respect targeting toggle and don't import rules") This will result in the same evaluation behavior as in LaunchDarkly. Choose this option if you want your feature flags to produce the same values as in LaunchDarkly. Please consider the following consequences: * The state of targeting toggles will be respected. * The *off variation* values will be served. * The targeting rules won't be imported in environments where the targeting toggle is off. #### Emulate targeting toggle using a prerequisite flag[​](#emulate-targeting-toggle-using-a-prerequisite-flag "Direct link to Emulate targeting toggle using a prerequisite flag") This is a workaround that combines the upsides of the other two options at the expense of creating extra feature flags. Choose this option if you want to import your targeting rules in all cases, and also want your feature flags to produce the same values as they do in LaunchDarkly. Please consider the following consequences: * The state of targeting toggles will be respected, however, for each problematic LaunchDarkly feature flag an extra [prerequisite flag](https://configcat.com/docs/docs/targeting/targeting-rule/flag-condition/.md) will be created in ConfigCat to emulate the targeting toggle. * The *off variation* values will be served. * The targeting rules will be imported and evaluated depending on the state of the extra prerequisite flag. ### About the import operation[​](#about-the-import-operation "Direct link to About the import operation") After making your choices on what and how to import in the first steps of the wizard, the import tool performs the operation by importing the selected LaunchDarkly projects one by one. Importing a project consists of two phases: #### Translation phase[​](#translation-phase "Direct link to Translation phase") First, the import tool translates the LaunchDarkly project to a ConfigCat product. For more details on how this is done, please refer to [this document](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly-translation/.md). It's important to note that the import tool performs translation on a best effort basis. It aims to do translation in such a way that you get a feature flag evaluation behavior as close to the original as possible. However, since there are technical differences between LaunchDarkly and ConfigCat, an accurate translation is not possible in every case. Such problematic cases are called *translation issues*. The import tool detects and collects these issues during translation, and includes them in the report generated at the end of the import operation so you can review them, and make the necessary adjustments where necessary. You can find the list of possible translation issues [here](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly-translation/.md#translation-issues). #### Import phase[​](#import-phase "Direct link to Import phase") After the translation phase, the import tool loads the result into ConfigCat. This is when the corresponding ConfigCat product is actually created (or updated if it already exists). As the import tool has previously performed all the necessary validation and adjustments, generally you shouldn't encounter any issues during this phase. However, in rare cases failures may occur (most likely, due to a concurrent modification in ConfigCat). The import tool notifies you of such cases, and it also includes the failure details in the report. ### Final steps[​](#final-steps "Direct link to Final steps") After finishing the import operation, the import tool displays a summary. This shows you the overall success of each LaunchDarkly project selected for import. * If you see success icons next to every project, it means everything went fine, no significant issues were detected. * If you see a warning or error icon next to any project, it means that there are significant issues you need to pay closer attention to, and you will almost certainly need to make manual adjustments, or, in case of failure, even repeat the import. In either case, it's highly recommended to download and go through the report. It provides details about the detected issues, and also includes links to the original and imported entities, which can make it easier for you to look into and resolve the issues. ## Adjust the code of your applications[​](#adjust-the-code-of-your-applications "Direct link to Adjust the code of your applications") The next step in the migration process is to adjust the code of your applications to use ConfigCat instead of LaunchDarkly to evaluate your feature flags. This will also require more or less manual work, depending on what API your applications currently use for feature flag evaluation. ### Adjust a codebase that uses LaunchDarkly SDK[​](#adjust-a-codebase-that-uses-launchdarkly-sdk "Direct link to Adjust a codebase that uses LaunchDarkly SDK") If your applications implement feature flagging by directly consuming the LaunchDarkly SDK API, you will need to change those parts to use the ConfigCat SDK API. We show how to do this through a simple example. Let's assume you have the following simple Node.js application: ``` import LaunchDarkly from "@launchdarkly/node-server-sdk"; const sdkKey = process.env.LAUNCHDARKLY_SDK_KEY ?? "#YOUR-SDK-KEY#"; const client = LaunchDarkly.init(sdkKey); try { await client.waitForInitialization({ timeout: 10 }); } catch (error) { console.error(`SDK failed to initialize: ${error}`); process.exit(1); } const context = { "kind": "multi", "user": { "key": "#UNIQUE-USER-IDENTIFIER#", "name": "Alice", "email": "alice@example.com", "country": "UK" }, "organization": { "key": "#UNIQUE-ORG-IDENTIFIER#", "address": { "city": "London" } } }; const flagValue = await client.variation("isAwesomeFeatureEnabled", context, false); if (flagValue) { console.log("Feature is enabled.") } else { console.log("Feature is disabled.") } process.exit(0); ``` Let's see now step by step how to convert this code to ConfigCat: 1. Uninstall the LaunchDarkly SDK package, and install the ConfigCat one instead: ``` npm uninstall @launchdarkly/node-server-sdk npm install configcat-node ``` 2. Instead of the `LaunchDarkly` namespace, import `configcat`: ``` import configcat from "configcat-node"; ``` 3. Replace the LaunchDarkly SDK key with the ConfigCat one. You can obtain it from the [ConfigCat Dashboard](https://app.configcat.com/organization), by selecting the config containing the imported feature flag on the sidebar, and clicking the "VIEW SDK KEY" button in the top right corner of the page. 4. Instead of a LaunchDarkly client instance, obtain a ConfigCat one: ``` const client = configcat.getClient(sdkKey, configcat.PollingMode.AutoPoll, { maxInitWaitTimeSeconds: 10 }); ``` Please note that the ConfigCat client doesn't maintain a persistent connection to the remote server, but uses different polling strategies to get the data necessary for feature flag evaluation. Refer to the [SDK reference](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#creating-the-configcat-client) to learn more about the options. For frontend applications and long-running backend services, Auto Polling mode is usually a good choice. 5. Adjust the wait-for-initialization logic. * When using Auto Polling mode, you can rewrite it like this: ``` const clientCacheState = await client.waitForReady(); if (clientCacheState === configcat.ClientCacheState.NoFlagData) { /* ... */ process.exit(1); } ``` Please note that the `waitForReady` method is not available on all platforms. On such platforms, you can't really implement this logic at the moment. However, you don't really need to as the feature flag evaluation methods wait for initialization internally anyway. (It's worth noting that if initialization can't complete within the timeout duration specified by the `maxInitWaitTimeSeconds` option, then feature flag evaluation methods will return the default value you pass to them.) Actually, you only need this wait-for-initialization logic at the startup of your applications if you want to use [synchronous feature flag evaluation via snapshots](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#snapshots-and-synchronous-feature-flag-evaluation). * For other polling modes, the wait-for-initialization logic doesn't make sense, so just omit it. 6. Rewrite LaunchDarkly contexts to ConfigCat User Objects. ConfigCat uses the concept of [User Object](https://configcat.com/docs/docs/targeting/user-object/.md) to pass user and/or session-related contextual data to feature flag evaluation. It serves the same purpose as [LaunchDarkly contexts](https://launchdarkly.com/docs/home/observability/contexts), but it's a simpler data structure. To be able to convert a context data structure to a User Object one, you will need to do the following: * Read [the section on User Objects](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#user-object) in the reference of the SDK for your platform. * Read [this section](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly-translation/.md#mapping-between-launchdarkly-contexts-and-configcat-user-objects) to learn how context paths are mapped to User Object attribute names. For an example of such conversion, see the adjusted code at the end of this section. Please also keep in mind: * Some LaunchDarkly SDKs may [automatically provide additional attributes](https://launchdarkly.com/docs/sdk/features/environment-attributes) in contexts. ConfigCat SDKs don't offer a feature like that at the moment, so in case you target such additional attributes in your feature flags, you will need to provide them manually in your applications. * LaunchDarkly allows multiple attribute values (an array of values) for all clause operators, but ConfigCat allows multiple attribute values (an array of strings) for the ARRAY CONTAINS ANY OF / ARRAY NOT CONTAINS ANY OF comparators only. This means that it's not possible to specify multiple values for a user attribute if the evaluated feature flag contains a [User Condition](https://configcat.com/docs/docs/targeting/targeting-rule/user-condition/.md) that references the attribute, but has a comparator other than the two mentioned. Unfortunately, no workaround exists for this case. 7. Rewrite feature flag evaluation calls. This step is pretty straightforward as ConfigCat SDKs provide similar evaluation methods to LaunchDarkly SDKs. Those methods are named `getValue`, `getValueAsync` or similar. A few things to pay attention to: * The order of parameters is different. In ConfigCat, the User Object comes last. * The ConfigCat feature flag key may be different from the LaunchDarkly one. E.g. if the key starts with a non-letter character, or contains a dot, it will be changed by the import tool because such keys are not valid in ConfigCat. To see which keys have been changed, look for [T002](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly-translation/.md#translation-issue-T002) translation issues in the report. * ConfigCat SDKs don't support [automatic camel casing](https://launchdarkly.com/docs/sdk/client-side/react/react-web#flag-keys-in-the-react-web-sdk) of feature flag keys. * In statically typed languages, ConfigCat evaluation methods require that the default value type and the feature flag type match. (Usually, there is [a section about this](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#setting-type-mapping) in the SDK reference.) * Please be extra careful when evaluating number type feature flags. ConfigCat distinguishes between integer and decimal number feature flags. The former must be evaluated using `getValue`, `getIntValue` or similar, while the latter must be evaluated using `getValue`, `getDoubleValue` or similar. (JavaScript-based SDKs don't have this issue, but you can run into it in other languages.) * On some platforms, the ConfigCat client provides asynchronous evaluation methods only. In such cases, synchronous feature flag evaluation is usually still possible, [via snapshots](https://configcat.com/docs/docs/sdk-reference/js/overview/.md#snapshots-and-synchronous-feature-flag-evaluation). But this works slightly differently from the asynchronous methods, so make sure you understand its behavior and possible pitfalls. By adjusting the example code according to the above, we get this: ``` import configcat from "configcat-node"; const sdkKey = process.env.CONFIGCAT_SDK_KEY ?? "#YOUR-SDK-KEY#"; const client = configcat.getClient(sdkKey, configcat.PollingMode.AutoPoll, { maxInitWaitTimeSeconds: 10 }); const clientCacheState = await client.waitForReady(); if (clientCacheState === configcat.ClientCacheState.NoFlagData) { console.error("SDK failed to initialize."); process.exit(1); } const user = { identifier: "#UNIQUE-USER-IDENTIFIER#", email: "alice@example.com", country: "UK", custom: { "name": "Alice", "organization:key": "#UNIQUE-ORG-IDENTIFIER#", "organization:/address/city": "London", "/kind": ["user", "organization"], } }; const flagValue = await client.getValueAsync("isAwesomeFeatureEnabled", false, user); if (flagValue) { console.log("Feature is enabled.") } else { console.log("Feature is disabled.") } process.exit(0); ``` The conversion can be done in a similar way on other platforms as well. Obviously, there may be minor differences, plus advanced topics are not covered here, so it's recommended to start this work by going through the SDK reference for your platform. ### Adjust a codebase that uses OpenFeature[​](#adjust-a-codebase-that-uses-openfeature "Direct link to Adjust a codebase that uses OpenFeature") You should have an easier time if feature flagging is done using the [OpenFeature](https://openfeature.dev/docs/reference/intro/) abstraction in your applications. In this case, please check [this list](https://configcat.com/docs/sdk-reference/openfeature/overview/) to see if a ConfigCat OpenFeature provider is available for your platform. If you're out of luck, you can still use the ConfigCat SDK directly as explained in the previous section, or [contact us](https://configcat.com/support) about the missing OpenFeature provider. Otherwise, to switch to ConfigCat, you need to do the following: 1. Uninstall the LaunchDarkly OpenFeature provider package, and install the ConfigCat one instead. 2. Adjust the initialization logic. Look for a call to `setProvider`, `setProviderAndWait` or similar, and change it so an instance of ConfigCat OpenFeature provider is passed to it. (For ConfigCat, use `setProviderAndWait` if possible.) 3. Convert [LaunchDarkly-specific evaluation context objects](https://github.com/launchdarkly/openfeature-node-server?tab=readme-ov-file#openfeature-specific-considerations) to have a data structure compatible with ConfigCat. This is done in a very similar way to what's described in the previous section. Read [this section](https://configcat.com/docs/docs/advanced/migration-from-launchdarkly-translation/.md#mapping-between-launchdarkly-contexts-and-configcat-user-objects) to learn how context paths are mapped to User Object attribute names. For example, something like ``` const evaluationContext = { kind: "multi", user: { targetingKey: "#UNIQUE-USER-IDENTIFIER#", name: "Alice", email: "alice@example.com", country: "UK" }, organization: { targetingKey: "#UNIQUE-ORG-IDENTIFIER#", address: { city: "London" } } }; ``` should be converted to this: ``` const evaluationContext = { targetingKey: "#UNIQUE-USER-IDENTIFIER#", name: "Alice" email: "alice@example.com", country: "UK", "organization:key": "#UNIQUE-ORG-IDENTIFIER#", "organization:/address/city": "London", "/kind": ["user", "organization"], }; ``` 4. Review feature flag evaluation calls. Most of the pitfalls pointed out in the "Rewrite feature flag evaluation calls" part of the previous section applies here too. ### Implement experiments and analytics[​](#implement-experiments-and-analytics "Direct link to Implement experiments and analytics") There are some fundamental differences in the feature flag evaluation process between LaunchDarkly and ConfigCat. In ConfigCat, feature flag evaluation is entirely implemented within the SDKs, meaning your users' sensitive data never leaves your system. The data flow is one-way – from ConfigCat CDN servers to your SDKs – and ConfigCat does not receive or store any attributes of the [User Object](https://configcat.com/docs/docs/targeting/user-object/.md) passed to the SDKs. This design prioritizes the privacy and security of user data. However, this has an important consequence: as opposed to LaunchDarkly, ConfigCat cannot provide an out-of-the-box solution to A/B testing, experiments or other analytics. For this, you will need an additional service that provides the necessary functionality. Here are some examples of how you can integrate such tools with ConfigCat to replicate LaunchDarkly's analytics features: * [Amplitude](https://configcat.com/docs/docs/integrations/amplitude/.md#experiments) * [Google Analytics](https://configcat.com/docs/docs/integrations/google-analytics/.md) * [Mixpanel](https://configcat.com/docs/docs/integrations/mixpanel/.md#experiments) * [Twilio Segment](https://configcat.com/docs/docs/integrations/segment/.md#analytics) ## Migrate LaunchDarkly teams and permissions to ConfigCat[​](#migrate-launchdarkly-teams-and-permissions-to-configcat "Direct link to Migrate LaunchDarkly teams and permissions to ConfigCat") To complete the migration process, you will also need to migrate your teams and permissions from LaunchDarkly. At the moment, ConfigCat doesn't offer a tool or other automated solution for this task since there are fundamental differences between the user management and permission systems of the two services. LaunchDarkly allows more fine-grained access control over resources, while ConfigCat's permission system was designed to be simpler and easier to understand, at the expense of fewer possibilities for fine-tuning access control. Therefore, we can only give you some pointers, but this task will inevitably require some effort on your part. As the first step, we recommend getting familiar with ConfigCat's user management and permission system. You can find the basic concepts in the following guides: * [Organization & Roles](https://configcat.com/docs/docs/organization/.md) * [Team Management Basics](https://configcat.com/docs/docs/advanced/team-management/team-management-basics/.md) As you can see from this, ConfigCat doesn't use the concept of teams and roles of LaunchDarkly. You can't define such entities at the organization level, but *permission groups* per product instead. ### Map LaunchDarkly roles to ConfigCat permission groups[​](#map-launchdarkly-roles-to-configcat-permission-groups "Direct link to Map LaunchDarkly roles to ConfigCat permission groups") Permission groups roughly correspond to LaunchDarkly roles, with a few key differences: * They are scoped to the product where they are defined. * There are no [built-in roles](https://launchdarkly.com/docs/home/account/built-in-roles) like Reader or Writer. To recreate these in ConfigCat, you will need to define the corresponding permission groups in each relevant product. However, LaunchDarkly's Admin and Owner roles can't really be represented using permission groups. ConfigCat supports the concept of [Organization Admin role](https://configcat.com/docs/docs/organization/.md#organization-admin-role) but it's an organization-level permission. You can assign this to users on invite or on your organization's "Members & Roles" page as shown in the next section. * To migrate [custom roles](https://launchdarkly.com/docs/home/account/custom-roles) to ConfigCat, you will need to translate the [policies](https://launchdarkly.com/docs/home/account/role-concepts#policies) they define to the fixed set of permissions offered by ConfigCat permission groups. Obviously, this won't be entirely possible in every case. With this in mind, create the necessary permission groups in your products, based on the roles defined in your LaunchDarkly organization. To set up permission groups for a product, open the [ConfigCat Dashboard](https://app.configcat.com/organization), select the product on the sidebar, and choose "Permission Groups" in the top menu. ![Launching the import tool](/docs/assets/migration-from-launchdarkly/permission-groups_192dpi.png) ### Invite users to ConfigCat and assign them to permission groups[​](#invite-users-to-configcat-and-assign-them-to-permission-groups "Direct link to Invite users to ConfigCat and assign them to permission groups") Permission groups also act as per-product teams. Once created, you can assign users to them, who will then have the permissions specified by the permission group. (A user can only be a member of a single permission group at a time though.) This is how you map your LaunchDarkly teams to ConfigCat. However, users don't yet exist in ConfigCat at this point. You need to invite them to ConfigCat first. To do this, follow [these instructions](https://configcat.com/docs/docs/advanced/team-management/team-management-basics/.md#invite-others-to-collaborate). When inviting users, you will need to choose a product, more specifically, a permission group to invite them to. This means that they will be automatically assigned to the specified permission groups after signing up. So, as you have already created the permission groups, ideally you can immediately invite your users to the right permission groups. (Of course, you may need to do this in batches.) It can easily happen that you want to add a user to more than one product. In such cases, invite the user to one of the products (it doesn't matter which one), then, after they've signed up, navigate to the "Members & Roles" page of your organization, and assign them to the other products too, using the "Change roles" feature of the "Members & Roles" table. ![Launching the import tool](/docs/assets/migration-from-launchdarkly/member-and-roles_192dpi.png) --- # Notifications - Webhooks ConfigCat Webhooks can notify your applications when a feature flag or other Setting changes by calling a public HTTP endpoint on your end. This allows your applications to react almost immediately to updates. Webhooks add the speed of near real-time updates to the reliability of Polling, giving your applications a fast and robust way to stay in sync. To enable Webhooks, simply tell us which HTTP endpoint to call. ConfigCat will send a request to that URL whenever a change occurs. ## Adding a Webhook[​](#adding-a-webhook "Direct link to Adding a Webhook") 1. Go to the [Webhooks](https://app.configcat.com/webhook) screen. 2. Click the **+ ADD WEBHOOK** button. 3. Choose **when** webhook notifications should be sent by selecting the **Config** and **Environment** where changes should trigger the Webhook. 4. Define **how** to notify your system by setting the **URL** and the **HTTP METHOD**. This tells us which endpoint to call. 5. (Optional) Add custom HTTP headers and a request body if needed. ## Request body with variables[​](#request-body-with-variables "Direct link to Request body with variables") You can customize the request body that will be sent with each Webhook call. ConfigCat will replace certain placeholders in the body with real values at runtime. | Variable | Replaced with | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **##ConfigName##** | The name of the Config where the change happened. | | **##ConfigId##** | ID of the Config where the change happened. | | **##EnvironmentName##** | The name of the Environment where the change happened. | | **##EnvironmentId##** | ID of the Environment where the change happened. | | **##URL##** | A direct link to the Config in the *ConfigCat Dashboard.* | | **##ChangeNotes##** | The **Mandatory notes** added to the actual changeset. | | **##ChangedBy##** | The name and email address of the user who made the changes. | | **##ChangeDetails##** | Detailed change info in JSON format, including the name of the Setting or feature flag, old and new values and Targeting Rules. | | **##ChangeDetailsTeams##** | Change details formatted for Microsoft Teams. | | **##ChangeDetailsSlack##** | Change details formatted for Slack. | The ##ChangeDetails## variable is replaced with a JSON array in the following format: ``` [ { "settingKey":"myAwesomeFeature1", "event":"changed", "details":"\r\nmyAwesomeFeature1: false ➔ true" }, { "settingKey":"myAwesomeFeature2", "event":"changed", "details":"\r\nmyAwesomeFeature2:\r\n Rollout percentage items changed:\r\n + 20% true\r\n + 80% false" } ] ``` ## Testing your Webhook[​](#testing-your-webhook "Direct link to Testing your Webhook") 1. Change some of your settings in the *ConfigCat Dashboard.* 2. Click **SAVE & PUBLISH CHANGES**. 3. Check if your Webhook was called correctly. info **Developer Tip** * Running your Webhook on `localhost`? Expose it to the public internet temporarily by using a tool like [ngrok](https://ngrok.com/). This enables ConfigCat to call your webhook even in your local development environment. * Just interested in what ConfigCat sends? Try [Webhhok.site](https://webhook.site/). This allows you to catch HTTP requests and see their content without requiring your to run anything anywhere. ## Verifying Webhook requests[​](#verifying-webhook-requests "Direct link to Verifying Webhook requests") To make sure the requests you receive are actually sent by ConfigCat, we strongly recommend verifying the signature included in the request headers. You can do this by comparing the received signature with one you compute using your signing key. Each webhook request includes the following headers: | Header | Description | | ---------------------------------- | -------------------------------------------------------------------------------------------- | | `X-ConfigCat-Webhook-ID` | A unique ID for the webhook request. This is different for every request. | | `X-ConfigCat-Webhook-Timestamp` | The time the request was sent, in Unix timestamp format (seconds since epoch). | | `X-ConfigCat-Webhook-Signature-V1` | A comma-separated list of base64-encoded HMAC-SHA-256 signatures (one for each signing key). | Currently, the latest (and the only) signature header version is `V1`. If the signing process changes in the future, new headers will be added with incremented version numbers. Example request: ``` POST /path HTTP/1.1 Host: X-ConfigCat-Webhook-ID: b616ca659d154a5fb907dd8475792eeb X-ConfigCat-Webhook-Timestamp: 1669580020 X-ConfigCat-Webhook-Signature-V1: RoO/UMvSRqzJ0OolMMuhHBbM8/Vjn+nTh+SKyLcQf0M=,heIrGPw6aylAZEX6xmSLrxIWVif5injeBCxWQ+0+b2U= ``` ### Content to sign[​](#content-to-sign "Direct link to Content to sign") The signature is calculated from the content constructed by concatenating the webhook's `id`, `timestamp`, and raw `body` together. ``` const contentToSign = `${webhookId}${timestamp}${body}`; ``` | Content part | Description | | ------------ | ------------------------------------------------------------------------------------------------------------ | | `webhookId` | The webhook's identifier received in the `X-ConfigCat-Webhook-ID` request header. | | `timestamp` | The timestamp value received in the `X-ConfigCat-Webhook-Timestamp` request header. | | `body` | The raw body of the received webhook request. If the webhook doesn't have a request body it can be left out. | caution The signature calculation is sensitive to any changes on the signed content, so it's important to not change the request body before the verification. Otherwise, the calculated signature could be completely different from the value received in the
`X-ConfigCat-Webhook-Signature-V1` header. ### Calculating signature[​](#calculating-signature "Direct link to Calculating signature") ConfigCat uses `HMAC` with `SHA-256` to sign webhooks. You can retrieve the **signing key(s)** required for the signature calculation from the [ConfigCat Dashboard's webhook page](https://app.configcat.com/product/webhooks). ![signing keys](/docs/assets/whsk.png) info For **key rotation** purposes, you can generate a secondary signing key. In this case ConfigCat sends two signatures (one signed with the *primary* and one signed with the *secondary* key) in the `X-ConfigCat-Webhook-Signature-V1` header separated by a comma (`,`): ``` X-ConfigCat-Webhook-Signature-V1: RoO/UMvSRqzJ0OolMMuhHBbM8/Vjn+nTh+SKyLcQf0M=,heIrGPw6aylAZEX6xmSLrxIWVif5injeBCxWQ+0+b2U= ``` * Node.js * Python * Ruby * PHP * Go * .NET * Java ``` const crypto = require('crypto'); // retrieved from the ConfigCat Dashboard const signingKey = 'configcat_whsk_VN3juirnVh5pNvCKd81RYRYchxUX4j3NykbZG2fAy88='; // retrieved from the the X-ConfigCat-Webhook-Signature-V1 request header const receivedSignature = 'Ks3cYsu9Lslfo+hVxNC3oQWnsF9e5d73TI5t94D9DRA='; // retrieved from the the X-ConfigCat-Webhook-ID request header const requestId = 'b616ca659d154a5fb907dd8475792eeb'; // retrieved from the the X-ConfigCat-Webhook-Timestamp request header const timestamp = 1669629035; // the webhook request's raw body const body = 'examplebody'; const contentToSign = `${requestId}${timestamp}${body}`; const calculatedSignature = crypto .createHmac('sha256', signingKey) .update(contentToSign) .digest('base64'); console.log(calculatedSignature == receivedSignature); // must be true ``` ``` import hmac import base64 # retrieved from the ConfigCat Dashboard signing_key = "configcat_whsk_VN3juirnVh5pNvCKd81RYRYchxUX4j3NykbZG2fAy88=" # retrieved from the X-ConfigCat-Webhook-Signature-V1 request header received_signature = "Ks3cYsu9Lslfo+hVxNC3oQWnsF9e5d73TI5t94D9DRA=" # retrieved from the X-ConfigCat-Webhook-ID request header request_id = "b616ca659d154a5fb907dd8475792eeb" # retrieved from the X-ConfigCat-Webhook-Timestamp request header timestamp = 1669629035 # the webhook request's raw body body = "examplebody" content_to_sign = request_id+str(timestamp)+body signing_key_bytes = bytes(signing_key, 'utf-8') calculated_signature = base64.b64encode(hmac.new(signing_key_bytes, bytes(content_to_sign, 'utf-8'), 'sha256').digest()) print(calculated_signature.decode() == received_signature) # must be true ``` ``` require 'openssl' require 'base64' # retrieved from the ConfigCat Dashboard signing_key = "configcat_whsk_VN3juirnVh5pNvCKd81RYRYchxUX4j3NykbZG2fAy88=" # retrieved from the X-ConfigCat-Webhook-Signature-V1 request header received_signature = "Ks3cYsu9Lslfo+hVxNC3oQWnsF9e5d73TI5t94D9DRA=" # retrieved from the X-ConfigCat-Webhook-ID request header request_id = "b616ca659d154a5fb907dd8475792eeb" # retrieved from the X-ConfigCat-Webhook-Timestamp request header timestamp = 1669629035 # the webhook request's raw body body = "examplebody" content_to_sign = "#{request_id}#{timestamp}#{body}" calculated_signature = Base64.strict_encode64(OpenSSL::HMAC.digest("sha256", signing_key, content_to_sign)) puts calculated_signature == received_signature # must be true ``` ``` changed in ConfigCat: \n\n##ChangeDetailsSlack##" } ``` ## Connecting to Microsoft Teams[​](#connecting-to-microsoft-teams "Direct link to Connecting to Microsoft Teams") A few steps to set up Microsoft Teams and get a message when a setting changes: 1. In Microsoft Teams, create an [Incoming Webhook](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook#create-incoming-webhook-1) and copy the **Webhook URL**. 2. In ConfigCat, go to the [Webhooks](https://app.configcat.com/webhook) screen, and click **+ ADD WEBHOOK**. 3. Paste Microsoft Teams' **Webhhok URL** to ConfigCat's **URL** field. 4. Select **POST** as the **HTTP METHOD**. 5. Add the following request body: ``` { "@context": "https://schema.org/extensions", "@type": "MessageCard", "themeColor": "0072C6", "title": "##ConfigName## - ##EnvironmentName##", "text": "##ChangeDetailsTeams##", "potentialAction": [ { "@type": "OpenUri", "name": "Open Config in ConfigCat Dashboard", "targets": [ { "os": "default", "uri": "##URL##" } ] } ] } ``` --- # Endpoints The Proxy accepts HTTP requests on the following endpoints. ## CDN Proxy[​](#cdn-proxy "Direct link to CDN Proxy") The CDN proxy endpoint's purpose is to forward the underlying *config JSON* to other ConfigCat SDKs used by your application. GETOPTIONS/configuration-files/{path} This endpoint is mainly used by ConfigCat SDKs to retrieve all required data for feature flag evaluation. **Route parameters**: * `path`: It's set by the ConfigCat SDK configured to use the ConfigCat Proxy. It contains either an SDK key or an [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Responses**: * 200: The `config.json` file is downloaded successfully. * 204: In response to an `OPTIONS` request. * 304: The `config.json` file isn't modified based on the `Etag` sent in the `If-None-Match` header. * 400: The `sdkId` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. ### SDK Usage[​](#sdk-usage "Direct link to SDK Usage") In order to let a ConfigCat SDK use the Proxy, you have to set the SDK's `baseUrl` parameter to point to the Proxy's host. example.js ``` import * as configcat from "@configcat/sdk"; const configCatClient = configcat.getClient( "#YOUR-SDK-KEY#", configcat.PollingMode.AutoPoll, { baseUrl: "http://localhost:8050" } // Proxy URL ); ``` Additionally, as the Proxy maps [unique identifiers to each configured SDK key](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) it works with, you can use that identifier prefixed with `configcat-proxy/` as the SDK key at the ConfigCat SDK's initialization. So, let's assume you set up the Proxy with an SDK key mapped to the `my_sdk` SDK identifier: example.js ``` import * as configcat from "@configcat/sdk"; const configCatClient = configcat.getClient( "configcat-proxy/my_sdk", // SDK identifier prefixed with 'configcat-proxy/' configcat.PollingMode.AutoPoll, { baseUrl: "http://localhost:8050" } // Proxy URL ); ``` ### Supported SDK Versions[​](#supported-sdk-versions "Direct link to Supported SDK Versions") The following SDK versions are supported by the `>=v0.3.X` Proxy's CDN endpoint: | SDK | Version | | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | .NET | >= [v9.0.0](https://github.com/configcat/.net-sdk/releases/tag/v9.0.0) | | Android (Java) | >= [v10.0.0](https://github.com/configcat/android-sdk/releases/tag/v10.0.0) | | C++ | >= [v4.0.0](https://github.com/configcat/cpp-sdk/releases/tag/v4.0.0) | | Dart (Flutter) | >= [v4.0.0](https://github.com/configcat/dart-sdk/releases/tag/4.0.0) | | Elixir | >= [v4.0.0](https://github.com/configcat/elixir-sdk/releases/tag/v4.0.0) | | Go | >= [v9.0.0](https://github.com/configcat/go-sdk/releases/tag/v9.0.0) | | Java | >= [v9.0.0](https://github.com/configcat/java-sdk/releases/tag/v9.0.0) | | JavaScript (Browser, Bun, Chromium Extension, Cloudflare Worker, Deno, Node) | >= [v1.0.0](https://github.com/configcat/js-unified-sdk/releases) | | JS - Legacy | >= [v9.0.0](https://github.com/configcat/js-sdk/releases/tag/v9.0.0) | | JS SSR - Legacy | >= [v8.0.0](https://github.com/configcat/js-ssr-sdk/releases/tag/v8.0.0) | | Kotlin | >= [v3.0.0](https://github.com/configcat/kotlin-sdk/releases/tag/3.0.0) | | Node - Legacy | >= [v11.0.0](https://github.com/configcat/node-sdk/releases/tag/v11.0.0) | | PHP 8.1+ | >= [v9.0.0](https://github.com/configcat/php-sdk/releases/tag/v9.0.0) | | PHP 7.1+ | >= [v3.0.0](https://github.com/configcat/php7-sdk/releases/tag/v3.0.0) | | Python | >= [v9.0.3](https://github.com/configcat/python-sdk/releases/tag/v9.0.3) | | React | >= [v4.0.0](https://github.com/configcat/react-sdk/releases/tag/v4.0.0) | | Ruby | >= [v8.0.0](https://github.com/configcat/ruby-sdk/releases/tag/v8.0.0) | | Rust | >= [v0.1.0](https://github.com/configcat/rust-sdk/releases/tag/v0.1.0) | | Swift (iOS) | >= [v11.0.0](https://github.com/configcat/swift-sdk/releases/tag/11.0.0) | ### Available Options[​](#available-options "Direct link to Available Options") The following CDN Proxy related options are available: | Option | Default | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` http: cdn_proxy: enabled: `````` CONFIGCAT_HTTP_CDN_PROXY_ENABLED= ``` | `true` | Turns the hosting of the CDN proxy endpoint on/off. This endpoint can be used by other ConfigCat SDKs in your applications. | | - YAML
- Environment variable``` http: cdn_proxy: cors: enabled: `````` CONFIGCAT_HTTP_CDN_PROXY_CORS_ENABLED= ``` | `true` | Turns the sending of CORS headers on/off. It can be used to restrict access to specific domains. By default, the Proxy allows each origin by setting the `Access-Control-Allow-Origin` response header to the request's origin. You can override this functionality by restricting the allowed origins with the `allowed_origins` or `allowed_origins_regex` options. | | - YAML
- Environment variable``` http: cdn_proxy: cors: allowed_origins: - https://domain1.com - https://domain2.com `````` CONFIGCAT_HTTP_CDN_PROXY_CORS_ALLOWED_ORIGINS='["https://domain1.com","https://domain2.com"]' ``` | - | List of allowed CORS origins. When it's set, the Proxy will include only that origin in the `Access-Control-Allow-Origin` response header which matches the request's `Origin`.
When there's no matching request origin and the `allowed_origins_regex` option is not set, the Proxy will set the `Access-Control-Allow-Origin` response header to the first item in the allowed origins list. | | - YAML
- Environment variable``` http: cdn_proxy: cors: allowed_origins_regex: patterns: - https:\/\/.*domain1\.com - https:\/\/.*domain2\.com `````` CONFIGCAT_HTTP_CDN_PROXY_CORS_ALLOWED_ORIGINS_REGEX_PATTERNS='["https:\\/\\/.*domain1\\.com","https:\\/\\/.*domain2\\.com"]' ``` | - | List of regex patterns used to match allowed CORS origins. When it's set, the Proxy will match the request's `Origin` with the given regex patterns. When there's a match, the `Access-Control-Allow-Origin` response header will be set to the matched origin.
When there's no matching request origin, the Proxy will set the `Access-Control-Allow-Origin` response header to the `if_no_match` field's value.
The `if_no_match` option is mandatory if this option is used.
When using the environment variable, the regex escape character must be doubled (`\\`) because it's parsed as a JSON list and `\` is also a JSON escape character. | | - YAML
- Environment variable``` http: cdn_proxy: cors: allowed_origins_regex: if_no_match: https://domain1.com `````` CONFIGCAT_HTTP_CDN_PROXY_CORS_ALLOWED_ORIGINS_REGEX_IF_NO_MATCH="https://domain1.com" ``` | - | Required when the previous `patterns` option is set. It's value is used in the `Access-Control-Allow-Origin` header when an incoming request's `Origin` doesn't match with any previously configured regex patterns. | | - YAML
- Environment variable``` http: cdn_proxy: headers: Custom-Header-Name: "" `````` CONFIGCAT_HTTP_CDN_PROXY_HEADERS='{"Custom-Header-Name":""}' ``` | - | Additional headers that must be sent back on each CDN proxy endpoint response. | ## API[​](#api "Direct link to API") The API endpoints are for server side feature flag evaluation. POSTOPTIONS/api/{sdkId}/eval This endpoint evaluates a single feature flag identified by a `key` with the given [User Object](https://configcat.com/docs/docs/targeting/user-object/.md). **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Request body**: ``` { "key": "", "user": { "Identifier": "", "Rating": 4.5, "Roles": ["Role1","Role2"], // any other attribute } } ``` The type of the `user` object's fields can only be `string`, `number`, or `string[]`. **Responses**: * 200: The feature flag evaluation finished successfully. * Response body: ``` { "value": , "variationId": "" } ``` 204: In response to an `OPTIONS` request. * 400: The `sdkId` or the `key` from the request body is missing. * 404: The `sdkId` is pointing to a non-existent SDK. **Example**: example.js ``` const url = "http://localhost:8050/api/#SDK-IDENTIFIER#/eval"; // Proxy API URL with SDK identifier const data = { key: "isMyAwesomeFeatureEnabled", // Feature flag key user: { // User Object for evaluation Identifier: "#UNIQUE-USER-IDENTIFIER#" } }; const requestOptions = { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify(data), }; try { const response = await fetch(url, requestOptions); const responseData = await response.json(); console.log(responseData); // {"value":,"variationId":""} } catch (error) { console.error('Error:', error) } ``` POSTOPTIONS/api/{sdkId}/eval-all This endpoint evaluates all feature flags with the given [User Object](https://configcat.com/docs/docs/targeting/user-object/.md). **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Request body**: ``` { "user": { "Identifier": "", "Rating": 4.5, "Roles": ["Role1","Role2"], // any other attribute } } ``` The type of the `user` object's fields can only be `string`, `number`, or `string[]`. **Responses**: * 200: The evaluation of all feature flags finished successfully. * Response body: ``` { "feature-flag-key-1": { "value": , "variationId": "" }, "feature-flag-key-2": { "value": , "variationId": "" } } ``` 204: In response to an `OPTIONS` request. * 400: The `sdkId` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. **Example**: example.js ``` const url = "http://localhost:8050/api/#SDK-IDENTIFIER#/eval-all"; // Proxy API URL with SDK identifier const data = { user: { // User Object for evaluation Identifier: "#UNIQUE-USER-IDENTIFIER#" } }; const requestOptions = { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify(data), }; try { const response = await fetch(url, requestOptions); const responseData = await response.json(); console.log(responseData); } catch (error) { console.error('Error:', error) } ``` POSTOPTIONS/api/{sdkId}/refresh This endpoint commands the underlying SDK to download the latest available *config JSON*. **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Responses**: * 200: The refresh was successful. * 204: In response to an `OPTIONS` request. * 400: The `sdkId` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. GETOPTIONS/api/{sdkId}/keys This endpoint returns all feature flag keys belonging to the given [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key). **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Responses**: * 200: The keys are returned successfully. * Response body: ``` { "keys": [ "feature-flag-key-1", "feature-flag-key-1" ] } ``` 204: In response to an `OPTIONS` request. * 400: The `sdkId` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. ### Available Options[​](#available-options-1 "Direct link to Available Options") The following API related options are available: | Option | Default | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` http: api: enabled: `````` CONFIGCAT_HTTP_API_ENABLED= ``` | `true` | Turns the hosting of the API endpoints on/off. These endpoints can be used for server side feature flag evaluation. | | - YAML
- Environment variable``` http: api: cors: enabled: `````` CONFIGCAT_HTTP_API_CORS_ENABLED= ``` | `true` | Turns the sending of CORS headers on/off. It can be used to restrict access to specific domains. By default, the Proxy allows each origin by setting the `Access-Control-Allow-Origin` response header to the request's origin. You can override this functionality by restricting the allowed origins with the `allowed_origins` or `allowed_origins_regex` options. | | - YAML
- Environment variable``` http: api: cors: allowed_origins: - https://domain1.com - https://domain2.com `````` CONFIGCAT_HTTP_API_CORS_ALLOWED_ORIGINS='["https://domain1.com","https://domain2.com"]' ``` | - | List of allowed CORS origins. When it's set, the Proxy will include only that origin in the `Access-Control-Allow-Origin` response header which matches the request's `Origin`.
When there's no matching request origin and the `allowed_origins_regex` option is not set, the Proxy will set the `Access-Control-Allow-Origin` response header to the first item in the allowed origins list. | | - YAML
- Environment variable``` http: api: cors: allowed_origins_regex: patterns: - https:\/\/.*domain1\.com - https:\/\/.*domain2\.com `````` CONFIGCAT_HTTP_API_CORS_ALLOWED_ORIGINS_REGEX_PATTERNS='["https:\\/\\/.*domain1\\.com","https:\\/\\/.*domain2\\.com"]' ``` | - | List of regex patterns used to match allowed CORS origins. When it's set, the Proxy will match the request's `Origin` with the given regex patterns. When there's a match, the `Access-Control-Allow-Origin` response header will be set to the matched origin.
When there's no matching request origin, the Proxy will set the `Access-Control-Allow-Origin` response header to the `if_no_match` field's value.
The `if_no_match` option is mandatory if this option is used.
When using the environment variable, the regex escape character must be doubled (`\\`) because it's parsed as a JSON list and `\` is also a JSON escape character. | | - YAML
- Environment variable``` http: api: cors: allowed_origins_regex: if_no_match: https://domain1.com `````` CONFIGCAT_HTTP_API_CORS_ALLOWED_ORIGINS_REGEX_IF_NO_MATCH="https://domain1.com" ``` | - | Required when the previous `patterns` option is set. It's value is used in the `Access-Control-Allow-Origin` header when an incoming request's `Origin` doesn't match with any previously configured regex patterns. | | - YAML
- Environment variable``` http: api: headers: Custom-Header-Name: "" `````` CONFIGCAT_HTTP_API_HEADERS='{"Custom-Header-Name":""}' ``` | - | Additional headers that must be sent back on each API endpoint response. | | - YAML
- Environment variable``` http: api: auth_headers: X-API-KEY: "" `````` CONFIGCAT_HTTP_API_AUTH_HEADERS='{"X-API-KEY":""}' ``` | - | Additional headers that must be on each request sent to the API endpoints. If the request doesn't include the specified header, or the values are not matching, the Proxy will respond with a `401` HTTP status code. | ## OpenFeature Remote Evaluation Protocol (OFREP)[​](#openfeature-remote-evaluation-protocol-ofrep "Direct link to OpenFeature Remote Evaluation Protocol (OFREP)") info OFREP compatibility is only available from Proxy version [`v2.0.0`](https://github.com/configcat/configcat-proxy/releases/tag/v2.0.0). The Proxy conforms to the [OpenFeature Remote Evaluation Protocol](https://github.com/open-feature/protocol), which means it can be used with OFREP compatible OpenFeature providers. POSTOPTIONS/ofrep/v1/evaluate/flags/{key} This endpoint is used by OFREP compatible OpenFeature providers to evaluate a feature flag. **Route parameters**: * `key`: The key of the feature flag to evaluate. **Headers**: * `X-ConfigCat-SdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Request body**: ``` { "context": { "targetingKey": "", "Rating": 4.5, "Roles": ["Role1","Role2"], } } ``` **Responses**: * 200: The feature flag evaluation finished successfully. * Response body: ``` { "key": "", "value": , "variant": "", "reason": "" } ``` 204: In response to an `OPTIONS` request. * 400: The `X-ConfigCat-SdkId` header is missing. * 404: The `X-ConfigCat-SdkId` header is pointing to a non-existent SDK or the feature flag for `key` is not found. **Example**: example.js ``` import { OpenFeature } from "@openfeature/web-sdk"; import { OFREPWebProvider } from '@openfeature/ofrep-web-provider'; OpenFeature.setProvider( new OFREPWebProvider({ baseUrl: 'http://localhost:8050', // Proxy URL headers: [ ['X-ConfigCat-SdkId', `#SDK-IDENTIFIER#`], ], }), ); ``` POSTOPTIONS/ofrep/v1/evaluate/flags This endpoint is used by OFREP compatible OpenFeature providers to evaluate all feature flags. **Headers**: * `X-ConfigCat-SdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Request body**: ``` { "context": { "targetingKey": "", "Rating": 4.5, "Roles": ["Role1","Role2"], } } ``` **Responses**: * 200: The evaluation of all feature flags finished successfully. * Response body: ``` { "flags": [ { "key": "", "value": , "variant": "", "reason": "" }, { "key": "", "value": , "variant": "", "reason": "" } ] } ``` 204: In response to an `OPTIONS` request. * 400: The `X-ConfigCat-SdkId` header is missing. * 404: The `X-ConfigCat-SdkId` header is pointing to a non-existent SDK. **Example**: example.js ``` import { OpenFeature } from "@openfeature/web-sdk"; import { OFREPWebProvider } from '@openfeature/ofrep-web-provider'; OpenFeature.setProvider( new OFREPWebProvider({ baseUrl: 'http://localhost:8050', // Proxy URL headers: [ ['X-ConfigCat-SdkId', '#SDK-IDENTIFIER#'], ], }), ); ``` ### Available Options[​](#available-options-2 "Direct link to Available Options") The following OFREP related options are available: | Option | Default | Description | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` http: ofrep: enabled: `````` CONFIGCAT_HTTP_OFREP_ENABLED= ``` | `false` | Turns the hosting of the OFREP endpoints on/off. These endpoints can be used by OFREP compatible OpenFeature providers for server side feature flag evaluation. | | - YAML
- Environment variable``` http: ofrep: cors: enabled: `````` CONFIGCAT_HTTP_OFREP_CORS_ENABLED= ``` | `true` | Turns the sending of CORS headers on/off. It can be used to restrict access to specific domains. By default, the Proxy allows each origin by setting the `Access-Control-Allow-Origin` response header to the request's origin. You can override this functionality by restricting the allowed origins with the `allowed_origins` or `allowed_origins_regex` options. | | - YAML
- Environment variable``` http: ofrep: cors: allowed_origins: - https://domain1.com - https://domain2.com `````` CONFIGCAT_HTTP_OFREP_CORS_ALLOWED_ORIGINS='["https://domain1.com","https://domain2.com"]' ``` | - | List of allowed CORS origins. When it's set, the Proxy will include only that origin in the `Access-Control-Allow-Origin` response header which matches the request's `Origin`.
When there's no matching request origin and the `allowed_origins_regex` option is not set, the Proxy will set the `Access-Control-Allow-Origin` response header to the first item in the allowed origins list. | | - YAML
- Environment variable``` http: ofrep: cors: allowed_origins_regex: patterns: - https:\/\/.*domain1\.com - https:\/\/.*domain2\.com `````` CONFIGCAT_HTTP_OFREP_CORS_ALLOWED_ORIGINS_REGEX_PATTERNS='["https:\\/\\/.*domain1\\.com","https:\\/\\/.*domain2\\.com"]' ``` | - | List of regex patterns used to match allowed CORS origins. When it's set, the Proxy will match the request's `Origin` with the given regex patterns. When there's a match, the `Access-Control-Allow-Origin` response header will be set to the matched origin.
When there's no matching request origin, the Proxy will set the `Access-Control-Allow-Origin` response header to the `if_no_match` field's value.
The `if_no_match` option is mandatory if this option is used.
When using the environment variable, the regex escape character must be doubled (`\\`) because it's parsed as a JSON list and `\` is also a JSON escape character. | | - YAML
- Environment variable``` http: ofrep: cors: allowed_origins_regex: if_no_match: https://domain1.com `````` CONFIGCAT_HTTP_OFREP_CORS_ALLOWED_ORIGINS_REGEX_IF_NO_MATCH="https://domain1.com" ``` | - | Required when the previous `patterns` option is set. It's value is used in the `Access-Control-Allow-Origin` header when an incoming request's `Origin` doesn't match with any previously configured regex patterns. | | - YAML
- Environment variable``` http: ofrep: headers: Custom-Header-Name: "" `````` CONFIGCAT_HTTP_OFREP_HEADERS='{"Custom-Header-Name":""}' ``` | - | Additional headers that must be sent back on each OFREP endpoint response. | | - YAML
- Environment variable``` http: ofrep: auth_headers: X-API-KEY: "" `````` CONFIGCAT_HTTP_OFREP_AUTH_HEADERS='{"X-API-KEY":""}' ``` | - | Additional headers that must be on each request sent to the OFREP endpoints. If the request doesn't include the specified header, or the values are not matching, the Proxy will respond with a `401` HTTP status code. | ## SSE[​](#sse "Direct link to SSE") The SSE endpoint allows you to subscribe for feature flag value changes through [Server-Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) connections. GETOPTIONS/sse/{sdkId}/eval/{data} This endpoint subscribes to a single flag's changes. Whenever the watched flag's value changes, the Proxy sends the new value to each connected client. **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. * `data`: The `base64` encoded input data for feature flag evaluation that must contain the feature flag's key and a [User Object](https://configcat.com/docs/docs/targeting/user-object/.md). **Responses**: * 200: The SSE connection established successfully. * Response body: ``` { "value": , "variationId": "" } ``` 204: In response to an `OPTIONS` request. * 400: The `sdkId`, `data`, or the `key` attribute of `data` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. **Example**: example.js ``` const rawData = { key: "", user: { // field types can only be `string`, `number`, or `string[]`. Identifier: "", Rating: 4.5, Roles: ["Role1","Role2"], // any other attribute } } const data = btoa(JSON.stringify(rawData)) const evtSource = new EventSource("http://localhost:8050/sse/#SDK-IDENTIFIER#/eval/" + data); evtSource.onmessage = (event) => { console.log(event.data); // {"value":,"variationId":""} }; ``` GETOPTIONS/sse/{sdkId}/eval-all/{data} This endpoint subscribes to all feature flags' changes behind the given [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key). When any of the watched flags' value change, the Proxy sends its new value to each connected client. **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. * `data`: **Optional**. The `base64` encoded input data for feature flag evaluation that contains a [User Object](https://configcat.com/docs/docs/targeting/user-object/.md). **Responses**: * 200: The SSE connection established successfully. * Response body: ``` { "feature-flag-key-1": { "value": , "variationId": "" }, "feature-flag-key-2": { "value": , "variationId": "" } } ``` 204: In response to an `OPTIONS` request. * 400: The `sdkId` is missing. * 404: The `sdkId` is pointing to a non-existent SDK. **Example**: example.js ``` const rawData = { user: { // field types can only be `string`, `number`, or `string[]`. Identifier: "", Rating: 4.5, Roles: ["Role1","Role2"], // any other attribute } } const data = btoa(JSON.stringify(rawData)) const evtSource = new EventSource("http://localhost:8050/sse/#SDK-IDENTIFIER#/eval-all/" + data); evtSource.onmessage = (event) => { console.log(event.data); // {"feature-flag-key":{"value":,"variationId":""}} }; ``` ### Available Options[​](#available-options-3 "Direct link to Available Options") The following SSE related options are available: | Option | Default | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` http: sse: enabled: `````` CONFIGCAT_HTTP_SSE_ENABLED= ``` | `true` | Turns the hosting of the SSE endpoint on/off, This endpoint can be used to stream feature flag value changes. | | - YAML
- Environment variable``` http: sse: cors: enabled: `````` CONFIGCAT_HTTP_SSE_CORS_ENABLED= ``` | `true` | Turns the sending of CORS headers on/off. It can be used to restrict access to specific domains. By default, the Proxy allows each origin by setting the `Access-Control-Allow-Origin` response header to the request's origin. You can override this functionality by restricting the allowed origins with the `allowed_origins` or `allowed_origins_regex` options. | | - YAML
- Environment variable``` http: sse: cors: allowed_origins: - https://domain1.com - https://domain2.com `````` CONFIGCAT_HTTP_SSE_CORS_ALLOWED_ORIGINS='["https://domain1.com","https://domain2.com"]' ``` | - | List of allowed CORS origins. When it's set, the Proxy will include only that origin in the `Access-Control-Allow-Origin` response header which matches the request's `Origin`.
When there's no matching request origin and the `allowed_origins_regex` option is not set, the Proxy will set the `Access-Control-Allow-Origin` response header to the first item in the allowed origins list. | | - YAML
- Environment variable``` http: sse: cors: allowed_origins_regex: patterns: - https:\/\/.*domain1\.com - https:\/\/.*domain2\.com `````` CONFIGCAT_HTTP_SSE_CORS_ALLOWED_ORIGINS_REGEX_PATTERNS='["https:\\/\\/.*domain1\\.com","https:\\/\\/.*domain2\\.com"]' ``` | - | List of regex patterns used to match allowed CORS origins. When it's set, the Proxy will match the request's `Origin` with the given regex patterns. When there's a match, the `Access-Control-Allow-Origin` response header will be set to the matched origin.
When there's no matching request origin, the Proxy will set the `Access-Control-Allow-Origin` response header to the `if_no_match` field's value.
The `if_no_match` option is mandatory if this option is used.
When using the environment variable, the regex escape character must be doubled (`\\`) because it's parsed as a JSON list and `\` is also a JSON escape character. | | - YAML
- Environment variable``` http: sse: cors: allowed_origins_regex: if_no_match: https://domain1.com `````` CONFIGCAT_HTTP_SSE_CORS_ALLOWED_ORIGINS_REGEX_IF_NO_MATCH="https://domain1.com" ``` | - | Required when the previous `patterns` option is set. It's value is used in the `Access-Control-Allow-Origin` header when an incoming request's `Origin` doesn't match with any previously configured regex patterns. | | - YAML
- Environment variable``` http: sse: headers: Custom-Header-Name: "" `````` CONFIGCAT_HTTP_SSE_HEADERS='{"Custom-Header-Name":""}' ``` | - | Additional headers that must be sent back on each [SSE endpoint](#sse) response. | | - YAML
- Environment variable``` http: sse: log: level: "" `````` CONFIGCAT_HTTP_SSE_LOG_LEVEL="" ``` | `warn` | The verbosity of the SSE related logs.
Possible values: `error`, `warn`, `info` or `debug`. | ## Webhook[​](#webhook "Direct link to Webhook") Through the webhook endpoint, you can notify the Proxy about the availability of new feature flag evaluation data. Also, with the appropriate [SDK options](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#additional-options-for-underlying-sdks), the Proxy can [validate the signature](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md#verifying-webhook-requests) of each incoming webhook request. info If you use the [automatic configuration with Proxy profiles](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#1-automatic-configuration-with-proxy-profiles), you don't have to set up individual webhooks manually. You can follow the documentation of webhook notifications for Proxy profiles [here](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#webhook-notification). GETPOST/hook/{sdkId} Notifies the Proxy that the SDK with the given [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) must refresh its *config JSON* to the latest version. **Route parameters**: * `sdkId`: The [SDK identifier](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#sdk-identifier--sdk-key) that uniquely identifies an SDK within the Proxy. **Responses**: * 200: The Proxy accepted the notification. * 400: The `sdkId` is missing or the [webhook signature validation](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md#verifying-webhook-requests) failed. * 404: The `sdkId` is pointing to a non-existent SDK. ### ConfigCat Dashboard[​](#configcat-dashboard "Direct link to ConfigCat Dashboard") You can set up webhooks to invoke the Proxy on the [Webhooks page](https://app.configcat.com/product/webhooks) of the ConfigCat Dashboard. ![Webhook](/docs/assets/proxy/webhook.png) ### Available Options[​](#available-options-4 "Direct link to Available Options") The following webhook related options are available: | Option | Default | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` http: webhook: enabled: `````` CONFIGCAT_HTTP_WEBHOOK_ENABLED= ``` | `true` | Turns the hosting of the Webhook endpoint on/off. This endpoint can be used to notify the Proxy about the availability of new feature flag evaluation data. | | - YAML
- Environment variable``` http: webhook: auth: user: "" `````` CONFIGCAT_HTTP_WEBHOOK_AUTH_USER="" ``` | - | Basic authentication user. The basic authentication webhook header can be set on the [Webhooks page](https://app.configcat.com/product/webhooks) of the ConfigCat Dashboard. | | - YAML
- Environment variable``` http: webhook: auth: password: "" `````` CONFIGCAT_HTTP_WEBHOOK_AUTH_PASSWORD="" ``` | - | Basic authentication password. The basic authentication webhook header can be set on the [Webhooks page](https://app.configcat.com/product/webhooks) of the ConfigCat Dashboard. | | - YAML
- Environment variable``` http: webhook: auth_headers: X-API-KEY: "" `````` CONFIGCAT_HTTP_WEBHOOK_AUTH_HEADERS='{"X-API-KEY":""}' ``` | - | Additional headers that ConfigCat must send with each request to the Webhook endpoint. Webhook headers can be set on the [Webhooks page](https://app.configcat.com/product/webhooks) of the ConfigCat Dashboard. | --- # gRPC The ConfigCat Proxy can communicate over [gRPC](https://grpc.io), an open-source, high-performance RPC framework with client support in several languages. To establish gRPC connections, you'll need the protobuf and the gRPC [service definition](https://github.com/configcat/configcat-proxy/blob/main/grpc/proto/flag_service.proto). It's required to generate clients with [`protoc`](https://protobuf.dev/downloads/) for your [desired platform](https://protobuf.dev/reference/). flag\_service.proto ``` syntax = "proto3"; option go_package = "github.com/configcat/configcat-proxy/grpc/proto"; package configcat; import "google/protobuf/empty.proto"; import "google/protobuf/timestamp.proto"; // Service that contains feature flag evaluation procedures. service FlagService { // Stream for getting notified when a feature flag's value changes. rpc EvalFlagStream(EvalRequest) returns (stream EvalResponse) {} // Stream for getting notified when any feature flag's value changes. rpc EvalAllFlagsStream(EvalRequest) returns (stream EvalAllResponse) {} // Evaluates a feature flag. rpc EvalFlag(EvalRequest) returns (EvalResponse) {} // Evaluates each feature flag. rpc EvalAllFlags(EvalRequest) returns (EvalAllResponse) {} // Requests the keys of each feature flag. rpc GetKeys(KeysRequest) returns (KeysResponse) {} // Commands the underlying SDK to refresh its evaluation data. rpc Refresh(RefreshRequest) returns (google.protobuf.Empty) {} } // Feature flag evaluation request message. message EvalRequest { // The SDK identifier. string sdk_id = 1; // The feature flag's key to evaluate. string key = 2; // The User Object. map user = 3; } // Feature flag evaluation response message. message EvalResponse { // The evaluated value. oneof value { int32 int_value = 1; double double_value = 2; string string_value = 3; bool bool_value = 4; } // The variation ID. string variation_id = 5; } // Response message that contains the evaluation result of each feature flag. message EvalAllResponse { // The evaluated value of each feature flag. map values = 1; } // Request message for getting each available feature flag's key. message KeysRequest { // The SDK identifier. string sdk_id = 1; } // Response message that contains each available feature flag's key. message KeysResponse { // The keys of each feature flag. repeated string keys = 1; } // Request message for the given SDK to refresh its evaluation data. message RefreshRequest { // The SDK identifier. string sdk_id = 1; } // Defines the possible values that can be set in the `user` map. message UserValue { oneof value { double number_value = 1; string string_value = 2; google.protobuf.Timestamp time_value = 3; StringList string_list_value = 4; } } // Represents a list of strings. message StringList { repeated string values = 1; } ``` info In order to secure the gRPC communication with the Proxy, set up [TLS](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#tls). ## Client Usage[​](#client-usage "Direct link to Client Usage") The following example uses a generated Go client, but gRPC clients generated for other languages are working as well. example.go ``` opts := []grpc.DialOption{ grpc.WithBlock(), grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{ // Any TLS options })), } conn, err := grpc.DialContext(context.Background(), "localhost:50051", // Proxy host and gRPC port opts...) if err != nil { panic(err) } defer func() { _ = conn.Close() }() client := proto.NewFlagServiceClient(conn) ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() resp, err := client.EvalFlag(ctx, &proto.EvalRequest{ SdkId: "", Key: "", User: map[string]*proto.UserValue{"Identifier": {Value: &proto.UserValue_StringValue{StringValue: ""}}} }) if err != nil { panic(err) } fmt.Printf("Evaluation result: %v", resp.GetBoolValue()) ``` ## Health Check[​](#health-check "Direct link to Health Check") The Proxy exposes health information over a [standardized health RPC service](https://github.com/grpc/grpc-proto/blob/master/grpc/health/v1/health.proto). Clients can set `""` as the `service` parameter (or skip specifying it) to get the health status of the gRPC server. Exposing the health check service is configurable and turned on by default. For more details about gRPC health checking, check out the [official documentation](https://grpc.io/docs/guides/health-checking/). ## Server Reflection[​](#server-reflection "Direct link to Server Reflection") The Proxy can expose its protobuf-defined feature flag evaluation API over a [standardized reflection RPC service](https://github.com/grpc/grpc-proto/blob/master/grpc/reflection/v1/reflection.proto), including all types referenced by the request and response messages. Exposing the reflection service is configurable and turned off by default. For more details about gRPC server reflection, check out the [official documentation](https://grpc.io/docs/guides/reflection/). ## Available Options[​](#available-options "Direct link to Available Options") The following gRPC related options are available: * YAML * Environment variables options.yml ``` grpc: enabled: port: 50051 server_reflection_enabled: health_check_enabled: keep_alive: max_connection_idle: 15 max_connection_age: 30 max_connection_age_grace: 5 time: 5 timeout: 1 log: level: "" ``` ``` CONFIGCAT_GRPC_ENABLED= CONFIGCAT_GRPC_PORT=50051 CONFIGCAT_GRPC_HEALTH_CHECK_ENABLED= CONFIGCAT_GRPC_SERVER_REFLECTION_ENABLED= CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_IDLE=15 CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_AGE=30 CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_AGE_GRACE=5 CONFIGCAT_GRPC_KEEP_ALIVE_TIME=5 CONFIGCAT_GRPC_KEEP_ALIVE_TIMEOUT=1 CONFIGCAT_GRPC_LOG_LEVEL="" ``` Here's the explanation for each option: | Option | Default | Description | | --------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` grpc: enabled: `````` CONFIGCAT_GRPC_ENABLED= ``` | `true` | Turns the ability to communicate with the Proxy through gRPC on/off. | | - YAML
- Environment variable``` grpc: port: 50051 `````` CONFIGCAT_GRPC_PORT=50051 ``` | `50051` | The port used for gRPC communication. | | - YAML
- Environment variable``` grpc: health_check_enabled: `````` CONFIGCAT_GRPC_HEALTH_CHECK_ENABLED= ``` | `true` | Turns the [gRPC health check service](https://grpc.io/docs/guides/health-checking/) on/off. | | - YAML
- Environment variable``` grpc: server_reflection_enabled: `````` CONFIGCAT_GRPC_SERVER_REFLECTION_ENABLED= ``` | `false` | Turns the [gRPC server reflection](https://grpc.io/docs/guides/reflection/) on/off. | | - YAML
- Environment variable``` grpc: keep_alive: max_connection_idle: 15 `````` CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_IDLE=15 ``` | `INT_MAX (Infinite)` | Maximum time in seconds that a channel may have no outstanding rpcs, after which the server will close the connection. [More about the gRPC keep-alive](https://grpc.io/docs/guides/keepalive/). | | - YAML
- Environment variable``` grpc: keep_alive: max_connection_age: 30 `````` CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_AGE=30 ``` | `INT_MAX (Infinite)` | Maximum time in seconds that a channel may exist. [More about the gRPC keep-alive](https://grpc.io/docs/guides/keepalive/). | | - YAML
- Environment variable``` grpc: keep_alive: max_connection_age_grace: 5 `````` CONFIGCAT_GRPC_KEEP_ALIVE_MAX_CONNECTION_AGE_GRACE=5 ``` | `INT_MAX (Infinite)` | Grace period in seconds after the channel reaches its max age. [More about the gRPC keep-alive](https://grpc.io/docs/guides/keepalive/). | | - YAML
- Environment variable``` grpc: keep_alive: time: 5 `````` CONFIGCAT_GRPC_KEEP_ALIVE_TIME=5 ``` | `7200` | The interval in seconds between PING frames. [More about the gRPC keep-alive](https://grpc.io/docs/guides/keepalive/). | | - YAML
- Environment variable``` grpc: keep_alive: timeout: 1 `````` CONFIGCAT_GRPC_KEEP_ALIVE_TIMEOUT=1 ``` | `20` | The timeout in seconds for a PING frame to be acknowledged. If sender does not receive an acknowledgment within this time, it will close the connection. [More about the gRPC keep-alive](https://grpc.io/docs/guides/keepalive/). | | - YAML
- Environment variable``` grpc: log: level: "" `````` CONFIGCAT_GRPC_LOG_LEVEL="" ``` | `warn` | The verbosity of the gRPC related logs.
Possible values: `error`, `warn`, `info` or `debug`.
When `debug` is set, the Proxy will log each RPC with additional details. | --- # Monitoring The ConfigCat Proxy provides diagnostic data via its `/status` and a Prometheus-compatible `/metrics` endpoint. These endpoints are served on a specific port, so you can separate them from the public HTTP communication. The following diagnostics related configuration options are available: | Option | Default | Description | | --------------------------------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------ | | - YAML
- Environment variable``` diag: enabled: `````` CONFIGCAT_DIAG_ENABLED= ``` | `true` | Turns the diagnostics HTTP server on/off. | | - YAML
- Environment variable``` diag: port: 8051 `````` CONFIGCAT_DIAG_PORT=8051 ``` | `8051` | The port used by the diagnostics HTTP server. | | - YAML
- Environment variable``` diag: status: enabled: `````` CONFIGCAT_DIAG_STATUS_ENABLED= ``` | `true` | Turns the hosting of the [status endpoint](#status) on the diagnostics HTTP server on/off. | | - YAML
- Environment variable``` diag: metrics: enabled: `````` CONFIGCAT_DIAG_METRICS_ENABLED= ``` | `true` | Turns the [Prometheus metrics](#prometheus-metrics) on the diagnostics HTTP server on/off. | ## Status Endpoint[​](#status "Direct link to Status Endpoint") The Proxy provides status information (health check) about its components on the following endpoint: GETOPTIONS/status The Proxy regularly checks whether the underlying SDKs can communicate with their configured source and with the cache. This endpoint returns the actual state of these checks. **Responses**: * 200: The status returned successfully. * 204: In response to an `OPTIONS` request. **Example Response**: ``` { "status": "healthy", "sdks": { "my_sdk": { "key": "****************************************hwTYg", "mode": "online", "source": { "type": "remote", "status": "healthy", "records": [ "Mon, 29 May 2023 16:36:40 UTC: [ok] config fetched" ] } }, "another_sdk": { "key": "****************************************ovVnQ", "mode": "offline", "source": { "type": "cache", "status": "healthy", "records": [ "Mon, 29 May 2023 16:36:40 UTC: [ok] reload from cache succeeded", "Mon, 29 May 2023 16:36:45 UTC: [ok] config from cache not modified" ] } } }, "cache": { "status": "healthy", "records": [ "Mon, 29 May 2023 16:36:40 UTC: [ok] cache read succeeded", "Mon, 29 May 2023 16:36:40 UTC: [ok] cache write succeeded", "Mon, 29 May 2023 16:36:40 UTC: [ok] cache read succeeded", "Mon, 29 May 2023 16:36:45 UTC: [ok] cache read succeeded" ] } } ``` **Details**: If everything is operational, each `status` node shows the value `healthy`. If a component encounters a failure, it'll put an error to its `records` collection. If a component's last two records are errors, its `status` will switch to `degraded`. If a component becomes operational again it'll put an `[ok]` to the `records` and will switch back to `healthy`. If an SDK couldn't initialize itself neither from an external cache nor from the ConfigCat CDN, its status will be `down`. It means, this SDK is not able to accept evaluation requests because it doesn't have a valid *config JSON* to work with. If an SDK was able to initialize from its configured source, but its last two attempts to refresh has been failed (either from cache or from the ConfigCat CDN), it will become `degraded` because each refresh attempt will put an error to its `records` collection. This means, it's still able to evaluate feature flags, but it might work on a stale *config JSON*. The root `status` is `healthy` if all of the SDKs are `healthy`. If any of the SDKs become `degraded` or `down`, the root will also switch to `degraded` (or `down` if each SDK is `down`). note You can enable the status endpoint on the main HTTP port (default: `8050`) with the [HTTP configuration options](https://configcat.com/docs/docs/advanced/proxy/proxy-overview/.md#http). ## Prometheus Metrics[​](#prometheus-metrics "Direct link to Prometheus Metrics") You can set up the Proxy to export metrics about its internal state in Prometheus format. These metrics are served via the `/metrics` endpoint. The following metrics are exported: | Name | Type | Description | | --------------------------------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `configcat_http_request_duration_seconds` | Histogram | Histogram of Proxy HTTP response time in seconds.

Tags:- `route`: The request's URL path.
- `method`: The request's HTTP method.
- `status`: The response's HTTP status. | | `configcat_grpc_rpc_duration_seconds` | Histogram | Histogram of RPC call latency in seconds.

Tags:- `method`: The RPCs name.
- `code`: The RPCs response code. | | `configcat_sdk_http_request_duration_seconds` | Histogram | Histogram of ConfigCat CDN HTTP response time in seconds.

Tags:- `sdk`: The SDK's identifier that initiated the request.
- `route`: The request's URL path.
- `status`: The response's HTTP status. | | `configcat_stream_connections` | Gauge | Number of active client connections per stream.

Tags:- `sdk`: The SDK's identifier that handles the connection.
- `type`: `sse` or `grpc`.
- `flag`: The streamed feature flag's key. | | `configcat_stream_msg_sent_total` | Counter | Total number of all messages sent with streaming.

Tags:- `sdk`: The related SDK's identifier.
- `type`: `sse` or `grpc`.
- `flag`: The evaluated feature flag's key. | info The Proxy also exports metrics about the Go environment, e.g., `go_goroutines` or `go_memstats_alloc_bytes`, and process-related stats, e.g., `process_cpu_seconds_total`. To integrate with Prometheus, put the following scrape config—that points to the Proxy—into your Prometheus configuration: ``` scrape_configs: - job_name: configcat_proxy metrics_path: /metrics static_configs: - targets: - :8051 ``` --- # ConfigCat Proxy The [ConfigCat Proxy](https://github.com/configcat/configcat-proxy) allows you to host a feature flag evaluation service in your own infrastructure. It's a small Go application that communicates with ConfigCat's CDN network and caches/proxies *config JSON* files for your frontend and backend applications. The *config JSON* contains all the data that is needed for ConfigCat SDKs to evaluate feature flags. The Proxy provides the following: * **Performance**: The Proxy can be deployed close to your applications and can serve the downloaded *config JSON* files from memory. ConfigCat SDKs then can operate on the [proxied *config JSON*](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#cdn-proxy). This can reduce the duration of feature flag evaluation for stateless or short lived applications. * **Reliability**: The Proxy can store the downloaded *config JSON* files in an external [cache](#cache). It can fall back to operating on the cached *config JSON* if the ConfigCat CDN network becomes inaccessible. * **Security**: The Proxy can act as a [server side flag evaluation](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#api) component. Using it like that can prevent the exposure of *config JSON* files to frontend and mobile applications. * **Scalability**: Horizontal scaling allows you to align with the load coming from your applications accordingly. * **Streaming**: The Proxy provides real-time feature flag change notifications via [Server-Sent Events (SSE)](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#sse) and [gRPC](https://configcat.com/docs/docs/advanced/proxy/grpc/.md). ## Architecture[​](#architecture "Direct link to Architecture") The following diagram shows the high level architecture of the Proxy. ![High level Proxy architecture](/docs/assets/proxy/proxy_arch.png) ### How It Works[​](#how-it-works "Direct link to How It Works") The Proxy wraps one or more SDK instances for handling feature flag evaluation requests. It also serves the related *config JSON* files that can be consumed by other ConfigCat SDKs running in your applications. Within the Proxy, the underlying SDK instances can run in the following modes: * **Online**: In this mode, the underlying SDK has an active connection to the ConfigCat CDN network through the internet. * **Offline**: In [this mode](#offline-mode), the underlying SDK doesn't have an active connection to ConfigCat. Instead, it uses the configured cache or a file as a source of its *config JSON*. With the combination of the above modes, you can construct a cluster of proxies where only one node is responsible for the communication with ConfigCat, and all the other nodes are working from a central cache. ![Load balanced Proxy architecture](/docs/assets/proxy/load_balanced.png) ### Communication[​](#communication "Direct link to Communication") There are three ways how the Proxy is informed about the availability of new feature flag evaluation data: * **Polling**: The ConfigCat SDKs within the Proxy are regularly polling the ConfigCat CDN for new *config JSON* versions. * **Webhook**: The Proxy has [webhook endpoints](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#webhook) (for each underlying SDK) which can be set on the [ConfigCat Dashboard](https://app.configcat.com/product/webhooks) to be invoked when someone saves & publishes new feature flag changes. * **Cache polling / file watching**: In [offline mode](#offline-mode), the Proxy can regularly poll a cache or watch a file for new *config JSON* versions. These are the ports used by the Proxy by default: * **8050**: for standard HTTP communication. ([API](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#api), [CDN proxy](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#cdn-proxy), [Webhook](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#webhook), [SSE](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#sse)) * **8051**: for providing diagnostic data ([status](https://configcat.com/docs/docs/advanced/proxy/monitoring/.md#status), [prometheus metrics](https://configcat.com/docs/docs/advanced/proxy/monitoring/.md#prometheus-metrics)). * **50051**: for [gRPC](https://configcat.com/docs/docs/advanced/proxy/grpc/.md) communication. ## Installation[​](#installation "Direct link to Installation") You can install the ConfigCat Proxy from the following sources: **Docker** The docker image is available on DockerHub. You can run the image either as a standalone docker container or via `docker-compose`. * Standalone * docker-compose Pull the docker image: ``` docker pull configcat/proxy ``` Run the ConfigCat Proxy: ``` docker run -d --name configcat-proxy \ -p 8050:8050 -p 8051:8051 -p 50051:50051 \ -e CONFIGCAT_SDKS='{"":""}' \ configcat/proxy ``` docker-compose.yml ``` services: configcat_proxy: image: configcat/proxy environment: - CONFIGCAT_SDKS={"":""} ports: - "8050:8050" - "8051:8051" - "50051:50051" ``` To start docker services, execute the following command: ``` docker-compose up -f docker-compose.yml -d ``` **Standalone executable** You can download the executables directly from [GitHub Releases](https://github.com/configcat/configcat-proxy/releases) for your desired platform. You can then check the [status endpoint](https://configcat.com/docs/docs/advanced/proxy/monitoring/.md#status) of the Proxy to ensure it's working correctly: `http://localhost:8051/status` ## Usage Scenarios[​](#usage-scenarios "Direct link to Usage Scenarios") This section describes the possible ways of how you can use the Proxy from your application. You can decide where you want the actual feature flag evaluation to happen. * **Local evaluation**: Feature flags are evaluated in your application by the ConfigCat SDK running in your application. The Proxy only provides the data required for the evaluation process. * **Remote evaluation**: Feature flags are evaluated within the Proxy, your application only gets the result of the evaluation process. ### 1. Local evaluation using a ConfigCat SDK connected to the Proxy[​](#1-local-evaluation-using-a-configcat-sdk-connected-to-the-proxy "Direct link to 1. Local evaluation using a ConfigCat SDK connected to the Proxy") The Proxy has the ability to forward all information required for feature flag evaluation to ConfigCat SDKs via its [CDN proxy](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#cdn-proxy) endpoint. This means that you can set up your ConfigCat SDK instances to use the Proxy as their data source. To do this, you have to set the SDK's `baseUrl` option to the Proxy's host. example.js (Initializing the ConfigCat JS SDK to use the Proxy with SDK Key) ``` import * as configcat from "@configcat/sdk"; const configCatClient = configcat.getClient( "#YOUR-SDK-KEY#", configcat.PollingMode.AutoPoll, { baseUrl: "http://localhost:8050" } // Proxy URL ); ``` Additionally, as the Proxy maps [unique identifiers to each configured SDK key](#sdk-identifier--sdk-key) it works with, you can use that identifier prefixed with `configcat-proxy/` as the SDK key at the ConfigCat SDK's initialization. example.js (Initializing the ConfigCat JS SDK to use the Proxy with SDK identifier) ``` import * as configcat from "@configcat/sdk"; var configCatClient = configcat.getClient( "configcat-proxy/#SDK-IDENTIFIER#", // SDK identifier prefixed with 'configcat-proxy/' configcat.PollingMode.AutoPoll, { baseUrl: "http://localhost:8050" } // Proxy URL ); ``` ### 2. Remote evaluation with the Proxy's API endpoints[​](#2-remote-evaluation-with-the-proxys-api-endpoints "Direct link to 2. Remote evaluation with the Proxy's API endpoints") You can leverage the Proxy's server side feature flag evaluation feature by sending simple HTTP requests to the Proxy's API endpoints. example.js (Evaluating a feature flag with API) ``` const url = "http://localhost:8050/api/#SDK-IDENTIFIER#/eval"; // Proxy API URL with SDK identifier const data = { key: "isMyAwesomeFeatureEnabled", // Feature flag key user: { // User Object for evaluation Identifier: "#UNIQUE-USER-IDENTIFIER#" } }; const requestOptions = { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify(data), }; try { const response = await fetch(url, requestOptions); const responseData = await response.json(); console.log(responseData); // {"value":,"variationId":""} } catch (error) { console.error('Error:', error) } ``` You can find the available API endpoints with their HTTP request/response schemas [here](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#api). ### 3. Remote evaluation with OpenFeature Remote Evaluation Protocol (OFREP)[​](#3-remote-evaluation-with-openfeature-remote-evaluation-protocol-ofrep "Direct link to 3. Remote evaluation with OpenFeature Remote Evaluation Protocol (OFREP)") info OFREP compatibility is only available from Proxy version [`v2.0.0`](https://github.com/configcat/configcat-proxy/releases/tag/v2.0.0). info The OFREP feature of the Proxy is turned OFF by default, to use it, you have to turn it ON with the [OFREP endpoint options](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#available-options-2). The Proxy conforms to the [OpenFeature Remote Evaluation Protocol](https://github.com/open-feature/protocol), which means it can be used with OFREP compatible OpenFeature providers. example.js (Initializing the OFREP JS Web provider to use the Proxy) ``` import { OpenFeature } from "@openfeature/web-sdk"; import { OFREPWebProvider } from '@openfeature/ofrep-web-provider'; OpenFeature.setProvider( new OFREPWebProvider({ baseUrl: 'http://localhost:8050', // Proxy URL headers: [ ['X-ConfigCat-SdkId', '#SDK-IDENTIFIER#'], ], }), ); ``` You can find the available OFREP endpoints with their HTTP request/response schemas [here](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#openfeature-remote-evaluation-protocol-ofrep). ### 4. Remote evaluation and streaming with SSE[​](#4-remote-evaluation-and-streaming-with-sse "Direct link to 4. Remote evaluation and streaming with SSE") The Proxy has the ability to evaluate feature flags and send notifications about subsequent evaluated flag value changes through [Server-Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events) connections. example.js (Evaluating a feature flag and listening to changes with SSE) ``` const rawData = { key: "isMyAwesomeFeatureEnabled", // Feature flag key user: { // User Object for evaluation Identifier: "#UNIQUE-USER-IDENTIFIER#" } } const data = btoa(JSON.stringify(rawData)) const url = "http://localhost:8050/sse/#SDK-IDENTIFIER#/eval"; // Proxy SSE URL with SDK identifier const evtSource = new EventSource(url + "/" + data); evtSource.onmessage = (event) => { console.log(event.data); // {"value":,"variationId":""} }; ``` For more information and usage examples, see the related [SSE endpoints documentation](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#sse). ### 5. Remote evaluation and streaming with gRPC[​](#5-remote-evaluation-and-streaming-with-grpc "Direct link to 5. Remote evaluation and streaming with gRPC") The Proxy supports both unary feature flag evaluation RPCs and server streaming of evaluated flag value changes. For more information and usage examples, see the [gRPC section of this documentation](https://configcat.com/docs/docs/advanced/proxy/grpc/.md). ## Configuration Options[​](#configuration-options "Direct link to Configuration Options") You can specify options for the Proxy either via a YAML file or with environment variables. When an option is defined in both places, the environment variable's value takes precedence. By default, the Proxy reads the options YAML from the following default locations: * **Windows**: `%PROGRAMDATA%\configcat\proxy\options.yml`, usually `C:\ProgramData\configcat\proxy\options.yml` * **macOS**: `/Library/Application Support/configcat/proxy/options.yml` * **Linux**: `/etc/configcat/proxy/options.yml` When the default location is not suitable, you can specify a custom location for your options YAML file via the `-c` argument. * YAML * Environment variables **Docker** When running the Proxy in docker, you can mount the options YAML file as a volume. ``` docker run -d --name configcat-proxy \ -p 8050:8050 -p 8051:8051 -p 50051:50051 \ -v /options.yml:/etc/configcat/proxy/options.yml ``` (Optional) With the `-c` argument to specify a custom path for your options YAML file: ``` docker run -d --name configcat-proxy \ -p 8050:8050 -p 8051:8051 -p 50051:50051 \ -v /options.yml:/cnf/options.yml \ configcat/proxy -c /cnf/options.yml ``` **Standalone executable** Run the Proxy as a standalone executable with the options YAML file in its default location: * macOS / Linux * Windows ``` ./configcat-proxy ``` ``` .\configcat-proxy.exe ``` (Optional) With the `-c` argument to specify a custom path for your options YAML file: * macOS / Linux * Windows ``` ./configcat-proxy -c /path-to-file/options.yml ``` ``` .\configcat-proxy.exe -c \path-to-file\options.yml ``` **Docker** When running the Proxy in docker, you can pass environment variables to the executing container. ``` docker run -d --name configcat-proxy \ -p 8050:8050 -p 8051:8051 -p 50051:50051 \ -e CONFIGCAT_SDKS='{"":""}' \ configcat/proxy ``` **Standalone executable** Make sure the related environment variables are available for the Proxy's hosting process. * shell * PowerShell ``` export CONFIGCAT_SDKS='{"":""}' ``` Then start the Proxy: ``` ./configcat-proxy ``` ``` $Env:CONFIGCAT_SDKS='{"":""}' ``` Then start the Proxy: ``` .\configcat-proxy.exe ``` The following sections will go through each available option in detail. ## How does the Proxy learn about feature flags?[​](#sdk "Direct link to How does the Proxy learn about feature flags?") In order to make the Proxy work properly, it must be set up with one or more [SDK keys](https://app.configcat.com/sdkkey). It creates one SDK instance per SDK key internally and uses those for feature flag evaluation. ### SDK Identifier[​](#sdk-identifier--sdk-key "Direct link to SDK Identifier") Within the Proxy, [SDK keys](https://app.configcat.com/sdkkey) are mapped to unique SDK identifiers. The *SDK key* identifies a config/environment pair and is used to configure an SDK instance to fetch the config JSON of that config/environment pair. The *SDK identifier* identifies an SDK instance running within the Proxy and configured to use the associated SDK key. That is, the SDK identifier is effectively an alias for the associated SDK key and is used in [endpoint routes](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md) to avoid exposing the SDK Key. There are two ways to let the Proxy know which SDK Keys it should use: ### 1. Automatic configuration with Proxy profiles[​](#1-automatic-configuration-with-proxy-profiles "Direct link to 1. Automatic configuration with Proxy profiles") info **Beta Feature**: Automatic configuration with Proxy profiles is in public beta. We're now collecting feedback from real-world usage to fine-tune the experience. Share your feedback [here](https://configcat.com/support). info The automatic configuration with Proxy profiles feature is only available from Proxy version [`v2.0.0`](https://github.com/configcat/configcat-proxy/releases/tag/v2.0.0). The Proxy has the ability to use *Proxy profiles* to determine which SDK keys to download and distribute. It periodically checks for profile changes, allowing it to pick up the changes on the fly, without needing a restart. You can set up Proxy profiles under the `Manage organization` -> `Proxy Profiles` menu on the [ConfigCat Dashboard](https://app.configcat.com/organization/proxy-profiles). ![Proxy Profiles menu](/docs/assets/proxy/profile-menu.png)

To connect a Proxy instance to a Proxy profile, follow these steps: * #### Create a new Proxy profile[​](#create-a-new-proxy-profile "Direct link to Create a new Proxy profile") Click on the `+ ADD PROFILE` button. ![Add Profile](/docs/assets/proxy/profile-add.png) Give the profile a meaningful name and description, then click `CREATE`. ![Create Profile](/docs/assets/proxy/profile-create.png)

* #### Configure your Proxy instance[​](#configure-your-proxy-instance "Direct link to Configure your Proxy instance") Grab the `Key` and `Secret` from the profile creation dialog and put them into the Proxy's configuration. ![Configure Proxy with key and secret](/docs/assets/proxy/profile-key-secret.png) * YAML * Environment variables options.yml ``` profile: key: secret: ``` ``` CONFIGCAT_PROFILE_KEY="" CONFIGCAT_PROFILE_SECRET="" ```
* #### Select which SDK Keys your Proxy should use[​](#select-which-sdk-keys-your-proxy-should-use "Direct link to Select which SDK Keys your Proxy should use") Click on the edit icon in the `SDK Keys` column. ![Click on Select SDK Keys](/docs/assets/proxy/profile-sdk-keys-configure.png) Select the config/environment pairs whose SDK key you want to make available for your Proxy instance. ![Select SDK Keys](/docs/assets/proxy/profile-sdk-keys-select.png) info You can click config names in the first column to toggle all SDK keys in a row, or environment names in the column headers to toggle all SDK keys in a column.
* #### Locate SDK identifiers for the selected SDK Keys[​](#locate-sdk-identifiers-for-the-selected-sdk-keys "Direct link to Locate SDK identifiers for the selected SDK Keys") You can find the SDK identifiers generated for the selected config/environment pairs on the ConfigCat Dashboard right where you find their SDK Key. ![Click on view SDK identifiers for ConfigCat Proxy](/docs/assets/proxy/profile-sdk-ids-arrow.png) In the dialog that appears, you can find the SDK identifiers for the current config/environment pair, listed for each available Proxy profile. ![Click on view SDK identifiers for ConfigCat Proxy](/docs/assets/proxy/profile-sdk-ids-dialog.png)

* #### (Optional) Set up how your Proxy should learn about feature flag changes[​](#optional-set-up-how-your-proxy-should-learn-about-feature-flag-changes "Direct link to (Optional) Set up how your Proxy should learn about feature flag changes") There are two ways a Proxy can detect feature flag changes. Each config/environment pair identified by each SDK key is automatically monitored for changes by periodic polling of the corresponding config JSON file at a configured frequency. Besides polling, the Proxy can receive change notifications over HTTP, via its [webhook endpoint](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md#webhook). * ##### Config JSON poll interval[​](#config-json-poll-interval "Direct link to Config JSON poll interval") You have the option to control how frequently the Proxy should poll for config JSON changes.
Click on the configure icon in the `Connection preferences` column, set the poll interval and click on `SAVE POLL INTERVAL`. ![Set config JSON poll interval](/docs/assets/proxy/profile-sdk-poll-interval.png)

* ##### Webhook notification[​](#webhook-notification "Direct link to Webhook notification") You can set up automatic webhook notifications about feature flag changes for your Proxy by providing its public URL.
Click on the configure icon in the `Connection preferences` column and select `Webhook notification`. Then, enter your Proxy instance's public URL and click `ADD PROXY URL`. ![Set Proxy webhook URL](/docs/assets/proxy/profile-webhook-url.png) Put the displayed webhook signing key(s) into your Proxy's configuration. Signing keys are for making sure that webhook requests received by your Proxy are sent by ConfigCat. Signatures are automatically [verified](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md#verifying-webhook-requests) by the Proxy. ![Copy webhook signing key](/docs/assets/proxy/profile-webhook-signing-key.png) * YAML * Environment variables options.yml ``` profile: webhook_signing_key: ``` ``` CONFIGCAT_PROFILE_WEBHOOK_SIGNING_KEY="" ``` Test the connection to your Proxy instance. ![Test the webhook configuration](/docs/assets/proxy/profile-webhook-test.png)

* #### All configuration options related to Proxy profiles[​](#all-configuration-options-related-to-proxy-profiles "Direct link to All configuration options related to Proxy profiles") | Option | Default | Description | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | - YAML
- Environment variable``` profile: key: "" `````` CONFIGCAT_PROFILE_KEY="" ``` | - | The Proxy profile's key. | | - YAML
- Environment variable``` profile: secret: "" `````` CONFIGCAT_PROFILE_SECRET="" ``` | - | The Proxy profile's secret used by the Proxy to authenticate requests to the Public Management API. | | - YAML
- Environment variable``` profile: base_url: "" `````` CONFIGCAT_PROFILE_BASE_URL="" ``` | ConfigCat Public Management API URL | The base URL from where the Proxy should fetch the SDK Keys selected in the connected Proxy profile. | | - YAML
- Environment variable``` profile: poll_interval: 300 `````` CONFIGCAT_PROFILE_POLL_INTERVAL=300 ``` | 300 | The interval (in seconds) specifying how frequently the Proxy should poll for changes in the connected Proxy profile. | | - YAML
- Environment variable``` profile: webhook_signing_key: "" `````` CONFIGCAT_PROFILE_WEBHOOK_SIGNING_KEY="" ``` | - | The [key used to sign](https://configcat.com/docs/docs/advanced/notifications-webhooks/.md#calculating-signature) the webhook requests sent to the Proxy. [More about how to set up webhooks for a Proxy profile](#webhook-notification). | | - YAML
- Environment variable``` profile: webhook_signature_valid_for: 300 `````` CONFIGCAT_PROFILE_WEBHOOK_SIGNATURE_VALID_FOR=300 ``` | 300 | The time period (in seconds) within which webhook requests are considered valid. [More about how to set up webhooks for a Proxy profile](#webhook-notification). | | - YAML
- Environment variable``` profile: log: level: "" `````` CONFIGCAT_PROFILE_LOG_LEVEL="" ``` | `warn` | The verbosity level for Proxy profile-related logging.
Possible values: `error`, `warn`, `info`, or `debug`. | | - YAML
- Environment variable``` profile: sdks: base_url: "" `````` CONFIGCAT_PROFILE_SDKS_BASE_URL="" ``` | ConfigCat's CDN URL. | The CDN base URL (forward proxy, dedicated subscription) from where the ConfigCat SDKs should download the config JSON. | | - YAML
- Environment variable``` profile: sdks: log: level: "" `````` CONFIGCAT_PROFILE_SDKS_LOG_LEVEL="" ``` | `warn` | The verbosity level for logging performed by the ConfigCat SDKs spawned for the connected Proxy profile.
Possible values: `error`, `warn`, `info`, or `debug`. |
#### Profile caching[​](#profile-caching "Direct link to Profile caching") Proxy instances running in online mode are caching their connected profile if they have a [cache](#cache) configured. This means that other Proxy instances running with [global offline mode](#global-offline-mode) enabled can use those cached profiles from the same shared cache. info Offline Proxy instances only need the profile's `key` to read the connected profile from the cache, the `secret` option is not mandatory in this mode. ### 2. Manual configuration[​](#2-manual-configuration "Direct link to 2. Manual configuration") When using environment variables, the SDK keys can be specified as a JSON object, where the **property name is the SDK identifier** (the identifier of the config/environment pair whose SDK Key the underlying SDK instance is configured to use) and the **property value is the actual SDK key**. The **SDK identifier** part is later used in [endpoint routes](https://configcat.com/docs/docs/advanced/proxy/endpoints/.md) to recognize which SDK must serve the given flag evaluation request. Furthermore, when configuring the Proxy **via environment variables**, the identifier becomes a **part of the SDK specific environment variable's name** in the following format: `CONFIGCAT__