API Keys Overview

Key Types#

RenderStack has four API key types, each designed for a specific use case:

Type	Prefix	Use Case
Master	rs_live_	Full server-side access — render any template, list templates, read render history
Project	rs_live_	Scoped server-side access for a specific project or integration
Read-only	rs_live_	Can call render endpoints and read data, but cannot modify templates or settings
GET	rs_get_	Dynamic image URLs embedded directly in HTML <img> tags

Master Keys#

Master keys provide full API access across all /api/v1 endpoints. Use them for trusted server-side integrations — your backend, automation pipelines, or CI workflows — where the key is never exposed to end users.

Project Keys#

Project keys are scoped to a specific template or context. They are ideal when you want to give a service access to render one template without exposing your entire account.

Read-only Keys#

Read-only keys can call render endpoints and retrieve data but cannot create or modify templates, assets, or settings. Use these for semi-trusted environments or read-heavy integrations.

GET Keys#

GET keys (prefix rs_get_) are designed exclusively for the GET /api/v1/render endpoint — the dynamic image URL endpoint. The key is passed as a query parameter directly in the URL:

<img src="https://renderstack.io/api/v1/render?apiKey=rs_get_...&template=social-card&title.text=Hello+World" />

Because GET keys are visible in URLs and browser source, they have restricted access — they can only call the GET render endpoint and nothing else. You must configure at least one Allowed Host in Settings before GET key requests are accepted. This prevents unauthorized domains from using your key to generate images at your expense.

Creating an API Key#

1. Navigate to API Keys in the sidebar
2. Click Create API Key
3. Enter a descriptive name (e.g., "Production Server", "Email Campaign Worker", "Blog Image Embed")
4. Select the key type that matches your use case
5. Click Create Key

Important: Your full API key is shown only once, immediately after creation. Copy it and store it securely — in an environment variable, a secrets manager, or your CI secret store. After you dismiss the dialog, only the key prefix is visible. The full value cannot be retrieved again.

Using Your API Key#

POST requests — server-side rendering#

For Master, Project, and Read-only keys, pass the key in the Authorization header:

curl -X POST https://renderstack.io/api/v1/renders/sync \
  -H "Authorization: Bearer rs_live_..." \
  -H "Content-Type: application/json" \
  -d '{"template":"social-card","layers":{"title":{"text":"Hello World"}}}' \
  --output result.png

In application code (Node.js):

const response = await fetch('https://renderstack.io/api/v1/renders/sync', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer rs_live_...',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    template: 'social-card',
    layers: {
      title: { text: 'Hello World' },
    },
  }),
});
const imageBuffer = await response.arrayBuffer();

GET render — dynamic image URLs#

For GET keys, pass the key as a query parameter:

<img src="https://renderstack.io/api/v1/render?apiKey=rs_get_...&template=social-card&title.text=Hello+World" />

Requests must originate from a domain listed in your Allowed Hosts configuration. Requests from unlisted domains are rejected with a 403 error. See Allowed Hosts Configuration for setup instructions.

Identifying Keys by Prefix#

Prefix	Type
rs_live_	Master, Project, or Read-only
rs_get_	GET (dynamic image URL)

The key prefix (e.g., rs_live_abc1) is always shown in the API Keys list so you can identify each key at a glance without exposing the full secret.

Security Best Practices#

• Never put Master or Project keys in client-side code, browser JavaScript, or mobile apps. These keys must stay server-side.
• Store keys in environment variables — not in source code or config files checked into version control.
• Use GET keys for public-facing image URLs — they are the only key type designed for browser exposure, and only when paired with Allowed Hosts.
• Name keys descriptively so you can identify which service or integration each key belongs to.
• Create one key per service — this way you can revoke a single key if a service is compromised without disrupting other integrations.
• Rotate keys periodically — create a new key, update your configuration, then revoke the old key.

Revoking and Deleting Keys#

Revoking#

Revoking a key immediately invalidates it. Any request using a revoked key returns 401 Unauthorized. The revoked key remains visible in the list (showing its name, prefix, and creation date) as an audit record.

To revoke: open API Keys, find the key, click Revoke, and confirm.

Deleting#

Deleting permanently removes a revoked key and all its records. This cannot be undone.

To delete: revoke the key first, then click Delete.

Permissions#

Action	Owner	Admin	User	Viewer
Create API keys	Yes	Yes	Yes	No
View own keys	Yes	Yes	Yes	No
View all org keys	Yes	Yes	No	No
Revoke any key	Yes	Yes	No	No
Delete any key	Yes	Yes	No	No

Users can only see and manage the keys they created. Owners and Admins can view and manage all keys across the organization.

Allowed Hosts (GET keys)#

Allowed Hosts restrict which domains may embed your GET-type keys. Without at least one Allowed Host configured, all GET key requests are rejected.

To configure:

1. Go to Settings in the sidebar
2. Find the Allowed Hosts section
3. Add every domain that embeds your dynamic image URLs (e.g., example.com, app.example.com, staging.example.com)
4. Save

The check uses the Referer and Origin headers of the incoming request. Include all environments — production, staging, and any preview domains — where your <img> tags appear.