To automate the world, you must first understand how to connect it. APIs and Webhooks are the protocols that allow disparate systems to function as a single, unified organism.
1The API Request Cycle
An API (Application Programming Interface) is a contract between two pieces of software. When you call an API, you're the one initiating the conversation — you send a request and wait for a response. Think of it like a waiter at a restaurant: you order, they go to the kitchen, and they come back with your data.
In practice, this means calling a URL with an HTTP method (GET to read, POST to write), optionally passing a body or query parameters, and receiving a JSON payload in return. Your automation engine sits idle until it decides to ask. This is the pull model — great for on-demand lookups, but terrible for real-time reactions.
Understanding the HTTP verbs matters more than most tutorials let on. GET requests never have a body — they encode everything in the URL. POST sends a body payload. Use the wrong one and the API will reject you with a 400 or 405 error that takes an hour to debug.
// Calling the GitHub API
const response = await fetch(
'https://api.github.com/users/octocat',
{
method: 'GET',
headers: {
'Authorization': 'Bearer YOUR_TOKEN',
'Content-Type': 'application/json'
}
}
);
const data = await response.json();
console.log(data.name); // 'The Octocat'2Webhooks: The Push Model
Webhooks flip the API model on its head. Instead of you asking for data, the other system tells you when something happens. You register a URL with the external service, and the moment an event fires — a payment succeeds, a form submits, a message arrives — they send a POST request to your endpoint with the event payload.
This is the push model, and it's far more efficient for event-driven workflows. A Stripe payment webhook reaches your server in milliseconds of the transaction. If you'd been polling the Stripe API every 5 seconds instead, you'd be burning API quota and still experiencing a delay.
The critical thing to remember: your endpoint must always be live to receive webhooks. If your server is down when Stripe sends the event, that data is gone — most services retry a few times, but there's no guarantee. This is why n8n's Webhook node (when hosted) or Zapier's endpoints are so valuable: they're always-on listeners.
// n8n Webhook Trigger endpoint
// POST /webhook/stripe-payment
app.post('/webhook/stripe-payment', (req, res) => {
const event = req.body;
if (event.type === 'payment_intent.succeeded') {
const amount = event.data.object.amount;
sendSlackAlert(`Payment of $${amount/100} received!`);
}
res.sendStatus(200); // Always respond 200!
});3API Key Security
An API Key is a credential that proves your application is authorized to talk to a service. It's the equivalent of a password for your code. Most APIs expect it in an Authorization header using the Bearer scheme: Authorization: Bearer sk-abc123....
The single most common mistake junior developers make is hardcoding the key directly in the source file. The moment that file gets pushed to a public GitHub repo, bots scrape it within seconds. Your OpenAI credits vanish overnight. The fix is simple: store secrets in environment variables inside a .env file, and add .env to your .gitignore immediately.
In n8n, you handle this automatically through Credentials — the platform encrypts your API keys and injects them at runtime. You never see the raw key in the workflow JSON. This is the pattern you want to follow everywhere.
# .env file (NEVER commit this)
OPENAI_API_KEY=sk-proj-abc123...
STRIPE_SECRET_KEY=sk_live_xyz789...
# In your code
const openai = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
# .gitignore
.env