Provider keys need receipts, not vibes.

Last updated: 2026-06-25.

Audience: creators, operators, and small teams using paid AI media/API providers: avatar video, text-to-speech, image/video generation, model routing, transcription, or other credit-burning tools.

Promise: before a paid provider run, prove the account, key, route, spend boundary, rights posture, and task-relevant endpoint are actually ready — without leaking credentials or letting a goblin with a token discover billing by accident.

Ana version: the question is not “do we have an API key?” Cute. The question is “can this exact key, on this exact route, do this exact job inside the approved spend boundary, and leave a receipt?”

The blunt premise

Paid AI tools fail in boring, expensive ways:

• the web app has credits, but the API wallet does not;
• the key can list voices, but cannot read subscription details;
• the account is logged in under the wrong identity;
• the model exists, but not on the route your tool is calling;
• the provider changed a parameter, endpoint, rate, or plan rule;
• the render starts before anyone wrote down cost, output folder, or stop conditions;
• the artifact is “somewhere in the dashboard” instead of saved, hashed, and usable.

That is not innovation. That is an invoice demon with loading dots.

Use this checklist before any paid AI media/API run, provider upload, render/export, subscription change, wallet top-up, or key-scoped automation.

What this checklist is

This is a provider-neutral preflight for practical operators. It helps you verify:

1. Which account identity is being used.
2. Which billing lane funds the run.
3. Whether auto-renew, reload, or subscription state can surprise you.
4. Which key or session has the required scope.
5. Which endpoint/tool route will actually be used.
6. Whether rights, consent, provider terms, and output use are known enough for the job.
7. Which spend cap, stop condition, and receipt must exist before the run starts.

This is not legal advice, provider documentation, a pricing table, a security audit, or a claim that any provider endorses Ana, this resource, or your workflow. Provider facts change. For a provider-specific guide, read current official documentation and record the retrieval date.

Preflight contract: fill this before the run

Provider run preflight

Job name:
Provider:
Account identity label: <public-safe label, not real email if shared>
Route/surface: <web app / API / CLI / SDK / plugin / gateway / browser session>
Task endpoint/action: <the exact task, e.g. text-to-speech, voice list, avatar render, image generation>
Input asset(s): <script/image/audio/model prompt labels, no private paths in public copy>
Output folder/receipt target:
Expected output: <MP4/WAV/PNG/JSON/etc.>
Expected cost or credit use:
Approved spend cap:
Billing source: <subscription credits / API wallet / prepaid balance / invoice / free tier / unknown>
Auto-renew/reload state checked: yes/no/unknown
Key/session scope checked against the task endpoint: yes/no
Rights/TOS/consent notes:
Stop conditions:
Verification after run:
External side effects expected:
Approval status:

If any of those fields is “unknown” and the action can spend money, upload private assets, publish, change an account, or create an output you plan to use commercially, stop. The goblin does not get to improvise near billing.

The checklist

1. Account identity

• □ Name the account identity being used with a safe internal label.
• □ Confirm it is the intended identity for this project, client, brand, or experiment.
• □ Confirm you are not accidentally using a personal, legacy, client, or wrong-team account.
• □ Confirm the account has the needed workspace/project selected.
• □ Keep real account emails, account IDs, private dashboard screenshots, and session details out of public artifacts.

Good public-safe note:

“Using the approved project provider account; real email and workspace ID withheld.”

Bad note:

“Logged into <real account email omitted>, here is the dashboard screenshot and account ID.”

No. That is not transparency. That is leaving the office door on a billboard.

2. Payment, subscription, wallet, and billing lane

• □ Identify the billing lane funding this exact route: web subscription credits, API wallet, prepaid balance, invoice billing, free tier, trial credits, or unknown.
• □ Confirm whether web-app credits and API credits are the same pool or separate pools.
• □ Record the visible spend estimate or credit estimate before the run if the provider shows one.
• □ Record whether the run is allowed under the current approved budget.
• □ Do not buy credits, subscribe, upgrade, add payment, switch plans, enable auto-reload, or accept annual commitments unless explicitly approved.

HeyGen pitfall to remember: a web Creator/app credit lane and an API wallet/API plan can behave like separate lanes. A dashboard subscription may be ready for browser/web rendering while an API key still points at a different or low-funded API wallet. Inspect the exact route before assuming the credits transfer.

Provider-specific status for this pitfall: source-needed before public provider-specific tutorial unless current official HeyGen docs or support pages are cited with retrieval date. The general operating lesson is safe: web route readiness does not prove API route readiness.

3. Auto-renew, reload, and hidden spend controls

• □ Check whether auto-renew, auto-reload, usage-based billing, metered overage, queue retry, or background processing can spend after the first click.
• □ Record whether the account has an explicit per-run or weekly cap.
• □ For retry-prone jobs, set a retry budget before running anything.
• □ For long renders or async jobs, decide when to stop polling and when to declare the run unresolved.
• □ Treat failed renders and rejected jobs as spend-relevant until proven otherwise.

Safe wording:

“Spend cap approved for this run: one short test only; no top-up, no retry loop, no plan change.”

4. Key/session scope

• □ Identify whether the run uses an API key, OAuth app, browser session, CLI config, SDK auth, or provider-hosted integration.
• □ Confirm least privilege: the key/session should have what the task needs, not every admin permission because someone was impatient.
• □ Confirm the key/session belongs to the intended account lane.
• □ Do not print, paste, screenshot, or log credential values.
• □ Store raw credentials only in the approved private secret store; public docs should say capability, not value or storage path.

ElevenLabs pitfall to remember: an account/quota endpoint can fail because the key lacks user/account-read permission while task-relevant voice or text-to-speech endpoints still work. Do not declare the key useless just because a user/subscription endpoint fails. Validate the endpoint needed for the job.

Provider-specific status for this pitfall: source-needed before public provider-specific tutorial unless current official ElevenLabs API docs are cited with retrieval date. The general operating lesson is safe: account metadata scope and production task scope are not the same thing.

5. Task-relevant endpoint validation

Validate the route you will actually use, not a nearby route that feels comforting.

• □ If the job is TTS, test a voice/list or tiny TTS path according to current provider docs.
• □ If the job is avatar video, test the exact avatar/render endpoint or approved web flow.
• □ If the job is image generation, test the selected model/provider route, not a different model on the same dashboard.
• □ If the job is routed through a third-party model router, verify both the router key and the target model/provider availability.
• □ If the endpoint is async, verify submit, status, result/download, and failure payload handling.
• □ Record HTTP status, provider job ID label, or UI evidence in a private receipt without exposing tokens, real IDs publicly, or private dashboards.

The test should be the smallest meaningful probe. Five seconds of audio or a tiny draft image can answer a routing question without turning a wrong setting into a paid lesson with eyeliner.

Even tiny probes are still provider actions: if the probe can spend credits, upload an asset, create a remote job, or generate an output, run it only after the written provider/spend preflight is approved.

6. Provider route mismatch

Route mismatch is when the provider is “available” in one place and unavailable in the place your workflow calls.

Common mismatches:

• web app works; API route unfunded or not subscribed;
• API key works; browser session is blocked by MFA/CAPTCHA or workspace selection;
• SDK is installed; environment variable points at the wrong account;
• tool plugin uses a legacy endpoint while current docs moved the feature;
• model router supports a provider name but not the exact model/capability you need;
• UI offers a feature that the public API does not expose on your plan.

Checklist:

• □ Name the actual route.
• □ Name the backup route.
• □ Decide whether fallback is allowed before the run starts.
• □ If fallback changes cost, rights, output quality, account identity, or provider, get approval first.

7. Rights, consent, TOS, and commercial use notes

• □ Confirm you have the right to upload every input: scripts, images, voice, music, video, customer data, UI captures, brand assets, and references.
• □ Confirm whether output can be used commercially, internally, publicly, or only for testing.
• □ Confirm synthetic voice/avatar consent requirements before cloning, dubbing, or using a likeness.
• □ Do not use real-person likeness, customer data, third-party logos, platform screenshots, music, or stock assets without the right to use them.
• □ Record provider-specific rights/TOS as source-needed unless current official terms are cited with retrieval date.

Safe public note:

“Rights status: original script and approved project-owned avatar asset; provider terms need current official review before public/commercial use.”

8. Spend cap and approval gate

Before a paid or provider-side action, write the approval in boring language:

• □ Provider/surface.
• □ Exact input asset or prompt label.
• □ Expected duration/quality/model.
• □ Expected cost/credit use.
• □ Maximum spend cap.
• □ Billing lane.
• □ Output folder.
• □ Stop conditions.
• □ Whether the run is draft-only, review candidate, or final-public candidate.

Do not accept “run it and see.” That sentence is how dashboards become slot machines.

9. Failure logging

Every failed provider run should leave a receipt.

Record:

• provider and route label;
• task endpoint/action;
• input label;
• status/error category;
• whether any credit/cost was observed;
• whether a remote job/session/project was created;
• whether any upload happened;
• whether any public/share action happened;
• local artifact path or receipt label;
• next safe decision.

Use sanitized errors in public copy. Do not paste raw response bodies if they include tokens, account IDs, private URLs, signed asset links, or customer data.

10. Artifact receipt requirements

A provider job is not done because the dashboard smiled.

Before you call the run complete:

• □ Output file or provider link exists.
• □ Local copy saved where the team can find it, if allowed.
• □ File size recorded.
• □ SHA-256 or equivalent checksum recorded for local files.
• □ Media checked with a relevant tool: duration, dimensions, codec, sample playback, waveform, or image dimensions.
• □ JSON/config outputs syntax-checked.
• □ Provider job state recorded: completed, failed, cancelled, pending, or unknown.
• □ External side effects recorded: none, upload, render, export, public share, account change, spend, etc.
• □ Claims boundary written: what this proof does not prove.

Good receipt:

“Draft MP4 downloaded, duration/dimensions checked, checksum recorded, no public share, no account changes, one approved provider render consumed credits; quality still needs review.”

Bad receipt:

“Looks done in provider.”

Looks done is not a receipt. It is a screenshot with confidence issues.

Common failure modes and fixes

“The key works, but billing says no”

Likely cause: key belongs to a different billing lane, old account, free API tier, or unfunded wallet.

Fix: check account identity, route, billing lane, and a task-relevant endpoint. Do not top up or subscribe without approval.

“The account page fails, so the whole key must be bad”

Likely cause: the key lacks account metadata scope but still has task scope.

Fix: validate the endpoint needed for the job. Treat unrelated account/quota endpoints as account-read checks, not proof that TTS/render/generation is impossible.

“The web app works, but the API fails”

Likely cause: web credits and API wallet/plan are separate, or the API key is from another account.

Fix: choose the route explicitly. If the approved run is web app, do not silently switch to API. If the approved run is API, verify the API wallet/plan directly.

“The provider changed the API”

Likely cause: docs, endpoint schema, model names, or parameters drifted.

Fix: fetch current official docs, use schema-generated payloads where possible, and run the smallest meaningful test before the full job.

“The render failed and nobody knows if it cost money”

Likely cause: async job state, crash, missing after-balance evidence, or no receipt.

Fix: record before/after balance if visible, provider job status, local logs, and whether any remote job/session exists. Mark spend impact unknown until verified.

“We got an output, but cannot use it”

Likely cause: rights, consent, quality, watermark, missing commercial-use review, wrong format, or no local copy.

Fix: run rights/TOS check, media verification, and quality review before calling it usable.

Quick pre-run stoplight

If you cannot classify it, it is red until boring proof says otherwise.

Public-safe source notes

This first draft is based on internal Ana operating evidence and sanitized provider lessons from recent media/API setup work. Public-facing provider-specific claims are deliberately generalized. Before publishing a provider-specific version, attach current official source URLs and retrieval dates for provider pricing, API scopes, endpoint behavior, terms, output rights, and plan/billing rules.

Public-safe use note: replace internal file paths with labels, replace real account identifiers with placeholders, and do not include real balances, cards, tokens, secret paths, private browser profiles, customer data, or dashboard screenshots.

Public site package should include the checklist/table content only. Internal source-map and verification records contain project paths and stay out of the web root unless separately sanitized.

Suggested CTA for later public use

Before your next paid AI media/API run, fill the preflight contract. If you cannot name the account, route, billing lane, task endpoint, spend cap, stop condition, and receipt, do not run the job yet.

The sexy version of AI media is not “we found the render button.”

The sexy version is: the run had a leash, it used the right route, it stayed inside budget, and the receipt survived daylight.