What to Cache
If your plan does not permit caching, you must not store any data returned by the API. All requests must be made in real-time. If your plan permits caching, refer to the recommended TTL values below:| Data Type | Changes How Often | Recommended TTL |
|---|---|---|
| Exercise ID | Rarely | 7 days or longer |
| Body parts, muscles, equipment lists | Rarely | 7 days or longer |
| Muscle visualization images | Per request | Duration of subscription |
| Media asset URLs (images, GIFs, videos) | Weekly (Monday 00:00 UTC) | Under 7 days |
ExerciseDB V1 and V2
Exercise IDs are stable and do not rotate. You may treat them as permanent identifiers. Media asset URLs rotate every week on Monday at 00:00 UTC.- If your plan does not permit caching, media URLs can change at any time and should never be stored. Always fetch fresh URLs with every request.
- If your plan permits caching, you may cache media URLs, but you must set your TTL to expire before Monday 00:00 UTC to prevent broken links (404 errors).
Media Assets
Media assets (images, GIFs, and videos) are served directly from our CDN. You should reference the URLs returned by the API in your application. You do not need to proxy or re-host them under standard plans. Because media URLs rotate every Monday at 00:00 UTC, plans that allow caching must still refresh these URLs weekly.Muscle Visualizer
Generated muscle visualization images can be cached on your server for the duration of your active subscription if your plan permits caching. Caching these images helps avoid regenerating the same visualization on every request.Cached Muscle Visualizer assets must not be served after your subscription ends.