Validate feature flag names

This capability validates a candidate name against a practical industry pattern: the name must be non-empty, entirely lowercase, written either as hyphenated kebab-case or as snake_case (never both separators in one string), contain at least two segments, start with a descriptive prefix such as enable, feature, ff, rollout, or beta, stay within sixty-four characters, and avoid edge or consecutive separators. Empty input fails with invalid_input and is not billed. Convention misses return a structured success payload with valid set to false and an ordered issues list so continuous integration can fail the build with a clear report.

What the naming convention requires

First, it must not be empty or whitespace-only: an empty name is rejected immediately as invalid_input because there is nothing useful to evaluate. Second, every character must be lowercase ASCII letters, digits, and exactly one style of separator—either hyphens for kebab-case or underscores for snake_case. Together these rules map cleanly onto LaunchDarkly-style keys, Unleash toggles, and most in-house JSON or YAML flag files without inventing a vendor-specific dialect.

Input contract, response shape, and error behaviour

The example value enable-checkout-express is a valid kebab-case flag with the enable prefix. When the name meets every rule, valid is true, issues is an empty array, and style is kebab or snake. Numbers are coerced to strings; objects and arrays are rejected. On success the response always includes valid (boolean), the echoed name after trim, style (kebab, snake, or null when the pattern could not be classified), prefix (first segment or null), segments as an ordered string array, segment_count, has_descriptive_prefix, issues as a stable ordered list of machine-readable codes, and a short convention sentence suitable for UI display. When the name is present but breaks the convention, valid is false and issues lists codes such as not_lowercase, mixed_separators, missing_descriptive_prefix, too_few_segments, invalid_characters, consecutive_separators, leading_or_trailing_separator, too_long, missing_separator_segments, or invalid_pattern—without throwing—so linters and pull-request bots can print every problem at once. Only empty, missing, or non-string names throw invalid_input; those failures do not consume prepaid balance.

Where feature flag name validation earns its keep

Platform and developer-experience teams wire this check into scaffolding generators so new flags cannot land without a prefix and separator style. Continuous integration jobs scan pull requests that touch flag catalogues or environment sample files and fail the build when a name would confuse operators six months later. Product analytics and experiment tooling use the same rules when registering rollout keys so dashboards group by prefix consistently across mobile, web, and backend. Code review bots call the API with a candidate string and paste the issues list into the review thread instead of arguing style by taste. Because every successful call costs the published $0.002 base price with no model tokens, you can validate thousands of names in a migration script without surprising spend; empty submissions stay free of charge as client errors. Keep the prefix table aligned with your org’s house style by mapping internal verbs onto the supported set, or wrap this endpoint and reject any prefix your policy forbids even when the base convention passes.