Add support for feature flags management API

[stanleyphu]

Description

• Adds the following methods to support the feature flags management API
  • listFeatureFlags (GET /feature-flags)
  • getFeatureFlag (GET /feature-flags/:slug)
  • enableFeatureFlag (PUT /feature-flags/:slug/enable)
  • disableFeatureFlag (PUT /feature-flags/:slug/disable)
  • addFlagTarget (POST /feature-flags/:slug/targets/:targetId)
  • removeFlagTarget (DELETE /feature-flags/:slug/targets/:targetId)
• Updates FeatureFlag interface to add tags, enabled and defaultValue fields
• Updates FeatureFlag.description to be a required field to match the API response

Documentation

Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.

[x] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

[greptile-apps]

Greptile Overview

Greptile Summary

Added comprehensive feature flags management API support to the WorkOS SDK. This PR introduces a new FeatureFlags class with six management methods (listFeatureFlags, getFeatureFlag, enableFeatureFlag, disableFeatureFlag, addFlagTarget, removeFlagTarget) following established SDK patterns.

Key changes:

• New FeatureFlags class integrated into WorkOS client with proper HTTP methods (GET, PUT, POST, DELETE)
• Updated FeatureFlag interface with new fields (tags, enabled, defaultValue) and made description required to align with API schema
• Comprehensive test coverage for all new methods including pagination options
• Updated existing organization and user management fixtures to include new fields
• Added serializers index file for consistency with project structure
• All URL paths use template literals with parameters directly embedded (no string concatenation)

Confidence Score: 5/5

• This PR is safe to merge with no issues found
• Clean implementation following established SDK patterns with comprehensive test coverage. All new methods properly use HTTP client abstractions, no direct string concatenation in SQL or URLs, no security vulnerabilities present. Interface changes are backward-compatible through serialization layer. No sensitive data logging detected.
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
src/feature-flags/feature-flags.ts	5/5	Added new FeatureFlags class with 6 management methods following existing SDK patterns
src/feature-flags/feature-flags.spec.ts	5/5	Comprehensive test coverage for all new feature flag management methods
src/feature-flags/interfaces/feature-flag.interface.ts	5/5	Added tags, enabled, defaultValue fields and made description required to match API
src/feature-flags/serializers/feature-flag.serializer.ts	5/5	Updated serializer to handle new tags, enabled, and defaultValue fields
src/workos.ts	5/5	Added featureFlags property to WorkOS class and alphabetized properties

Sequence Diagram

sequenceDiagram
    participant Client
    participant WorkOS
    participant FeatureFlags
    participant HttpClient
    participant API as WorkOS API

    Note over Client,API: List Feature Flags
    Client->>WorkOS: featureFlags.listFeatureFlags(options)
    WorkOS->>FeatureFlags: listFeatureFlags(options)
    FeatureFlags->>HttpClient: fetchAndDeserialize('/feature-flags')
    HttpClient->>API: GET /feature-flags
    API-->>HttpClient: List response with feature flags
    HttpClient-->>FeatureFlags: Deserialized list
    FeatureFlags-->>WorkOS: AutoPaginatable<FeatureFlag>
    WorkOS-->>Client: Feature flags list

    Note over Client,API: Get Feature Flag
    Client->>WorkOS: featureFlags.getFeatureFlag(slug)
    WorkOS->>FeatureFlags: getFeatureFlag(slug)
    FeatureFlags->>HttpClient: workos.get(`/feature-flags/${slug}`)
    HttpClient->>API: GET /feature-flags/:slug
    API-->>HttpClient: Feature flag response
    HttpClient-->>FeatureFlags: FeatureFlagResponse
    FeatureFlags->>FeatureFlags: deserializeFeatureFlag()
    FeatureFlags-->>WorkOS: FeatureFlag
    WorkOS-->>Client: Feature flag

    Note over Client,API: Enable/Disable Feature Flag
    Client->>WorkOS: featureFlags.enableFeatureFlag(slug)
    WorkOS->>FeatureFlags: enableFeatureFlag(slug)
    FeatureFlags->>HttpClient: workos.put(`/feature-flags/${slug}/enable`)
    HttpClient->>API: PUT /feature-flags/:slug/enable
    API-->>HttpClient: Updated feature flag
    HttpClient-->>FeatureFlags: FeatureFlagResponse
    FeatureFlags->>FeatureFlags: deserializeFeatureFlag()
    FeatureFlags-->>WorkOS: FeatureFlag
    WorkOS-->>Client: Updated feature flag

    Note over Client,API: Add/Remove Flag Target
    Client->>WorkOS: featureFlags.addFlagTarget(slug, targetId)
    WorkOS->>FeatureFlags: addFlagTarget(slug, targetId)
    FeatureFlags->>HttpClient: workos.post(`/feature-flags/${slug}/targets/${targetId}`)
    HttpClient->>API: POST /feature-flags/:slug/targets/:targetId
    API-->>HttpClient: 204 No Content
    HttpClient-->>FeatureFlags: void
    FeatureFlags-->>WorkOS: void
    WorkOS-->>Client: Success

Loading

[greptile-apps]

_{18 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[nholden]

Did you consider making slug and targetId named arguments instead of positional arguments? The order of those arguments aren't particularly obvious, so I'm wondering if addFlagTarget({ slug: 'my-feature', targetId: 'user_foobar' }) might be more foolproof.

[stanleyphu]

I agree - I think named arguments makes more sense here. Updated the PR to do this