# Data And Integrations

## Steam Web API

The MVP should use the Steam Web API for reliable owned-game import. Users should be guided through supplying their own Steam Web API key.

Relevant Steam API areas:

- Resolve vanity URL to Steam ID.
- Fetch owned games.
- Fetch player summaries.
- Fetch recently played games, if useful.

Known limitation: Steam library data may not be available when the user's profile or game details are private. Private-profile fallback import is out of scope for the MVP.

## SteamDB Consideration

SteamDB can be investigated as an alternative metadata source only after confirming availability, terms, and suitability. It should not be assumed as a replacement for the Steam Web API until that validation is complete.

## Steam Store Metadata

Steam store endpoints may be useful for metadata such as:

- Header images
- Genres
- Categories
- Short descriptions
- Release date

These endpoints should be cached locally and refreshed conservatively.

## Completion Time Data

Estimated game length is required for the MVP recommendation flow.

Preferred direction:

- Use a HowLongToBeat-compatible API or library after validating terms, maintenance status, and package quality.
- Cache estimates locally with source and confidence fields.
- Do not allow manual metadata editing in the MVP.

The project should avoid depending on an unofficial or license-unclear source without documenting the risk.

## Local Storage

Use SQLite for durable local data.

The app should support:

- Local-only operation after import.
- Metadata caching.
- Local settings.
- Resetting cached metadata.

Manual data import/export is out of scope for the MVP.

## Privacy

Default privacy posture:

- Store user data locally.
- Do not create a hosted account for MVP.
- Do not transmit the user's library to third-party services beyond the configured metadata providers required for the recommendation flow.
- Document which Steam API calls are made.
- Do not collect telemetry in the MVP.

## API Key Handling

The MVP should use user-provided API keys where required.

Credentials should not be stored as plain text if the platform provides a practical secure storage option.

Preferred order:

- Use OS-provided credential storage through a Tauri-compatible plugin or Rust crate.
- Fall back to a clearly documented local settings file only during early development.
- Never commit real API keys.

No hosted proxy service is planned for the MVP.