Write a how-to post whose steps get checked against the real tool before publish

You are writing a how-to tutorial. Every step needs to be either confirmed against an actual walkthrough of the tool or explicitly flagged as unconfirmed — a plausible-sounding button label that wasn't actually checked is exactly the kind of error that survives editing because it reads as correct even when it isn't.

TASK TO TEACH
Set up a webhook that fires when a new row is added to an Airtable base

TOOL AND VERSION
Airtable, web app, as of the July 2026 Automations redesign

ACTUAL STEPS PERFORMED
Automations tab → Create automation → trigger "When record created" → select base and table → action "Send webhook" → paste URL → hit Test → confirmed 200 response in the log panel.

COMMON FAILURE POINTS
The test webhook often returns a 401 if the receiving endpoint expects a specific header Airtable doesn't send by default — needs a note on adding a custom header in the action config.

AUDIENCE SKILL LEVEL
Comfortable with no-code tools generally, has never set up a webhook specifically before

TUTORIAL RULES
Write only the steps that are confirmed in the actual walkthrough notes provided — never invent a plausible menu label, button name, or screen location to fill a gap in what was actually observed; if a step is needed but wasn't part of the confirmed walkthrough, write it as a flagged placeholder describing what needs to happen, with an explicit note that the exact UI location needs verification before publish, rather than guessing at wording that will read as confident and turn out to be wrong. Number steps atomically — one physical action per numbered step, not two or three actions compressed into one numbered line just to keep the list short; a reader following along loses their place the moment a single step secretly required them to do two things. After any step where a reader might reasonably wonder if they did it right, state what success actually looks like — what changes on screen, what confirmation appears — so the reader can self-check before moving to the next step instead of discovering three steps later that something went wrong earlier. Address every common failure point explicitly, with the actual fix, at the exact step where it's likely to occur — not gathered into a generic troubleshooting section at the end that a reader hits only after already getting stuck and giving up partway through. Note the specific product version this tutorial was verified against, and flag anywhere the walkthrough notes mention behavior that seems version-specific — a menu that moved in a recent redesign, a feature currently in beta — since an unpinned how-to silently goes stale the moment the interface changes, and a reader following an outdated tutorial with no version note has no way to know their confusion is the tutorial's fault, not their own.

OUTPUT FORMAT
1. The tutorial, numbered atomically, with success confirmation stated after any step where it matters and failure-point fixes inline at the relevant step.
2. A list of any steps written as flagged placeholders because they weren't in the confirmed walkthrough, stating exactly what needs verification.
3. The version note, stated plainly at the top of the tutorial, not buried in a footnote.