canonical: https://jentic.com/apis/configcat.com/configcat # ConfigCat Public Management API The ConfigCat Public Management API lets developers and AI agents administer feature flags, configs, environments, products, and segments in the ConfigCat platform programmatically. It exposes 91 REST endpoints across 20 resource groups including Feature Flags & Settings, Configs, Environments, Segments, Webhooks, Permission Groups, Audit Logs, and Code References. The API is for management workflows such as creating flags, rolling out targeted releases, and reviewing audit history; flag value evaluation at runtime should still be done with the ConfigCat SDKs or Proxy. ## For AI agents Manage ConfigCat feature flags, configs, environments, segments, and team permissions programmatically. Useful for agents that automate flag rollouts, audit reviews, and SDK key rotation. ## Scope Does not handle runtime flag evaluation, A/B test analytics, or end-user delivery - use for ConfigCat platform management only. ## Capabilities - Create and update feature flags inside a config and target them to specific environments - Roll out percentage-based or segment-based releases by updating flag values per environment - Provision new environments and configs under a product for staged deployments - Review audit logs at the product or organization level to track who changed which flag - Rotate SDK keys for an environment after a security incident or team change - Manage permission groups and product members to enforce least-privilege access - Wire integrations and webhooks to trigger downstream workflows when a flag changes ## Use cases ### Automate Feature Flag Rollouts in CI/CD Use the ConfigCat Public Management API to flip flags as part of a deployment pipeline. After a build is promoted to staging, the pipeline calls PATCH /v1/settings/{settingId}/value to enable the flag in the staging environment, runs smoke tests, then promotes the same change to production. This keeps flag state in lock-step with deploy state and removes the manual dashboard click. Setup with Jentic takes under an hour versus a few hours integrating directly. Example prompt: Call PATCH /v1/settings/{settingId}/value to set the new-checkout flag to true in the production environment, then read it back with GET to confirm the change. ### Compliance Audit Review Pull audit log entries for a product or organization to satisfy SOC 2 or ISO 27001 evidence requests. The API exposes GET /v1/products/{productId}/auditlogs and GET /v1/organizations/{organizationId}/auditlogs with date range filters, so an agent can collect every flag change in the audit window and export it as CSV. The work that took hours of dashboard clicks finishes in seconds. Example prompt: Fetch all audit log entries for product 12345 between 2026-01-01 and 2026-03-31 via GET /v1/products/{productId}/auditlogs and write the result to audit-q1.csv. ### Programmatic Segment Targeting Create and update user segments to target rollouts at cohorts such as internal staff, beta testers, or a single tenant. The agent calls POST /v1/products/{productId}/segments to define the segment with comparator rules (email contains, country equals), then references that segment from a flag's targeting rules. This is well suited for support engineers who need to enable a fix for one customer while a wider release is paused. Example prompt: Create a segment named internal-staff that matches users where email ends with @example.com, then attach it as a targeting rule on the new-dashboard flag. ### AI Agent Flag Operations via Jentic Expose ConfigCat management as a tool an AI agent can call from inside a chat or workflow. The agent searches Jentic for configcat manage feature flag, loads the matching operation schema, and executes it with credentials kept server-side in your Jentic One instance. The agent never sees the raw Basic auth password, and the same wrapper works whether the underlying call is creating a flag, listing configs, or rotating an SDK key. Example prompt: Through Jentic, search for manage configcat feature flag, load the PATCH /v1/settings/{settingId}/value operation, and execute it to disable the legacy-checkout flag in production. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /v1/configs/{configId}/settings | List feature flags in a config | | POST | /v1/configs/{configId}/settings | Create a new feature flag | | PATCH | /v1/settings/{settingId}/value | Update a flag value in an environment | | GET | /v1/products/{productId}/auditlogs | List audit log entries for a product | | POST | /v1/products/{productId}/segments | Create a user segment for targeting | | GET | /v1/configs/{configId}/environments/{environmentId} | Retrieve the SDK key for an environment | | POST | /v1/products/{productId}/webhooks | Create a webhook that fires on flag changes | ## Key resources - **Feature Flags & Settings** — Create, list, update, and delete flag definitions inside a config - **Feature Flag & Setting values** — Read and write per-environment flag values, including targeting and percentage rules - **Configs** — Group flags into configs scoped to a product - **Environments** — Provision and manage environments such as dev, staging, and production - **Segments** — Define reusable user segments and reference them from flag targeting rules - **SDK Keys** — Retrieve and rotate the SDK key for an environment - **Audit logs** — Query change history at the product or organization level - **Permission Groups** — Manage role-based access for product members ## Why Jentic - **Setup:** Wiring the ConfigCat Public Management API by hand means learning its basic auth, mapping its product, config, and setting resources, and threading identifiers through management calls yourself. Through Jentic you install once, import the ConfigCat Public Management API from the API Directory, store the credentials once, and your agent calls it. - **Permission scoping:** ConfigCat puts the config, product, and setting ids in the URL path (/configs/{configId}/settings, /products/{productId}/segments), so a rule can pin your agent to one config or product. You choose the operations it may call, so you can allow reading settings and audit logs while leaving setting-value changes out unless you add them. - **Credential handling:** Your ConfigCat credentials are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'list feature flag settings' or 'read a product's audit log', and Jentic returns the matching ConfigCat operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **LaunchDarkly API** — LaunchDarkly is a larger feature flag platform with deeper experimentation features - **Split API** — Split focuses on feature delivery plus statistical experimentation - **Unleash API** — Unleash is an open-source feature flag service with a self-hosted option - **Statsig API** — Statsig pairs flag management with product analytics and experiment readouts ## FAQ ### What authentication does the ConfigCat Public Management API use? It uses HTTP Basic authentication with Public API credentials issued from the ConfigCat dashboard. When you call it through Jentic, the credentials live in your Jentic One instance and never enter the agent's prompt or context. ### Can I evaluate feature flag values for end users with this API? No. The Public Management API is for management actions only - creating, listing, updating, and deleting flags and configs. For runtime evaluation of flag values for your end users you should use the ConfigCat SDKs or the ConfigCat Proxy, which are designed for low-latency reads. ### What are the rate limits for the ConfigCat Public Management API? Rate-limited calls return X-Rate-Limit-Remaining and X-Rate-Limit-Reset headers describing the current window. When the limit is exceeded the API responds with HTTP 429 and a Retry-After header, so an agent can back off and retry after the indicated interval. ### How do I update a feature flag value through Jentic? Run pip install jentic, then use the async pattern: await client.search('update configcat feature flag value'), load the matching operation schema, and execute it. The underlying call is PATCH /v1/settings/{settingId}/value scoped to a specific environment. ### Can I retrieve the SDK key for an environment via the API? Yes. Call GET /v1/configs/{configId}/environments/{environmentId} to retrieve the SDK key for a specific environment, which is useful for rotating keys from a deployment pipeline or rotating after an offboarding event. ### Does the API support webhooks for flag changes? Yes. Use POST /v1/products/{productId}/webhooks to create a webhook scoped to a product, then GET /v1/products/{productId}/webhooks to list configured webhooks. ConfigCat will POST to your endpoint when a flag in that product changes. ### Can I limit what my agent is allowed to do with the ConfigCat Public Management API? Yes. Because Jentic One is self-hosted, your own rules decide which ConfigCat operations and credentials the agent may use, and you pick exactly which endpoints it can call. Since ConfigCat puts the config, product, and setting ids in the URL path, such as /configs/{configId}/settings and /products/{productId}/segments, a rule can pin the agent to a single config or product. You can, for example, allow read-only calls like GET /v1/products/{productId}/auditlogs while withholding PATCH /v1/settings/{settingId}/value so the agent cannot change flag values unless you grant it.