Operating limits

Three things govern how much and how fast you can render: credits (the billing unit), the Idempotency-Key header (retry safety), and rate limits (the per-key throughput cap).

Credits

Each successful POST /v1/render deducts 1 credit, debited after the render succeeds — a failed render is not charged. When the account balance hits zero, requests return 402 insufficient-credits; top up to continue (this is distinct from 403, which is a lapsed subscription, not an empty balance).

For batches, an account without enough credits is rejected before any row renders — the batch status reports rejectedReason: "insufficient-credits".

Idempotency — retry-safe renders

Supply an Idempotency-Key header to make retries safe:

curl -sS -X POST "https://api.lemtika.com/v1/render" \
  -H "Authorization: Bearer $LEMTIKA_API_KEY" \
  -H "Idempotency-Key: launch-day-og-001" \
  -H "Content-Type: application/json" \
  -d '{ "templateId": "tmpl_og_card", "values": { "headline": "Launch day" } }' \
  -o render.png

• The key is echoed back in the response headers.
• A retry with the same key returns the original render's bytes (re-streamed) and is not charged again (debit-after-success means the original charge stands once).
• A keyless retry is treated as a brand-new render — a fresh charge.

This makes 503/504 retries safe: send the same key so a retry that already succeeded server-side isn't double-charged. Outputs are retained briefly so a same-key retry can be re-streamed.

Rate limits

Each key has a per-key request rate limit (a safety valve — programmatic renders share capacity with the web app). Every request is counted. Exceeding the window returns 429 rate-limited with a Retry-After (seconds) header; retry after that interval.

Two response headers help you stay under the cap:

Header	Meaning
x-ratelimit-remaining	Requests left in the current window, observed at auth time.
Retry-After	Seconds to wait after a 429, before retrying.

See Errors for the full status table.