How to export your feature flags from ConfigCat

How to export your feature flags from ConfigCat without losing targeting rules

Teams leaving ConfigCat before a renewal, a pricing change or a data residency review should plan the export as an API job. ConfigCat has no single bulk export button, so flag definitions leave through the Public Management API, one resource at a time. Start by listing the products in your account, then walk each product's configs, environments, flags and targeting rules, and write every response to a versioned JSON file stored outside the vendor. Keep the raw responses as a record, because the file you rebuild in the new platform will later be compared against them.

The API should return the structure you need to recreate the flags: products, configs (the containers that hold flags and settings), environments, flag keys, value types, default values, percentage options and the targeting rules attached to each flag. Map each field to its target equivalent before you begin, because a rule nested inside another object is easy to flatten incorrectly. Some items will not come out. Plan to issue new SDK keys in the target platform, since the existing keys belong to ConfigCat, and do not expect evaluation data or the full audit history beyond the retention window. Confirm the endpoints, fields and limits for your plan in ConfigCat's own documentation, because this page does not cover them in detail.

Pull data in small batches and back off when the API throttles your requests. Confirm the current rate limit and retry behavior before you schedule a run, and avoid exporting during a release window. Export the audit log early, while the entries you need still fall inside ConfigCat's retention window, and confirm that window with the vendor in writing. Before the plan ends, run a reconciliation: compare product, environment and flag counts with the source, then evaluate a sample of users against both systems and record every mismatch. Keep the export until the cutover is signed off.

What you can export from ConfigCat and how

This table lists each data type you need for a migration, the Public Management API call path your script uses to read it, the JSON you store, and the limits to confirm with ConfigCat before you start. ConfigCat has no single bulk export, so every row is assembled by your own script, and the limits column is the list to settle before you plan the cutover.

Data type	Export method	Output format	Limits to confirm
Products	Public Management API, read by your script with a management API credential	JSON saved by your script, one file per product	Token scope, page size and rate limit for list calls
Configs and environments	Public Management API calls per product, listing configs and their environments	JSON with config and environment identifiers, saved as a index file	Whether all environments return on one call or need paging
Flags and their variations	Public Management API calls per config and environment for setting values	JSON with flag keys, types, default values and variation values	Which setting types and value formats the API returns for your plan
Targeting rules	Targeting data returned with each flag setting, read by the same script	Nested JSON of conditions, comparators, values and served outcome	Whether rule evaluation order and conditions are fully included in responses
Percentage and segment-style options	Percentage rollouts and user-based rules included in flag settings, if the API returns them	JSON fields for percentage splits and attribute conditions	Whether percentage splits and any segment objects appear in the API output
Audit log entries	Audit log access through the ConfigCat dashboard or API, depending on your plan	CSV or JSON exported by you, stored with the migration record	Retention window and how far back entries are available before the plan ends

What does not leave ConfigCat and how to cover each gap

The Public Management API returns the structure of your flags, but several things stay behind or lose meaning once they leave ConfigCat. Each card names one of these gaps and the step that covers it before the plan ends, so the target environment is not left with missing credentials, history or integrations.

SDK keys and environment credentials

Your application SDKs authenticate with ConfigCat SDK keys, and those keys do not belong in an export file. Nothing in the flag definitions tells you which services hold a key, so the export gives you a list of flags but not a list of places that must change. Before cutover, inventory every service that reads flags, then issue new credentials in the target system and plan the swap per environment. Check that no old key remains in build pipelines, container secrets or mobile builds, because an orphaned key can keep serving stale values.

Historical flag change history

The audit log is the record of who changed a flag and when, and it is kept only within ConfigCat's retention window. Once that window passes, entries are no longer available to you through the API, so the history of a flag that has been changed many times is at risk. Export audit entries in batches to your own storage while the account is still active, and store them with the export so reviewers can match a flag's current state to the changes that produced it. Confirm the retention period for your plan with ConfigCat before you schedule this work.

Current flag state as observed by services

A flag definition tells you what ConfigCat is configured to return, not what each service received during a given hour. Evaluation and download statistics are not part of the management export, so you cannot reconstruct how often a flag was served or which variation users saw. If you need that record for a compliance review or an incident, capture the flag state from your own application logs or your monitoring before the plan ends. Treat this as evidence you collect yourself, not something the new platform will import.

Webhooks and third-party integrations

Webhooks, Slack or email notifications, and connections to CI pipelines and analytics tools are configured in ConfigCat's interface and are not flag data, so they are not part of a flag export. Each integration will stop firing when the ConfigCat account closes, and some downstream jobs may depend on those events without anyone noticing. List every integration from the ConfigCat settings, record its purpose and owner, then recreate it in the target platform or replace it with an event sent from your own code. Test each one with a non-production flag before cutover.

User-level targeting data in the application

Targeting rules that depend on user attributes, such as country, plan or account identifier, use values your application sends at evaluation time, not values stored in ConfigCat. The export therefore carries the rule but not the population it was tested against. Confirm which attributes each service sends, then check that the target platform receives the same attributes under the same names. Percentage rollouts are a special case: bucketing depends on the hash inputs, so a user may move to a different variation after the switch unless you plan for it.

The export sequence, from access to a verified snapshot

This sequence moves your ConfigCat flags into a versioned, checksummed snapshot that you can reconcile against the admin console before any migration work starts. Each stage has a check, so a gap is found while ConfigCat is still the system of record.

Confirm API access and token scope
Ask ConfigCat which token permissions the Public Management API needs to read products, configs, environments, flags and targeting, and confirm that your token has them. Also ask about request rate limits and how far back the audit log is kept, so you can schedule the pull and capture audit history before it ages out. The step is done when a test request returns your product list without errors.
Inventory products, configs and environments
List every product in the account, then the configs and environments under each one, and write them down in a simple inventory sheet. Note which environments are active and which are unused, because unused ones often hide stale flags. The step is done when the inventory lists every product, config and environment you can see in the admin console.
Pull flags and targeting per environment
Write a short script that calls the API once for each environment and requests its flags with their targeting rules, percentage options and variation values. Run it with a read-only token and keep the script in version control so the pull can be repeated. The step is done when every environment in the inventory has returned a response, and any failed calls are logged and retried.
Store raw JSON in a versioned location
Save each response exactly as received, without editing, in a repository or object store with versioning turned on. Name files by product, config, environment and pull time so that every file is traceable to one call. The step is done when the raw files are committed and a second person can open them and identify each environment.
Record counts for each environment
Create a summary file that lists, for each environment, the number of flags, the number of targeting rules, the number of percentage options and the variation names. Generate it from the raw JSON with the same script, not by hand. The step is done when the summary covers every environment in the inventory and its totals match the raw files.
Verify the export against the admin console
Compare the summary with the ConfigCat admin console for each environment, checking flag counts, variation names, targeting rule counts and percentage values. Mark any difference and resolve it by rerunning the pull, since the API response may differ from what the console shows for hidden or archived items. The step is done when every environment matches, or each mismatch has a written explanation signed off by the owner of that flag set.
Freeze the snapshot with a date and checksum
Record the pull date and generate a checksum for every raw file and for the summary, then store those values in a manifest file next to the snapshot. Lock the snapshot location so that no later edits can change it, and keep the manifest with the migration record. The step is done when the manifest is committed and recomputing the checksums on a copy of the snapshot produces identical values.

How to handle ConfigCat rate limits during a full pull

A full pull across every product and environment is a batch job, and it should be run like one: paced, retried and resumable. Treat each API call as something that can be throttled or fail partway through, because a run that lists dozens of environments and reads each flag and its targeting rules can generate many requests. Build the export script so that a throttled response triggers exponential backoff, with the wait growing after each retry and a cap on total attempts, rather than a tight loop that hammers the endpoint. The exact limits, the status code returned when you exceed them, and any header that tells you when to retry must be confirmed in ConfigCat's Public Management API documentation before you write the retry logic.

Save a checkpoint after each environment finishes, recording the product, config and environment identifiers and the file written for each. If the run fails on the fortieth request, the next run should skip what is already on disk and resume from the first missing environment instead of re-reading the whole tenant. This matters for the audit trail as well: ConfigCat's audit log has a retention window, so a run that stalls for days can lose history you meant to keep. Log every request with its timestamp, endpoint, environment, response status and retry count. That log is your evidence that each read succeeded, and it is the first thing to check when a flag count in the export does not match the ConfigCat dashboard.

Schedule the export for a window away from production deployments, and agree that window with the teams that ship configuration changes. A flag edited in the middle of a pull can appear in the export in one state and in another state later in the same run, so either freeze changes for the window or record the time of each read and reconcile it afterward. Before the production run, rehearse the whole pull against a sandbox or trial environment, and measure how the retries and checkpoints behave there. Ask ConfigCat, in writing, which limits apply to your plan, since the export must finish before the plan's access ends.

What the exported data needs in Unleash and in Flagsmith

Unleash supports environment import and export as JSON, which moves feature flag configurations between environments or between Unleash instances. That makes it the more direct landing place for a ConfigCat export, but the file does not carry everything with it. Segments and custom strategies are exported only as references, so they must exist in the target before you import, and the import will not create them for you. Your team still does the translation from ConfigCat targeting rules, percentage options and variations into Unleash activation strategies, strategy variants and segments, using the mapping in Unleash's LaunchDarkly migration guide as a pattern rather than a converter.

Segments first: Recreate every ConfigCat segment as an Unleash segment in the target project before importing, or the references in the JSON will not resolve.
Custom strategies: Build any custom strategy your ConfigCat rules depend on in the Unleash instance before import, since the export carries only the name.
Rule translation: Map each ConfigCat targeting rule and percentage option to an activation strategy by hand, then record the mapping so reviewers can trace each flag.
Environment ceiling: Unleash Open Source allows 1 project and 2 environments, so a ConfigCat setup with more environments needs either a choice of which two to keep or an Enterprise plan.
Parallel run: Keep ConfigCat live while the Unleash copies are verified, because the migration guide recommends running both systems behind an abstraction layer before cutover.

Before you rely on an import, compare flag states and rule outcomes in each environment against the ConfigCat export, and confirm that no segment or strategy reference is unresolved.

What to plan before the ConfigCat plan ends

Export is the last step of a longer wind-down, and several items expire on their own schedule. Settle the window, the snapshot, the parallel run and the access model before the plan lapses, so that no flag definition or audit record depends on a deadline you have not checked. Read your ConfigCat contract for notice periods and data deletion terms, and ask ConfigCat in writing what export support it offers during the wind-down.

Export window and audit log retention

Find out how long you can still call the Public Management API after the plan ends, and how far back the audit log reaches. Audit history is often the first record to disappear, and it may be needed for change control or an assessment after the cutover. Export the audit log in the same pass as the flags, and note the retention period you confirmed in writing with ConfigCat.

Dated and checksummed final snapshot

Take one complete snapshot of products, configs, environments and flags, stamped with the export date and a checksum for each file. Store it in your own object storage or repository with restricted access. Keep the snapshot unchanged so that the target system can be compared against a fixed reference, even if ConfigCat access ends earlier than planned.

Parallel running before cutover

Run ConfigCat and the new system side by side behind an abstraction layer, such as OpenFeature, before you switch production traffic. Compare the values each SDK returns for the same user and environment, and record any mismatches. Partial rollouts need particular attention, because percentage buckets may assign some users differently after a move. Keep ConfigCat active until the comparison is clean.

API access and plan end dates

Write down the date when API access stops and the date when the plan lapses, and treat the earlier one as the deadline. Plan the export and the parallel run to finish before the earlier date, and confirm whether read access continues after the plan ends. Set calendar reminders for each date and for any notice period in the contract, so renewal decisions are made before the deadline.

Ownership and revocation of API tokens

Identify who created each Public Management API token, which systems use them, and who is accountable for them. Tokens created by a departed engineer or a shared automation account are a common gap. Revoke every token once the export and snapshot are verified, and confirm the revocation by attempting a call with the old token. Record the revocation in your change log.

Which environments and history to keep

Decide which environments, flag histories and stale flags to carry forward and which to leave behind. Unleash Open Source is limited to 1 project and 2 environments, so the choice may be forced by the target edition. Document each exclusion with its owner and reason, so that a future auditor or engineer can see what was deliberately not migrated.

Questions buyers ask before exporting ConfigCat flags

How much effort does a full ConfigCat flag export take?

The effort depends mostly on how many products, environments, flags and targeting rules you have, and on how much verification you need afterwards. Extraction through the Public Management API is a scripted read, so the bulk of the time usually goes into checking that each flag's variations, targeting rules and percentage options came across intact. Teams with a few products and a short flag list can finish quickly. Teams with many environments and long-lived flags with complex rules should plan for a longer comparison pass. Ask ConfigCat to confirm current API limits and read-only scopes for your plan before you size the work.

Can our team export ConfigCat flags without outside help?

Yes, a team with an engineer who can call a REST API, parse JSON and write a small script can usually produce the export themselves. The script needs to handle pagination, retry on rate limit responses and store the output in a form you can diff later. The harder skill is judging the output: someone must know your targeting rules well enough to confirm that each one has a counterpart in the target platform. If nobody on the team has time for that comparison, or the flag count is large, an outside team can be scoped as a fixed-scope engagement with written deliverables.

How long does the export take, and what is one-time versus recurring?

The export itself is a one-time job that you run during the migration window, and you may run it several times while you refine the script. Recurring work starts after cutover, when you keep flags in sync during any parallel running period and decommission the ConfigCat connections. Timing depends on your flag inventory and on how many environments you read, so ask for a schedule based on your own counts rather than a general estimate. Keep a dated copy of each export so you can compare later snapshots against the original.

What do we need from our side before the export starts?

You need a ConfigCat API credential with read access to the products, configs, environments and flags you want to export, and a way to store that credential securely outside the script. You also need access to the target environment where the flags will be recreated, plus a test window in which both systems can run in parallel without changing live traffic. Name one owner who can approve the mapping of targeting rules and sign off the verification results. Confirm with ConfigCat which token scopes are available on your plan.

Do SDK keys and audit history come across in the export?

Flag definitions, targeting rules and environment structure can be read through the Public Management API, but you should not assume that SDK keys or audit history will transfer as data. SDK keys belong to ConfigCat environments and must be replaced by new keys in the target platform, so every application needs a code change and a deployment plan. Audit log entries are subject to ConfigCat's retention window, so export them early and store them in your own records if you need them for review. Confirm both points with ConfigCat's documentation for your plan.

When is outside help worth scoping as a fixed-scope engagement?

Outside help is worth scoping when the flag estate is large, when many applications depend on flags, or when you need evidence that the export and mapping were checked for a compliance review. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that written scope. Ask for the export, mapping and verification steps to be listed as separate deliverables.

Where should we confirm ConfigCat's export limits and rate limits?

ConfigCat's current API documentation and your account terms are the authoritative sources for rate limits, token scopes, retention periods for audit logs and any plan-specific restrictions. Read them before you write the script, because limits can change and differ by plan. Ask ConfigCat support in writing to confirm the figures that affect your schedule, including how many requests the script can make in a period and how long audit history remains available. Keep the written answers with your migration record.

How DeployOpen scopes and delivers a ConfigCat export

DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted open-source platforms inside your own infrastructure. For a ConfigCat export, we agree the scope in writing, pull product, config, environment and flag data through the Public Management API, and deliver a checked, documented export your team can take into the new platform.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which ConfigCat products, environments and config types are in the export.
We confirm how long your audit log must be kept and whether it is exported before the plan ends.

How we build

We write the export scripts against the Public Management API and handle rate limits with retries and pacing.
Exported flags, targeting rules and percentage options are stored as JSON in your own environment.
Each export run is compared against the ConfigCat dashboard so counts and values can be checked by hand.

How we hand over

You receive the export files, the scripts used to produce them and a written record of each run.
The handover document maps each ConfigCat concept to the target platform and lists items needing manual review.
We walk your team through the check results so the export can be accepted or re-run before the plan ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the handover.
A retainer can cover re-exports if your ConfigCat plan or flag set changes during a parallel run.
Support terms, response expectations and fees are set in the written quote, which follows from the agreed scope.

How to export your feature flags from ConfigCat