---
title: "Webhooks and APIs: connecting anything"
description: "When the built-in app isn't enough Every platform has thousands of prebuilt integrations, but sooner or later you need an endpoint the connector doesn't…"
url: https://optimizeall.com/learn/no-code-ai-automation-n8n-make-zapier/webhooks-and-apis
updated: 2026-10-05
---

AI Automation with n8n, Make and Zapier · APIs, webhooks, LLMs and MCP · lesson 9 of 17 · 16 min

# Webhooks and APIs: connecting anything

## When the built-in app isn't enough

Every platform has thousands of prebuilt integrations, but sooner or later you need an endpoint the connector doesn't support, a new app with no connector, or your own internal system. Then you use **HTTP APIs** and **webhooks** directly: the HTTP Request node (n8n), HTTP module (Make) or Webhooks by Zapier / API request actions (Zapier).

## API essentials in ten lines

- **Endpoint**: a URL such as `https://api.example.com/v1/contacts`.
- **Method**: `GET` (read), `POST` (create), `PUT`/`PATCH` (update), `DELETE`.
- **Headers**: metadata such as `Content-Type: application/json` and `Authorization`.
- **Body**: JSON payload for POST/PUT/PATCH.
- **Query parameters**: `?page=2&limit=100`.
- **Status codes**: 2xx success; 400 bad request; 401/403 auth problems; 404 not found; 409 conflict; 422 validation; 429 rate limited; 5xx server errors.
- **Authentication**: API keys (header or query), Bearer tokens, OAuth 2.0 (user-authorized access with refresh tokens), Basic auth, HMAC signatures.
- **Pagination**: page/limit, offset, or cursor (`next_cursor`) patterns.
- **Rate limits**: requests per second/minute; respect `Retry-After` headers.
- **Docs**: always read the API reference and test with a tool like curl or an API client first.

## Webhooks: APIs in reverse

A webhook is the source app calling **your** URL when something happens. Your automation platform gives you that URL (n8n Webhook node, Make custom webhook, Zapier Catch Hook).

**Security essentials for incoming webhooks:**

1. **Verify signatures**: many providers sign payloads with HMAC (for example Stripe, Shopify, GitHub, and many others). Compute the signature over the **raw body** with your secret and compare in constant time.
2. **Check timestamps** to reject replayed requests.
3. **Use secret, unguessable URLs** and rotate them if leaked; do not rely on obscurity alone.
4. **Respond fast** (2xx within a few seconds) and process asynchronously; providers retry on timeouts, which can create duplicates.
5. **Be idempotent**: providers can deliver the same event more than once; store event IDs and ignore repeats.

## Hands-on: verify an HMAC-signed webhook (Python)

A small verification service you can run in front of any platform, or adapt in a code step:

```python
import hmac, hashlib, os, time
from fastapi import FastAPI, Request, HTTPException

app = FastAPI()
SECRET = os.environ["WEBHOOK_SECRET"].encode()
SEEN = set()  # use a database or Redis in production

@app.post("/hooks/orders")
async def orders(request: Request):
    raw = await request.body()
    sig = request.headers.get("X-Signature", "")
    ts = request.headers.get("X-Timestamp", "0")
    if abs(time.time() - int(ts)) > 300:
        raise HTTPException(401, "stale")
    expected = hmac.new(SECRET, f"{ts}.".encode() + raw, hashlib.sha256).hexdigest()
    if not hmac.compare_digest(expected, sig):
        raise HTTPException(401, "bad signature")
    event = await request.json()
    if event["id"] in SEEN:
        return {"ok": True, "duplicate": True}
    SEEN.add(event["id"])
    # forward to n8n/Make/Zapier, or enqueue for processing
    return {"ok": True}
```

Header names and signing formats differ by provider; follow each provider's documentation exactly (some sign only the body, some include a timestamp, some base64-encode).

## Calling APIs well from automations

- **Store credentials in the platform's credential manager**, never in plain fields or code.
- **Handle pagination** with loops until no next page (n8n's HTTP Request node has built-in pagination options; Make supports pagination in some modules and via repeaters; Zapier code or looping).
- **Respect rate limits**: batch, add waits, use sequential processing.
- **Parse errors meaningfully**: map 4xx to data problems (fix and alert), 429/5xx to transient problems (retry with backoff).
- **Log request IDs** returned by APIs for support tickets.

## Worked example: connecting a Pakistani courier API with no connector

A Lahore e-commerce brand needs to create shipments with a local courier that offers a REST API but no n8n/Make/Zapier app.

- n8n: HTTP Request node, POST `/shipments`, header auth credential, JSON body mapped from the order; on 422, route to a Slack alert with the validation message; on 429/5xx, retry with wait.
- The courier sends status updates to a webhook; the n8n Webhook node receives them, verifies a shared-secret header, updates the order in Shopify and sends a WhatsApp template update to the customer (opted-in).
- Tracking numbers are stored against order IDs to keep updates idempotent.

## Test before you automate

```bash
curl -sS -X POST "https://api.example-courier.pk/v1/shipments" \
  -H "Authorization: Bearer $COURIER_API_KEY" -H "Content-Type: application/json" \
  -d '{"order_ref":"SO-1042","city":"Lahore","cod_amount":4500,"phone":"+923001234567"}'
```

If it works in curl, it will work in your platform's HTTP step with the same method, headers and body.

## Pitfalls

- Accepting unsigned webhooks from payment or order systems.
- Processing heavy work before responding, causing provider retries and duplicates.
- Hard-coding API keys in code steps or URLs.

## Measuring success

Track webhook signature failures (should be zero except attacks or misconfiguration), duplicate events ignored, API error rates by class (4xx vs 429/5xx), and the time from event to processed record.

## Video lecture: Webhooks and APIs: connecting anything

Lecture coming soon · 13 chapters · about 9 minutes. Read the full transcript below.

1. Webhooks and APIs
2. Why it matters
3. Analogy: a restaurant
4. Essentials
5. Webhooks, secured
6. Hands-on: verify a webhook
7. Example 1: POST without a connector
8. Example 2: Lahore courier integration
9. Five habits
10. Common mistakes
11. Watch me do it: courier API integration
12. Recap + try this now
13. Try this now

## Lecture transcript

### Webhooks and APIs

Sooner or later, every automation builder hits a wall: the app you need has no connector, or the connector doesn't support the one action you need. That's when you reach past the prebuilt modules and talk to APIs directly. The good news: once you understand a handful of ideas, you can connect almost anything. In this lesson you'll learn API essentials, webhooks and how to secure them, how to call APIs reliably from n8n, Make and Zapier, and you'll verify a signed webhook in code.

### Why it matters

Why does this matter? Because the most valuable automations often involve the systems no one else has connected: a local courier, a regional payment gateway, your own internal database, a government portal with an API. In Pakistan and the Gulf, many strong local services offer APIs but no Zapier or Make app. If you can read API docs and make a request, you're no longer limited by someone else's connector list.

### Analogy: a restaurant

Here's an analogy. An API is a restaurant with a menu. The endpoint is the counter you walk up to. The method says what you want to do: GET to look at the menu, POST to place an order, PATCH to change it, DELETE to cancel. Headers are your loyalty card and preferences, including your authorization. The body is your order written out. And the status code is the waiter's reply: two hundred means here you go, four twenty-nine means slow down, we're busy, and five hundred means the kitchen had a problem.

### Essentials

A few more essentials. Status codes in the two hundreds mean success. Four hundreds mean you sent something wrong: four oh one or four oh three for authentication, four oh four not found, four twenty-two validation errors, and four twenty-nine rate limited. Five hundreds are server problems. Authentication comes as API keys, bearer tokens, OAuth for user-authorized access, basic auth, or signed requests. Big lists come back in pages, so you loop until there's no next page. And rate limits cap how fast you can call, often with a retry after header telling you how long to wait.

### Webhooks, secured

Webhooks are APIs in reverse. Instead of you calling the app, the app calls your URL the moment something happens: an order is placed, a payment succeeds, a form is submitted. Your automation platform gives you that URL. But an open URL on the internet needs protection. Verify signatures: many providers sign each payload with a secret using HMAC, and you recompute the signature over the raw body and compare. Check timestamps to reject replays. Respond quickly and process afterwards, because providers retry on timeouts. And be idempotent: store event IDs and ignore repeats, because the same event can arrive twice.

### Hands-on: verify a webhook

The lesson text includes a small FastAPI service that verifies a signed webhook. It reads the raw body, checks the timestamp is within five minutes, recomputes an HMAC SHA two fifty-six signature with your secret, compares it in constant time, and ignores event IDs it has already seen. In production, keep seen IDs in a database or Redis, not memory. And follow each provider's exact signing format, because some sign only the body, some include a timestamp, and some encode differently.

### Example 1: POST without a connector

Example one, simple. You want new rows in a partner's system every time a form is submitted, but there's no connector. In n8n you add an HTTP Request node, set the method to POST, pick a header auth credential, and map the form fields into a JSON body. In Make it's the HTTP make a request module; in Zapier, Webhooks by Zapier POST or an API request action. Before any of that, test the call with curl. If it works in curl, it will work in your platform with the same method, headers and body.

### Example 2: Lahore courier integration

Example two, realistic. A Lahore e-commerce brand ships with a local courier that has a REST API but no connector. In n8n, an HTTP Request node creates shipments from new orders. If the courier returns four twenty-two, the validation message goes to Slack so someone fixes the address. On four twenty-nine or five hundreds, the node retries with a wait. The courier posts status updates to an n8n webhook, which checks a shared secret header, updates the order in Shopify, and sends an opted-in WhatsApp update to the customer. Tracking numbers stored against order IDs keep updates idempotent.

### Five habits

Calling APIs well comes down to five habits. Store credentials in the platform's credential manager, never in plain fields or code. Handle pagination until there's no next page. Respect rate limits with batching, waits and sequential processing. Treat errors differently: four hundreds are data problems to fix and alert on, while four twenty-nine and five hundreds are temporary, so retry with backoff. And log the request IDs APIs return, because support teams will ask for them.

### Common mistakes

And the common mistakes. Accepting unsigned webhooks from payment or order systems, which lets anyone fake an order. Doing heavy processing before responding, so the provider times out and retries, creating duplicates. And hard-coding API keys in code steps, URLs or shared screenshots. Each of these has caused real incidents. Each has a simple fix: verify, respond fast, and use credential storage.

### Watch me do it: courier API integration

Watch me do it. Crescent's clients use a local courier with an API but no connector, so I integrate it into the n8n build. First, curl. I read the courier's docs, export my API key as an environment variable, and create a test shipment with a POST request. It returns two hundred and one with a tracking number. I deliberately send a bad city name and get four twenty-two with a validation message. Now I rebuild the call in n8n: an HTTP Request node, method POST, the shipments URL, a header auth credential for the key, and a JSON body mapped from the order. In the node settings I enable retry on fail with three tries and a five-second wait, and I set on error to continue using the error output. On the error branch I add a Switch node on the status code: four twenty-two goes to a Slack alert with the validation message and order number; anything else goes to our global error handler. Then the inbound side: a webhook node for courier status updates. In a Code node I check the shared-secret header and the event ID against a table of processed events, skipping duplicates. I send the same status event twice with curl, and the second is skipped, which is exactly what idempotency looks like.

### Recap + try this now

Recap. APIs are menus you can order from; webhooks are apps calling you. Know methods, headers, bodies, status codes, auth, pagination and rate limits. Secure webhooks with signatures, timestamps, fast responses and idempotency. Try this now: pick one app you use that has an API but no connector in your platform. Make one successful call with curl, then recreate it in an HTTP step, and add handling for four twenty-two and four twenty-nine.

### Try this now

Try this now. Pick one app you use that has an API but no connector in your platform. Read its authentication and one endpoint in the docs. Make a successful call with curl, keeping the key in an environment variable. Recreate the call in an HTTP step on your platform, with the key in the credential store. Add handling for four twenty-two errors, sending them to a chat alert, and for four twenty-nine and five hundreds, retrying with a wait. Save the curl command in your workflow documentation.

## Key takeaways

- When connectors fall short, use HTTP APIs: endpoints, methods, headers, JSON bodies, status codes, auth, pagination and rate limits.
- Webhooks are the source app calling your URL; verify HMAC signatures over the raw body, check timestamps, respond fast and dedupe event IDs.
- Store credentials in the platform vault, paginate fully, respect rate limits, and treat 4xx (fix) differently from 429/5xx (retry with backoff).
- Test every API call with curl first, then recreate it in the platform's HTTP step.

## Try it

Pick an app with an API but no connector on your platform. Make one successful curl call, recreate it in an HTTP step, and add handling for 422 (alert) and 429 (retry).

- [Previous: Zapier AI: AI by Zapier, Agents, Copilot and MCP](https://optimizeall.com/learn/no-code-ai-automation-n8n-make-zapier/zapier-ai-agents-copilot-and-mcp)
- [Next: Connecting LLM APIs: structured outputs, cost and MCP](https://optimizeall.com/learn/no-code-ai-automation-n8n-make-zapier/llm-apis-structured-output-and-mcp)
- [All lessons of AI Automation with n8n, Make and Zapier](https://optimizeall.com/learn/no-code-ai-automation-n8n-make-zapier)