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.

Context received
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
Endpoint
# Percentage rollout
# Request and response: /docs/configure/rollouts

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.