By implementing a custom document transformer, you have access to the document to change it as you see fit before it is returned to the client: https://learn.microsoft.com/aspnet/core/fundamentals/openapi/customize-openapi

By implementing a custom document transformer, you have access to the document to change it as you see fit before it is returned to the client: https://learn.microsoft.com/aspnet/core/fundamentals/openapi/customize-openapi

yeah, I did implement my customizations, the OpenApi document which is returned by the endpoint looks good, but how can I access the OpenApiDocument with all the transformations applied, same document that is returned in the endpoint.

Ah I see - I don't think there's a way to do that.

@EliveltonRepolho Thanks for filing this issue!

@martincostello's response seems correct based on my understanding of the question. Currently, there's no public API for accessing the in-memory OpenAPI document.

Out of curiousity, how and where are you trying to access the OpenApiDocument?

@EliveltonRepolho Thanks for filing this issue!

@martincostello's response seems correct based on my understanding of the question. Currently, there's no public API for accessing the in-memory OpenAPI document.

Out of curiousity, how and where are you trying to access the OpenApiDocument?

Got it, our use case is for a internal framework build for a Backend For Front (BFF), which exposes metadata related to the endpoints (similar to OpenAPI json but with different schema, and with some enrichment), since it is generated on backend side, we take advantage of all properties already present in OpenApiDocument, with extra enrichment processes for internal attributes.

@EliveltonRepolho In the example above, is your endpoint returning the OpenAPI document back in the response or do you return your own type that you derive from the OpenAPI document?

What metadata from the document do you pull?

I might have a proposed resolution for you based on those questions. 🤔

@captainsafia in the example, we return our own type which is derived from OpenAPI document.

What we do is:

• We use document transformer to include our custom metada to OpenAPI, which is exposed to openapi endpoint/document
• Then we have our own endpoint, which uses OpenAPI Document to create our custom response type based on custom metada included as well default OpenAPI meta (required, length, permissions/roles, query params, body ...)
• The reason we don't use the OpenAPI document directly is because our custom endpoint first "curate" the metadata and create the response especifically for that User/App, so it consider feature flags and permissions for that particupar request

@EliveltonRepolho Ah, I see. I was going to recommend using the underlying IApiDescriptionProvider APIs to resolve the metadata that you need instead of the OpenAPI dcument. The IApiDescriptionProvider interface is the same one that OpenAPI implementations pull from to construct the document. You might find that it is higher fidelity than what is available in the OpenAPI document.

Absent this, you might have to leverage private reflection (for now) to resolve the OpenAPI document service and interact with.