How should I handle errors and statuses from the exercise API?
WorkoutDB returns standard HTTP status codes — 401 for a missing or invalid key, 404 for an unknown exercise, 429 when you exceed your quota — and every response includes a requestId you can log for tracing and support.
Predictable, traceable failures
Because the API follows HTTP conventions, your error handling is straightforward: treat 401 as an auth problem (check the X-API-Key header), 404 as a missing resource (verify the slug or id), and 429 as a quota signal (back off and retry, or upgrade). Success responses and errors share the same envelope discipline, so parsing stays uniform.
Every response carries a requestId. Log it on failures so that, if you need help, you can reference the exact request — and so you can correlate client behavior with your own observability.
- 401 — missing/invalid X-API-Key.
- 404 — unknown exercise slug or id.
- 429 — monthly quota exceeded; back off or upgrade.
- requestId on every response for tracing and support.
Related questions
- What does a 429 mean?
- You have exceeded your plan's monthly request quota. Implement a backoff and retry, or upgrade to a higher tier for more requests.
- How do I report a problematic request?
- Capture the requestId from the response and include it — it lets the exact call be traced quickly.
Build it on WorkoutDB
~873 exercises with demo video, ranked search, and four languages — over a clean REST API. Start free: 5,000 requests/month, no credit card.