BYO provider
In FTF or your own vendor — and how changes reach your applications
Your applications always ask FTF, with the same call. Behind it, each environment is stored where you choose — and the same toggle model, releases and attributes, works the same way on all three.
FTF built in
No other account needed — in the trial and in production. Every release, every attribute kind, promotion and history.
LaunchDarkly your account
An FTF environment backed by one of your LaunchDarkly environments. Your project and keys, never a pooled account.
ConfigCat your account
The same for ConfigCat — your configs, environments and credentials.
| Your LaunchDarkly or ConfigCat | Read-only | FTF writes through |
|---|---|---|
| Where you change toggles | In your vendor's own dashboard | In FTF or your vendor |
| A change made in FTF | Refused, with where to make it | Written to your vendor first; if it refuses, nothing changes |
| A change made in your vendor | Reaches FTF within seconds by your vendor's webhook, and at an interval you set in any case | |
How changes reach your applications
Your applications ask FTF
Web and mobile applications ask FTF when they need an answer. Platforms that keep their own copy are told to refresh on every change, and catch up in full whenever they start.
Webhook, then a safety net
A change in LaunchDarkly or ConfigCat reaches FTF by signed webhook; a full check at your chosen interval catches anything missed.
Export and import
A deployment that can't reach FTF reads an exported toggles file, and its changes are imported back. Promotion itself always goes through FTF, by the people allowed to.
Toggles in your vendor account that don't follow FTF's naming are left alone. What FTF can't read is listed, never guessed.