Hi @frotogoblin, it would be nice, but given some technical constraints, I doubt we'll be able to add such dynamic responses.

What kind of technical constraints are we referring to?

Not entirely sure what your API backend looks like but shouldn't be impossible to iterate through results, read the ID of each, and perform a DB query to fetch additional information. If we think about the use-case, the end result would be an identical amount of DB queries, identical computational cost, while providing reduced API hits.

Hey @travisbell ,

Am hopeful for a response.

Right now my OSS is in beta, and 51 beta testers can reach 15,926 daily API hits due to this limitation. Workarounds on my side would severely impact user experience. We are already caching external ID results for a week.

As mentioned, the ability to append external IDs to more endpoints would cut down queries by a huge factor.

Hi @frotogoblin, if you want/need certain data where we do not provide it, your best bet would be to pull in some of the data into a local data store of your own where you can build a schema that matches your particular use case.

The OSS software I'm developing is self-hosted. By "51 users" I am referring to 51 self-hosted instances. Your suggestion would require us to set up a server to be a middleman to the TMDB API. This unfortunately is not realistic for our development team.

@travisbell If the issue is "dynamic responses", what's the possibility of all top/popular/recommended/similar/search endpoints always having external IDs attached, similar to Trakt's API?

Unfortunately, we have no intention of adding externals ids to more responses.

How about on the V4 API? Is there consideration being made to allow for "more information" being able to be provided on popular and top endpoints?

If you really need to lower your api call count, this would be a perfect scenario to implement a cache system. Then have some kind of cron or background process update that data once a day/week.

We already have a cache system in place for on every self-hosted instance. All TMDB queries are cached. In terms of external IDs specifically, we are caching them for one week on a per-TV show basis. As far as I'm aware, I don't see a way for the API to dump all external IDs for all shows.

No, v4 won’t be a likely option. At this point, I doubt anything more will be done in the v4 namespace. It’s possible at some point in the next few years we start to work on v5, which will be more than likely a GraphQL API, which would theoretically support more dynamic responses but that is just not a priority for us this year. Too much other stuff to work on.

Your 7 day cache sounds good. It might only be improved if at some point, I get to this ticket. This would allow you to track the changes by key that you’re interested in. But you’d still have to request the change logs for each show you’re tracking.

@travisbell said: This would allow you to track the changes by key that you’re interested in. But you’d still have to request the change logs for each show you’re tracking.

Since it needs to occur on a per-show basis, I don't believe that would reduce my API usage.

Here's an endpoint idea that could be used to significantly reduce API usage:

• Inputs: parameter_name (ex. external_ids) and a tmdb_ids list of TMDB IDs.
• Outputs: results JSON array of modified times for that specific property.

or

• Inputs: tmdb_ids list of TMDB IDs.
• Outputs: results JSON array of modified times for every property.

Something along the lines of a /tv/bulk-changes endpoint. This idea would allow us to implement forever-caching, and only invalidate cache when TMDB reports a property is modified.

Due to varied inputs, you might be able to describe these response as dynamic. So this might not be feasible based on your technical limitations, but I am hopeful.