You already know one turn: build a request, send it with your API key, read the response.
Until now that trip lived on the page as JSON. Now your program does it for real — against a live server.
Your program is the client
The language model still runs on the company’s server. Your program does not contain the model.
Your program is the client: it builds the prompt, proves who pays with the API key, and reads the reply.
Your program (client) Server
┌──────────────────┐ request ┌──────────────┐
│ API key + prompt │ ─────────────▶ │ model runs │
│ │ ◀───────────── │ │
└──────────────────┘ response └──────────────┘That is the same picture from earlier chapters. The only new job is: you write the program that sends the turn.
What an SDK is
You could open a network connection and paste raw JSON yourself. Most people do not.
They use an SDK — short for software development kit. In plain words: a ready-made library from the model company that knows how to talk to that company’s API.
Think of two paths to the same turn:
| Path | What you do |
|---|---|
| Without an SDK | Build the JSON, attach the API key, send HTTP yourself, dig through the raw response |
| With an SDK | Call a few functions; the library builds and sends the request for you |
An SDK typically:
- Takes your API key
- Takes your prompt (and settings)
- Sends a correct request to the API
- Hands you back a response you can read in code
Different companies ship different SDKs. Method names change. The turn does not: request out, response back.
The Code panel shows the same four steps in Python, Java, Go, and TypeScript — one concrete SDK each.
Four steps of the call
Every first call follows the same contract:
| Step | What you do | How it maps to what you know |
|---|---|---|
| 1 | Provide your API key | Proof of who pays |
| 2 | Create a client with that key | “I am ready to call this company’s API” |
| 3 | Send one user question | The request — one turn, no history |
| 4 | Read the reply text | The main part of the response |
Here is the idea in plain order:
1. API_KEY = "…"
2. client = connect with API_KEY
3. response = client.send(model, "What is 2 + 2?")
4. print(response.text)
Under the hood, step 3 is still something like the request you already saw:
{
"model": "some-model",
"messages": [
{ "role": "user", "content": "What is 2 + 2?" }
]
}
Gemini’s SDK may say contents instead of messages. Same job: send the text the model should see. Learn the job; remap the name when you switch companies.
What you should see
When the key is valid and the network works, the program prints a short reply — for example something like:
2 + 2 is 4.
That printed line is the assistant text — message.content in the mental model. The SDK often exposes a shortcut such as response.text so you do not dig through the full JSON on day one.
The full response still has more (finish reason, usage). For this first call, reading the reply is enough to prove the turn works end to end.
One call, no memory
This call sends one question and gets one reply. It does not remember a previous turn.
That matches what you already learned: each call starts fresh unless you send history. Conversation memory comes in a later chapter.
The pattern travels
Swap Gemini for another company’s SDK later and you still do the same four steps:
- API key
- Client
- One question
- Read the reply text
Field names and method names move. The turn does not.
Cast for this beat:
| Word | Meaning |
|---|---|
| Client | Your program, calling the server |
| SDK | Software development kit — library that sends the request for you |
| First API call | One real turn, end to end |
Next you will look closer at roles — the labels on pieces of text in richer requests.