Getting started

Authentication

Every call to the Renderly API is authenticated with an API key from your organization. The key identifies who you are, which organization you belong to and which quota the render is counted against.

API keys

Production keys have the rndr_live_ prefix followed by a random string. Each key belongs to an organization; a render made with it counts toward that organization’s monthly quota and is recorded in its usage history. You create, list and revoke keys in the Dashboard.

The key is shown only once
At creation time we show the raw key once. After that we keep only the SHA-256 hash — we can’t recover it. If you lose it, revoke it and generate a new one.

How to send the key

Renderly accepts two equivalent headers. Use either one — pick whichever fits your HTTP client best.

Option A — Authorization: Bearer

The industry standard. Prefix the key with Bearer .

Authorization: Bearer
curl -X POST https://api.renderly.dev/v1/render \
  -H "Authorization: Bearer rndr_live_YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<h1>hi</h1>" }' --output out.pdf

Option B — X-API-Key

A dedicated header, no prefix. Handy when the client already uses Authorization for something else, or with gateways that reserve that header.

X-API-Key
curl -X POST https://api.renderly.dev/v1/render \
  -H "X-API-Key: rndr_live_YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "html": "<h1>hi</h1>" }' --output out.pdf
HeaderFormatWhen to use
AuthorizationBearer rndr_live_...Recommended default, compatible with most SDKs.
X-API-Keyrndr_live_...Direct alternative, no prefix.

Key security

The rndr_live_ grants full access to your organization. Treat it like a password.

DoDon’t
Load it from an environment variable / secret managerCommit the key to Git
Use it only on the back end (server)Expose the key in front-end code or a mobile app
One key per environment (dev, staging, prod)Share the same key across projects
Revoke it immediately if you suspect a leakLeave old keys active “just in case”
Rotate it periodicallyLog the key in plain text
Best practice — key via env
// Read from the environment; never hardcode the key in your code.
const RENDERLY_KEY = process.env.RENDERLY_API_KEY

const res = await fetch("https://api.renderly.dev/v1/render", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${RENDERLY_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ template: "invoice", data: { total: "$99.00" } }),
})
What we store
We store only the SHA-256 hash of the key and metadata (creation date, last use, status). Full details of our security posture are on the Security & Trust page.

Revocation and rotation

Revoking a key is instant: from the moment of revocation, any request made with it gets a 401 invalid_api_key. To rotate without downtime: generate the new key, update your secrets, deploy, and only then revoke the old one.

Authentication errors

Auth failures return a 401 with a JSON body in the format { error: { code, message } }.

No key — missing_api_key

Neither header was sent.

401 missing_api_key
{
  "error": {
    "code": "missing_api_key",
    "message": "Send your API key in Authorization: Bearer ..."
  }
}

Invalid or revoked key — invalid_api_key

The key doesn’t exist, is malformed or has been revoked.

401 invalid_api_key
{
  "error": {
    "code": "invalid_api_key",
    "message": "Invalid or revoked API key."
  }
}
HTTP statuscodeTypical cause
401missing_api_keyAuthentication header missing.
401invalid_api_keyKey nonexistent, malformed or revoked.
402quota_exceededThe key is valid, but the organization’s quota is used up.

The full list of API errors is on the Errors page.

Next
Render endpoint
Every body parameter, PDF/PNG options and complete examples.