Reforger Mods API Integration Guide
Build an integration that behaves well in production: choose the right endpoints, follow pagination links, cache responses, identify your client, and handle every response state cleanly.
Endpoints in one look
GET /v1/health process health, no Workshop data
GET /v1/mods first page of mod previews
GET /v1/mods/{page} specific page (positive integer)
GET /v1/search?search={query} convenience alias for first-page search
GET /v1/mod/{mod_id} full detail for one mod
GET /v1/rate-limits current public or API-key rate limit
GET /v1/refresh/jobs/{id} status of a background refresh job
List endpoints accept search, sort, and Workshop tag filters through tags or the single-value category alias.
Pagination
List responses include meta and ready-built links.next / links.prev URLs. Follow the links instead of reconstructing URLs yourself.
Identify your client
Send a User-Agent or X-API-Client header that names your project and gives a way to reach you.
For paid access, send your API key with X-API-Key or Authorization: Bearer. Paid limits are shared across the account, and /v1/rate-limits reports the active plan for the key.
User-Agent: my-server-panel/2.1 (+https://example.com; [email protected])
Cache like you mean it
- Honor
Cache-Control,Age, andETag. - Send
If-None-Matchwith the lastETagto get cheap304 Not Modifiedresponses. - Use
X-Cacheto understand whether you received aHIT,STALE, or fresh response. - Do not vary query strings just to bust caches; it wastes your rate budget and refresh capacity.
Handle every status
200- Use the data.
202- Cold cache. Wait
Retry-Afterseconds and retry the same URL with a bounded attempt count. 304- Your cached copy is still valid.
404- The mod or page does not exist. Cache the negative result briefly.
429- You exceeded the rate limit. Back off for
Retry-After. 5xx- Treat as temporary; retry with backoff and surface a friendly error.
All errors include a requestId. Log it and include it when reporting support issues.