If you're building APIs on AWS Lambda, chances are your system didn't stay "small" for very long.
What started as a single Lambda quickly turned into multiple services. Each service evolved independently. Each one now owns a slice of your API surface.
Architecturally, that's a win.
Operationally, it introduces a quiet but persistent problem:
How do you represent your API as a single, coherent contract?
The Reality of Multi-Lambda APIs
In modern AWS serverless environments, it's common to see:
- Multiple Lambda-based services
- Independent build and deployment pipelines
- A shared API Gateway fronting everything
Often, OpenAPI specifications don't exist at all.
In many AWS Lambda frameworks, APIs are defined directly in code and configuration, with OpenAPI either hand-written or omitted entirely. When specifications do exist, they tend to fall out of sync with production code.
When teams do invest in generating OpenAPI, a second problem quickly appears: those specifications live in isolation.
If you want a single documentation portal, consistent SDK generation or a platform-level API contract, you're suddenly left stitching multiple artifacts together yourself. Most teams end up building a "collector pipeline" - a separate job whose only purpose is to gather OpenAPI outputs from other pipelines and merge them. It works, but it's brittle, manual, and rarely anyone's favorite piece of infrastructure.
LambdaOpenApi and Compile-Time OpenAPI LambdaOpenApi focuses on generating OpenAPI specifications directly from AWS Lambda Annotations in C#/.NET projects, at build time.
AWS Lambda Annotations define how Lambda functions are exposed through API Gateway, but they do not produce an OpenAPI contract on their own. LambdaOpenApi fills that gap by turning annotation-based API definitions into a complete, accurate OpenAPI document.
Each Lambda Annotation project produces an OpenAPI document that:
- reflects the actual code
- requires no handwritten YAML
- avoids runtime scanning or reflection
That model works well at the service level.
The missing piece was a clean way to combine those service-level specs into a single API definition.
Introducing OpenAPI Consolidation in LambdaOpenApi 1.1
With the LambdaOpenApi 1.1 release, we introduced a new capability:
OpenAPI consolidation across multiple Lambda Annotation projects.
The idea is simple:
- Each service generates its own OpenAPI spec
- A merge tool combines them into one unified specification
- Conflicts are handled explicitly and predictably
This keeps service boundaries intact while producing a platform-level API contract that tooling can rely on.
It also fits naturally into existing CI/CD workflows. The merge step is explicit, deterministic, and easy to reason about.
Why This Approach Works
The idea is separation of concerns:
- Services generate their own OpenAPI specs
- Consolidation happens after the fact, using artifacts
- The combined spec becomes the contract consumers care about
Nothing about this requires changing how services are written or deployed. It simply acknowledges how serverless systems are actually structured in practice.
Closing Thoughts
Multi-Lambda APIs aren't an edge case anymore - they're the norm.
OpenAPI tooling needs to account for that reality, not fight it.
LambdaOpenApi 1.1 focuses on one specific problem:
How to consolidate accurate, build-time OpenAPI specs from multiple Lambda Annotation projects into a single, usable API contract.
If you're building APIs distributed across many Lambda functions and struggling with how to represent your API as a whole, this is exactly the scenario this release is meant to address.
LambdaOpenApi is an open-source project focused on compile-time OpenAPI generation for C# Lambda Functions written using AWS Lambda Annotations, with a growing emphasis on multi-service API automation.
