What is an API?

Hands bring information from several wordless workplace documents into one summary report.

Imagine preparing a weekly report without opening five tools, copying numbers, and fixing their formats.

Your report could ask each place for the information it needs. An API is the agreed way that request happens.

See how it works
Start with the work

The report is familiar. The repeated copying is the problem.

Every Monday, you open the advertising platform, a spreadsheet, and the finance tool. You find the latest figures, copy them, correct their formats, and paste them into one report.

Each place organizes information differently. You know what the report needs, but you repeat the same transfer by hand.

A desk scene contrasts scattered manual paper handling with three distinct sources connected to one summary.
Without a connection

A person moves every value, every time. A missed row or old figure can travel into the report unnoticed.

With an API

The report asks each source for a specific piece of information under agreed rules. The sources remain different.

An API is an agreed way for one tool to ask another tool for information or request an action, without needing to understand everything happening inside it.
Developers often describe those agreed rules as a contract between systems.

What changes in practice

The connection handles a repeated exchange. People still decide what the report should say and check whether the result makes sense.

  • Less copying and pasting
  • More current information
  • Fewer transcription mistakes
  • A process that can run the same way next week
  • Access limited to information the source permits

Where the idea shows up

Look for work where two tools need a repeatable, controlled exchange. The department does not need to be technical.

Marketing

Bring current campaign results into a weekly summary without copying each metric.

HR

Send approved employee details into an onboarding process while keeping access limited.

Accounting

Move invoice information into the accounting process instead of entering it twice.

Finance

Use current rates in a report or internal calculator and record where they came from.

An API may fit when

  • The same information moves between tools repeatedly.
  • The result needs to stay current or run on a schedule.
  • The source offers the required information or action with suitable permissions.

It may not fit when

  • The task is genuinely one-time and manual work is quicker.
  • The source does not expose the information you need.
  • Access is unavailable, too restricted, or too expensive.
  • Nobody has defined how to validate the result or handle a failed connection.

Bring a clear workflow to the development team

You define the work goal and check the outcome. The development team reviews implementation, permissions, security, and reliability.

An LLM can help describe the workflow, read documentation, draft code, and explain errors. It does not automatically have access to private or current company information. Official documentation and development review remain authoritative.

Questions worth answering first
  1. 1.Does the tool where this information lives offer an API?
  2. 2.Which information or actions does it expose?
  3. 3.What permissions are required?
  4. 4.How current does the information need to be?
  5. 5.What should happen if the connection fails?
01 / Formal model

Now put technical names on the exchange

One tool sends a request. The other processes it and returns a response under the rules its API defines.

If an LLM drafts an API call, verify the URL, parameters, and authentication method against the provider's official documentation. Never paste a secret key into public code or a public chat.
Your Application
External Server
1Request
2Processing
3Response
Request

Your app packages a question: what data do you need, in what format, with what credentials.

Processing

The server validates your request, retrieves or computes the data, and prepares a response.

Response

You receive structured data (JSON, XML, or binary) ready to parse and use in your analysis.

An everyday example

When you search for a flight, you enter a departure city, a destination, and a date. The airline's system returns available flights with prices and schedules. You never see the database, the pricing engine, or the seat inventory. You just fill in the inputs and get back the outputs. That search form is an API in disguise: structured inputs produce structured outputs, and the complexity stays hidden on the other side.

APIs are just functions, over a network

A developer or LLM may express the same exchange in code. The local example calls a function on one computer. The API example sends the inputs to another computer and reads its response. You do not need to write this code to discuss what it should do.

A function takes inputs and returns an output. For example, get_mortality(age=45) could return 0.00354 on the same computer. An API call sends parameters to a URL on another computer and receives a response. The comparison is useful, though an API also has network, permission, and failure concerns that a local function may not have.

Local function
# Local function call
result = get_mortality(age=45)
print(result)  # 0.00354
API call
# Same logic, but via API
import requests
response = requests.get(
  "https://api.example.com/mortality",
  params={"age": 45}
)
print(response.json())
# {"qx": 0.00354}
A brief history

Why do APIs exist?

Early programs often kept their code and data on one machine. As software began exchanging information across machines and organizations, each connection needed agreed rules. An API publishes the rules for a particular exchange, so one system can ask another for something without depending on its internal implementation.

1960s

Subroutine libraries let programs share code within a single machine.

1990s

The web arrives. Systems need to exchange data across networks. SOAP and XML-RPC appear.

2000

Roy Fielding defines REST in his dissertation. Simple, stateless, URL-based.

2010s

REST APIs become the standard. Twitter, Stripe, Google Maps expose public endpoints. JSON replaces XML.

Today

APIs connect many everyday services, including weather apps, banking tools, maps, and machine-learning systems.

02 / Guided request

See one exchange happen

Start with a prepared request. The advanced controls remain available when you want to change the question.

Recommended first request

Ask for a 10-year Treasury rate

FRED publishes economic data. The prepared values below ask for one series and return its observations over time.

  1. 01Keep FRED selected and use the visible default values.
  2. 02Select Send Request. The server will return data for those inputs.
  3. 03In the formatted result, look for dates paired with interest-rate values.
Quick fill

Parameters

Series identifier, such as DGS10, FEDFUNDS, or CPIAUCSL

First observation date in YYYY-MM-DD format

Last observation date in YYYY-MM-DD format

How often observations should appear

Request Preview
GET/api/proxy/fred?path=/series/observations&series_id=DGS10&observation_start=2020-01-01&frequency=m
Provider endpoint: https://api.stlouisfed.org/fred
Response

Send a request to see the response here.

03 / Access and safety

API keys and why they matter

Some APIs require the server to identify who is making a request, how often they call it, and what they may access. API keys are one common way to do that.

What is an API key?

An API key is a unique string that identifies you to the server. When you register for access to an API (like FRED or Banxico), the provider gives you a key. You include it in every request, usually as a header or query parameter. The server checks the key before responding.

Why not leave APIs open?

Without authentication, anyone could flood a server with millions of requests, consume expensive compute resources, or scrape proprietary data. API keys let the provider track usage per user, enforce rate limits (e.g. 120 requests per minute), and revoke access if someone abuses the system.

What happens if your key is exposed?

If you accidentally commit your API key to a public GitHub repository, push it in frontend JavaScript, or share it in a message, anyone who finds it can make requests as you. On paid APIs, this means charges on your account. On sensitive APIs, it means unauthorized access to your data. Leaked keys are one of the most common security incidents in software.

Basic rules
  1. 1.Never hardcode keys in your source code.
  2. 2.Use environment variables (.env files) to store them.
  3. 3.Never expose keys in frontend/client-side code.
  4. 4.Rotate keys periodically and revoke old ones.
  5. 5.Use a backend proxy to keep keys server-side.
Exposed key
# Never do this
response = requests.get(
  "https://api.fred.org/series",
  params={"api_key": "abc123secret"}
)
Key from environment
# Do this instead
import os
api_key = os.environ["FRED_API_KEY"]
response = requests.get(
  "https://api.fred.org/series",
  params={"api_key": api_key}
)
04 / Analysis

From JSON to insight

The same API responses from the playground, transformed into charts, metrics, and analytical output.

Interest Rates
FRED / FEDFUNDS

Source: FRED API, Federal Reserve Economic Data

Exchange Rates
Banxico / SF43718

Source: Banxico SIE API, series SF43718

Mortality Data
World Bank / SP.DYN.LE00.IN

Source: World Bank Indicators API, SP.DYN.LE00.IN

Risk Metrics
Combined APIs

Sources: FRED, Banxico, and World Bank APIs

05 / From idea to implementation

Plan the work before the code

A useful connection starts with a precise work outcome, an official source, and a clear plan for permissions and failures.

Define the work outcome

Name the information or action you need, who uses the result, and how you will know it is correct.

Find the official source

Confirm that the source offers an API. Read its official documentation for available data, limits, and costs.

Draft the connection

Ask an LLM or the development team to draft the request using the official documentation. Framework choices can wait until the workflow is clear.

Test the full path

Check inputs, outputs, permissions, missing data, and failure behavior. Validate the result with someone who knows the work.

Protect and deploy only when needed

Keep credentials on the server. Schedule or deploy the connection only if the work requires ongoing access.

Ready to go deeper?

You know the fundamentals. Now explore how APIs behave under pressure, how they fail, and how to debug them.

Enter Advanced Mode