Did you remove the TvDbId value from your API? I can’t see it anymore. My app crashed 
I wish you had chosen to send null, undefined or 0 instead of removing it. 
Could you please send the requests/endpoints you are using that makes your app crash?
We’ll see what we can do but I would still advise you to update your app to handle responses without a TVDB id.
Also, just for my own curiosity, what language and framework is your app written in? If you assume a value can be null, it shouldn’t be an issue to not have the value in the response in the first place 
Thanks for your feedback.
In the meantime, TVDB id were added back at shows level (seasons and episodes were already good). Let me know if okay for you now!
I’m still interested to know more about your app and what exactly broke parsing your side 
Hello,
I check TVDB when pulling shows/trends and shows/popular data. My app doesn’t crash and close, so I check “null, undefined” of course 
But since I’m pulling photos linked to TVDB, it’s not working properly. I understand you’ve also changed the URL structure of some photos. I understand you’ve removed the formatting with tvdbId. Right? I’m using react native.
And I’m working on your new response structure. If that’s OK with you, you can add the tvdb id again, but set the value to zero or null. I understand that no one wants to add a null or null value, but our applications are dependent on you in the live environment, so you can give us a certain amount of time to get them set up.
The TVDB id was removed temporarily at the show level. It has been re-added now.
Your app should be updated to expect optional external identifiers, especially for TVDB (I’m referencing here the announcement about the switch from TVDB to TMDB from Justin). Maybe also have a fallback for images fetching.
Anyway, thanks for flagging this. If we change something in the API, it will be shared on GitHub in advance.
1 Like
Hello,
Got it. I’ll update my app based on your new changes. Thank you.
1 Like
It looks like the tvdb id is still missing from the trending/popular show lists. Will it be added back?
I can confirm its not in the trending or recommended lists.
I use kometa to create dynamic collections, and they rely on tvdbid
Also I think there was a change to the /movies/collected endpoint – any chance it used to work without passing a /:period?
I get errors in kometa when I try to sync collected movies (I believe it may be hitting an undocumented endpoint without period) an also it doesn’t get a tvdbid for both “trending” and “recommended” shows APIs.
I can confirm it’s still missing from anticipated/trending/popular. @kcador Any hope of getting TVDB id’s back in place. We’ve used it for our app for years, and we still depend on it.
Might have to switch solely to TVDB recommendations if not.
I updated my app. Today, when I looked in the “shows/trending” endpoint, I saw “tvdb”: null, which is fine with me. I already updated my app, but some users may not have upgraded, so it’s at least working with the old version now.
However, if your app is linked to tvdbId, I think you should update it. @xstasy @adam.herzog
TVDb id’s have been added to those endpoints. Let me know if you are still missing some (the specific endpoints always help).
That said, as @Semihcelikol pointed out, it would be best to update your apps/services to use other identifiers like TMDb (our main metadata data-source), IMDb (a wider used standard external id) or Trakt id directly. The benefits of using Trakt id directly when hitting the Trakt API are higher performance and reliability.
I would love to better understand your use cases. Could you share why you rely on TVDb ids when using the Trakt API?
Thanks!
1 Like
Thank you, Kevin.
The app in question is Kometa ( Home - Kometa Wiki ). I’ve put in a feature request so that it’ll use TMDb or IMDb identifiers if/when the TVDb ID is missing, but right now it relies solely on the TVDb ID in order to eg. create a Plex collection from a Trakt chart/list.
1 Like
I have created two issues on the Kometa github repo about these two things:
This is an open source project, so its not something we can “just change” – It’ll need updates by the Kometa team.
The other issue @kcador is that it doesn’t appear either of these changes were actually communicated anywhere.
Hard for us to stay up-to-date with the API if changes aren’t communicated / deprecated properly.
1 Like
Totally understood. We try to communicate any breaking changes in advance. We ask developers using the Trakt API to follow discussions and submit issues on GitHub.
Because these are not changes. These are issues we are correcting (when we can).
To quote myself (sorry to be that guy 
):
For the first GitHub issue you shared, can you share the specific endpoint from our side that doesn’t have the TVDB id?
For the second one, this has nothing to do with a change on our side, right?
It looks like the first issue is no longer occurring since you added them back to those endpoints, so as long as they aren’t going to be removed again, I guess I can close that issue with the Kometa team. But if you intend to remove them again, I need to keep the issue and update it to be clearer that you do intend to still remove them from those endpoints.
The 2nd is occurring because it looks like /movies/collected used to work, it used to default to /movies/collected/weeklyI believe, but I can’t confirm now since its been changed. But /movies/collected did work, but no longer does, so it was a change. However, it appears that endpoint was never documented in your API docs, so it looks like its a situation where Kometa was using an endpoint (that worked) but wasn’t intended to be used the way they were?
Second issue has also been fixed on our side too. /movies/collected should work as documented now. The period is in fact optional and defaults to weekly.
Again, breaking changes will be communicated in advance. If you find something that doesn’t work as documented, please share it with us!
Thanks. I can confirm that both issues appear resolved now!
1 Like