I was trying to use the id field as a unique id for an android list but quickly realized the id is repeated based off the type of credit (movie vs tv for instance). I created my own combining the id and media_type fields but after looking at the response again I noticed the credit_id field. Can anyone confirm that this field is unique across all endpoints or should I stick with my current implementation? I appreciate any help I can get.
Can't find a movie or TV show? Login to create it.
Want to rate or add this item to a list?
Not a member?
Reply by ticao2 š§š· pt-BR
on June 2, 2025 at 11:52 AM
If I understand your question correctly...
Yes, the IDs are unique. There are no two Movies with the same ID.
But there may be a TV Show with the same Movie ID. Or a person.
The list of IDs are separate, different.
For example, ID 500:
https://www.themoviedb.org/movie/500-reservoir-dogs
https://www.themoviedb.org/tv/500-mad-about-you
https://www.themoviedb.org/person/500-tom-cruise
https://www.themoviedb.org/network/500
https://www.themoviedb.org/company/500
You can discern the difference between each media type
by looking at the
media_type
field returned with each object.Reply by WilderApps
on June 3, 2025 at 5:42 PM
I appreciate the reply, but that's not what I was looking for. Admittedly, I didn't explain my problem that well either. Let me try again.
I am creating an Android app that, as part of the app, will display the credits for a person. I originally designed the credit object off of the knownFor array from the Search - People endpoint. Once a person is selected, I then pull their credits from the Combined Credits endpoint. The lists in android require a unique identifier for the objects in the list so I used the id field for the credit object. I realized these weren't unique because the data was pulled from different tables in the database (much as your example points out) after, by pure luck, pulling Steven Spielberg's credits. He is the director of both The Color Purple and an episode of Columbo. I fixed this by creating a listId field for my credit object, which I set to id + movie_type. His credits in my app then changed from 2 ids of 873 to 873movie and 873tv, respectively.
I have decided to implement a history feature that will function offline, saving any previously searched people and credits to a local database. I realized this fix wouldn't work for the database as anyone credited to the same project would have the same listId. I could easily do a joined primary key of the person and either the project (movie or tv show) or credit ids to solve the database issue. I would still need to make the listId to use in the app itself, though. After looking at the Combined Credits endpoint in more depth, I realized I had overlooked the credit_id field in building my credit object the way I did. Steven Spielberg's The Color Purple credit_id is 52fe4285c3a36847f80257ad for example. I could add this to my credit object and use it as the unique field for both my database and in-app lists, assuming this field is unique across all media_types. My question is, can anyone confirm this field to be unique across all media_types? Thanks again for any help I can get!
Reply by WilderApps
on June 3, 2025 at 5:53 PM
I looked through the API endpoints more thoroughly after posting the above reply and found the Credit - Details endpoint. This takes a credit_id and returns information about the person and project (listed as media in the response) associated with the credit_id. It confirms these are unique across media_types as it will return only one result. Thanks again for your response and I'll try to do a better initial job of looking through the endpoints before posting in the future.
Reply by ticao2 š§š· pt-BR
on June 4, 2025 at 12:46 PM
I was researching this question this morning.
And in fact the credit_id refers only and exclusively to that combination of Actor+Character.
I was able to confirm this by looking at the response to this API Request.
The ID is different for each item.
But you already found the answer.
Sorry for being late.