OpenAI API keys for support: Setup & practices (2026)

What are OpenAI API keys?

OpenAI's production guidance describes API keys as an authentication mechanism. Your application's requests use the key within the access available to it. Possession of a key does not establish that the person making a support request owns the customer account they mention.

API usage is associated with the applicable organization and project. If you work across multiple environments, confirm where requests will be billed and which resources they can access. Keep staging separate from production so a test is less likely to disrupt live support.

For a support application, API access could enable drafting a reply or summarizing a ticket. Your application still supplies the permitted context, decides which tools are available, and controls how any output reaches the helpdesk.

Create and store a key for the intended application

Use the API keys page in the intended OpenAI organization and project. You need the appropriate account permissions. API access and billing should be checked in the Platform; do not assume that a ChatGPT subscription supplies the API usage your application needs.

1. Confirm the organization, project, and whether this is staging or production.
2. Create a key for the intended application with the access it requires. Use a name that identifies the service and environment rather than sharing an unexplained team-wide secret.
3. Store the secret securely when it is issued. Do not copy it into a ticket, chat prompt, screenshot, or repository.
4. Supply it to your server-side application through a secret manager or protected environment configuration. Confirm the expected project and access with a bounded test before enabling production traffic.

A key belongs on the server side of an application, not in browser JavaScript shipped to customers. An environment variable is a delivery mechanism, not protection against every leak: logs, debug output, build configuration, or an accidentally committed environment file can still expose it.

Billing controls: alerts are not the same as enforced limits

The official spend-limit guide, captured in September 2026, explains why a notification is different from an enforced cap.

Estimate costs using the models and tools the application actually calls. Input and output token usage is relevant for text generation, while additional services may have their own charges. Measure representative requests, retries, and expected ticket volume rather than assuming either unlimited usage or unknowable costs.

The current spend limits guide distinguishes notifications from hard limits. Hard-limit enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount. A hard limit can also interrupt a live support application; plan the fallback before enabling it.

Do not blindly retry every 429 response. The spend-limit documentation distinguishes organization and project spend limits, approved usage limits, exhausted credit balances, and rate limits. Check the error code and get the appropriate owner to address the cause.

Protect and replace credentials deliberately

Keep secrets out of customer-visible code, shared logs, screenshots, and support conversations. Give each environment only the access it needs, restrict who can retrieve secrets, and monitor usage for unexpected behavior.

If a key is exposed, revoke it and investigate the affected usage. For a planned replacement, update the authorized application, verify the new credential works, and retire the old one according to your team's process. A fixed rotation schedule does not replace prompt response to an actual leak.

Successful authentication and secure storage are necessary, but neither proves that an answer is correct or that an account action is authorized. Those checks belong in the support workflow.

What an API key does not build for you

An API key grants access; it does not define a support workflow. The amount of engineering depends on the task, your existing systems, and the components you reuse. Avoid treating every prototype as a months-long project or every successful API response as a production-ready service.

For a reply-drafting application, you still need to decide which ticket context and policy information the model receives, how access is checked, where the draft appears, and who reviews it. If the application can update customer records, it also needs explicit action permissions and reliable failure handling.

Custom applications can be tested before launch. OpenAI's production guidance recommends separating staging from production and testing extensively. Evaluate representative requests and policy exceptions, then verify your helpdesk integration separately. Do not interpret a fluent answer as proof that the system retrieved the right policy or delivered the intended update.

Costs can also be estimated. Measure input and output usage on representative requests, include any additional tool and infrastructure charges, and account for retries and volume changes. Compare the estimate with actual usage after launch. A managed product changes what you operate and how you are billed; it does not make usage or review costs disappear.

Operate a managed support teammate through eesel CLI

The eesel CLI documentation describes its own authentication path. The screenshot shows documentation, not a completed customer setup.

Using a managed product does not mean giving up terminal access. The eesel CLI lets people, scripts, and coding agents configure the same eesel teammate and workspace available in the dashboard. Claude Code, Cursor, or Codex can read its JSON output and help inspect knowledge, instructions, integrations, and automations.

The credential boundary matters. An OpenAI API key authenticates requests to OpenAI. The eesel CLI authenticates to an eesel workspace. Do not put an OpenAI key into an eesel token variable or paste either secret into a prompt. Using the documented eesel setup is not the same as building a model-backed application with your own OpenAI credentials.

Confirm access before asking a coding agent to make changes

With Node.js 18.17 or newer, an existing eesel user can authenticate and inspect the destination:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

Login opens a browser and stores credentials locally. The documentation identifies EESEL_API_URL and EESEL_API_TOKEN as the alternative for headless environments; these take precedence over a stored login. If the destination looks wrong, check whether environment configuration is overriding it. Do not print the token while debugging.

Choose the intended teammate, replace SUPPORT_AGENT_ID with its identifier, and inspect before changing anything:

npx @eesel/cli status --agent SUPPORT_AGENT_ID
npx @eesel/cli integrations --agent SUPPORT_AGENT_ID
npx @eesel/cli instructions --agent SUPPORT_AGENT_ID
npx @eesel/cli automations --agent SUPPORT_AGENT_ID

An existing teammate may already have live triggers or customer-facing permissions. Selecting it does not isolate your experiment. Confirm which knowledge is downloaded and ready, which systems are connected, and what actions the teammate can take. Request approval before connecting private accounts or changing its operating rules.

A bounded coding-agent instruction could be:

Inspect the selected eesel support teammate and explain any missing policy knowledge or permissions. Do not display credentials. Propose changes first; do not connect private accounts, change automations, send customer replies, or enable account actions without my approval.

Test policy behavior separately from authentication

Successful login only proves access. For a fictional rehearsal, disable write actions and ask the teammate to draft a response to someone requesting an account-email change while unable to pass the normal identity check. Give it an approved account-recovery policy. It should explain the permitted recovery path or escalation, not accept the customer's assertion as proof of identity or claim the email address was changed.

Use a fresh conversation for this case with new --name, scoped to the selected agent. A follow-up chat continues the current conversation, which lets you test whether the teammate maintains the same policy when the customer presses for an exception. Keep real customer identifiers and secrets out of the fictional case.

CLI chats are billed work; configuration inspection is free. The --dry-run flag previews a write request, not the quality of a policy answer. After reviewing the rehearsal, separately verify any approved helpdesk action against its destination record. A correct draft, permission to send it, and a delivered reply are different checks.

This approach avoids building a new support application just to gain programmatic control. It does not remove your responsibility for source access, policy accuracy, or approval of live actions.

Choose the responsibility you want to own

A custom application can be tested, monitored, and budgeted. It may fit when your requirements need application-specific logic or infrastructure. A managed teammate may fit when its supported connections and permissions cover the task and you want to configure the workflow instead of maintaining the application.

Neither column guarantees better answers. Compare the same representative support cases, including missing information, a policy exception, and a failed action. Use measured results to decide how much autonomy to allow.

Try eesel if you want a coding agent to help configure an existing support teammate through the CLI. Keep its credentials separate from your OpenAI API keys, review the proposed setup, and expand only after checking the actual outcome.