Fly Labs
Ask FlyBot

[Multiple languages] properties are generated as nullable/optional, despite required/nullable usage in OAS schema

Kiota ignores the usage of `required`/`nullable` in OAS schemas. C# properties are always generated as nullable. This results in unneeded noisy squiggles, as shown [here](https://github.com/microsoft/kiota/issues/3846#issuecomment-1844249797). NSwag does a better job, by performing the following translation (using the `/GenerateNullableReferenceTypes:true` switch): - OAS non-required + nullable: C# nullable - OAS required + nullable: C# nullable - OAS non-required + non-nullable: C# non-nullable, unless combined with the `/GenerateOptionalPropertiesAsNullable:true` switch - OAS required + non-nullable: C# non-nullable Additionally, NSwag adds `[Newtonsoft.Json.JsonProperty(Required = ..., , NullValueHandling = ...)]` on the generated properties, which results in client-side serialization errors (thus avoiding a server roundtrip on invalid input). Example component schema ```json "exampleComponent": { "required": [ "requiredNonNullableReferenceType", "requiredNullableReferenceType", "requiredNullableValueType", "requiredValueType" ], "type": "object", "properties": { "nonNullableReferenceType": { "type": "string" }, "requiredNonNullableReferenceType": { "type": "string" }, "nullableReferenceType": { "type": "string", "nullable": true }, "requiredNullableReferenceType": { "type": "string", "nullable": true }, "valueType": { "type": "integer", "format": "int32" }, "requiredValueType": { "type": "integer", "format": "int32" }, "nullableValueType": { "type": "integer", "format": "int32", "nullable": true }, "requiredNullableValueType": { "type": "integer", "format": "int32", "nullable": true } }, "additionalProperties": false } ```

GitHubToolDesign & CreativeSource
0Sign in to voteCopy link

FL score

65

out of 100

Verdict

BUILD

high confidence

Competition

7

competitors found, mature market, funded players

Trend

8 community mentions

A specific C# nullability and required property generation bug in Microsoft Kiota causes developer frustration and potential serialization errors, in a market saturated with free tools that already solve this correctly.

The pain

Kiota (Microsoft's API client generator) incorrectly generates C# properties as always nullable/optional, ignoring OpenAPI schema's `required` and `nullable` flags. This leads to 'noisy squiggles' in code and potentially critical client-side serialization errors, wasting developer time and introducing bugs.

The gap

The gap is specific to Kiota users; the broader market has mature tools (NSwag, OpenAPI Generator) that correctly handle this. For Kiota users, the gap is Kiota's own inability to correctly interpret the spec, creating an underserved niche *within* the Kiota ecosystem. Competitors prove demand for *correct* generation.

Build angle

The most viable build angle for a solo builder is a targeted post-processor or plugin for Kiota-generated C# code, which automatically corrects the nullability and required property attributes based on the original OpenAPI schema. This avoids needing to build a full generator from scratch.

Strengths

  • Highly specific and real problem for Kiota C# users, evidenced by GitHub issues and recent discussions.
  • Clear, measurable value proposition: eliminate squiggles and prevent serialization bugs.
  • Technical feasibility for a solo builder (especially for a post-processor MVP).

Risks

  • The overall API generation market is crowded with strong, free OSS competitors (NSwag, OpenAPI Generator) that already solve this problem correctly.
  • Low willingness to pay for a specific bug fix, as developers might expect this functionality for free or switch tools.
  • Microsoft (Kiota's creator) could fix the bug themselves, rendering an external solution obsolete.
  • Limited market size: only targets Kiota C# users, making monetization challenging for a micro-SaaS.
  • Building a truly robust solution that matches existing tools is complex for a solo builder.

Next steps

  1. Conduct in-depth interviews with Kiota C# developers to understand their exact pain points, frequency, and if they've considered paying for a solution or alternative.
  2. Validate if Kiota users would pay for a targeted post-processor, even a small amount, given the free alternatives.
  3. Explore potential for a 'buy me a coffee' model or integrate the fix into a broader, more valuable developer tooling suite.
  4. Build a proof-of-concept (POC) post-processor and share it with the Kiota community to gather feedback and gauge adoption interest before committing to a full product.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “[Multiple languages] properties are generated as nullable/optional, despite required/nullable usage in OAS schema”.

Open FlyBot