Zum Hauptinhalt springen

Flags: eine Entscheidung

Ein Feature-Flag ist eine Entscheidung, die gegen den Nutzerzustand ausgewertet wird. Targeting ist eine Menge von Bedingungen an diesen Zustand, geprüft in dem Moment, in dem das Flag abgefragt wird.

At a glance

Host
https://api.prodantix.com
Read
GET /v1/flags, GET /v1/flags/snapshot
Write
upsertFlag, archiveFlag over GraphQL
Live updates
flagChange on the project room
Auth
Project key to read, access token to write
  • Echtzeit-Targeting auf dem Live-Nutzerzustand
  • Im Moment der Abfrage entschieden, nicht aus einer gespeicherten Liste gelesen
  • Rollouts und Experimente an derselben Quelle der Wahrheit gemessen

So funktioniert es

A flag is evaluated against the user state currently on file for a distinct id. Rules are ordered; the first match wins, and a flag with no matching rule falls back to its default. Evaluation is server-side by default, so a rule change takes effect without a client release.

Wo Sie darauf zugreifen

SurfaceOperation
RESTGET /v1/flags · GET /v1/flags/snapshot
GraphQLflags query · upsertFlag, archiveFlag mutations
RealtimeflagChange on a project room
MCPprodantix.flags.list · .upsert · .archive

Beispiel

curl "https://api.prodantix.com/v1/flags?distinct_id=u_8f3a" \
  -H "Authorization: Bearer $PRODANTIX_KEY"

Evaluating locally

For latency-sensitive paths, fetch the whole ruleset once and evaluate in-process. Snapshot responses carry Cache-Control: public, max-age=30, stale-while-revalidate=300.

JSON
{
  "flags": [
    {
      "key": "new-checkout",
      "enabled": true,
      "rules": [
        { "property": "plan", "operator": "in", "values": ["pro", "scale"] }
      ]
    }
  ]
}