OpenAI Dev Overview

Last updated：2026-08-12· 14 min read

🚀 Quick access

ChatGPT Domestic：Open entry↗
Mirror site：Open mirror↗
Official ChatGPT：chatgpt.com ↗

OpenAI Dev Overview

Last updated: 2026-09-17. Flagship follow-up: GPT-6 Astra (gpt-6-astra) hands-on.

Overview

The OpenAI ecosystem has at least three layers people confuse: ChatGPT web for end users, OpenAI Platform for developers (keys, billing, Playground), and REST / SDK as what your code actually calls. API shapes are still evolving: Responses API is often the Quickstart entry today, Chat Completions carries most legacy integrations, and Assistants API may be in maintenance or migration. This article is the series “map page”—terminology, product choices, and reading order. Model IDs, endpoints, and pricing follow official docs and the pricing page.

Which path should developers take?

Need GPT in a product / script / backend?
  ├─ Yes → Platform key → Quickstart → pick Responses or Completions
  └─ No  → chat only → chatgpt.com
            (web chat cannot replace an API key)

Goal	Recommended path	Common mistake
Support bot, content moderation	Platform + API	Treating ChatGPT Plus as API quota
Batch summaries, offline jobs	API + Batch (if available)	Copy-paste through the web UI
Try prompts, write docs	ChatGPT web / Playground	Ship to production without eval
File-backed knowledge POC	Check docs: Responses / Assistants	Pick Assistants without reading deprecation notes

Reading order for this series

Order	Article	What you get
1	This page	Global map and terminology
2	Platform Overview	Console and doc structure
3	API Quickstart	Your first API request
4	ChatGPT API Developer Guide	Auth, rate limits, production checklist
5	Text Generation	Parameters and structured output
6	Prompt Engineering	Evaluable prompt engineering
7	Assistants API	Legacy path and migration notes
8+	Embeddings, Vision, Speech, etc.	Deep dives by module

Core terms (5-minute shared vocabulary)

Term	Meaning	Dev note
API Key	Platform-issued `sk-...` secret	Server-side only; separate keys per environment
Model ID	e.g. `gpt-4o-mini` (example)	Check Models page before launch; don’t copy old posts
Token	Billing and context unit	Input includes system, RAG, tool definitions
Chat Completions	`/v1/chat/completions`	You maintain the messages array
Responses API	`/v1/responses`	Prefer Quickstart for new work
Assistants	Assistant / Thread / Run	May be legacy—see dedicated guide
Rate limit	RPM / TPM quotas	429 needs backoff, not a bad key

API surface comparison: what to pick for new projects

API	Typical endpoint	Session state	New projects
Responses API	`/v1/responses`	Usually stateless (you manage input)	Follow official Quickstart
Chat Completions	`/v1/chat/completions`	You manage messages	Keep for legacy; check migration for new features
Assistants API	`/v1/assistants`, etc.	OpenAI stores Thread	Read deprecation first
Embeddings	`/v1/embeddings`	None	RAG retrieval layer

Deep dive: Responses API Guide; maintaining Assistants legacy: Assistants guide.

Capability modules and series articles

Business need	Guide
Text Q&A, JSON extraction	text-generation
Stable prompts, regression tests	prompt-engineering
Semantic search, RAG	embeddings
Image reading, OCR	vision
Speech synthesis / recognition	speech
Text-to-image	image-generation
Multi-step agents	agents-sdk
Domain fine-tuning	fine-tuning

Multi-vendor stacks: where OpenAI sits

If you also integrate Claude or Gemini, at the gateway layer:

Separate auth: OpenAI uses Authorization: Bearer; don’t reuse the same env var name as Anthropic x-api-key.
Separate serialization: A unified external API is fine; request bodies still follow each vendor’s docs.
Separate eval: Changing vendor or model requires rerunning your golden set—see Prompt Engineering.

Compare: Claude API Get Started.

Minimal runnable example

# model and path per official Quickstart; gpt-4o-mini is example ID only
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4o-mini","input":"In one sentence, explain Platform vs ChatGPT web"}'

Full steps (key, SDK, error codes): API Quickstart.

Security baseline before launch

Keys never in frontend, Git, or client config files.
Log request id and token usage—not passwords or full national IDs.
High-risk domains (medical, legal, finance) need human review on outputs.
API calls run server-side outbound; compliance and billing follow official policy.

Frequently asked questions

Does ChatGPT Plus offset API charges?

No. Subscription and API are separate billing; integrations need Platform API usage.

Can I use web ChatGPT without a Platform account?

No. API keys are created only on Platform; web login is not a Bearer token.

Can Responses and Chat Completions coexist long term?

Technically yes, but dual-stack maintenance is costly. Pick one primary path for new work; set migration milestones for legacy—see API Developer Guide.

Is Assistants worth new project investment?

Follow current official docs. If marked legacy or Responses / Agents SDK is recommended, don’t default to Assistants—see Assistants guide.

How do I try chat before building?

Use ChatGPT web; production still needs a Platform key and server access to api.openai.com.

Official resources

Next reading

Action path

Today: Open Platform docs and confirm the Quickstart’s recommended API shape. Tomorrow: Create a test key and run one curl from Quickstart. This week: List three team use cases, map each to a follow-up article in this series, and start a POC.