API Keys: Create, Scope, and Rotate Safely

How to create, scope, and rotate CoreReflex API keys, authenticate requests securely, limit blast radius, and keep your generation pipeline locked down.

API keys are the credential your code uses to talk to the CoreReflex platform, every programmatic request that boards a film, renders a cut, or reads a job's status carries one to prove it is allowed to run. Treat each key like a production secret: give it the narrowest reach it needs, store it where humans can't casually copy it, and rotate it on a schedule. This guide covers how to create CoreReflex API keys, scope them to limit blast radius, and rotate or revoke them without taking your generation pipeline down.

How CoreReflex API keys work

CoreReflex ships a public API, an SDK, and an MCP server, so you can drive the entire studio from your own systems, the same agentic Director, the same edit-as-data JSON engine, and the same deterministic render path you use inside the app, all reachable from code. Every request to that surface is authenticated with an API key. On each call the server verifies the key is active, confirms it is authorized for the operation, and attributes the work, including any credits a generation spends, back to your account.

That attribution is why key hygiene is not optional. In CoreReflex, planning, scoring, and editing are free; only generation consumes credits. A key that leaks or carries more privilege than it needs is therefore both a data risk and a spend risk. If you are new to the surface, the API quickstart gets a first authenticated call working in a few minutes; this article is about doing it safely once you move past that first call.

Create an API key

You generate keys from your account, not from code, so the secret never has to be minted in a place that logs it.

  1. Open your CoreReflex dashboard and go to the API keys section under your account settings.
  2. Choose Create key and give it a descriptive name that says where it will run, for example ci-render-prod or zapier-staging. Future-you, staring at a list of keys during an incident, will thank present-you.
  3. Set the key's scope and the environment it belongs to (more on scoping below).
  4. Copy the secret immediately. For security, the full key value is shown once at creation and stored only as a hash afterward, if you lose it, you rotate rather than recover.
  5. Paste it straight into your secret manager, never into a file, a chat message, or a commit.

Name keys per integration and per environment rather than sharing one "god key" across everything. A separate key for CI, for your production worker, and for each third-party automation means you can revoke one without disrupting the others, and you can read usage per key to see exactly what each integration is doing.

Scope a key to limit blast radius

Scoping is the practice of giving a key only the permissions its job requires, least privilege applied to automation. The goal is blast-radius control: if a key is exposed, what is the worst it can do?

Think about scope along a few axes:

  • Operation. A reporting dashboard that only reads render job status does not need permission to start generations. A key that only polls and downloads finished assets cannot run up your credit bill if it leaks.
  • Environment. Keep production and staging keys separate so a test harness can never touch live data or live spend.
  • Integration. One key per consumer keeps usage legible and revocation surgical.

The discipline is simple: start from the smallest set of permissions that lets the integration work, and add only when something breaks. A narrowly scoped, read-only key in a marketing dashboard is a non-event if it ends up in a screenshot; a broad key that can trigger generation is an incident. Pair tight scopes with the budget controls in our guide to API credits and cost control and a leaked key's damage is bounded on both the permission and the spend side.

Store keys securely

A perfectly scoped key is still a liability if it sits in plaintext somewhere shared. The fixes are well-worn because they work:

  • Use a secret manager or your platform's encrypted environment variables. Reference the key at runtime; never hard-code it.
  • Keep keys out of source control. Add .env to .gitignore, and scan your history so an old key isn't sitting in a commit from six months ago.
  • Never expose a key in client-side code. Browser and mobile bundles are readable by anyone. Calls that carry your secret belong on a server you control, which then talks to the CoreReflex API.
  • Don't paste keys into logs, error trackers, or support tickets. Redact them the way you would a password.

If a key ever lands somewhere it shouldn't, a public repo, a shared doc, a forwarded email, treat it as compromised and rotate immediately, there is no such thing as a partial leak.

Rotate and revoke keys safely

Rotation is replacing a key with a fresh one on a schedule, so that even a quietly compromised secret has a short useful life. Revocation is killing a key immediately because it is exposed or no longer needed. Because CoreReflex lets you hold multiple named keys at once, you can rotate with zero downtime.

To rotate without an outage:

  1. Create the new key with the same scope as the one it replaces, and name it clearly (ci-render-prod-2026q3).
  2. Deploy the new key into your secret manager and roll it out to the integration.
  3. Verify the integration is making successful calls on the new key, watch the per-key usage to confirm traffic moved.
  4. Revoke the old key once you see no more traffic on it.

Schedule this on a regular cadence, and trigger it immediately on any of these events: a key may have leaked, a teammate with access leaves, or an integration is decommissioned. To revoke, delete the key in the dashboard; the next request it makes fails authentication instantly. Because you scoped and named keys per integration, revoking one never cascades into the others.

A good test of your setup: could you revoke any single key right now and know exactly which integration goes dark, with a replacement ready? If yes, your key hygiene is production-grade.

Put it to work

Once keys are created, scoped, and on a rotation schedule, the rest of the platform opens up cleanly, you can generate a film from one sentence over the API, poll the render queue, and pull finished assets, all under credentials you can reason about. For the full endpoint reference and SDK details, see the developer docs, and browse the rest of the developer blog for deeper guides on the JSON engine, render jobs, and cost control.

Frequently asked questions

How do I create a CoreReflex API key?

Open the API keys section of your CoreReflex dashboard, choose Create key, give it a descriptive name and the narrowest scope it needs, then copy the secret. The full value is shown only once at creation, so paste it straight into your secret manager. Keys are minted in the dashboard rather than via code, so the raw secret never passes through a system that might log it.

How do I rotate or revoke an API key?

To rotate, create a new key with the same scope, deploy it, confirm traffic has moved using the per-key usage view, then revoke the old one, because CoreReflex supports multiple active keys. This is zero-downtime. To revoke, delete the key in the dashboard; its next request fails authentication immediately. Rotate on a schedule and revoke on the spot whenever a key may be exposed.

What scope should I give an API key?

The least it needs to do its job. A dashboard that only reads job status should get a read-only key; only a worker that actually triggers generation needs that permission. Keep separate keys per environment and per integration so a single exposed key has a small, well-understood blast radius.

Will using the API cost credits?

Only generation costs credits, planning, scoring, and editing are free, the same as in the app. Reading job status, listing assets, and editing your project as data don't spend credits, so a read-only key carries no spend risk. See the pricing page for how credits work.

What happens if my API key leaks?

Treat it as compromised and rotate it immediately: create a replacement, move your integration over, and revoke the exposed key so its next call fails. If the key was tightly scoped, read-only, single-environment, the exposure is contained to that narrow surface, which is exactly why scoping matters before anything goes wrong.

Lock it down, then build

Secure key management is the unglamorous foundation under everything else you do with the platform, get create, scope, and rotate right once, and you can wire CoreReflex into CI, automations, and your own apps without losing sleep over the credentials. Start free with no credit card, create your first scoped key, and build a generation pipeline you can actually trust in production.

Share this article

Pass it to someone who is still editing by hand.

Ready to direct your own film? It is free to start — no credit card.

Start free

← All articles