Roll out to a stable slice of users.
A flag key, a percentage in basis points, and a stable identifier go in. Included or excluded, with the reason and bucket, comes out.
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, a percentage in basis points, and a stable identifier go in. Included or excluded, with the reason and bucket, comes out.
- Identifier hashed into a bucket from 0 to 9,999
- Same identifier, same bucket, always
- Widen the percentage without reshuffling
- Bucket included in the response
Input
Flag key, percentage, and a stable identifier
Output
Included or excluded, with the rollout reason
Where it fits
Where it fits
01
Gradual launches
02
Canary cohorts
03
Kill switches with partial exposure
API example
One request.
Percentage rollout. The full request and response contract is in Flowyn Docs.
AcceptedClaimedAttemptedTerminal state# Percentage rollout
# Request and response: /docs/configure/rolloutsRelated capabilities
Frequently asked questions
Where is the exact request contract for Percentage rollouts?
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 Percentage rollouts.
Create a workspace, make your first call in the test environment, and inspect every attempt.
