In this article
A copied API example can look like a complete recipe: endpoint, authentication, model identifier, input, and perhaps an optional execution mode. In practice, those details are documented across several pages.
That distinction matters when maintaining an integration. A quickstart can demonstrate a basic call without defining every supported field. The model catalog can provide an identifier without documenting complete request syntax. Model-specific and production guides can add constraints that a generic example does not show.
The practical approach is to trace each configuration choice to the page that most directly documents it.
This map covers four official OpenAI pages retrieved on October 3, 2026. It is an editorial navigation aid, not an official documentation hierarchy. No API calls or performance tests were performed.
One request, several documentation owners
The following schematic collects fragments demonstrated by the quickstart. It is an annotation, not a complete or executable request:
POST https://api.openai.com/v1/responses ← Quickstart: endpoint
Authorization: Bearer $OPENAI_API_KEY ← Quickstart: authentication
model: gpt-6-astra ← Quickstart: field shape
image_url: https://example.invalid/image ← Quickstart: demonstrated input type
The OpenAI API quickstart shows the Responses API endpoint, bearer authorization using OPENAI_API_KEY, model selection, and an image supplied through image_url. It also says OpenAI SDKs automatically read the API key from the system environment.
Those lines establish a basic request skeleton. They do not establish which models support every option, how a special execution mode behaves, or how credentials should be managed in production. Those questions belong to other documentation layers.
Documentation map
The first four rows below concern demonstrated request elements. The remaining rows include model-specific behavior and request-adjacent operational configuration; key storage, organization selection, and compression are not JSON request-body fields.
| Element or concern | Page to consult | What the page documents | Evidentiary boundary |
|---|---|---|---|
| Responses API endpoint | Quickstart | Examples send requests to https://api.openai.com/v1/responses. |
The examples do not define an exhaustive API schema. |
| Authorization | Quickstart | A cURL example uses a bearer token from OPENAI_API_KEY, and SDKs read the key from the system environment. |
Production storage and rotation require separate guidance. |
model in a basic request |
Quickstart | Demonstrated calls select a model with model. |
The current identifier and capabilities should be checked in the catalog. |
| Image URL input | Quickstart | An example supplies an image through image_url. |
This example does not establish support across every model category. |
| Model identifier | Model catalog | The catalog pairs model names with identifiers, such as GPT-6.1 Sol with gpt-6.1-sol. |
Catalog entries are current snapshots, not lifecycle guarantees. |
| Capabilities and limits | Model catalog | Entries list reasoning levels, tools, maximum output, context window, and knowledge cutoff. | A listed capability does not establish compatibility with every optional field. |
| Pro mode | Latest-model guide | Pro mode is described as a Responses API execution mode enabled in the request. | The supplied extraction does not preserve exact syntax or a complete eligible-model list. |
| Fast mode with EU data residency | Latest-model guide | Fast mode is unavailable with EU data residency for GPT-6 Astra, GPT-6 Sol, and GPT-6 Luna. | The statement does not define behavior in other regions. |
| Key storage | Production guide | Keys should stay out of code and public repositories and be supplied through environment variables or secret management. | This is operational configuration, not a request-body field. |
| Organization selection | Production guide | An organization ID can select the organization used for a request; usage counts against its quota. | The supplied text does not preserve the header name or complete default behavior. |
| Request compression | Production guide | Compression reduces network bytes but does not change token usage or context limits. | The guide provides no compression ratio or latency measurement. |
Confirm identity and capabilities in the catalog
The model catalog is the relevant source for validating the value placed in model and reviewing the model’s published capabilities and limits.
For example, the catalog associates GPT-6.1 Sol with gpt-6.1-sol. Its entry lists reasoning levels, supported tools, maximum output, context window, and knowledge cutoff (OpenAI model catalog). These details let a maintainer check whether an identifier copied from an older example still appears in the current catalog.
The catalog also states that its “latest OpenAI models” support text and image input, text output, multilingual capabilities, and vision through the Responses API and client SDKs (OpenAI model catalog). That statement applies to the category named on the page; it should not be extended to every specialized, realtime, deprecated, or historical model.
Check the guide before adding model-specific options
A request can follow the quickstart’s basic shape and still miss an important model-specific rule.
The latest-model guide describes Pro mode as a Responses API execution mode that applies more model work before returning one final answer. It says the mode increases latency and includes that work in reported usage billed at the selected model’s standard token rates (latest-model guide). These are documented characteristics, not measurements produced for this article.
The same guide states that Fast mode is unavailable with EU data residency for GPT-6 Astra, GPT-6 Sol, and GPT-6 Luna (latest-model guide). A generic request example would not reveal that deployment restriction.
The supplied evidence does not preserve Pro mode’s exact request syntax or a complete list of eligible models. Those details should therefore be verified on the current guide rather than reconstructed from surrounding prose.
Keep operational configuration separate
Some choices affect requests without appearing in their JSON bodies.
The production guide recommends keeping API keys out of source code and public repositories. It says applications should receive keys through environment variables or a secret-management service (production best practices).
The guide also documents organization selection and quota attribution: an organization identifier can select the organization used for a request, and usage counts against that organization’s quota (production best practices). The supplied extraction does not include the header name, so it should be taken from the current page rather than inferred.
Request compression has another explicit boundary. It reduces bytes sent over the network, but it does not change token usage or model context limits (production best practices).
For maintenance, record the relevant documentation URL beside each non-obvious configuration choice in code comments, an architecture note, or a configuration reference. Review the quickstart for the demonstrated request shape, the catalog for the identifier and published capabilities, the model guide for special modes and restrictions, and the production guide for operational settings. This preserves provenance without inventing compatibility rules, performance results, pricing calculations, or lifecycle promises.
No comments yet