Codecov Report

Merging#3144 (fcf3c1c) intomaster (347e391) willnot change coverage.
The diff coverage is100.00%.

@@            Coverage Diff             @@##            master     #3144    +/-   ##==========================================  Coverage   100.00%   100.00%            ==========================================  Files          504       509     +5       Lines        12707     12807   +100     ==========================================+ Hits         12707     12807   +100

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update347e391...fcf3c1c. Read thecomment docs.

📝 Docs preview for commit685532c at:https://608d27c8521eb7158616ef14--fastapi.netlify.app

@jordantshaw no idea but I have updated the request with a code sample from the original issue. Hope that will speed up the review.

This is a useful PR for me, too.

Very useful for me too to remove allX-Forwarded-* headers in the doc.

Please merge this!! This is a super useful feature! 😊😊

hello, any updates on this? this will be a really helpful additiona feature 👍

@tiangolo Any updates on when this will merged? Looks like a lot of people would find this very helpful.

@tiangolo Ping? I would also be very delighted to see this feature :3

@tiangolo Any update for this, really helpful

Joining the gang, I would find this very useful too

📝 Docs preview for commit8b60572 at:https://61ed7670c8634ec6d8ce1542--fastapi.netlify.app

📝 Docs preview for commitc49e01c at:https://61ed78f66a86fc22f4026592--fastapi.netlify.app

📝 Docs preview for commitfcf3c1c at:https://61ed79c4bc1bd1bb22e41376--fastapi.netlify.app

Awesome, thank you@astraldawn! ☕

Thanks everyone for the discussion! 🍰

I updated a bit the tests and added source examples (and tests) for Python 3.10.

I was thinking that maybe it could make sense to support also body/form-data, but the implementation would be non-trivial, or it would have to be a per-routeinclude_body_in_schema or something like that. But at the same time, I don't easily see a use case where hiding the entire body would be wanted without just hiding the entire route, so let's just have this for now and I'll see if anyone finds later a use case that would benefit from hiding the body before implementing that. 🤓

This is available in FastAPI version0.73.0 (released in a couple of hours). 🎉

This is a fantastic feature addition—thank you for this! 🎉

I wanted to share an alternative approach I’ve used in a similar context where I needed to exclude certain fields from the OpenAPI schema for a cleaner API documentation. My use case involved building an OAuth2-like authentication schema where fields likegrant_type andaccess_token are essential for internal processing but irrelevant for API consumers to see in the documentation.

Here’s the implementation I used, leveragingpydantic.json_schema.SkipJsonSchema:

from pydantic import BaseModel, Field, root_validatorfrom pydantic.json_schema import SkipJsonSchemaclass UserSignInSchema(BaseModel):    grant_type: SkipJsonSchema[GrantType] = GrantType.PASSWORD    access_token: SkipJsonSchema[str] = None    username: str = Field(..., alias="email")    password: str    @root_validator(pre=True)    def validate_fields(cls, values):        grant_type = values.get('grant_type')        if grant_type == GrantType.PASSWORD:            values['access_token'] = 'Null'          elif grant_type in (GrantType.GOOGLE, GrantType.FACEBOOK):            values['username'] = 'null@null.com'            values['password'] = 'Null1234567'        return values

In this approach,SkipJsonSchema ensures that fields likegrant_type andaccess_token are excluded from the OpenAPI spec, allowing us to focus the documentation on the fields users need to interact with, like username and password.

I’m curious about how this compares to the include_in_schema parameter introduced here. Both approaches achieve field exclusion but might cater to slightly different needs. For instance, does include_in_schema offer better control in dynamically configurable scenarios, or are there limitations when usingSkipJsonSchema?

Thank you again for this valuable addition—it’s going to make handling such use cases a lot more intuitive! 😊