Learning path map
Detailed content
⚙️ Environment setup
Choose the platform, create accounts, configure credentials and API keys securely, understand the anatomy of a workflow, and run your first “hello world.”
n8n is an open-source automation platform (self-hosted or cloud) with visual logic in nodes; Make is a 100% hosted no-code alternative. You only need one to build.
The choice determines cost, data control, and the complexity ceiling. Self-hosted n8n is cheap and flexible; Make is faster to get started with but charges per operation.
Self-host vs. cloud, cost per run vs. per operation, vendor lock-in, code when needed (n8n Code node).
Credentials are reusable objects that store access to a service (Gmail, OpenAI, Supabase) once and reuse it across all nodes.
Centralizing the credential avoids pasting the same key into 10 nodes and lets you change the password in one place if it leaks.
Credential type, OAuth vs API key, permission scope, service account dedicated to the automation.
Environment variables store values outside the code (keys, URLs, IDs) in a file .env or in the service dashboard.
Separating configuration from logic lets the same workflow run in development and production by changing only the environment, without editing nodes.
.env, $env in n8n, never commit secrets; use values per environment.
Practices to ensure keys and tokens never appear in logs, screenshots, repositories, or webhook response bodies.
A leaked LLM key can rack up a bill of thousands of reais in hours. An exposed secret is a beginner’s most expensive mistake.
Key rotation, principle of least privilege, secret manager, masking data in logs.
A workflow is a graph: nodes (boxes that do something) connected by links that pass data in JSON item format.
Understanding that everything is “a list of items flowing between nodes” is the mental model that unlocks everything else.
Node, connection, item, $json, trigger vs. action, data flow.
A minimal flow: a Manual Trigger connected to a node that writes a message — your first end-to-end run.
Proving that the environment runs eliminates 90% of the anxiety. You see data coming out of one node and entering another.
Manual Trigger, Set/Edit Fields node, run and read the output, execution panel.
🔁 First end-to-end automation
From trigger to action: fire via webhook or schedule, collect the input, call the AI, parse the output, execute the action, and observe the result as it runs.
The node that starts the workflow: a Webhook responds to an HTTP call; a Schedule Trigger runs at set times (cron).
The trigger type determines whether the automation is reactive (someone sends data) or proactive (runs on its own every hour).
Webhook URL, HTTP method, Schedule/cron, input payload.
Extract the fields that matter from the incoming item — the webhook body, query string, or spreadsheet rows.
AI is only as good as the context you give it. Collecting the right fields is half the quality of the result.
$json.body, Set node, expressions ={{ }}, basic validation.
Send the prompt + data to a model via a native node (OpenAI/Anthropic) or via HTTP Request when the node doesn’t exist.
It's the heart of AI automation. Knowing how to build the prompt in the node and request structured output saves parsing later.
System vs. user prompt, temperature, JSON mode, cost per token.
Turn the model's response (text) into structured fields that the next nodes can use.
Without parsing, the output is a loose string. Structuring it lets you write to columns, make decisions in IFs, and map fields.
JSON.parse, Code node, structured output parser, fallback if malformed.
The step that creates visible value: sending the email, writing the row to the spreadsheet, inserting the record into the database.
Without action, it’s just invisible processing. The action is what the client notices and pays for.
Output node (Gmail/Sheets/Postgres): map fields and confirm success.
Run the actual workflow and inspect item by item what went in and out of each node in the execution panel.
Reading the execution is how you debug automation: the error is almost always in the data format between two nodes.
Execution log, pin data, re-run with fixed input, inspect input/output.
🔌 Integrations and data
Connect the world: HTTP Request and REST APIs, Bearer/OAuth authentication, read and write data in Supabase, spreadsheets, pagination and loops, and handling nulls in mapping.
The HTTP Request node talks to any REST API: you choose the method, URL, headers, and body, and receive the response as an item.
When there’s no native node, HTTP Request gets the job done. Knowing how to use it unlocks 100% of integrations.
GET/POST/PUT/DELETE, status code, query params, JSON body.
How the API proves who you are: a token in the header Authorization: Bearer ... or an OAuth flow with consent.
Error 401 is the most common stumbling block in integrations. Understanding Bearer vs OAuth resolves most roadblocks.
Bearer token, OAuth2, refresh token, Authorization header.
Persist data in a database (Supabase/Postgres): SELECT to read, INSERT/UPDATE/UPSERT to write results.
The database is the automation’s memory. Without it, every run forgets everything, and you can’t prevent duplicates.
SELECT/INSERT/UPSERT, unique key, WHERE filter, Supabase REST.
Use Google Sheets as input (read rows) or output (append/update)—the favorite "database" of people who aren’t developers.
Clients understand spreadsheets. Delivering the result in a tab is the fastest way to show value without training anyone.
Append row, update by key, column→field mapping, range.
Process many items in batches and fetch API pages using a cursor/offset, rather than trying to do everything at once.
APIs limit how many items they return per call and impose rate limits. Pagination is what separates a prototype from production.
SplitInBatches, Loop Over Items, cursor/offset, rate limit, wait.
Use expressions to transform and protect data: a default value when it’s null, rename fields, format dates.
An unexpected null field breaks the flow midway. Handling nulls is what makes automation resilient to dirty data.
={{ $json.email ?? 'sem-email' }}, optional chaining ?., default, map.
🛡️ Reliability
What separates a toy from a service: error handling, retries and timeouts, idempotency, observability, staging tests, and a checklist before going to production.
Capture failures instead of letting the flow die silently: global error workflow, node error branch, continue on fail.
In production, everything eventually fails. Systems that handle errors notify you; systems that don’t leave you to find out from an angry customer.
Error Trigger, continue on fail, Stop and Error, error branch.
Rerun a node that failed for a transient reason (unstable API, timeout), with a wait between attempts.
Many failures are temporary. A retry with backoff turns “it errored” into “it fixed itself on the 2nd attempt.”
Retry on failure, max attempts, wait between attempts, timeout, backoff.
Ensure that running the same input twice produces the same effect—it doesn’t create two records or send two emails.
Retries and webhooks redeliver. Without idempotency, each resend creates a duplicate, and the client gets charged 3 times for the same thing.
Idempotency key, UPSERT, dedupe, check before inserting.
Knowing what the automation is doing: log executions and trigger an alert (Slack/email) when something fails.
You can’t fix what you can’t see. Proactive alerts are the difference between 5 minutes and 5 hours of losses.
Structured log, Slack alert, success metric, execution history.
A separate environment (staging) with test data to validate changes before touching production.
Testing directly in production breaks the customer's live service. Staging is your safety net.
Staging vs. production, test data, pin data, smoke test.
A final checklist: handled errors, retries, idempotency, alerts, secrets, and a rollback plan in place.
The checklist turns “I think it’s ready” into “it’s ready”—and it’s what you show the client as a guarantee.
Go-live checklist, rollback, active monitoring, responsible owner.