You've used AI tools. Now learn how the apps you use every day actually talk to each other — and how to make them do new things for you.
An API is how one piece of software asks another for something. If you've ever ordered from a restaurant menu, you already understand the idea.
You sit down at a restaurant. You don't walk into the kitchen and start cooking — you read the menu, tell the server what you want, and wait. The kitchen does the work. The server brings back the dish.
An API is the menu. The kitchen is the server (where the data lives). You're the customer. The server (the API) takes your specific request and brings back exactly what you asked for — no more, no less.
Request — what you ask for. Response — what comes back. That's the whole loop. Every API call is just request → response.
Every recruiting tool you use — Ashby, Greenhouse, BrightHire, LinkedIn Recruiter — is built on APIs talking to each other. When you click "Move to Job Fit" in your ATS, your browser is making an API call. Understanding what's happening under the hood unlocks two things:
Enough theory. Let's actually do it. We'll use GitHub's public API — no signup, no key, just type a username and see real data come back.
Every API call has a few parts. Here's what we're about to send to GitHub:
There are other verbs (POST to create, PUT to update, DELETE to remove), but GET is by far the most common. 90% of what a recruiter would do with an API starts with GET.
There isn't one. That's the unusual part, and it's worth explaining so you don't think this is how all APIs work.
GitHub's public profile data is exactly that — public. The same data you can see by going to github.com/octocat in your browser. So GitHub lets anyone read it without authentication. Your browser doesn't have a "key" when you visit github.com; this API call works the same way.
That's why this demo runs in your browser with zero setup. It's the friendliest possible "first API call."
But most APIs aren't like this. Anthropic, OpenAI, Ashby, BrightHire, Slack — all require a key on every request. Even GitHub requires one as soon as you want to do anything beyond public reads (search private data, post comments, etc.). The reasons are universal:
Concept 04 covers what keys look like, where they come from, and the safe ways to handle them. For now, just know: this demo is the exception, not the rule.
JSON (JavaScript Object Notation) is the format almost every modern API returns. It's structured data — key-value pairs like "name": "The Octocat" — that apps can read and use. The "raw JSON" panel shows exactly what GitHub sent. The "parsed" panel shows what that data looks like once you pull out the pieces you care about. Same data, two views.
You just did programmatically what a recruiter normally does by going to github.com/octocat in a browser. The browser does the same call under the hood. The difference: you can now do this at scale — fetch 50 profiles in a Zap, paste a list into a Claude conversation, automate the whole thing.
Most APIs do more than fetch one record at a time. Parameters let you filter, search, and combine — which is where the real sourcing power shows up.
Parameters are extra instructions you tack onto the URL. They come after a ?. Multiple parameters are joined with &. For example:
That URL above? It's basically "find me Python engineers in Portland." No sourcing tool needed. The API is the sourcing tool.
One API endpoint, one URL, and you can:
This is the same logic LinkedIn Recruiter Search uses — boolean filters narrowing a giant pool down to a list of relevant candidates. Except the GitHub version is free, returns more depth on people's actual work, and you can automate it.
Four things you'll trip over the first time you use an API for real: API keys, rate limits, errors, and sensitive data. Knowing these up front saves you hours of confusion later.
GitHub's public endpoints don't require a key, which is why this module works without one. But most APIs you'll use professionally (Ashby, BrightHire, Anthropic, OpenAI, Slack) require a key — a long random string that proves who you are and what you're allowed to do.
Think of it like a hotel key card. It's tied to you, it controls what rooms you can enter, and if you lose it, anyone holding it can walk in pretending to be you.
Every API provider has an "API keys" or "Developer settings" section in their dashboard. You log in, click a button, and they generate a unique key for you. Here's roughly what that looks like:
| Name | Key (last 4) | Created | Status |
|---|---|---|---|
| Production Zap | ···f3Lq | Jan 12, 2026 | Active |
| Old Slack Bot | ···9Aab | Nov 04, 2025 | Revoked |
Anthropic, OpenAI, GitHub, Ashby — almost every provider only shows the full key one time, at creation. After that, only the last 4 characters are visible. If you forget where you stored it, you have to generate a new one and update everywhere it was being used. Store it carefully the moment you create it.
Different providers use different formats, but they all share a recognizable prefix that tells you which provider it came from. Some examples (these are fake, but the format is real):
If you ever see a string starting with sk-ant- in a Slack channel or a Google Doc — that's an Anthropic key in the wild and someone has a problem. Train your eye to recognize them. Tools like GitHub's secret scanning and Slack's data loss prevention auto-detect these patterns.
The key goes in a header on the request — a piece of metadata sent alongside the URL. The API reads the header, checks the key, and decides whether to respond.
When you connect Anthropic to Zapier, or paste a key into Claude Desktop's settings, or add it to a `.env` file — what's happening behind the scenes is that tool is attaching this Authorization header to every API call it makes on your behalf.
.env files, never committed).env file?If you've ever followed a tutorial that said "add your API key to a .env file" and felt lost — you're not alone. It's one of the most common stumbling blocks for non-engineers, and it's actually really simple once you see it.
A .env file is just a plain text file that lives in your project folder. It holds your secrets (API keys, passwords, database URLs) as a list of key-value pairs. Apps read those values at startup, so the secrets never appear in the actual code.
Here's how each piece works:
.env — holds the actual secret values. Lives only on your computer (or your server). Never gets shared..gitignore — a safety net that tells Git "if you ever try to commit .env to GitHub, refuse." This is what stops you from accidentally pushing your keys to a public repo.The format inside .env is just KEY_NAME=value, one per line. No quotes needed, no spaces around the equals sign. Lines starting with # are comments.
Instead of hardcoding the key in the source code (where anyone reading the code would see it), the code references the variable name. The actual value loads from .env at runtime:
Think of .env as the "secrets drawer" of a project. The code knows there's a drawer with a label like ANTHROPIC_API_KEY. It opens the drawer and uses whatever's inside. If you replace the key, the code keeps working — you just swap the contents of the drawer. The code itself never changes.
Forgetting to add .env to .gitignore before your first commit. The keys then get pushed to GitHub, and even if you delete them later, they live in git history forever. Always set up .gitignore first. Most modern project templates (created via npx, create-react-app, etc.) handle this for you automatically — but always double-check.
.env files.env".env.example showing what variables you need to fill in).env automaticallyIf you're using no-code tools (Zapier, n8n, Claude Desktop), you usually don't need a .env file — those tools have their own "credentials" UI that does the same job. .env mostly matters when you're writing or running actual code.
Revoke it immediately in the provider's settings (every provider has a "Revoke" button), then generate a new one. A leaked key can run up bills, expose data, or get your account suspended. Editing or deleting the message isn't enough — cached copies, notifications, and other people's screens may have seen it. Speed matters more than damage control.
APIs cap how many requests you can make in a window of time. GitHub's unauthenticated limit is 60 requests per hour, per IP address. With a key (free), that jumps to 5,000/hour. If you hit the cap, the API returns a 403 error until the window resets.
Rule of thumb: if you're calling an API in a Zap or a loop, count your calls. 50 candidates × 3 lookups each = 150 calls. Plan for that.
Every response comes with a status code. The common ones:
This is the most important section. APIs are powerful, but they send your data to someone else's server. If you wouldn't email it to an external vendor, don't send it to an API without thinking hard first.
At Zapier, our People Team data classification rules apply to API usage too: yellow-tier data (candidate PII, comp ranges, interview notes) needs approval before being routed through Zapier products or third-party APIs. Red-tier data (medical notes, pre-announcement reorg info) is prohibited.
If you're not sure whether you can route a piece of data through an API, ask your data governance owner. At Zapier, that's #wg-people-ai-transformation. Better to ask once than to find out the hard way.
A few things that'll save you time when you go from this module to something useful at work.
Every API publishes documentation. Skim it before writing your first call — it'll show you the endpoints, the parameters, the limits. Don't guess.
Before wiring an API into a Zap or a script, hit it once manually. Confirm it returns what you expect. Then automate.
If you're looking up the same data repeatedly, save the response somewhere (a Google Sheet, a database). Don't re-call the API for data that doesn't change.
Build delays into bulk operations. 60 calls per hour means roughly one per minute. Slamming an API gets you blocked.
When something breaks (and it will), you'll want to see what request you sent and what came back. Keep logs in your automation tool.
Get one candidate lookup working perfectly before running 200 in a loop. Bugs at scale are 200x more painful to debug.
Now that you understand requests, responses, parameters, and the real-world gotchas, you're set up for the next module: building your first MCP — wrapping an API like GitHub into a tool that Claude or Sidekick can use natively. Same concepts, applied differently.
Five quick questions. Click an answer to see if you've got it.
GET https://api.github.com/users/octocat and get back a JSON response. What did you actually do?