@supabase/middleware - v0.6.0
    Preparing search index...

    Interface WithFeatureFlagConfig

    Per-instance configuration the consumer passes to withFeatureFlag(config, handler).

    Keep this surface small — every field becomes part of the public API.

    interface WithFeatureFlagConfig {
        name: string;
        evaluate: (
            req: Request,
            ctx: object,
        ) => boolean | FeatureFlagVerdict | Promise<boolean | FeatureFlagVerdict>;
        rejectStatus?: number;
        rejectBody?: unknown;
    }
    Index
    name evaluate rejectStatus? rejectBody?
    name: string

    Human-readable name for the flag. Echoed back on ctx.featureFlag.name and the default rejection body.

    evaluate: (
        req: Request,
        ctx: object,
    ) => boolean | FeatureFlagVerdict | Promise<boolean | FeatureFlagVerdict>

    Decide whether the flag is enabled for this request.

    Return true/false for a simple on-off check, or a FeatureFlagVerdict to also record a variant or provider payload. Async is fine.

    ctx carries the contributions of every upstream entry, so a flag placed after an auth middleware can target the verified caller. It is typed as BaseContext because this middleware declares no prerequisites and composes at any position; narrow it to the shape of the entries you place before it.

    rejectStatus?: number

    HTTP status when the flag rejects. Default is 404 — "this feature doesn't exist for you yet" — a softer reveal than 403 that avoids tipping off attackers about the existence of gated functionality.

    404

    rejectBody?: unknown

    Body when the flag rejects.

    { error: 'feature_disabled', flag: <name> }

    Settings
    Member Visibility

    On This Page
    Properties