FastAPI not recognising field in Request body

I'm having an issue with a FastAPI app I'm creating. I have a route to create a new user calendar which I'm currently trying to test.

Route

# Add User Calendar
@router.post("", response_model=schemas.UserCalendar)
async def add_user_calendar(
    user_calendar: schemas.UserCalendarBase,
    current_user: schemas.User = Depends(deps.get_current_active_user),
    db: Session = Depends(deps.get_db),
    parent_slot: schemas.ParentSlot = None
):
    return usercalendar.add_user_calendar(user_calendar,
                                          current_user,
                                          db,
                                          parent_slot)

Helper Function

# generate a user calendar
def generate_user_calendar(
    account_id,
    calendar_name = "offline_test",
    calendar_id = "test_calendar_id",
    timezone = "Europe/London"
):
    return  {
        "account_id": account_id,
        "calendar_name": calendar_name,
        "calendar_id": calendar_id,
        "timezone": timezone
    }

# create a user calendar
def create_user_calendar(user_calendar, headers):
    return requests.post(API_ENDPOINT + "/calendar",
                         headers=headers,
                         json=user_calendar)

Schema

class UserCalendarBase(BaseModel):

    account_id: int
    calendar_name: str
    calendar_id: Union[str, None]
    timezone: str

    class Config:
        orm_mode = True

When I generate a calendar and then call create_user_calendar to create it I get an error on the server side:

1 validation error for Request body -> user_calendar field required (type=value_error.missing)

If I amend the helper function to include "user_calendar" at the top level then it works, e.g.

# generate a user calendar
def generate_user_calendar(
    account_id,
    calendar_name = "offline_test",
    calendar_id = "test_calendar_id",
    timezone = "Europe/London"
):
    return  {
        "user_calendar" : {
            "account_id": account_id,
            "calendar_name": calendar_name,
            "calendar_id": calendar_id,
            "timezone": timezone
        }
    }

In other routes though I have not had to add this top level field.

For example:

# generate a user account helper function
def generate_user_account(
    user_id,
    account_type = "online",
    account_email = str(get_datetime_now_iso()) + "@email.com",
    account_provider = "google",
    used_for="PERSONAL"
):
    return {
        "user_id": user_id,
        "account_type": account_type,
        "account_email": account_email,
        "account_provider": account_provider, 
        "used_for": used_for
    }

# create a user account helper function
def create_user_account(payload, headers):
    return requests.post(API_ENDPOINT + "/account",
                         headers=headers,
                         json=payload)

# User creation / registration route
@router.post("/", response_model=schemas.User)
def create_user(
    user_to_create: schemas.UserCreate,
    db: Session = Depends(deps.get_db)
):
    return user.create_user(db=db, user=user_to_create)

# schemas
class UserBase(BaseModel):
    username: str
    email: str
    timezone: str

class UserCreate(UserBase):
    password: str

Is this something that I've done wrong somewhere? It seems to be the only route I've created that I've encountered this issue. I've obviously got the fix but it means that I need to work with this route in an inconsistent manner to the others, i.e. adding the field name to the request where the others just seem to recognise the schema and do the work.

Thanks

In the endpoint add_user_calendar you are expecting several Pydantic objects (i.e., user_calendar, current_user and parent_slot). This means that the three of them will be interpreted as requests bodies, which makes little sense.

The solution would be to create a single Pydantic model that takes all the fields needed by the endpoint (you could call it, e.g., AddUserRequest).

Notice that in your other example, create_user, only one Pydantic model is received, and therefore the confusion doesn't exist.