> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fleack.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Endpoints: How Fleack Classifies Your API Traffic

> Understand how Fleack groups and classifies the API calls your app makes, and why only config-candidate endpoints can carry A/B tests.

When your app sends requests through Fleack's proxy, the platform automatically observes and categorizes every API pattern it sees. An **endpoint** in Fleack is a single URL pattern — defined by its HTTP method, normalized path, and routing query parameters — that has been captured at least once. Understanding how endpoints are classified tells you which parts of your backend are ready to test, and which ones are off-limits for good reason.

## 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.

<Note>
  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.
</Note>