Codecov Report

Merging #3144 (fcf3c1c) into master (347e391) will not change coverage.
The diff coverage is 100.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 by Codecov. Last update 347e391...fcf3c1c. Read the comment docs.

📝 Docs preview for commit 685532c 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 all X-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 commit 8b60572 at: https://61ed7670c8634ec6d8ce1542--fastapi.netlify.app

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

📝 Docs preview for commit fcf3c1c 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-route include_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 version 0.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 like grant_type and access_token are essential for internal processing but irrelevant for API consumers to see in the documentation.

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

from pydantic import BaseModel, Field, root_validator
from pydantic.json_schema import SkipJsonSchema

class 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'] = '[email protected]'
            values['password'] = 'Null1234567'

        return values

In this approach, SkipJsonSchema ensures that fields like grant_type and access_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 using SkipJsonSchema?

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