An LLM API lets your application send a prompt to a hosted model and get a generated response back over HTTP — no need to host or run the model yourself. Providers differ in specifics, but the core request/response shape is broadly similar across most of them.
The Basic Shape of a Request
# Conceptual — real syntax differs by provider (see Chat Completions)
response = llm_client.generate(
model="model-name",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain what an API is."}
],
temperature=0.7,
max_tokens=200
)
print(response.text)What's Common Across Most Providers
| Concept | Typically Present As |
|---|---|
| Model selection | A model name/ID parameter — see Model Selection |
| Message-based input | System/user/assistant roles — see Chat Completions |
| Sampling controls | temperature, top_p |
| Output length control | max_tokens or equivalent |
| Usage/cost data | Token counts returned with the response — see LLM API Cost |
What Genuinely Differs Across Providers
Exact parameter names, authentication methods, rate limit structures, available models, and specific features (like structured output support or built-in tool calling) all vary meaningfully between providers — and change over time as providers update their offerings. Always check a specific provider's current official documentation before writing production code against their API; do not assume this hub's conceptual examples map exactly to any one provider's current syntax.
Practical Use Case
Most LLM-powered applications are, at their core, a thin (or not-so-thin) layer of application logic wrapped around calls to an LLM API — understanding this request/response cycle is foundational to building anything from a simple chatbot to a complex agent system.
Common Mistakes
- Assuming all provider APIs are interchangeable with only the base URL changed — parameter names, defaults, and behavior can differ meaningfully
- Hardcoding API calls throughout an application instead of behind a thin wrapper, making it harder to switch providers or models later
Interview Relevance
"What are the core components of a typical LLM API request?" — model, messages/prompt, sampling parameters, and output limits are the expected baseline answer.
Practice Question
Sketch (in pseudocode) a thin wrapper function around an LLM API call that would make it easier to swap providers later without changing calling code throughout your app.
