Production patterns
How to run noxstock in real products without wasting quota or confusing users.
Keep keys server-side
Never call noxstock directly from browser JavaScript with a real API key. Put noxstock calls behind your backend, server action, API route, or agent runtime.
browser/app → your backend/agent → noxstock APICache by job type
Suggested starting points:
| Data | Suggested cache |
|---|---|
| Search/coverage | Hours to days |
| Snapshot during market hours | 30–120 seconds |
| Snapshot after close | 5–30 minutes |
| Fundamentals/valuation/dividends | 1–24 hours |
| Filings metadata/sections | Days to indefinite |
| Insider | 1–24 hours |
Use your own cache for user-facing repeat views. noxstock also has upstream caching, but your app should avoid needless requests.
Respect response headers
Authenticated requests include rate-limit headers when applicable:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed in the current minute window. |
X-RateLimit-Remaining | Requests left in the current window. |
X-RateLimit-Reset | Epoch timestamp when the minute window resets. |
Retry-After | Seconds to wait before retrying retryable errors. |
Batch carefully
noxstock does not expose a bulk endpoint today. If you need batch analysis:
- Use
/v2/coverageto filter symbols. - Limit concurrency.
- Cache results.
- Start with
/v2/snapshotand call deeper routes only for shortlisted symbols.
Handle slow SEC cold paths
EDGAR-backed routes can be slower on cold cache, especially for heavy filers:
/v2/profile/v2/filings/v2/filings/{accession}/v2/filings/{accession}/section/{name}/v2/insider
For UX, use loading states or background jobs for long filing/insider requests.
Do not hide caveats
If freshness is stale, degraded, or unsupported, surface that to users. It is part of the product contract.