Synchronize inventory data

Your application decides when it needs newer inventory data. SteamCall collects the complete inventory in the background and makes it available through Current only after the scan succeeds.

Separate reads from refreshes

• Current reads the latest saved inventory without contacting Steam.
• Refresh requests a new complete scan in the background.
• Status reports progress and billing for that refresh. Status reads cost no credits but count toward the Service Account's request limit.
• Live Page requests one page directly from Steam. Use Refresh when you need a complete saved inventory.

This separation keeps opening a profile page from unexpectedly triggering a paid scan. If no saved inventory exists, Current returns inventory_revision_not_found. Your application can show “not synchronized yet” or request Refresh.

Pick a freshness policy

Use verified_at, age_seconds, and scan_window from Current rather than inventing freshness from your own cache time.

Examples:

• user-owned profile: serve Current immediately, offer a visible Refresh button when older than your product target;
• bot decision: require a bounded maximum age, submit Refresh when too old, and defer the decision until completion;
• background index: schedule Refresh with jitter, then process only a newly observed revision_id;
• progress UI: poll refresh status on your server and update the browser through your own application.

Spread scheduled refreshes over time instead of starting them all at the top of the hour. Limit simultaneous requests and give each workflow a deadline. Wait at least the Retry-After interval before polling again. Reuse the same idempotency key and inputs when retrying a POST whose result is uncertain; use a new key for a genuinely new refresh.

What a complete refresh includes

For TF2 440/2, SteamCall follows every Steam page and checks the collected inventory before saving it. A 100,000-item inventory takes about 50 source pages. Refresh collects them all even if your application later reads only two Current pages.

Simultaneous refreshes for the same inventory can share collection work. Each customer still has a separate refresh ID, access checks and billing result. Save your refresh_id to check your request's progress.

An incomplete or failed scan leaves the previous Current revision intact. If collection fails because of an infrastructure problem, the credit reservation is released. Keep the request ID and refresh ID for support, but never log the API key, authorization headers, or full inventory responses.

Billing behavior

The credit amounts below apply to prepaid funding. Subscription-funded Refresh uses fresh inventory units, with the same reservation and observed-asset counting rule. The operation does not consume both funding sources. See subscription allowances.

Refresh reserves 125 credits while it collects the inventory. A complete scan costs one credit per started 2,000 observed assets, with a minimum of 1 and a maximum of 125 credits. Unused reserved credits return to your available balance. SteamCall's retries do not increase the charge.

Confirmed private or not-found outcomes cost the one-credit diagnostic minimum. Unavailable, incomplete, cancelled and internal failures release the reservation. Check the status response's billing fields for the final charge and released credits; see Usage & credits for examples.

If you need only two pages directly from Steam and do not need a saved complete inventory, use two Live Page requests instead. Reading fewer Current pages does not reduce the cost of a complete Refresh.

Failure behavior in your application

Keep synchronization state beside the last usable revision:

Review Caching, Retries & timeouts, and the full integration guide together.

Receive refresh notifications

Where Events is enabled, use a signed webhook or authenticated Project stream to learn when a refresh reaches a terminal outcome. Correlate the notification's Refresh ID with the request you accepted, deduplicate by event ID, and inspect the outcome before reading Current. A terminal notification can describe a private or failed inventory; it does not contain the inventory or guarantee a successful refresh.

Keep bounded status polling as a fallback when Events is unavailable. After a disconnect or missed notification, follow Events recovery and reconcile refresh status before reading Current. Events is not generally available and does not provide Images preparation notifications.