What to Cache
If your plan permits caching, the table below gives recommended TTL values based on how frequently each data type changes.| Data Type | Changes How Often | Recommended TTL |
|---|---|---|
| Exercise ID | Start of every week (Monday 00:00 UTC) | Under 7 days |
| Body parts, muscles, equipment lists | Rarely | 7 days or longer |
| Muscle visualization images | Per request | Duration of session |
| Media asset URLs (images, GIFs, videos) | Start of every week (Monday 00:00 UTC) | Under 7 days |
ExerciseDB V1 and V2
Exercise IDs and media asset URLs are rotated at the start of every week on Monday at 00:00 UTC. If your plan does not permit caching, these values can change at any point and should never be stored. If your plan permits caching, set your TTL to expire before Monday 00:00 UTC to ensure your cache stays valid. Any cached exercise IDs or media URLs that are not refreshed before rotation will return a404 error when accessed.
Media Assets
Media assets including images, GIFs, and videos are served directly from a CDN. Reference the URLs returned by the API in your app. You do not need to proxy or re-host them under standard plans. Since media URLs rotate alongside exercise IDs every Monday at 00:00 UTC, ensure you refresh cached URLs before that window.Muscle Visualizer
Generated muscle visualization images can be cached on your server for the duration of your active subscription. Storing the generated image and serving it from your own layer avoids regenerating the same visualization on every request.Cached Muscle Visualizer assets must not be served after your subscription ends.