Quickstart

Add a dynamic muscle diagram to your app with a single image URL — no SDK, no image processing, no bundled artwork.

A request is a URL. There is no SDK to install, no build step, and no component — if your platform can render an image from a URL, the integration is complete.

Front Back

A male figure, front view, with the biceps highlighted as secondary muscles.

The same figure from behind, with the lats highlighted as the primary muscles.

Same URL, one word apart. Demo images carry a watermark. Images on your own key do not.

Build an image URL

/v1/{key}/body/{figure}/{side}.webp

segment	values
`key`	your publishable key, from the portal
`figure`	`male` or `female`
`side`	`front` or `back`

These URLs cache normally in browsers and in any CDN you put in front of them. The format is in the path rather than an Accept header.

There is no default figure — omitting it is refused rather than answered with a body you did not choose.

Highlight muscles

Pass a comma-separated list to primary, and optionally secondary:

/v1/{key}/body/male/front.webp?primary=pectorals&secondary=delts

The catalogue and the artwork need no mapping layer between them. The names are the same ids the data API returns: pectorals in /v1/muscles is ?primary=pectorals here.

Read them rather than typing them, and a muscle added after you integrate needs no change from you:

curl 'https://api.gymassets.dev/v1/muscles?figure=male&side=front' \
  -H "Authorization: Bearer $GA_SECRET_KEY"

Each record’s drawn field says which figures and sides can highlight it. A picker can offer only what will light up.

Naming a muscle the sheet does not draw is not an error — the image returns 200 with an x-muscles-not-drawn header listing what it could not show. If a name is misspelled it also comes back in x-muscles-unknown. A typo and a muscle that view does not have are reported separately.

Serve the right image size

Request the image at the size your interface actually needs, from a list thumbnail to a workout summary. w sets the rendered width in pixels:

/v1/{key}/body/female/back.webp?primary=lats&w=480

It defaults to 176 and is clamped: ask for more than the maximum and you receive the maximum rather than an error.

Crop to the highlight

crop=primary trims to the highlighted region, which is what you want for an avatar or a dense list rather than a full figure:

/v1/{key}/body/male/front.webp?primary=biceps&crop=primary&w=96

What protects your publishable key

A publishable key is meant to be visible. It appears in page source by design, and what protects it is not secrecy:

requests are restricted to the domains you list
requests are rate-limited per key
consumption is capped by your monthly allowance

A request from an origin you did not allow is refused before it is counted.

Each response states how long it can be reused — see caching.

Which host to use

The examples above are paths. Images are served from cdn.gymassets.dev, and the data API answers on api.gymassets.dev:

https://cdn.gymassets.dev/v1/{key}/body/male/front.webp?primary=pectorals
https://api.gymassets.dev/v1/muscles