n8n Masterclass
0/24 complete

Module 03 · Working With APIs

The HTTP Request Node: Your Universal Connector

25 minfocused lesson5practical steps4grounded questions3source links
Open lesson + course map

On this lesson

Course outline

The HTTP Request node can call APIs not covered by a dedicated node. “Universal” means protocol flexibility, not permission to call arbitrary URLs. Define destination, method, authentication, schema, pagination, rate behavior, timeout, and idempotency before the node runs.

// concept

Read the API Contract

From official documentation record:

// prompt — copy me11 lines
base URL and supported version
method/path
authentication and required scopes
headers/content type
request/response schemas
pagination and filtering
rate-limit headers
timeouts/retries
idempotency support
error codes
webhook/status reconciliation

Pin the base URL in configuration or credential, not user/model input. Block private/link-local networks and unapproved redirects when accepting any dynamic destination; arbitrary fetching creates SSRF risk.

// concept

Build Read Before Write

Start with a synthetic GET. Validate status, content type, size, and response fields. Use batching/pagination with caps. Store only needed fields.

For POST/PATCH/DELETE, separate a prepared request from execution. Use an authoritative service for authorization and stable idempotency. A successful HTTP status still needs domain validation; 200 can contain an error object or stale state.

// worked_example

Worked Example

A sample inventory API supports GET /v1/items/{sku}. n8n accepts a validated SKU matching ^[A-Z0-9-]{2,20}$, constructs the path against a fixed base URL, applies a scoped credential, and expects JSON under a size limit.

It maps only SKU, sellable quantity, price reference, and updated_at. Unknown SKU becomes NOT_FOUND; 429 returns a bounded retry instruction; HTML or unexpected schema stops. The workflow cannot supply a new host or query internal metadata addresses.

// failure_cases

Failure Cases to Diagnose

6 cases to diagnose

  • URL comes from form input

    allowlist base and path parameters.

  • Secret in query string

    use supported auth headers/credentials.

  • All response fields persisted

    minimize and redact.

  • Pagination unbounded

    cap pages/items/time.

  • HTTP 200 called business success

    validate body/state.

  • Write retries blindly

    reconcile and deduplicate.

// pakistan_angle

Pakistan Angle

Pakistani courier, payment, wallet, SMS, and government APIs may differ in documentation and availability. Use the authorized official endpoint and contract; do not replace it with scraping when unavailable.

Never send OTP, PIN, banking password, or unnecessary CNIC data. Use provider transaction/order references and display pending states honestly during outages.

// hands_on

Hands-On Exercise

5 steps

  1. Document one official API contract.

  2. build a fixed-destination GET.

  3. validate response status/type/schema/size.

  4. add capped pagination and rate handling.

  5. test SSRF-like URL, HTML response, 429, and malformed JSON.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// sources

Sources

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4
  1. 1 / 4 · diagnose

    Your work shows this failure mode: “Secret in query string.” What does the lesson tell you to do about it?