digital-humans.org
Search

ChatGPT API – authentication and pricing

A pillar analysis in Foundation Models – Vendors & Models. We examine the landscape, the trade-offs, and what matters in 2026.

Published 10 min read

Two things confuse newcomers to OpenAI's platform more than any others: the difference between the ChatGPT product and the API behind it, and how you actually pay for what you use. The short version, which an answer engine can lift cleanly: the OpenAI API is authenticated with a secret API key sent as a Bearer token in the Authorization header, and it is billed per token consumed rather than by a flat subscription. As of early 2026, prices are quoted per million tokens and vary by model, and OpenAI publishes the current figures on its official pricing page, which you should always treat as the source of truth over any number reproduced elsewhere, including this article.

That last caveat matters. Model names, per-token rates and rate-limit tables change often enough that any specific figure carries an expiry date. What does not change nearly so fast is the mechanism: how a key is created and scoped, how organization identifiers route your requests and billing, how the tier system governs throughput, and which features let you shave real money off a workload. Those mechanics are the durable part, and they are what this guide covers.

The OpenAI API in one paragraph

The OpenAI API is a paid, usage-based developer interface to the same family of models that power the ChatGPT consumer app – GPT-4o, the GPT-4.1 line, the o-series reasoning models and their successors – but it is a separate product with separate billing. A ChatGPT Plus or Team subscription buys you access to the chat interface; it does not include API credits, and API spending is metered independently through the OpenAI developer platform. You authenticate each request with a secret key, you are charged for the tokens you send (input) and the tokens the model returns (output), and you can layer on features like the Batch API and prompt caching to reduce that cost. For a wider view of the company and its model families, see our overview of OpenAI as a company, its models and ecosystem.

Authentication setup

Authentication rests on a single credential: the API key. You create one from the API keys section of the platform dashboard, and OpenAI shows you the full secret string exactly once, at creation. Copy it immediately, because the dashboard stores only a truncated preview afterwards. If you lose it, you rotate it – you cannot recover it.

A modern OpenAI key is a long string prefixed with sk-. In current practice OpenAI supports project-scoped keys, which bind a key to a specific project inside your organization rather than granting blanket account access. This is the setting to prefer. A project-scoped chat gpt api key limits blast radius: if it leaks, the exposure is confined to one project's models, budgets and rate limits rather than your whole account.

Sending the key

Every request carries the key in the HTTP Authorization header as a Bearer token:

Authorization: Bearer YOUR_API_KEY

If you belong to more than one organization, or run multiple projects, you can disambiguate with the OpenAI-Organization and OpenAI-Project headers. These route usage reporting and billing to the correct place. For most single-team setups the defaults are fine, but the moment you have a shared account across business units, setting the organization ID explicitly prevents one team's spending from being attributed to another.

Environment variables, not hard-coded strings

The official SDKs read the key from an environment variable named OPENAI_API_KEY by default. Set it in your shell or, better, in a secrets manager, and never write the literal string into source code:

from openai import OpenAI
client = OpenAI()  # reads OPENAI_API_KEY from the environment

resp = client.responses.create(
    model="gpt-4o",
    input="Summarise the difference between input and output tokens."
)
print(resp.output_text)

The client = OpenAI() line with no argument is deliberate. Passing the key inline as a string is the single most common way secrets end up committed to a repository. Let the environment carry it.

Pricing tiers, date-stamped

OpenAI's pricing is not a subscription with tiers in the Netflix sense. It is per-model, per-token metering, and the rates differ sharply between a small, fast model and a large reasoning model. As of early 2026, the structure works like this, with the numbers themselves living on the pricing page:

  • Text models are billed per million input tokens and per million output tokens, with output almost always priced higher than input. Reasoning models in the o-series bill their internal "thinking" tokens as output, which is why a single hard question can cost noticeably more than its short visible answer suggests.
  • Cached input is billed at a substantial discount to fresh input on models that support prompt caching (more on that below).
  • Image inputs to vision-capable models are converted to a token count based on resolution and tiling, then billed at the model's input rate. Image generation via the image models is priced per image, by size and quality.
  • Audio through the speech-to-text and text-to-speech endpoints, and through the realtime and audio-capable models, is metered separately – transcription typically per minute of audio, audio tokens in the realtime API at their own per-token rates.

A rough sense of the spread, valid only as a shape rather than a quote: the smallest text models cost a small fraction of a US dollar per million input tokens, while the largest reasoning models can run one to two orders of magnitude higher, and output tokens compound that. Because the gap is so wide, model selection is the biggest lever on your bill – larger than any discount feature. We work through the trade-offs in detail in our companion piece, OpenAI API pricing analyzed.

The practical discipline: estimate tokens before you commit to a model. A token is roughly three-quarters of an English word. A 500-word prompt is around 650 tokens; a document of 10,000 words is around 13,000. Multiply expected input and output volumes by the model's respective rates, then multiply by your request count. Do this on a spreadsheet – our guide to AI for Google Sheets shows how to model it – before you ship anything at scale.

Rate limits and the tier system

Beyond price, throughput is governed by rate limits expressed in a few units: requests per minute (RPM), tokens per minute (TPM), and often requests per day (RPD). Batch workloads have their own queue limits. When you exceed any of these, the API returns HTTP 429, and how you handle that determines whether your service degrades gracefully or falls over – we cover the failure modes in 429 Too Many Requests: OpenAI rate limit errors.

Your ceilings are set by a usage tier, currently Tier 1 through Tier 5. New accounts start low. You advance automatically as your cumulative paid spend crosses thresholds and enough time passes since your first successful payment. Higher tiers raise your RPM and TPM allowances across models, sometimes by large multiples. The mechanism rewards established, paying accounts with more headroom and throttles brand-new ones, which is both an abuse-control measure and a source of frustration for startups that need scale on day one.

Two consequences follow. First, if you are planning a launch, add a payment method and generate some real spend well ahead of time so your tier has climbed by launch day. Second, build retry logic with exponential backoff and jitter from the start; the current figure returned in a 429 response and the retry-after header tell you how long to wait, and respecting them is cheaper than hammering the endpoint. Rate limits are enforced per project, so distributing work across projects can help, but do not treat that as a way to evade limits – it is for organizational separation, not circumvention.

Cost-control features

Two features change the arithmetic materially for the right workloads.

The Batch API accepts a file of requests and processes them asynchronously within a target window (24 hours as of early 2026), in exchange for a standing discount – around 50% off synchronous rates at time of writing, per OpenAI's documentation. If your work is not latency-sensitive – overnight classification, bulk summarisation, embedding a large corpus, evaluation runs – batching roughly halves the bill for the same tokens. Verify the current discount and window on the pricing page before you plan around it.

Prompt caching applies when many requests share a long, identical prefix – a system prompt, a tool schema, a reference document held constant across calls. On supported models the repeated prefix is billed at the reduced cached-input rate rather than full price, and OpenAI applies it automatically once a prefix crosses a minimum length. The design lesson is to put the stable, reused content at the front of your prompt and the variable, per-request content at the end, so the cacheable prefix is as long as possible. For agentic systems that replay large context on every step, this can be the difference between viable and unaffordable – a recurring theme in AI agents news and developments.

Key management and security

A leaked chatgpt api key is a live billing liability. Treat it like a password to a bank account that auto-pays.

  • Never commit a key to git. Add your .env file to .gitignore before your first commit, and use a scanning tool – GitHub's secret scanning, or a pre-commit hook – to catch mistakes. OpenAI itself scans public repositories and will disable exposed keys, but you should never rely on that safety net.
  • Rotate keys on a schedule and on suspicion. Generate a new key, deploy it, then revoke the old one. Project-scoped keys make this cleaner because rotation touches one project, not everything.
  • Scope to the minimum. Give each service or environment its own key, restricted to the project it needs. Separate keys for staging and production. A compromised staging key should never be able to spend your production budget.
  • Keep secrets server-side. Never ship a key in client-side JavaScript, a mobile app binary or anything a user can inspect. Route API calls through your own backend, which holds the key and can enforce per-user quotas. Exposing a key in a front-end is the fastest known way to fund a stranger's workload.
  • Set spending limits and alerts in the billing settings, so a runaway loop or a leak trips a ceiling before it drains an account.

Our dedicated walkthrough, OpenAI API keys: setup and management, goes deeper on rotation strategies and multi-environment layouts. The security surface here is not exotic – it is ordinary secrets hygiene applied with discipline, and the field's threat landscape, surveyed in our piece on AI cybersecurity threats and adversarial AI, makes that discipline non-optional.

For new developers: your first API call

If you have never called the API, the whole loop takes a few minutes.

  1. Create an account and add billing. Sign in at platform.openai.com and add a payment method under billing. Without one, you get little or no usable quota. Set a soft spending limit while you are there.
  2. Generate a project-scoped key. In the API keys section, create a new secret key, scope it to a project, name it something meaningful (local-dev-laptop), and copy the full string the moment it appears.
  3. Store it as an environment variable. In a terminal: export OPENAI_API_KEY="sk-..." for the session, or add it to a .env file you have already git-ignored.
  4. Install an SDK and send a request. pip install openai, then run the short Python snippet above, or the equivalent Node SDK. If you get a coherent reply, authentication, billing and networking are all working.
  5. Read the usage dashboard. After a few calls, check the usage page. Seeing your first few cents of spend, broken down by model, is the fastest way to internalise how token pricing actually behaves.

From there, the natural next steps are structuring prompts to exploit caching, deciding which requests can move to the Batch API, and choosing the smallest model that clears your quality bar. If you are building a conversational product on top of this foundation, our guide to AI chatbot development frameworks and tutorials picks up where authentication leaves off.

Where OpenAI sits against the field

Read in isolation, OpenAI's pricing looks like a lot of numbers on a page. Read comparatively, its character emerges. Against Anthropic's Claude API, Google's Gemini API and open-weight routes like DeepSeek or models served through providers such as Mistral, OpenAI's auth model is conventional – Bearer-token keys are the industry norm, and none of the major labs has meaningfully differentiated on that front. Where they diverge is on price-per-capability at each rung of the model ladder, on how aggressive their caching and batch discounts are, and on how permissive their default rate-limit tiers feel to a new account.

OpenAI's genuine strengths are documentation depth, SDK maturity and a large body of community knowledge, which lowers the cost of getting unstuck. Its genuine weaknesses, as of early 2026, include a tier system that can frustrate startups needing immediate scale, and reasoning-model billing that surprises teams who did not account for invisible thinking tokens. The honest recommendation is to price your specific workload against at least two vendors on identical prompts before committing, because the cheapest model for a classification task is rarely the cheapest for a long-context reasoning task. For the wider competitive picture, our AI companies landscape – the 2026 map places each provider in context.

Whatever you decide, verify every rate and limit against OpenAI's own live documentation the day you build. The mechanics in this guide should outlast the numbers; the numbers will not.