I wanna know your opinion on this: Even though it's undocumented in this specific method, all other kwargs are passed directly to TasksService.get_tasks, would it be simpler to keep track if the definitions were all just the same? You also wouldn't have a partially unknown **kwargs.

I think this definition could be improved either way:
TasksService.get_tasks is also overloaded based on async_req. Passing async_req=True in TasksApi.find_tasks would fail because .tasks would be called on a ApplyResult. The current definition of TasksApi.find_tasks with **kwargs allows that. We could enforce async_req: Literal[False] = ... here.

I was debating this. Technically, you can pass all those arguments to it, even async_req, but I'm not sure this is actually intended. Especially in the case of async_req.

Maybe @bednar could provide some insight: Should the functions in _api.py that call call_api under the hood accept the additional keyword arguments that call_api accepts? Including async_req?

The purpose of passing **kwargs from _api.py to _service.py is to provide a flexible way to forward query parameters to HTTP requests. This design allows any number of additional keyword arguments (parameters) to be passed through the API layer directly to the service layer, which then constructs and executes the HTTP request