Skip to main content
Fleack runs between your mobile app and your backend. It captures your API responses, surfaces the parameters worth testing, and rewrites them on the fly when a test is live. You don’t install anything in the app. This guide takes you from a brand-new account to a running A/B test, step by step.

​
Before you start

You need three things:
  • An app whose backend is reachable at a public hostname you control — for example, api.your-game.com.
  • DNS access to that hostname so you can add a CNAME record.
  • A Fleack account. If you don’t have one yet, request access.
If your backend is bundled into your app binary, or hosted on a third-party domain you don’t control (such as firebaseio.com), Fleack can’t intercept it. That’s a deliberate limit, not a bug — see When Fleack is not the right tool.

​
Setup

1

Create your organisation

After signing in to the backoffice, your organisation is created automatically with a default tenant_id. You’ll see it on the dashboard — it’s the identifier Fleack uses to route your traffic and store your data.If you have multiple apps (different brands or bundle IDs), create one tenant per app using the org switcher. Each tenant gets its own DNS endpoint and its own isolated set of tests.
2

Point your DNS at Fleack

This is the only infrastructure change required. Add a CNAME record on the hostname your app already calls, pointing to your Fleack endpoint:
api-<your-tenant-id>.fleack.io
For example, if your app calls api.your-game.com, update that hostname’s CNAME target to api-acme.fleack.io (using your actual tenant ID).Once DNS propagates, Fleack receives your app’s traffic, forwards every request unchanged to your real backend, and returns the response byte-for-byte. Until you launch a test, nothing is modified.Verify the proxy is working with a quick curl:
curl -i https://api.your-game.com/api/get_appsettings
The response should be identical to what your backend returns directly. Check the headers — Fleack adds an x-fleack-tenant header so you can confirm the request flowed through.
If you can’t change the production DNS record yet (slow IT approval, compliance review), point a sub-domain like fleack.your-game.com at Fleack temporarily and switch to the real hostname once you’re confident.
3

Send some traffic

Open your app and navigate through the screens that make API calls to your backend — config screens, home screens, any view that fetches settings or game parameters. Within a few seconds those requests appear in the backoffice under Endpoints.Fleack classifies each endpoint automatically based on observed responses:
ClassificationWhat it meansTestable?
config-candidateSame response across all usersYes
user-dataResponse varies per userNo — used for segmentation only
mixedSome shared, some per-user fieldsCase by case
unknownNot enough traffic to classify yetSend more traffic and wait
Only config-candidate endpoints can carry tests. This is a safety guard — rewriting per-user transactional data would be a product bug, not an experiment.
If an endpoint you expect to be testable shows up as unknown or mixed, trigger it from a few more devices or user accounts. Classification improves as Fleack sees more response variety.
4

Pick a lever

Open the Levers page. For each config-candidate endpoint, Fleack either auto-detects testable parameters (when AI enrichment is enabled) or lets you create them manually.To create a lever manually:
  1. Click + New lever.
  2. Select the endpoint that returns the parameter you want to test.
  3. Click the parameter in the response tree — for example, data.gems_reward = 30.
  4. Give it a label (e.g. “Gems reward amount”), choose a type (number, price, frequency, color, toggle, or text), and optionally set starter variant values.
  5. Click Save.
The lever now appears in the catalog. The value shown in the backoffice always reflects what your backend actually returned — not what any running test has rewritten — so you can always trust the catalog as the source of truth.
5

Launch your first test

From the lever detail page, click Test. The test creation dialog opens with the lever pre-selected.Configure the test:
  1. Variants — Fleack proposes a control (your current value) and one or two alternatives. Adjust the values to whatever you want to test, for example gems_reward = 30 (control) vs gems_reward = 50 (variant A).
  2. Allocation — split traffic between variants. Defaults to an even split.
  3. Segment — leave this as “All users” for your first test. You can target by platform, country, or user-level attributes once you have a baseline.
  4. Metric — define what success looks like: conversion on a specific endpoint (e.g. the user hits the purchase endpoint), day-N retention, or a revenue attribute.
  5. Click Launch.
The test goes live immediately. The next time a user calls the endpoint, Fleack assigns them a variant — sticky by user identity, computed by hashing the test ID and the user’s identifier. The same user will always see the same variant for the life of the test.
6

Read the results

Open the test detail page. Within minutes you’ll see exposures counted per variant. As conversions accumulate, Fleack displays a Bayesian win probability for each variant:
  • 87% likely to beat control — keep running, build more confidence.
  • 96% likely to beat control — ready to promote.
  • No clear winner — wait for more data, or stop and revisit your hypothesis.
The verdict thresholds are:
  • Winner — variant reaches ≥ 90% win probability vs the control.
  • Control wins — the control reaches ≥ 90% probability of beating the variant.
  • No difference — neither side has hit the threshold yet.
  • Not enough data — fewer than 30 total exposures; Fleack declines to give a verdict.
When you’re ready to ship, click Promote on the winning variant. Fleack routes 100% of traffic to that value. Engineering was never in the loop.

​
What you just did

You added one DNS record. You picked a parameter your backend already returns. You shipped a test that reaches every user on every app version — instantly, without a release. That’s the entire integration.
If anything in this guide didn’t work end-to-end in five minutes, that’s on us. Email contact@fleack.io and describe where you got stuck.

​
Next steps

Core concepts

Understand what endpoints, levers, segments, exposures, and the results engine actually do under the hood.

How integration works

DNS details, fail-open behaviour, latency budget, and how Fleack handles your traffic at the edge.