Skip to main content
Fleack sits in the network path between your mobile app and your backend, activated by a single DNS change you make on a hostname you already own. This page explains the exact traffic flow from the moment your app makes a request to the moment it receives a response, what data Fleack captures along the way, and the service levels you can rely on.

​
Traffic flow

When your app calls its API endpoint, here is what happens: 
mobile app ──► api.your-game.com ──► Fleack edge ──► your real backend
                   (CNAME)                │
                                          ▼
                                    tests + levers
                                    + variant injection
                                    + exposure logging
Your app’s code never changes. The CNAME on api.your-game.com silently redirects traffic to your Fleack tenant, which acts as a transparent proxy.

​
The five-step request lifecycle

1

Fleack receives the request

Your app sends its normal API call to api.your-game.com. Because the CNAME points to your Fleack tenant, the request arrives at the Fleack edge instead of your backend.
2

Fleack forwards the request unchanged

Fleack proxies the request — headers, body, method, and query parameters — to your real backend exactly as your app sent it. Your backend sees the original request without modification.
3

Your backend responds

Your backend returns its normal response. Fleack holds that response while it checks whether any running test matches the endpoint and the user.
4

Fleack injects a variant if a test matches

If a running test targets this endpoint and the user is in the assigned segment, Fleack rewrites the specific JSON path with the user’s assigned variant value. Every other byte of the response is untouched. If no test matches, the response passes through unchanged.
5

Fleack returns the response to your app

Your app receives the response — potentially with one value rewritten. Asynchronously, Fleack logs the request as an event and, if a variant was served, as an exposure for metric computation.

​
What Fleack captures

For every request that passes through the edge, Fleack records:
  • HTTP method and normalized path — routing query parameters (filter, sort, pagination keys) are excluded so the same endpoint isn’t counted as multiple distinct endpoints.
  • HTTP status, response latency, and a response body sample — body samples are captured from GET responses only, and always from the upstream response before any variant injection. The Levers catalog always reflects what your backend actually returns, never a rewritten test value.
  • A user_hint — a coarse user identity derived from request headers, path segments, query parameters, or the body. When no real identity can be extracted, Fleack falls back to a hash of user-agent plus IP.
  • Profile-level scalars — from endpoints that return per-user data (level, ARPU, days since install). These power segmentation without requiring any additional instrumentation on your part.

​
SLOs

MetricTargetWhat it means
Edge latency p95< 40 msTime Fleack adds between receiving the request and forwarding it, plus injection overhead on the response path.
Availability99.9% (Pro) / 99.99% (Enterprise)Percentage of requests Fleack accepts and either forwards or returns a defined error for.
Fail-open success rate100%If Fleack itself fails, your users always see the original backend response or a clean 502. Fleack never breaks your app.
The 40 ms p95 budget is a hard constraint, not a guideline. Any feature that adds latency beyond that budget runs in a background worker instead of the request path.

​
What you do not have to do

  • No SDK to install. Your app’s Podfile, build.gradle, or package.json does not change.
  • No new app build to ship. No App Store review, no Play Store rollout, no waiting for users to update.
  • No new permissions. Fleack does not require any additions to your Info.plist or AndroidManifest.xml.
  • No analytics rewiring. Your existing analytics continue to work. Fleack’s exposure logging runs as an additional stream alongside them.

​
When Fleack is the wrong choice

Fleack requires your app to make a network call that Fleack can intercept. There are a few situations where that’s not possible:
  • Bundled config — if your app reads configuration from a file bundled into the binary (no API call), Fleack has nothing to intercept. Move that config to a backend endpoint first.
  • Offline flag evaluation — if your use case requires millisecond feature flag decisions without a network round-trip, use a traditional SDK such as LaunchDarkly or Statsig. Fleack is online-only by design.
  • Enterprise flag governance — if you need approval workflows, SOC 2 audit trails on every flag change, or role-based access controls across environments at scale, Fleack is not the right fit. Fleack is built for experimentation throughput, not flag operations discipline.
For mobile A/B testing on parameters that already travel through your API, removing the SDK is the entire value proposition.

DNS setup

Add the CNAME record and verify traffic is flowing through Fleack.

Fail-open guarantee

Understand what happens when something goes wrong on Fleack’s side.