Looks like the not_found key was a WIP progress. Maybe something changed between when it was originally stubbed out, but the not found response is slightly different than originally structured. The item arrays are actually "items with ids" rather than an array of ids.
This implement might be an okay start. There are some additional fields that could be part of NotFoundItem. The API seems to return the item object as sent in the request. So it may even have a title, year, etc. The ideal thing might be to re-use the same request struct as it's simply mirrored back. However that doesn't seem to be modeled either. It's just RawJSON.
Looks like the
not_foundkey was a WIP progress. Maybe something changed between when it was originally stubbed out, but the not found response is slightly different than originally structured. The item arrays are actually "items with ids" rather than an array of ids.The test json file is actually correct.
https://github.com/MaxHasADHD/TraktKit/blob/a99703bf93d060843ac51258e4971a4f5174033e/TraktKitTests/Models/Sync/test_add_items_to_collection.json#L14-L31
This implement might be an okay start. There are some additional fields that could be part of
NotFoundItem. The API seems to return the item object as sent in the request. So it may even have a title, year, etc. The ideal thing might be to re-use the same request struct as it's simply mirrored back. However that doesn't seem to be modeled either. It's justRawJSON.Let me know what you're thinking. Thanks!