BYOKchat
BYOKchat Blog

How to Get an OpenAI API Key and Use It Safely

Learn how to create an OpenAI API key, set up API billing, connect it to a BYOK client, understand browser security tradeoffs, and rotate or revoke it safely.

· 6 min read

On this page
  1. 1. Use the OpenAI API Platform, not the ChatGPT subscription page
  2. 2. Make sure API billing is ready
  3. 3. Create the API key
  4. 4. Copy the secret and treat it as a billable credential
  5. 5. Understand OpenAI’s client-side security guidance
  6. 6. Add the key to your BYOK client
  7. 7. Test with a small request first
  8. What happens when the request is sent?
  9. Should you create a separate key for each app?
  10. What if the key leaks?
  11. API access gives you control, not free usage
  12. A safe OpenAI BYOK checklist
  13. Further reading

If you want to use OpenAI models through a bring-your-own-key app, you need an OpenAI API key from the API Platform. A ChatGPT subscription is not the same thing as API access, and ChatGPT billing does not automatically fund API usage.

The practical setup is:

OpenAI API Platform account
        │
        ├── API billing / credits
        └── API key
              │
              ▼
          BYOK client
              │
              ▼
          OpenAI API

An API key can authorize paid usage on your account, so the important part is not merely creating it. You should understand where the key is stored, which client can access it, where requests travel, and how to revoke it if the credential is exposed.

1. Use the OpenAI API Platform, not the ChatGPT subscription page

OpenAI operates ChatGPT and the developer API as separate products with separate billing systems.

If your goal is to connect a BYOK client, start with the OpenAI API Platform rather than looking for an API key inside ChatGPT settings.

OpenAI documents this separation directly:

If you already subscribe to ChatGPT Plus or another ChatGPT plan, that subscription can still be useful for the ChatGPT product, but it does not turn the subscription allowance into API credit for another client.

For the full distinction, read Does ChatGPT Plus Include API Access? and API Key vs AI Subscription.

2. Make sure API billing is ready

Before relying on a new key, check the API Platform billing area and make sure the organization or project you intend to use can make paid requests.

The exact billing controls can evolve, but the durable distinction is:

ChatGPT subscription billing  ≠  OpenAI API billing

API cost depends on the models and features you call. Input/output tokens, tool use, storage, retries, model choice, and other billable API features can all affect spending.

If token-based billing is new to you, see Understanding AI API Costs and Token Usage.

3. Create the API key

Open the official API key management page:

platform.openai.com/api-keys

Create a new secret key for the project or account context you want to use. Give it a descriptive name when the interface allows it, for example:

BYOKchat personal

or:

Mac AI workspace

Descriptive names make rotation and cleanup easier. If a credential later leaks, you want to know which client needs replacing without guessing.

4. Copy the secret and treat it as a billable credential

Once the secret is shown, store it only where you intend to use it. Do not put it in:

  • a public Git repository;
  • a screenshot;
  • a support email;
  • a shared notes document;
  • a URL or query string;
  • analytics events;
  • crash reports;
  • ordinary application logs.

If the key is exposed publicly, assume it may already have been copied and rotate it rather than relying on deleting the public copy.

For the broader threat model, read How to Store API Keys Safely and Why API Keys Should Never Be Put in URLs.

5. Understand OpenAI’s client-side security guidance

OpenAI’s current security guidance says not to deploy API keys in client-side environments such as browsers or mobile apps and recommends routing requests through a backend that can keep the key secret:

Best Practices for API Key Safety

That guidance is written for applications where a developer-owned credential would otherwise be exposed to users. A BYOK client is different in one important way: the user supplies their own key at runtime instead of the application shipping one shared developer key.

But BYOK does not make the browser security tradeoff disappear.

If you enter your own OpenAI key into a browser-based BYOK client:

Your key
   │
   ▼
Browser-local credential store
   │
   └── accessible to trusted application code
           │
           ▼
       OpenAI API

The key is still present in a client-side environment. Code executing with the trusted site’s origin privileges may be able to access it. This differs from OpenAI’s recommended server-side architecture.

So there are two separate claims:

Developer hard-codes one shared key in frontend code
→ clearly unsafe

User deliberately supplies their own key to a trusted BYOK web client
→ different ownership model, but still a client-side secret-storage tradeoff

Use a browser-based BYOK client only if that tradeoff fits your threat model. For stronger OS-native secret storage on Apple platforms, a native client can keep provider credentials in Apple Keychain.

Read Where Does a BYOK Web App Store Your API Key? and BYOK Web App vs Native App: What Changes? before deciding which surface to use.

6. Add the key to your BYOK client

A typical OpenAI connection needs:

Provider:  OpenAI
API key:   sk-…
Model:     <model available to your account>

The client then authenticates API requests using your credential.

A well-designed BYOK client should:

  • keep the credential out of ordinary portable backups;
  • avoid logging or analyzing the raw secret;
  • never require you to send the raw key to support;
  • make the active provider/model explicit;
  • make credential replacement and deletion straightforward.

BYOKchat’s goal is to make the client your workspace while leaving the provider account, API access, and provider-side billing under your control. That is the core idea in What Is BYOK? Bring Your Own API Key Explained.

7. Test with a small request first

After saving the connection, send a simple text request before starting an important workflow.

If it fails, classify the failure instead of immediately regenerating the key.

Common categories include:

  • 401 — credential missing, malformed, revoked, or invalid;
  • 403 — project/account permission problem;
  • 429 — rate limit, quota, or billing-related limit;
  • model error — selected model not available to that account or endpoint;
  • network error — request did not reach OpenAI;
  • browser policy error — browser/CORS/security policy blocked the request before normal provider handling.

See AI API Errors 401, 403, and 429 for a systematic troubleshooting guide.

What happens when the request is sent?

A direct API request looks roughly like this:

┌──────────────┐
│ BYOK client  │
└──────┬───────┘
       │ HTTPS
       │ Authorization: Bearer <API_KEY>
       │ prompt / context / model
       ▼
┌──────────────┐
│ OpenAI API   │
└──────────────┘

The provider receives both the authentication credential and the content needed to process the generation.

Using BYOK does not mean OpenAI sees nothing. It means you control which provider account and credential the client uses, and a direct client can avoid adding an unnecessary application-owned model proxy in the middle.

Read What Happens When You Send an API Key to an AI Provider? for the deeper trust-boundary discussion.

Should you create a separate key for each app?

For many users, yes.

A simple structure can be:

OpenAI account
├── BYOKchat key
├── development key
└── automation key

Separate credentials make revocation easier. If one client stops being used or one secret is exposed, you can rotate only that integration instead of changing every tool that depends on your account.

What if the key leaks?

Treat a known exposure as compromise.

A sensible response is:

  1. revoke or delete the exposed key in the OpenAI API Platform;
  2. create a replacement;
  3. update only trusted clients that need it;
  4. inspect provider-side usage and billing for unexpected activity;
  5. remove the leaked copy where possible;
  6. assume the old secret may already have been captured.

Do not keep using a compromised key because replacing it is inconvenient.

API access gives you control, not free usage

An API key is authorization, not a subscription entitlement and not unlimited free access.

With your own OpenAI API key:

  • the provider account remains yours;
  • API usage is billed under OpenAI’s API rules;
  • you control creation and revocation;
  • the client does not need to resell OpenAI usage to you;
  • you can move that provider relationship between compatible clients.

That portability is one of the strongest reasons to use BYOK.

A safe OpenAI BYOK checklist

Before you consider the setup complete, verify:

  • you created the key in the official OpenAI API Platform;
  • API billing is configured separately from ChatGPT billing;
  • the key is stored only in clients you trust;
  • you understand OpenAI recommends server-side key storage for production applications;
  • if you use a BYOK web client, you accept that your own key exists inside the browser-origin security boundary;
  • the secret is not present in Git, logs, URLs, screenshots, or analytics;
  • a small test request succeeds;
  • you know where to revoke the credential;
  • you understand that prompts and request data still go to OpenAI when you use OpenAI models.

Once those points are clear, an OpenAI API key becomes what it should be: a replaceable credential connecting your provider account to the client you choose, with an explicit security boundary rather than an assumed one.

Further reading

Keep reading