How to Integrate the ExerciseDB API (2026)

ExerciseDB gives you a searchable library of exercises — each with a name, target muscle, body part, required equipment, and an animated gifUrl demo — over a plain API-key REST interface. There is no OAuth, no token exchange, and no callback URL: you subscribe on RapidAPI, then send your key in two request headers. It is the simplest integration in the fitness-API stack, and this guide walks you from subscription to your first exercise query.

Heads up: "ExerciseDB" is two different things

Before you write any code, know that the name ExerciseDB is ambiguous and points at two separate products that even share the same media CDN:

1. The commercial RapidAPI listing — host exercisedb.p.rapidapi.com, accessed with a RapidAPI key. This is what most tutorials (and this one) mean, and it is the fastest way to get running.
2. The open-source exercisedb.dev project — github.com/ExerciseDB/exercisedb-api, AGPL-3.0 licensed and self-hostable. It exposes its own endpoint shapes (its own /api/v1-style routes), which do not match the RapidAPI paths below.

Pick one and code strictly to its docs. Do not assume a path from one works on the other. This guide covers the RapidAPI listing; see the self-host section near the end if you would rather avoid marketplace billing and rate limits. For a wider comparison of options, see our exercise database APIs roundup.

What you'll need

• A RapidAPI account (free to create).
• A subscription to the ExerciseDB listing on RapidAPI — even the free tier requires subscribing so your key is authorized for the API.
• Your RapidAPI key, which RapidAPI issues per account and shows on the listing's endpoint page.

That is the whole checklist. No app-approval step, no partner program.

Step 1: Subscribe on RapidAPI and copy your key

Sign in to RapidAPI, open the ExerciseDB listing, and subscribe to a plan (a free tier exists but is small — see the pricing note below). Once subscribed, the listing's "Endpoints" tab shows your X-RapidAPI-Key value. Every request you make will carry two headers:

• X-RapidAPI-Key: YOUR_RAPIDAPI_KEY
• X-RapidAPI-Host: exercisedb.p.rapidapi.com

The host header is required by RapidAPI on every proxied call — omitting it returns an error even when the key is valid.

Step 2: Make your first request

Fetch exercises for a body part. The bodyPart path segment accepts values like back, chest, legs, and so on:

curl -X GET 'https://exercisedb.p.rapidapi.com/exercises/bodyPart/back?limit=10&offset=0' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: exercisedb.p.rapidapi.com'

The same in JavaScript with fetch:

const res = await fetch(
  'https://exercisedb.p.rapidapi.com/exercises/bodyPart/back?limit=10&offset=0',
  {
    method: 'GET',
    headers: {
      'X-RapidAPI-Key': process.env.RAPIDAPI_KEY,
      'X-RapidAPI-Host': 'exercisedb.p.rapidapi.com',
    },
  }
);
const exercises = await res.json();

Each exercise object returns these fields:

Newer versions of the listing may also include secondaryMuscles and instructions arrays — verify against the current listing before relying on them.

Step 3: Query by the axis your app needs

The listing exposes a small, predictable set of endpoints. The three you will use most:

For example, pull every exercise that targets a specific muscle:

curl -X GET 'https://exercisedb.p.rapidapi.com/exercises/target/biceps?limit=10&offset=0' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: exercisedb.p.rapidapi.com'

GET /exercises and the filtered endpoints accept limit and offset pagination params — verify the current defaults and maximums on the listing, since a bare GET /exercises can otherwise return a large payload. The listing also documents additional filter and list endpoints (by equipment, by name, by id, and list-of-values helpers like body parts and targets); confirm their exact paths on the current listing before wiring them in, as they have varied across versions.

Step 4: Cache the catalog and display the GIFs

ExerciseDB data is a reference catalog — it changes rarely — so treat it that way:

• Cache aggressively. Fetch once, store the exercises in your own database, and refresh on a schedule rather than calling the API on every user request. This is the single biggest lever on both latency and your rate-limit budget.
• Serve gifUrl through your own layer (proxy or re-host where the license allows) so a change to the upstream CDN does not break your UI.
• Key your local records on id so you can map favorites, workout plans, and history to a stable reference.

With the catalog cached, wiring it into a workout builder is straightforward — see our guide to building a strength-training app for how the exercise catalog, sets/reps, and progression fit together.

Self-hosting alternative: exercisedb.dev

If the RapidAPI free tier is too small or you want to avoid marketplace billing and rate limits entirely, the open-source project is a real alternative:

• Repo: github.com/ExerciseDB/exercisedb-api, licensed AGPL-3.0.
• Advertises 11,000+ exercises with videos, images, and GIFs — verify the current count.
• Exposes its own route shapes (documented at oss.exercisedb.dev/docs), which differ from the RapidAPI paths above.

The trade-off: you host and maintain it yourself, and AGPL-3.0 has obligations you must comply with (notably, making source available for network-served modifications). Read the license before shipping.

Gotchas and production notes

• Free tier is tiny. The free RapidAPI plan has been reported at roughly ~10 requests/day — enough to prototype, not to run in production. Exact tier names, monthly caps, and per-second limits change on the listing, so verify against the current RapidAPI pricing page and plan around caching.
• Both headers are mandatory. Missing or wrong X-RapidAPI-Host fails the request even with a valid key.
• Don't mix the two ExerciseDBs. RapidAPI paths will not work against a self-hosted exercisedb.dev instance, and vice versa.
• Keep your key server-side. Never ship X-RapidAPI-Key in client-side web code; proxy requests through your backend.
• Field list can drift. Treat secondaryMuscles/instructions and the extra filter endpoints as "verify against current docs" rather than guaranteed.

For where ExerciseDB fits among other catalog and movement-data providers, see our exercise database APIs comparison.