|
| 1 | +# Documentation Hub |
| 2 | + |
| 3 | +This SDK already ships a broad surface. The fastest way to make it usable is not |
| 4 | +to make the main README even longer, but to give users a clear map. |
| 5 | + |
| 6 | +If you are reading this on npm: |
| 7 | + |
| 8 | +1. start with the repository README for the high-level pitch and install snippet |
| 9 | +2. use this `docs/` directory for task-oriented guidance |
| 10 | +3. use `API_COVERAGE.md` when you need endpoint-level truth |
| 11 | + |
| 12 | +## Start Here |
| 13 | + |
| 14 | +- [Getting Started](./getting-started.md) |
| 15 | + First install, API key setup, first requests, local verification. |
| 16 | +- [Resources And Workflows](./resources-and-workflows.md) |
| 17 | + Which SDK surface to use for market reads, account automation, loadouts, and higher-level helpers. |
| 18 | +- [Transport, Errors, And Metadata](./transport-and-errors.md) |
| 19 | + Retries, pacing, typed errors, and the new opt-in response metadata surface. |
| 20 | +- [Examples And Recipes](./examples-and-recipes.md) |
| 21 | + Examples, CLI commands, and which script to run for common tasks. |
| 22 | + |
| 23 | +## How To Read This SDK |
| 24 | + |
| 25 | +Use the SDK in three layers: |
| 26 | + |
| 27 | +1. `CsfloatSdk` resources for normal application code |
| 28 | +2. helpers/builders/workflows when you want less glue code |
| 29 | +3. `sdk.client.*WithMetadata()` when you need low-level response visibility |
| 30 | + |
| 31 | +## Where Different Kinds Of Truth Live |
| 32 | + |
| 33 | +- Product overview: `README.md` |
| 34 | +- Stable endpoint coverage notes: `API_COVERAGE.md` |
| 35 | +- Release history: `CHANGELOG.md` |
| 36 | +- Task-oriented usage: `docs/*.md` |
| 37 | +- Executable examples: `examples/*.mjs` |
| 38 | + |
| 39 | +## Should You Build A Separate Docs Site? |
| 40 | + |
| 41 | +Not yet, unless you are ready to keep GitHub, npm, and the site in sync. |
| 42 | + |
| 43 | +The better near-term strategy is: |
| 44 | + |
| 45 | +1. keep GitHub + npm-readable docs as the source of truth |
| 46 | +2. keep docs in Markdown inside the package repository |
| 47 | +3. only later add a Vercel-hosted site that reuses this same content |
| 48 | + |
| 49 | +That way npm users are not forced onto an external site just to understand the |
| 50 | +package, and a future docs site becomes a presentation layer, not a second |
| 51 | +documentation system. |
0 commit comments