One identifier in. One value and its reason out.
A flag key, an identifier, and attributes go in. A typed value and the reason for that value come out. The same input always produces the same output.
test
checkout_v2
Context- environment
- production
- user_id
- usr_142
- plan
- pro
- country
- DE
Rules · same input, same path, every time
Rule 1environment is stagingpending
Rule 2plan is enterprisepending
Rollout25% by user_idpending
What it does
Real product states, not a promise.
A flag key, an identifier, and attributes go in. A typed value and the reason for that value come out. The same input always produces the same output.
- Rules evaluated in order
- Typed values: boolean, string, number, JSON
- Environment-aware values
- Reason and matched rule returned
Input
Flag key, identifier, and attributes
Output
A value and the reason for that value
Where it fits
Where it fits
01
Feature gating
02
Remote configuration
03
Per-plan behaviour
API example
One request.
POST /v1/flags/evaluate. The full request and response contract is in Flowyn Docs.
POSThttps://api.flowyn.dev/v1/flags/evaluate200
curl -X POST https://api.flowyn.dev/v1/flags/evaluate \
-H "Authorization: Bearer flw_test_••••" \
-H "Content-Type: application/json" \
-d '{
"key": "checkout_v2",
"identifier": "usr_142",
"attributes": {
"plan": "pro"
}
}'Related capabilities
Frequently asked questions
Where is the exact request contract for Deterministic evaluation?
In Flowyn Docs and the OpenAPI document at https://api.flowyn.dev/openapi/v1.yaml. This page shows the request; the docs page lists every field, status value, error, and limit.
Is evaluation deterministic?
Yes. The same flag configuration, identifier, and attributes always return the same value. Rollouts hash a stable identifier into a bucket.
Who supplies the attributes?
Your application. Flowyn evaluates what you send and never guesses user attributes.
Build with Deterministic evaluation.
Create a workspace, make your first call in the test environment, and inspect every attempt.
