EDB With Videos and Images by AscendAPI – Fitness Exercise Database Review

What the API does and who it is for

EDB With Videos and Images by AscendAPI solves a problem that trips up most fitness app developers early: sourcing and structuring exercise content. Cataloguing exercises from scratch—capturing muscle anatomy diagrams, filming demonstration videos, writing instructional copy, and tagging equipment—is months of content work. EDB ships all of that as a single REST API with over 11,000 exercises already structured and queryable.

The audience is essentially any developer building something fitness-related: a mobile workout tracker, a gym management SaaS, a personal-trainer scheduling tool, or a generative training-plan feature within a larger health app. The database is broad enough that niche use cases (calisthenics-only, rehabilitation-focused, equipment-specific) can be served by filtering rather than requiring custom data ingestion.

Endpoint walkthrough

The API exposes eight endpoints under the /api/v1/ path.

Reference / taxonomy endpoints

Four endpoints return lookup lists used to drive filters elsewhere:

• GET /api/v1/muscles — returns the full list of recognized muscle names.
• GET /api/v1/bodyparts — returns top-level body part categories (e.g., chest, legs).
• GET /api/v1/equipments — returns the equipment catalogue (barbell, resistance band, bodyweight, etc.).
• GET /api/v1/exercisetypes — returns exercise type classifications (strength, cardio, stretching, and so on).

These are inexpensive calls that you would typically make once on startup to populate filter UIs or validation logic. They consume your monthly quota like any other request, so caching the results in memory for the session lifetime (well within the permitted one-hour operational cache window) is the right approach.

Exercise retrieval endpoints

• GET /api/v1/exercises — the primary listing endpoint. It accepts filters, making it the workhorse for any browse-or-search feature. You would combine this with the taxonomy data above to let users drill down by body part, equipment, or exercise type.
• GET /api/v1/exercises/search — a dedicated search endpoint that accepts a query string. Useful for free-text search boxes where the user types a movement name rather than selecting from filters.
• GET /api/v1/exercises/{exerciseId} — fetches the complete record for a single exercise by its ID. This is where you get the full detail payload: muscle targets, equipment, images, GIF, video, and step-by-step instructions.

Operational endpoint

• GET /api/v1/liveness — a health-check endpoint. Useful for monitoring integrations or deployment pipelines that need to verify the API is reachable before serving traffic.

Performance characteristics

The API reports a 95 ms average latency and a 99% success rate across its subscriber base. For a media-rich API that returns video and image URLs alongside structured data, 95 ms is a solid baseline. In practice, your users' perceived latency will also include the time to load the image or video assets themselves (which are fetched directly from wherever AscendAPI hosts them), so design your UI to lazy-load or stream those assets rather than waiting on them before rendering exercise metadata.

Pricing breakdown

The free BASIC tier gives you 2,000 requests per month. That is enough for development and light prototyping—if your app makes roughly 65 API calls per day you will stay within the limit. It is not realistic for a production app with even modest user activity; a single user completing a 10-exercise workout session could trigger 10–15 API calls if each exercise detail is fetched individually.

The PRO tier at $100/month unlocks 80,000 requests. At that quota, a single-page detail fetch per exercise, you could serve around 8,000 complete workout sessions per month before hitting overage, or around 270 per day. The overage charge of $0.002 per request means each additional thousand requests beyond the cap costs $2, which is predictable and easy to model. If your app is data-intensive (pre-loading exercise libraries, supporting high-traffic fitness platforms), track your daily consumption early so the overage does not compound quietly.

Important usage constraints

Before integrating EDB With Videos and Images by AscendAPI into a production system, the terms of service impose a strict real-time access model that has concrete architectural implications:

• No persistent storage. You cannot save exercise data—text, images, GIFs, videos—to your own database, file system, or cloud storage. Every render of an exercise must result in a live API call.
• Cache window is one hour maximum for operational needs only. Session-level in-memory caching of taxonomy lists is fine; writing exercise records to Redis with a 24-hour TTL is not.
• Subscription termination immediately revokes all rights. If you stop paying, you must stop serving content and remove cached data within 24 hours. Design your app with this dependency in mind—there is no grace period for migrating off.
• No redistribution or sublicensing. You cannot repackage the exercise content for resale or share your API key with other services.

These constraints mean EDB With Videos and Images by AscendAPI is best suited for apps where the API call happens at display time, not apps that pre-download a workout library to support offline use. If offline capability is a hard requirement, this API's terms make that use case incompatible.

Practical use cases

• Workout builder apps: Use the filter endpoint to let users select exercises by body part and equipment, then pull full detail on demand when they tap into an exercise card.
• AI training plan generators: After an LLM or recommendation engine produces a list of exercise IDs, fetch the full metadata and media in real time to render the plan with visual content.
• Gym management platforms: Populate an exercise library browser for trainers writing client programs, fetching exercise detail each time a trainer previews a movement.
• Fitness content platforms: Render on-the-fly exercise encyclopedias or muscle-group guides using the taxonomy and listing endpoints to drive navigation.

Getting started

The API documentation lives at https://v2.exercisedb.dev. The free BASIC plan requires no upfront payment, making it straightforward to start experimenting. A sensible first integration sequence is: (1) call the four taxonomy endpoints to understand available filter dimensions, (2) use /api/v1/exercises with a body part filter to verify the response shape matches your data model, (3) call /api/v1/exercises/{exerciseId} on a few results to inspect the media payload and understand what image/video URLs look like, then (4) wire up the liveness endpoint to your deployment health checks before going to production.