Separate catalog caching, price refreshes and recognition work. A monthly allowance controls total usage, while per-minute and daily limits control when that usage can occur. TCGGraph publishes operation costs and response headers that help a backend track both constraints.
Which options should you evaluate?
| Option | What to evaluate | Decision detail |
|---|---|---|
| Metadata cache | Names, images and printing attributes | Refresh according to updates and permitted storage rules. |
| Price cache | Market, metric, currency and source time | Use an explicit freshness policy. |
| Request scheduler | Concurrency, retries and plan limits | Avoid retry loops that consume the entire budget. |
Provider facts come from the linked documentation. Examples and workflow recommendations are this guide’s analysis.
Design cache keys around the actual request
A cache key should include every parameter that changes the result: game, language, printing, source and relevant filters. A response sorted by US market value cannot be reused as a European price ranking. Keep list pages distinct from individual card records.
Use your own timestamps to record when data was fetched, while retaining the provider’s observation time. These are different clocks. A successful request at noon can still contain yesterday’s price observation; the interface should not imply that fetching it makes the underlying quote new.
Separate traffic limits from monthly credits
A plan may have sufficient monthly allowance but still limit a nightly inventory job. Estimate peak requests per minute, the heaviest day and total monthly operation cost. Recognition and history can use different billing units from ordinary lookups, so count them explicitly.
For example, 900 one-credit requests completed over 30 minutes average 30 requests per minute. Sending them all at once is a different workload even though the monthly total is unchanged. This arithmetic is illustrative; include endpoint costs, bursts and other application traffic in the real schedule.
Use conditional requests and deliberate retries
TCGGraph documents ETag-based conditional responses and zero-credit 304 responses. Retain the validator with the cached body so an unchanged result can reuse the existing record. Verify the current rules for each provider; do not assume a cache strategy has identical billing everywhere.
When a rate-limit response includes Retry-After, schedule the next attempt accordingly and keep concurrency bounded. Distinguish temporary throttling from invalid input, authentication errors and exhausted plan budgets. Repeating an invalid request will not make it valid and can hide the real failure.
Keep the user experience usable during delayed refreshes
A collector should still see saved holdings if the latest price job fails. Display the last known value with its age, and show which records remain unpriced. Avoid an interface that clears a whole portfolio because one provider request timed out.
Add a small set of operational metrics: cache hit rate, requests by operation, remaining budget, oldest price observation and failed refreshes. Use those measurements to decide whether to optimize the request pattern or move to another plan. Start with the workload guide before choosing by headline credits alone.
Before you choose an API
- Include source and language in relevant cache keys.
- Retain source time and fetch time separately.
- Respect retry guidance and bound concurrency.
- Keep a stale-but-labeled display when refreshes fail.
Frequently asked questions
Does a cached card response always cost zero?
A response served entirely from your own cache makes no provider request. A conditional provider request follows that provider’s billing rules. TCGGraph documents zero-credit 304 responses when its conditional request mechanism is used.
Why can I get a 429 while I still have monthly credits?
A per-minute or daily limit can be reached before the monthly allowance. Inspect the response and current plan rules so the scheduler waits for the correct reset.
Should API keys be stored in a mobile app?
Keep private provider credentials on your backend. A distributed client cannot reliably keep an embedded service key secret. Let your backend enforce the application’s user and usage rules.
Sources and further reading
Your next step with TCGGraph
Inspect the documented fields, then test the cards and workload your application needs.