Stigg REST API: money in full dollars not cents, plus auth and entitlement gotchas

TL;DR: GET /api/v1/subscriptions does not include subscriptionEntitlements per item (too expensive at scale). Context: Official docs (Stigg skills repo, stigg-api/SKILL.md): the auth/transport/SDK reference for Stigg's REST and GraphQL APIs. Documents three API key types, the money-amounts convention that inverts Stripe's, the two subscriptions/entitlements gotchas, an auth-failure diagnosis table, and the common mistakes list.

Context: Official docs (Stigg skills repo, stigg-api/SKILL.md): the auth/transport/SDK reference for Stigg's REST and GraphQL APIs. Documents three API key types, the money-amounts convention that inverts Stripe's, the two subscriptions/entitlements gotchas, an auth-failure diagnosis table, and the common mistakes list. REST base: YOUR_HOST.stigg.io/api/v1, auth header X-API-KEY.

Key things agents get wrong: 1. Money amounts are full dollars, not cents. 49 means $49.00, 3990 means $3,990. Stripe convention is the opposite (minor units). Do not multiply by 100 when handing values to Stigg, and do not divide by 100 reading them back. Applies to plan prices, charge amounts, cost_basis on credit grants, and subtotal/total/discount/tax on invoice previews. 2. GET /api/v1/subscriptions does not include subscriptionEntitlements per item (too expensive at scale). Use GET /api/v1/subscriptions/{id} for detailed entitlements. 3. subscriptionEntitlements on a single subscription is overrides only, not the full set inherited from the plan. For full plan entitlements call GET /api/v1/plans/{planId}/entitlements. 4. Key types: full-access server keys (server- prefix, backend only, automatically inherit new permissions, immutable scope), publishable client keys (client- prefix, read-only, immutable, safe for browsers/mobile with HMAC client-side hardening), and scoped server keys (Scale plan, least privilege, do not inherit future capabilities). Never put a server key in a frontend bundle; use environment variables on the server. 5. Auth diagnosis: 401 on everything means the header name is wrong (use X-API-KEY exactly, not Authorization). 401 only on POSTs means missing/wrong Content-Type. 403 means a scoped key lacks the resource permission. 6. Add Idempotency-Key to customer/subscription POSTs; Stigg caches the response 24h so retries are safe. 7. Rate limits are per-environment per-endpoint: handle 429 with backoff on production hot paths.

When to use

You hit exactly this: Stigg REST API: money in full dollars not cents, plus auth and entitlement gotchas in Stigg REST API.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Stigg REST API (versions mentioned here: 49.00, v1).

Official docs page: https://github.com/stiggio/skills/blob/HEAD/skills/stigg-api/SKILL.md. What it documents: Official docs (Stigg skills repo, stigg-api/SKILL.md): the auth/transport/SDK reference for Stigg's REST and GraphQL APIs. Documents three API key types, the money-amounts convention that inverts Stripe's, the two subscriptions/entitlements gotchas, an auth-failure diagnosis table, and the common mistakes list. REST base: https://api.stigg.io/api/v1, auth header X-API-KEY. The verified guidance distilled above: Key things agents get wrong: 1. Money amounts are full dollars, not cents. 49 means $49.00, 3990 means $3,990. Stripe convention is the opposite (minor units). Do not multiply by 100 when handing values to Stigg, and do not divide by 100 reading them back. Applies to plan prices, charge amounts, cost_basis on credit grants, and subtotal/total/discount/tax on invoice previews. 2. GET /api/v1/subscriptions does not include subscriptionEntitlements per item (too expensive at scale). Use GET /api/v1/subscriptions/{id} for detailed entitlements. 3. subscriptionEntitlements on a single subscription is overrides only, not the full set inherited from the plan. For full plan entitlements call GET /api/v1/plans/{planId}/entitlements. 4. Key types: full-access server keys (server- prefix, backend only, automatically inherit new permissions, immutable scope), publishable client keys (client- prefix, read-only, immutable, safe for browsers/mobile with HMAC client-side hardening), and scoped server keys (Scale plan, least privilege, do not inherit future capabilities). Never put a server key in a frontend bundle; use environment variables on the server. 5. Auth diagnosis: 401 on everything means the header name is wrong (use X-API-KEY exactly, not Authorization). 401 only on POSTs means missing/wrong Content-Type. 403 means a scoped key lacks the resource permission. 6. Add Idempotency-Key to customer/subscription POSTs; Stigg caches the response 24h so retries are safe. 7. Rate limits are