The API is an HTTP endpoint you can curl

The OpenAI chat-completions shape has become the common interface: a list of messages, a model name, a handful of parameters, and either a response or a stream of chunks. Self-hosted servers implement it, gateways speak it, and most client libraries expect it. That is why a deployment can start on a hosted endpoint and move onto your own hardware without the application being rewritten — the base URL and the key change, and nothing else does.

Treat that as an architectural decision rather than a convenience. Anything in your stack that speaks a proprietary shape is a component you cannot swap when the constraint changes.

Two knobs earn their place in most deployments. Temperature controls how much the sampling wanders; for extraction and classification you want it at or near zero, because you are not asking for creativity, you are asking for the same answer twice. The maximum output length is the other, because it is the difference between a truncated answer and a bill.

Structured output is the third thing to learn, and it changes how you build. Asking for JSON in the prompt and hoping is a parsing problem you will have forever; constraining generation to a schema turns it into a validation problem you can test. The extraction recipes on this site take the second route and their steps cite the server documentation for it.

Context overflow, when the prompt plus the requested output exceeds the window. Timeouts, when a long generation outlives the client’s patience. Rate limiting and queueing, when more requests arrive than the server can hold in flight. And malformed output, when the model returns something your parser did not expect.

Every one of them is normal operation rather than an incident, so handle each explicitly: count tokens before you send, set timeouts deliberately, back off on a queue, and validate every response against a schema before it reaches the rest of the system.