What Is an API Call? A Developer's Guide

An API call is a request one program sends to another. It asks for data, or asks the other program to do something. The client sends the request. The server handles it and sends back a reply. (Postman)

Most apps you use today run on API calls. A weather app calls a weather service. A payment form calls a card processor. This blog runs on API calls too — Draftbase serves every post through its own delivery API.

What Is an API Call?

API stands for Application Programming Interface. The term dates to the 1940s. Early engineers built shared code libraries then. They wanted to avoid rewriting the same routines. (Wikipedia)

The modern web API era began around 2000. Roy Fielding's dissertation introduced REST that year. REST became the top style for web APIs. (Wikipedia)

An API call is one use of that interface. You don't call "the API" as one big thing. You call one endpoint. You use one method. You send specific data.

How an API Call Works

Every API call follows the same three steps. First, the client builds a request. Then the server handles it. Then the server sends a reply. (Postman)

The request has four parts. A method. A URL. Headers. And, often, a body. The method tells the server what to do. The URL tells it where. Headers carry extra data, like an auth token. The body carries the payload, if there is one.

The reply has three parts. A status code. Headers. And usually a body. The status code tells the client what happened. 200 means success. 404 means the resource wasn't found. The body carries the data, often as JSON.

Here's a real call to Draftbase's own delivery API:

curl "$DRAFTBASE_API_URL/delivery/entries?contentTypeId=blogPost" \
  -H "Authorization: Bearer $DRAFTBASE_DELIVERY_API_KEY"

The server sends back a JSON list of entries. Each entry has its fields already filled in. A reference field returns the linked entry itself, not just its id.

Common HTTP Methods and What They Do

Four methods cover most API calls. GET fetches data. It changes nothing. POST creates a new resource. PUT or PATCH updates one that exists. DELETE removes it. (Postman)

Method	Purpose	Changes data?
GET	Retrieve a resource	No
POST	Create a resource	Yes
PUT/PATCH	Update a resource	Yes
DELETE	Remove a resource	Yes

GET calls are safe to repeat. Call one once, or a hundred times. The result stays the same. POST calls usually aren't safe to repeat. Call POST /orders twice, and you'll likely create two orders.

How an API Call Proves Who's Asking

Most API calls need to prove who's asking. Without that, anyone could pull your data or trigger your actions.

The most common method is an API key. It's a long string sent in a header, like Authorization: Bearer sk_live_.... The server checks the key against its records before it does anything else.

Some APIs use OAuth instead. That's a longer flow. A user grants access once. The app gets a token back. The app sends that token with each call after that. OAuth fits cases where the app acts on a user's behalf, not its own.

A key or a token that leaks is a real risk. Anyone who has it can call the API as you. Store keys in environment variables, not in client-side code, and rotate them if one ever gets exposed.

Rate Limits and Status Codes You'll Hit

Every public API caps how many calls a client can make. This stops one client from overloading the server. It also keeps the API fair for everyone else. (Speakeasy)

When you go over the cap, the server should reply with 429 Too Many Requests. That code is newer than you'd think. It was added in 2012, in RFC 6585. (InventiveHQ)

Some older APIs reply with 503 Service Unavailable instead. That's the wrong code. 503 means the server itself is down. It doesn't mean one client went over its limit. Use 429 for that case. Save 503 for real outages.

Good APIs also add rate-limit headers to every reply. Win or lose, you get X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. A client can read these and slow down on its own, before it gets blocked. (Speakeasy)

The Underused Angle: AI Agents Are Now Making the Calls

Most guides on this topic assume a person built the app that's calling. That assumption is fading fast.

Postman's 2025 State of the API Report asked over 5,700 developers about this. 89% said they use AI in their daily work now. Only 24% said they design their APIs for AI agents. (Postman)

That gap is a problem. An AI agent doesn't read your docs like a person does. It calls your API based on your schema shape and your field names. Over half of developers, 50.8%, named unwanted or excess API calls from AI agents as their top security worry. (Postman)

Your API may soon get called by agents as often as by browsers. Clear method rules and honest rate-limit headers stop being extras at that point. They become the contract an agent actually reads.

Conclusion

An API call is a simple exchange. A client asks. A server answers. The method picks the action. The status code reports the result. Rate limits keep the whole system fair under load.

That contract matters more now that AI agents call APIs too, not just people. A CMS's delivery API is no exception. See Draftbase pricing for API access, or browse the Draftbase blog for more on content infrastructure.