API and UI serve different users
An API, or Application Programming Interface, is a defined way for software to interact with other software. A UI, or User Interface, is how a person interacts with an application: a button, a form or a screen. APIs are not limited to the internet; this guide focuses on web APIs that use HTTP.
When a shopper presses “Check stock”, the UI can ask the shop’s server for availability through an API. The screen displays the answer; the API defines the exchange. Providing API access does not automatically provide a ready-made shop, chat screen or connection to your own database.
What goes into a request?
A web request has a method, an address and headers, and may have a body. The method describes the intended operation; headers describe details such as the body’s format. For this fictional stock check, imagine POST /example/stock-check with Content-Type: application/json. This is a teaching example, not an AIAPI endpoint.
Example request body: {"item_id":"notebook","quantity":2}
Here item_id is a product identifier and quantity is the amount requested. The field names and allowed values must come from that API’s contract. A server cannot reliably infer a missing field or an unsupported operation just because the request is valid JSON.
How to read the response
The server returns a status, headers and, where applicable, a body. In this example, a 200 response could carry the following JSON. The number is a JSON number, and true is a boolean, not a quoted word.
Example response body: {"item_id":"notebook","available":true,"quantity":2}
This says the requested quantity is available in the example; it does not reserve or purchase it. Read the documented meaning of each field. For an AI response, successful delivery and valid JSON do not prove that the generated facts are correct. Validate both structure and meaning before using the result.
Identity is not permission
Authentication checks the caller’s identity or credential. Authorization decides what that caller may do. An API key may represent an application’s access rather than an individual person. Your own backend still needs to check which signed-in user may read a record or trigger an action.
- Use HTTPS. For a confidential server API key, use server-side secret storage, not browser code, public repositories or URLs.
- Apply the narrowest available permissions and usage limits. If a key leaks, revoke and replace it; deleting the visible copy is not enough.
- Keep credentials and unnecessary personal information out of prompts, logs and support messages.
What an AI gateway does—and does not do
An AI gateway sits between your application and upstream model services. Depending on its configuration, it can route requests, apply access controls, track usage and translate supported request formats. AIAPI is a gateway service, not the model that generates the answer.
A common interface does not mean every model supports every feature. A gateway does not automatically add your business data, grant database permissions, verify generated claims or guarantee uninterrupted service. Your application owns those checks and integrations. Use the developer guide for connection examples and the glossary when a term is unfamiliar.
Primary sources and further reading
The explanations above are written by AIAPI. These primary sources document the underlying concepts; their inclusion does not imply a partnership.
- MDN: API
- RFC 9110: HTTP Semantics
- RFC 8259: The JSON Data Interchange Format
- OWASP: REST Security Cheat Sheet
Found an unclear explanation or an error? Contact [email protected].