YoutubeVideo initialization fails when API response contains unexpected fields (e.g., access_status)

[hanqyu]

Problem

When the Supadata API response includes fields that are not defined in the YoutubeVideo dataclass (such as access_status), the library raises a TypeError during initialization.

Error:

TypeError: YoutubeVideo.init() got an unexpected keyword argument 'access_status'

Stack trace location:

File "/app/.venv/lib/python3.12/site-packages/supadata/youtube.py", line 190, in call
return YoutubeVideo(response, uploaded_date=uploaded_time)

Root Cause

The library directly unpacks the API response dictionary (**response) when initializing YoutubeVideo, which fails if the response contains fields not defined in the dataclass. This can happen when:

• The API adds new fields (like access_status for member-only videos)
• The API response structure changes
• Some videos have additional metadata fields

Expected Behavior

The library should filter out fields that are not defined in the YoutubeVideo dataclass before initialization, or handle unexpected fields gracefully without raising an error.

Suggested Solution

Filter the API response to only include fields that are defined in the YoutubeVideo dataclass before initialization:

In supadata/youtube.py, line ~190

valid_fields = {f.name for f in fields(YoutubeVideo)}
valid_fields.discard("uploaded_date") # uploaded_date is handled separately
filtered_response = {k: v for k, v in response.items() if k in valid_fields}
return YoutubeVideo(**filtered_response, uploaded_date=uploaded_time)## Additional Context

• This affects videos that may have access_status or other unexpected fields in the API response
• Some videos work fine, while others (particularly member-only videos) trigger this error
• We've implemented a workaround by wrapping the library method, but it would be better to handle this in the library itself

Environment

• Python 3.12
• supadata library

Additional Context

This affects videos that may have access_status or other unexpected fields in the API response
Some videos work fine, while others (particularly member-only videos) trigger this error
We've implemented a workaround by wrapping the library method, but it would be better to handle this in the library itself