When you tap "Sign in with Google" in an app, check where your package is on an online store, or open a weather app, the same thing happens behind the scenes: one piece of software is talking to another through an API. So what is an API, how does it work and why does it matter so much? In this post we explain it so that even non-technical readers can follow, with examples and tables.
What Is an API?
API stands for Application Programming Interface. In short, it's a set of rules describing how two pieces of software talk to each other.
The most common analogy is a restaurant: you (the customer) don't walk into the kitchen and cook the food yourself. You tell the waiter what you want from the menu, the waiter passes the order to the kitchen and brings the food back to you. The waiter is the API. The menu is the API's documentation: it shows what you can ask for and how to ask for it. You don't need to know what's going on in the kitchen.
Everyday API Examples
- Weather apps: They don't measure the weather themselves, they pull data from a weather service's API.
- Online payments: The store sends your card details to a payment provider's API and gets back "approved" or "declined".
- Maps: The "find our store" map on a website is shown through a map service's API.
- "Sign in with Google / Apple": Authentication happens through that service's API.
- Package tracking: The store asks the shipping company's API about your tracking number and shows you the latest status.
How Does an API Work?
Most modern APIs work over HTTP, the same protocol the web uses. The logic is simple:
- The client (an app, a website or another server) sends a request to a specific address.
- The server receives the request, checks permissions and does the work (reading from a database, creating a record, etc.).
- The server sends back a response; usually data in JSON format plus a status code describing the result.
The Parts of an API Request
| Part | What it's for | Example |
|---|---|---|
| Endpoint (URL) | The address the request goes to | https://api.example.com/v1/orders/1042 |
| HTTP method | Says what you want to do | GET, POST, DELETE... |
| Headers | Extra info like authentication and data format | Authorization: Bearer ... |
| Body | The data being sent (usually JSON) | {"name": "Alice"} |
| Status code | Tells you the result in the response | 200, 404, 500 |
HTTP Methods
| Method | What it does | Example |
|---|---|---|
GET | Reads data | Fetching an order's details |
POST | Creates a new record | Placing a new order |
PUT | Replaces a record entirely | Changing the whole address |
PATCH | Updates part of a record | Changing just the phone number |
DELETE | Deletes a record | Cancelling an order |
Common Status Codes
| Code | Meaning | When you see it |
|---|---|---|
| 200 OK | Success | The request was processed fine |
| 201 Created | Created | A new record was created |
| 400 Bad Request | Bad request | Missing or badly formatted data |
| 401 Unauthorized | Not authenticated | No API key, or an invalid one |
| 403 Forbidden | Not allowed | You're authenticated but not permitted to do this |
| 404 Not Found | Not found | No such record or address |
| 429 Too Many Requests | Too many requests | Usage limit (rate limit) exceeded |
| 500 Internal Server Error | Server error | The problem is on the server side |
An Example Request and Response
Let's ask for an order's details from the command line with curl:
curl -H "Authorization: Bearer YOUR_API_KEY" \
https://api.example.com/v1/orders/1042The server's response would be JSON along these lines:
{
"id": 1042,
"status": "shipped",
"total": 349.90,
"currency": "USD",
"items": [
{ "product": "Keyboard", "quantity": 1 }
]
}The app takes this data and shows "Your order has shipped" on screen. That's all you see; the API handles everthing behind it.
Types of APIs
| Type | Data format | Key trait | Where it's used |
|---|---|---|---|
| REST | Usually JSON | Simple, widespread, built on HTTP methods | Most web and mobile apps |
| GraphQL | JSON | The client asks for exactly the fields it wants | Complex interfaces, mobile apps |
| SOAP | XML | Strict rules, old but still common | Banking, enterprise and government systems |
| gRPC | Protocol Buffers (binary) | Very fast, small payloads | Communication between microservices |
| WebSocket | Free-form | Always-open, two-way connection | Live chat, instant notifications, market data |
APIs by Who Can Use Them
| Type | Who uses it | Example |
|---|---|---|
| Public API | Anyone, usually with an API key | Weather, map services |
| Partner API | Only contracted business partners | Shipping or payment integrations |
| Internal (private) API | Only the company's own systems | A mobile app talking to its own backend |
API Security
APIs are doors to your data, so security really matters. The basics:
- API keys: A secret key that identifies who's making the request. Don't hard-code it and push it to places like GitHub; use environment variables or a secrets manager.
- OAuth 2.0 and tokens: The standard for granting limited, time-bound access on a user's behalf ("Sign in with Google" uses it).
- HTTPS: All API traffic should be encrypted; sending keys over plain HTTP is like leaving the door open.
- Rate limiting: Capping how many requests can be made in a given time to prevent abuse and overload.
- Least privilege: Give each key only the permissions it needs; don't give delete rights to an integration that only reads.
APIs and AI
Today, the most common way to add AI to a product is also through an API. Large language model providers offer their models as APIs; you send text, the model sends back an answer. Even when you run an open-source model on your own server (e.g. with Ollama), you still use it through an API. We cover how to do that in our how AI runs on a virtual server post. For integrating AI into your existing systems, check out our AI service.
Where Should You Run Your Own API?
When you write an API for your own app, you need a server that keeps it up 24/7. Roughly, your options are:
- A virtual server: Whatever language you used, Node.js, Python, PHP, Go..., you can run it directly. The most practical start for small to mid-size APIs. VECDC virtual servers come with NVMe storage, start at $6/month and are ready in about 5 minutes.
- With Docker: Package your API as a container and run it the same way everywhere. Developer VDS, delivered with Docker installed, is ideal for this.
- With Kubernetes: If you want a setup that scales automatically with traffic and updates without downtime, you can start with Kubernetes Server.
Frequently Asked Questions
What's the difference between an API and a web service?
A web service is a type of API that's accessed over a network (usually HTTP). So every web service is an API, but not every API is a web service; for example, the interfaces an operating system or software library provides are APIs too, but they don't run over a network.
What is a REST API?
REST is an API design approach that uses HTTP methods (GET, POST, PUT, DELETE) and accesses resources through URLs. Data is usually carried as JSON. It's the most common type of API in web and mobile apps today.
What is an API key?
An API key is a secret code that identifies the application sending requests to an API. The provider uses it to track who makes how many requests and to block unauthorized access. Keep it like a password and never hard-code it into code that ends up in public places.
Is using an API free?
It depends. Many APIs are free up to a certain usage limit and are billed by requests or usage beyond that. A company's own internal APIs only cost whatever the server they run on costs.
In Short
An API is an interface that lets pieces of software talk to each other. You send a request, the other side does the work and sends back a response; you don't need to know what happens in the kitchen. Almost every app we use today runs on dozens of APIs working together. If you'd like help shipping your own API or connecting your systems, drop us a message and lets take a look together.