Back to Getting Started
Getting Started

What Is an API? (Plain English)

Non-technical explanation of APIs, REST, authentication. Diagrams included.

What Is an API
? (Plain English)

An API

(Application Programming Interface) is a set of rules that lets one piece of software request data or actions from another piece of software. That's it. No mystery, no magic.

When your law firm's practice management system pulls client data into your billing software, that's an API

. When your accounting platform fetches bank transactions automatically, that's an API
. When your CRM
 syncs contacts with your email system, that's an API
.

APIs

are the reason you don't manually copy-paste data between systems all day. They're the plumbing that connects your software stack.

The Restaurant Analogy (Actually Useful)

You sit at a table. You don't walk into the kitchen and grab ingredients. You tell the waiter what you want. The waiter takes your order to the kitchen, the kitchen prepares it, and the waiter brings it back.

In this scenario:

  • You = your application (your CRM
    , your billing system, your custom tool)
  • The waiter = the API
  • The kitchen = the database or service you're requesting from
  • The menu = the API
     documentation (tells you what you can order)

The waiter doesn't let you order a cheeseburger if the kitchen only makes Italian food. Similarly, an API

only accepts requests it's designed to handle.

How APIs
 Actually Work (Step by Step)

Here's what happens when your application makes an API

request:

Step 1: Your application sends a request
Your app constructs a URL (called an endpoint) and sends it to the API

server. Example: https://api.example.com/clients/12345

Step 2: The API

authenticates you
The API
 checks your credentials (usually an API
 key or token) to verify you're allowed to make this request.

Step 3: The API

processes your request
The server retrieves the data you asked for or performs the action you requested.

Step 4: The API

sends a response
You get back a structured data package (usually JSON format) containing the information you requested or a confirmation that your action completed.

Step 5: Your application uses the data
Your app parses the response and displays it to users or stores it in your database.

Total time: typically 100-500 milliseconds.

REST APIs
 (The Standard You'll Actually Use)

REST (Representational State Transfer) is the dominant API

architecture. If someone says "API
" without qualifiers, they probably mean a REST API
.

REST APIs

use standard HTTP methods. Here's what each one does:

GET - Retrieve data (read-only, doesn't change anything)
Example: GET /clients/12345 fetches client #12345's information

POST - Create new data
Example: POST /clients with client details creates a new client record

PUT - Update existing data (replaces the entire record)
Example: PUT /clients/12345 updates all fields for client #12345

PATCH - Update specific fields (partial update)
Example: PATCH /clients/12345 updates only the email address

DELETE - Remove data
Example: DELETE /clients/12345 deletes client #12345

REST APIs

return status codes that tell you what happened:

  • 200 OK - Request succeeded
  • 201 Created - New resource created successfully
  • 400 Bad Request - You sent malformed data
  • 401 Unauthorized - Your credentials are invalid
  • 404 Not Found - The resource doesn't exist
  • 500 Internal Server Error - The API
     server broke (not your fault)

Authentication Methods (What You Need to Know)

APIs

need to verify you're authorized to access their data. Here are the four methods you'll encounter:

API
 Keys

The simplest method. You get a long string (like ak_live_3x4mpl3k3y789) and include it in every request.

Include it in the header:

Authorization: Bearer ak_live_3x4mpl3k3y789

Or in the URL (less secure):

https://api.example.com/clients?api_key=ak_live_3x4mpl3k3y789

When you'll see this: Simple internal tools, weather APIs

, mapping services.

OAuth 2.0

The standard for accessing user data on their behalf. You've used this when you clicked "Sign in with Google" or "Connect to QuickBooks."

The flow:

  1. User clicks "Connect to [Service]" in your app
  2. They're redirected to the service's login page
  3. They grant permission
  4. Your app receives an access token
  5. You use that token for all future requests on their behalf

When you'll see this: Any integration where you access a user's data in another system (Gmail, Salesforce, Xero, etc.).

JSON Web Tokens (JWT)

A self-contained token that includes encoded user information. The server can verify it without checking a database.

Looks like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

When you'll see this: Modern SaaS platforms, custom applications, mobile app backends.

Basic Authentication

Username and password sent with each request (Base64 encoded). Simple but less secure.

When you'll see this: Legacy systems, internal tools, development environments.

Real Example: Pulling Client Data

Let's say you want to fetch a client's information from your practice management system's API

.

Step 1: Get your API

credentials
Log into your practice management system, navigate to Settings > API
 Access, generate an API
 key. You get: pk_live_abc123xyz789

Step 2: Find the endpoint in the documentation
The docs say: GET https://api.practicemanager.com/v1/clients/{client_id}

Step 3: Construct your request
Replace {client_id} with the actual ID: https://api.practicemanager.com/v1/clients/45678

Step 4: Include authentication
Add your API

key to the request header:

GET /v1/clients/45678 HTTP/1.1
Host: api.practicemanager.com
Authorization: Bearer pk_live_abc123xyz789

Step 5: Receive the response
You get back JSON data:

{
  "id": 45678,
  "name": "Acme Corporation",
  "email": "contact@acme.com",
  "phone": "555-0123",
  "status": "active",
  "billing_rate": 350
}

Step 6: Use the data
Your application parses this JSON and displays it in your interface or stores it in your database.

Common API
 Mistakes (And How to Avoid Them)

Mistake 1: Hardcoding API

keys in your code
Never commit API
 keys to version control. Use environment variables instead.

Mistake 2: Not handling rate limits
Most APIs

limit how many requests you can make per hour. Check the documentation and implement retry logic.

Mistake 3: Ignoring error responses
Always check the status code. A 200 response means success. Anything else requires error handling.

Mistake 4: Not reading the documentation
Every API

is different. Spend 20 minutes reading the docs before you write a single line of code.

Mistake 5: Using production keys for testing
Most services provide separate test/sandbox keys. Use them during development.

What to Look for in API
 Documentation

Good API

documentation includes:

  • Base URL - Where all requests go (e.g., https://api.service.com/v1)
  • Authentication method - How to prove you're authorized
  • Endpoints list - All available URLs and what they do
  • Request examples - Sample code showing how to make requests
  • Response examples - What the data looks like when it comes back
  • Rate limits - How many requests you can make per hour/day
  • Error codes - What each error means and how to fix it
  • Changelog - How the API
     has changed over time

If the documentation is missing any of these, expect problems.

When You Need an API
 vs. When You Don't

You need an API

when:

  • You're connecting two software systems
  • You're building a custom tool that needs live data
  • You're automating a repetitive data transfer task
  • You're building a mobile app that needs server data

You don't need an API

when:

  • A simple CSV export/import works fine
  • You're doing a one-time data migration
  • The systems already have a built-in integration
  • You're just viewing data (a report might be enough)

APIs

add complexity. Use them when the automation value exceeds the setup cost.

Next Steps

Pick one system you use daily that has an API

. Read its documentation for 15 minutes. Find the authentication section. Locate one endpoint that retrieves data you care about.

That's how you learn APIs

. Not by reading theory, but by poking at real systems until they respond.

Revenue Institute

Reviewed by Revenue Institute

This guide is actively maintained and reviewed by the implementation experts at Revenue Institute. As the creators of The AI Workforce Playbook, we test and deploy these exact frameworks for professional services firms scaling without new headcount.

Visit Revenue Institute →Get the Book →

Related Reading

Getting Started

90-Day Implementation Planner

Read Guide

Getting Started

ROI Calculator (General)

Read Guide

Getting Started

n8n Self-Hosting Setup Guide (GCP)

Read Guide

Related Links

Workflows

Browse Ready-to-Use n8n Workflow Files

Read

Platform Guides

Tool Comparisons & Setup Guides

Read

Revenue Institute

Need help turning this guide into reality? Revenue Institute builds and implements the AI workforce for professional services firms.

RevenueInstitute.com