How a site talks to an AI service

What happens when a page asks an AI service a question?

Three separate programs take part. The visitor's browser shows your page. Your server is a program you control, running on a computer you rent or own. The AI service is run by a company and answers questions sent to it by programs that have a key.

The question travels in two hops. First the page sends it to your server, at an address on your own site such as /api/ask. Your server adds the private key, sends the question on to the AI service, waits for the answer, and passes it back to the page. The page never talks to the AI service directly.

That middle step can feel like extra work when you first meet it. It exists because the browser is the one place you cannot keep a secret: everything a page loads can be read by the person looking at it. The next lesson is all about that key. This one covers the page side: how to send the question and show the answer well.

How does the page send a question?

Pages send data to a server with fetch. For a question you use a POST request, because you are sending something for the server to act on, and you put the question in the body as JSON. The Content-Type header tells the server what kind of body to expect.

The server sends back JSON too. In this course the pretend server always answers with an object that has one property, answer. Your code waits for the response, turns it into an object with res.json(), and reads data.answer.

Real servers can use different names. Whoever writes the server decides them, and the page has to match. When an AI assistant writes both sides for you, check that the names on the page match the names on the server.

const res = await fetch('/api/ask', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ question })
});
const data = await res.json();
answerBox.textContent = data.answer;

Why does /api/ask start with a slash?

An address that starts with a slash means the same site the page came from. If the bakery lives at crumb.example, then /api/ask means crumb.example/api/ask. The request goes to your own server, which is the whole point.

Browsers are strict about pages talking to other sites. A request to a different address is often blocked unless that site says it is allowed, and the error messages can be confusing. Talking to your own address avoids that problem, and it keeps the outside service's address and key out of the page entirely.

In the Preview here, nothing goes online. A small stand-in answers requests to /api/ask with a pretend answer that repeats your question, and blocks every other address with a message in the console strip. That lets you practise the page side without a real server.

How should you ask an AI assistant for this code?

Say what the feature is for, show your page, and name the address. The last part is the most important. Without it, many AI answers call the AI service straight from the browser and ask you to paste your key into the page, because that is the shortest example. In the practice area, leave out the server address and you get exactly that reply.

Add your limits as usual, such as plain JavaScript only. Check the **Prompt check** view: this exercise adds a Your server row, ticked when your request says the page should talk to your own server.

Please add a question box to my bakery page so visitors can ask the baker something and see the answer below it. Here is my page: <h1>Ask the baker</h1> and one paragraph. The page should send the question to my own server at /api/ask with a POST request and show the answer it sends back. Plain JavaScript only, no libraries.

Why show the answer with textContent?

An answer from an AI service is text you did not write. It can contain angle brackets, odd characters, or a sentence that happens to look like HTML. Treat it the way you treat a visitor's comment: put it on the page with textContent, so it is always shown as plain text.

This is more important than it looks. Visitors can type tricky instructions into the question box, and an AI service can be talked into repeating them in its answer. If your page builds that answer as HTML, a visitor has found a back door into your page. With textContent, the worst case is some strange text in a box.

What should the visitor see while they wait?

AI answers take time, often a few seconds. Without a sign that something is happening, visitors click again, which sends the question twice and costs you twice. A short Thinking... message, put in place before the request is sent, solves most of that.

Things also go wrong: the server is busy, the visitor's connection drops, the AI service has a limit. Wrap the request in try and catch and show a short, kind message when it fails. An empty box with no explanation is the worst outcome, because the visitor cannot tell a slow answer from a broken page.

Read AI-written code for these two cases specifically. Many quick answers handle the happy path and skip the waiting and failure states entirely.

How do you check the result?

Use the code, then try it in the Preview. Ask a normal question and check the answer appears. Send an empty box and check nothing is sent. Ask a question with angle brackets in it, such as Is <b>rye</b> gluten free?, and check the answer shows the brackets as plain characters.

Then open the **Review** view to see your changes next to the AI's version. In this exercise you should see two: the answer line switched to textContent, and a new label above the input. The placeholder can stay as a hint, since the label now does the real job.

What is different on a real site?

On a real site you also write the server part, or use a hosting service that runs a small function for you. That code receives the question, checks it is a sensible length, adds the key from a private setting, calls the AI service and returns the answer. The next lesson shows what that looks like and why each step is there.

Real AI services also charge per question and limit how many questions you can send in a minute. Your page is the first line of defence against wasted requests: skip empty questions, stop double clicks, and show a clear message when the service says no. The pretend server here never charges and never refuses, so those are things to read for in the code.

Field notes

• The page sends the question to your server, and your server talks to the AI service.
• Pages send data with fetch, using a POST request with a JSON body.
• An address starting with / goes to the same site the page came from.
• Show AI answers with textContent, because you didn't write that text.

Easy to get wrong

Anything the page sends can be seen by visitors, including the key the service needs. Going through your own server keeps the key private and gives you one place to add limits.

The answer is text from outside your code. If it contains HTML, innerHTML builds it into your page, and visitors can sometimes steer what the answer contains.

A silent page makes people click again, which sends duplicate requests and makes a slow service look broken.

Questions people ask

Do I need my own server to add AI to a site?

Yes, some program you control has to hold the key and talk to the service. It can be a small function on a hosting service instead of a whole server. The page talks to it the same way.

Why POST instead of GET?

GET puts the question in the address, where it ends up in logs and history and can break on long or unusual text. POST carries it in the body, which is the normal way to send data for a server to act on.

What does the pretend /api/ask do?

It waits a moment and answers with { answer }, repeating your question back. It never goes online. Any other address is blocked in the Preview with a message.

Can the AI service's answer be wrong?

Yes. Say on the page that answers come from an AI tool and may be mistaken, and avoid using them for anything like prices, allergens or health advice without checking.