Complete examples

One program per language, written the way you would ship it: the token read from the environment, a 429 waited out, and any other error failed loudly with the sentence the API sent. The Node version also sends the ETag back, so an unchanged tokens file is not written twice.

The program

Pick a language in the sidebar or above the code. Every version reads the manual called acme; replace it with the slug the dashboard prints for yours under API (opens in a new tab).

export STYLEHUB_TOKEN=sh_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# The manual
curl -sS https://stylehub.cloud/api/v1/manuals/acme.json \
  -H "Authorization: Bearer $STYLEHUB_TOKEN" | jq '.title, .sections[].title'

# Design tokens, straight into a file a build can read
curl -sS https://stylehub.cloud/api/v1/manuals/acme/tokens.json \
  -H "Authorization: Bearer $STYLEHUB_TOKEN" \
  -o tokens.json

# The manual as a PDF
curl -sS https://stylehub.cloud/api/v1/manuals/acme.pdf \
  -H "Authorization: Bearer $STYLEHUB_TOKEN" \
  -o acme.pdf

# Just the headers: the limit, what is left, and when it turns
curl -sS -D - -o /dev/null https://stylehub.cloud/api/v1/manuals/acme.json \
  -H "Authorization: Bearer $STYLEHUB_TOKEN" | grep -i "x-ratelimit\|etag"

Four habits worth keeping

• Read the token from the environment. Never from a file in the repository, and never from anything a browser downloads. How tokens are made and revoked is on Authentication.
• Obey Retry-After. A fixed sleep is a guess; the number in the header is the seconds until the window turns. See Rate limits.
• Send the ETag back. Most builds run far more often than the manual changes. A 304 still counts as a request, but it carries no body. See Caching.
• Fail loudly on 401 and 403. Those are configuration mistakes: the answer will not change until the token or the manual does. Every error sentence is listed on Errors.