Pricing with one call?

currently if i call this url ,


i get a list of every card in magic. with every detail about the card, except it’s pricing.

is there a way to include pricing in this call? having one call to get everything would make things very easy in coding and the server load. also i am wanting to play around with algorithms with the pool of every card and it’s pricing. does your server only calculate the prices in real time whenever a price is queried? is giving prices for 30,000+ cards all in the one call not possible from the server end?

i just realized that call only returns the first 10 cards out of the 35,109 that is declared in the total.

We do not, currently, have a single calls that returns all the prices for all products (without restriction). We are taking things slow and reviewing how our data is being used. We are looking for Strong Partners that develop applications that add value to TCGplayer, so if you could explain how you would use “real time” data, that may make a stronger case for it.

As for the current TTL of the prices, that all depends on which one. The API itself is cached for 5 minutes. Some prices are calculated daily on the platform, while others are updated almost every minute.

For information purposes, prices will never be in the /catalog/ endpoint, as that is reserved for product information (metadata, weight, dimenstions, etc.).

i just tried to do a loop that changed the offset by 100 each loop. that was an attempt to load a file that was a list of each card name. but that seemed to be unpractical. i stopped it at card 1400. i could use a list of every card in MTG in order to create an “autofilling” action in the search bar when searching for cards. instead of having to spell the complete word correctly to do a search for an individual card price. being able to quickly load a list of every available MTG card would eliminate the need to having to manually update the list every time new cards are released.

the first reason i wanted all card prices of MTG was to have run each card through an algorith comparing market and mid price. when i trade in real life i look at these to determine the “unseen value” to a card. if i can press a button and have all cards/data loaded and then compared individually on the app, then i can populate a list of the strongest cards in the current market of that moment. sending only the card name along with the different prices would make this a lot more feasible than sending every bit of information about the card. not sure if that would require too much framework re-writing. the more pricing data i have to work with the more interesting i feel the hypothetical results could be. such as past prices dating back however long, in order to compare the rate of change. the idea is one opens the app or when they “refresh” the current complete list of cards is loaded, then the list pops up showing the “hottest” cards based on the comparative algorithm. this can also be shown on a widget.

another idea is to have a way to notice when buyouts happen. if there is a way to observe and “alarm” on your side when many sales over a short period of time happen for an individual card, it can be linked to a notification that pops up in the top of the phone like all the other apps notify when you get messaged or whatever, and that can notify the user of the app when a buyout is happening that moment

another endpoint i feel would be beneficial would be to request individual card data, but multiple at a time. like adding on each card to the end of the url, with no real limit. unless this is already attainable and i didnt notice. this would be good for collection tracking, so if i have a collection of cards saved on the app, to get the collections value, one call asking for each card individually would be easier to show the collections value instead of making a call for each card. but if one can practically have one call to load all card data at once, then the collection tracker could run off that call as well.

FYI i have stumbled apon this site it allows downloading a file of a current list of all MTG cards in JSON format and is constantly updated. since the names of the cards wont change, ill most likely be able to pull the list easily and quickly from that site in order to have the list of cards saved in the app and stay updated. then ill be able to use your current api to call each card individually. i get how TCGs current API fits webpage navigation and flow.

@tcgplayeradmin let me add that currently I am trying to make my apps (12) from your marketplace.

So, lets check some numbers:


Since my goal is so that my users can have prices offline, I need to fetch every price every day to my servers, and then push them to the apps - while the users are online - so if they come to be offline they still have prices for the day.

That said, I would need to make ~100,000 calls each day to your servers, I do think that there should be a better way to do this.

Also I guess that you don’t want me to do that each day.

Thoughts? :confused:

just throwing ideas out there… if there was a way to call for every card, but only get the current prices with that list instead of all the information about the card, it could make the call data less. then in the app. when selecting an individual card, the app can then make another call for only the specific card and get all the information about the card under the current api.

We are in the process of expanding an endpoint to allow for a comma-separated list of productIds and skus so you can call for prices in batches of 100. Additionally, we are also working on showing/hiding extended data on the product endpoint so that you can choose to show/hide sku information through that same call.

And lastly; we are working on a design for a pricing/X/history endpoint that will act like a pricing feed. We are working on what level it will exist at right now (catalog, group, product), how frequently is updates (because every price point calculates at a different interval), and if we want to provide a “changes SINCE X datetime” option.


This would be very useful. An “addedSince” parameter accepting a date or epoch time to update an existing catalog preventing the need for another full scan/fetch would be :ok_hand:.


We wouldn’t show each price change; just the products/skus that changed, and the most updated prices. We’ll keep everyone updated on when that endpoint will be ready. Thanks!

1 Like

That sounds great.

Is there a recommendation (minimum or maximum) on how frequently to check for those SKUs that have updated?

I’ll have to confirm; but I think the longest cache duration for one of the prices points is 5 minutes … so it doesn’t make sense to call it more often than that. Having said that; do you think there’s any value in having the /history be based on a singeprice point? Or do you need them for all the prices? ie. /pricing/products/history?price=directlow

1 Like

having the history be part of the single call with all the prices would be awesome to utilize. returns each card, the associated market, mid, low, high (at minimum the market and mid. i dont really see use of the low and high in the real world from my perspective) and then a record of the history of the card. short term and long term are both beneficial. like maybe the last 2 weeks day by day (14 entries) then the last 2 years month by month (24 entries). just an example. if it doesnt take much data. the entire history. the more data we can use the more things we can do. but the speed of being able to make the “one call” is important. users do not have more than a couple seconds attention span in actuality.

returning the history with a single card call is the easy solid set up, and allows people to gather details once they click on a card… but if history is not associated with the “all pricing one call” then the app cannot run all the cards histories and pricings through an algorithm and any type of price fluxuation notifications cannot exist. edit*— algorithms based on history cant be run through all the cards, but an algorithm based on comparing mid and market still would be able to without the “all pricing call” returning history. im trying to answer you as strait forward as i can and not try to sound like anything can magically happen haha.

Greetings, was the history endpoint ever created? Sounds really cool!