• I am unable to connect because of a mismatched origin header
    We take the security of your data at LaunchDarkly seriously. One of the protections we've implemented is validation that the Origin header for any API request authenticated by session cookie matches the expected Origin header (namely This is just one way that we help to prevent CSRF attacks. (Note that we do not require origin matching when authenticating via Access Token, so this does not affect normal API usage.)
    If the Origin header does not match what's expected, we return an error. And since our application relies heavily on interaction with the API, the application will not function properly.
    Known causes
    Any browser extension that intentionally changes the Origin header will cause this problem. For example, the Allow-Control-Allow-Origin: * Chrome extension is known to change the Origin header to and will result in the problems described above.
  • What does "Your configuration is incomplete" mean?

    If you're seeing the "Your configuration is incomplete" message, it will usually indicate that there is an incomplete or invalid rule configured for your flag. For example, this could mean that an attribute was not selected, or a negative number was selected for a percentage rollout.

  • How do I connect to my team’s LaunchDarkly account?

    If your team already has a LaunchDarkly account, the owner of that account must send you an email invitation to join the team. Once you receive the invitation, follow the sign up instructions and you will be automatically added to your team’s account.

    If you have an existing LaunchDarkly account and want to use that email address to join your team, please take the following steps:

    • Log in to your existing LaunchDarkly account
    • Navigate to Account Settings to access your Profile Page
    • Change your email to something different (e.g. if your email is, you may change it to
    • You should now be able to accept the invitation from your team owner using your preferred email
  • Why are all my users seeing the same variant of my flag?

    Make sure that you’re sending distinct user keys for each user in your variation calls. A few other possibilities:

    • Your default rollout rule is serving a single variation
    • Your users are receiving the fallback variation because something is not working correctly
    • The kill switch was activated, and the feature is set to ‘Off’
  • How do you sync between environments? Can it be automated?

    We don’t have a “promote from environment A to B” workflow built into the tool yet, though that is coming. In the meantime, we have a script available that you can use to automate the process:

  • The click goal editor cannot load my page

    The editor is failing to load your site through an <iframe> because of security restrictions. To ensure our editor works, add X-Frame-Options: ALLOW-FROM and Content-Security-Policy: frame-ancestors 'self' to the response headers of your site; alternatively remove the headers if you don’t need to restrict embedding of your site using an <iframe>.

    Note that Chrome and Safari do not respect the ALLOW-FROM directive. Also, Internet Explorer does not currently support Content-Security-Policy with frame-ancestors.

See all 8 articles


  • Does the LD SDK support Postgres as a caching backend?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres.

  • I am getting a JSON parsing exception with the Java client


    Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType:

    Make sure your build tool is bringing in the proper version of Gson. The LaunchDarkly SDK may have problems with versions earlier than 2.2.4. To enforce the proper version add this dependency:



  • I am getting SSL exceptions when calling variation() in the Java client

    Make sure your build tool is bringing in the proper version of the Apache http client. The LaunchDarkly SDK may have problems with versions earlier than 3.3.6. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>org.apache.httpcomponents</groupId>
    3.  <artifactId>httpclient</artifactId>
    4.  <version>4.3.6</version>
    5. </dependency>
  • Every time I call get_flag, a remote call is made.

    One possibility is that you have streaming mode disabled and your feature’s TTL is set to 0. We do not recommend disabling streaming unless you are using PHP. If you do disable streaming mode, we recommend setting the TTL to 5 minutes in production environments.

    If you’re using PHP, you may need to configure a custom HTTP cache provider as described in the PHP SDK Reference. PHP’s shared-nothing architecture means that the in-memory HTTP cache will be reset on every request, which means that almost every flag request will require a remote call. Using a Memcache or Redis-backed cache is the best solution.



  • How do the mobile SDKs handle airplane/flight mode?

    When a user is in flight or airplane mode on their mobile device, LaunchDarkly will use the latest stored flag settings.  When the user reconnects to a network, LaunchDarkly will reconnect to the stream to see if there are any new flag updates.  This ensures that your users will always receive the most up-to-date flag settings, even if their devices are not currently connected to a network.

  • I’m seeing inconsistencies while testing the iOS SDK

    There are a few things to be aware of with the iOS SDK:

    • When an app is first installed, until the first response is received back from LD, the default variation values will be used. There is a delegate pattern (see userDidUpdate) that can be used to block until the first response is received.
    • The iOS SDK polls for changes based on the TTL set in your environment settings ( Unlike our other SDKs, a minimum TTL of 1 minute is enforced. So if your TTL setting is 0, changes will still take 1 minute to propagate to your mobile client
    • If your app has a login flow, or you need to change to a brand new user context for any reason, you should use the userDidUpdatedelegate to wait until the feature flags for the new user have been received. Once the user context has been seen at least once, it is cached on the device.
    • If you change environments during testing (say by changing your API key from a test key to a production key), you should clear the device cache.
  • Why is there a different mobile environment SDK key?

    The server SDK keys are intended to be embedded in trusted environments. The mobile SDK keys are suitable for use in (untrusted) mobile clients. If a mobile user were to somehow decompile your app, or gain access to your mobile key, there is really no impact, as those keys can only access a restricted subset of our APIs that do not reveal any private data.