How Fleack groups requests
Fleack identifies an endpoint by combining three things: the HTTP method, the normalized path (with variable segments replaced by placeholders, e.g./api/v1/levels/:id), and any query parameters that determine which resource is returned (routing params).
Filter-style query parameters — things like filter[*], sort, limit, offset, page, fields, and search — are deliberately excluded from the grouping key. Without this exclusion, a single endpoint with five common filter combinations would appear as five separate endpoints in your catalog, making it much harder to manage.
Classifications
Fleack assigns every captured endpoint one of four classifications based on the traffic it observes:| Classification | What it means | Can carry tests? |
|---|---|---|
config-candidate | Response is the same across all users | Yes |
user-data | Response varies per user | No — used for segmentation only |
mixed | Some fields are shared, others are per-user | Case by case |
unknown | Not enough traffic to classify yet | Wait for more data |
Why only config-candidate endpoints are testable
Fleack only permits tests on config-candidate endpoints. This is a deliberate safety constraint, not a limitation.
If Fleack rewrote values on a user-data endpoint — one that returns per-user transactional data — it would corrupt real user records: overwriting a player’s actual level, balance, or purchase history with a test value. That’s a UX bug, not an experiment. By restricting tests to endpoints where the response is structurally identical across users, Fleack ensures that variant injection is always safe.
user-data endpoints are still valuable: Fleack reads them over time to build profile attributes (like arpu, level, and days_since_install) that you can use to target tests to specific user segments.
Examples
GET /api/get_appsettings — returns the same config payload to every user, regardless of who they are. Fleack classifies this as config-candidate. Every field in the response body is a candidate lever.
GET /api/v1/levels/:id — returns level configuration for a given level ID. If the content is consistent across users (same rewards, same difficulty parameters), it will also be classified as config-candidate.
GET /api/users/me — returns account data specific to the authenticated user. Fleack classifies this as user-data. It won’t show up in your testable lever catalog, but attributes extracted from it become available for segment rules.
What to do with mixed or unknown endpoints
If an endpoint is mixed, inspect its response body. Some fields may be consistent (safe to test) while others are user-specific. You can still create a lever manually by pointing to a specific JSON path that you know is config-like.
If an endpoint is unknown, it simply hasn’t received enough traffic yet. Send more requests through the proxy — navigating the relevant screens in your app usually resolves this within a few minutes.
Classification updates automatically as more traffic arrives. An endpoint that starts as
unknown will be reclassified once Fleack has seen enough varied requests to determine whether the response is consistent.