Go-live checklist

Check these before your integration renders for real: key handling, safe retries, polling, storing images and every error.

Updated

Keys

  • Secret keys live on servers only. Read them from an environment variable or a secret manager, never from code, a repository or a web page.
  • One key per system. Name each one for what uses it, so you can revoke one without stopping the rest.
  • Secret scanning is on. Your repositories flag a committed key before it ships. See Catch leaked keys.
  • Rotation is rehearsed. Know who can create and revoke keys, and rotate one once before you need to. See Rotate a key.

Requests and retries

  • Every render request has an Idempotency-Key. Stored with the job and sent again on any retry. See Idempotent requests.
  • Errors branch on type, not message. Messages are written for people and may change. See Errors and status codes.
  • 429s wait for Retry-After. And 5xx errors retry with a growing wait, but only for requests that are safe to resend.
  • Timeouts are generous. Allow at least 60 seconds for a request that uploads a room picture or queues a large batch.
  • Renders go in batches. Up to 100 in one request, charged together. See Render in batches.

Results

  • Scenes are ready before you render. Wait for status: "ready", and handle failed by trying a clearer room picture.
  • Polling backs off and has a deadline. See Poll for results.
  • Failed renders are handled. Log the render’s error and send it again if it is worth another try; the failed one cost nothing.
  • Unknown statuses are tolerated. Treat a status you do not recognise as still in progress, so a new one never breaks your code.

Images

  • Images are downloaded and stored. An image link lasts at least 30 days, not forever. Copy each finished image to your own storage, DAM or CDN as soon as its render completes. See Image output and links.
  • Render ids are kept. Store each render’s id beside its image, so you can fetch a fresh link or trace a question back to it.

Credits and spend

  • Credits are checked before big jobs. Call Retrieve your account before a large batch, and pause on insufficient_credits rather than retrying.
  • Someone is told when credits run low. Alert your team when credits.remaining falls below what a normal week of rendering uses.
  • Only what you need is queued. Cancel queued renders you no longer want, for their credits back.

Website visualizer

  • Only your real sites are listed. List every website the visualizer appears on, including any staging site you test on, and nothing else. See Install the visualizer.
  • Limits are set to your budget. Set the monthly picture limit to what you are happy to spend. See Visualizer settings and limits.

Before your first large run

Something these pages do not answer? Email admin@skipshoot.com and we’ll help.