E-commerce order sync & stock alerts

I treat webhooks as at-least-once delivery. First, every event ID goes into a processed_events table with a unique constraint using INSERT ON CONFLICT DO NOTHING. If no row comes back, the execution stops. Second, retries inside n8n can re-run a node, so the decrement is keyed on order ID plus line ID. One option is a small ledger table the UPDATE joins against, so a replayed line has no effect. Third, the arithmetic happens in a single Postgres UPDATE … RETURNING, never as read-then-write in n8n, because queue-mode workers run in parallel. Finally, the event is persisted before Respond to Webhook sends 200. That way a crash after the acknowledgement is recoverable from the table instead of being lost.

The store POSTs each order event to an n8n Webhook node. A Code node verifies the HMAC signature on the raw body, and an IF node rejects failures. The event ID goes into processed_events with INSERT … ON CONFLICT DO NOTHING, so duplicates stop there. A Respond to Webhook node then returns 200. A Switch node sends order-created events one way and cancellations or refunds another. Set/Edit Fields splits the order into line items, and Loop Over Items processes them in batches. Each line runs one atomic UPDATE … RETURNING. An IF node detects a reorder-point crossing and triggers Slack, WhatsApp and a purchase-draft sub-workflow that waits for approval. Retry-on-fail and an error workflow make sure no failure is silent.

Store platforms expect a quick acknowledgement and resend if they time out. If we held the response until every line was decremented and every alert was sent, a slow Postgres or Slack call could push us past that timeout. The store would then resend an event we are already processing. So we do only the minimum: verify the signature, record the event ID durably, then answer 200. That gives the store a fast, honest acknowledgement, because the event is now safely on our side. Dedupe absorbs any resends that still happen. The trade-off is that processing failures are no longer visible to the store. That is why the error workflow, failed status and replay path are mandatory, not optional.

processed_events: event_id as the primary key, plus event type, order ID, status (received, done, failed), timestamps and the n8n execution ID. inventory: sku and location as the key, with on_hand and reorder_point. Optionally inventory_movements, with event_id, line id, sku, delta and created_at, and a unique constraint on event plus line. That table gives an audit trail and per-line idempotency. purchase_drafts: id, sku, suggested quantity, supplier, status (open, approved, rejected) and approval timestamps, with a partial unique index on sku where status is open. workflow_errors: execution ID, event ID, failing node, error message and time. Every guarantee the workflow makes, such as dedupe, no lost updates and one open draft, is backed by a constraint rather than by workflow logic alone.

Lines one and two are already committed, and the error workflow marks the event failed. A naive replay would decrement lines one and two again, because event-level dedupe only protects the whole event. There are two safe fixes. You can record each line in an inventory_movements table keyed on event ID plus line ID, in the same SQL statement as the update, for example a CTE that inserts the movement and updates inventory only if that insert succeeded. Or you can wrap all lines of one event in a single transaction so it is all or nothing. Per-line keys suit batched loops better. The replay then sets the event back to processing, skips the lines already applied and continues from line three.

Most n8n nodes already run once per item. I use Loop Over Items when I want control over batch size. Examples are throttling Postgres or WhatsApp calls during a flash sale, or replaying a backlog of failed events without flooding downstream APIs. Each batch passes through the decrement and the threshold check, and the IF node's output feeds back into the loop for the next batch. Things to watch: the loop must actually reconnect, or only the first batch runs. Nodes after the loop see the combined output only from the done branch. And a failure in the middle of a loop should go to the error workflow with enough context, such as order ID and line ID, to replay just the remaining lines.

Alert on transitions, not states. The UPDATE returns the new quantity, and I compare previous and new values against the reorder point, firing only when stock crosses the line. Slack goes to the purchasing channel for visibility, and WhatsApp goes to the named buyer using an approved template, because template messages are needed outside the customer service window. The purchase-draft sub-workflow checks for an existing open draft per SKU, so a second crossing after a restock-and-sell cycle does not create duplicates. Reorder points live in Postgres per SKU and location, so buyers can tune them without editing the workflow. I also track stock-outs that had no prior alert, to catch bad thresholds.

Configure the Webhook node so the raw body is available, because the signature is computed over the exact bytes the store sent. Re-serialising parsed JSON can change whitespace or key order and break the match. In a Code node, compute the HMAC with the shared secret using the algorithm the platform documents, then compare it with the header using a constant-time comparison such as crypto.timingSafeEqual. On self-hosted n8n you may need to allow the built-in crypto module for the Code node. Keep the secret in a credential or environment variable, never hard-coded in the node. An IF node rejects failures with a 401 and logs them. If the platform signs a timestamp, also reject requests that are too old to limit replay.

The UPDATE returns the new on_hand and the reorder_point. For a sale, the previous quantity is the new on_hand plus the line quantity. The IF node fires only when previous is above reorder_point and new is at or below it. Because the UPDATE is atomic, each row change has exactly one before and after. Two concurrent orders cannot both see the same crossing: only the update that moves the value across the threshold satisfies the condition. For example, with a reorder point of 5, an order of 3 that takes stock from 7 to 4 alerts. A later order of 1 that takes it from 4 to 3 does not. Cancellations add stock back, so they never fire a low-stock alert.

In n8n, a Postgres query that returns no rows can produce no output items, so the downstream nodes simply do not run. The line disappears without any error, which breaks the rule against silent drops. To prevent this, enable Always Output Data on that node, or check the result count with an IF node. Then treat zero rows as a real failure: throw an error from a Code node, or route the line to an unmatched-SKU path. That path records it in Postgres, marks the event for attention and alerts Slack. Typical causes are a new product not yet synced, a SKU typo or a wrong location, and someone has to fix the data before replaying.

First, not every refund means stock is coming back. A refund for a damaged item or a partial money-only refund should not restock. So the path must look at line-level restock flags or quantities, not just the event type. Second, a cancellation must only restore stock that was actually decremented. If the original order failed or was never processed, adding stock back inflates inventory. I would check that inventory_movements holds the original lines before applying the reversal. Third, cancellations have their own event IDs, so they go through the same dedupe. Fourth, adding stock can lift a SKU back above its reorder point. That re-arms the alert, which is correct, and it may also make an open purchase draft unnecessary, so buyers should be told.

I would start from the business's own numbers rather than guess. That means orders per day, average lines per order, and the peak-to-average ratio during sales or festival campaigns. As an illustration, if a store had 10,000 orders a day with 3 lines each, that is 30,000 inventory updates a day, well under one per second on average. A sale could multiply the peak many times over. Each line costs one small indexed UPDATE, which Postgres handles easily. The real limits are n8n execution overhead, concurrency and how many backlog events a replay releases at once. Alert volume is low by design, because only crossings alert. I would load-test with a replayed backlog at the expected peak before a big sale.

Move when a single main instance cannot keep up with peak executions, or when you need workers that can restart without losing work. In queue mode, the main or webhook process receives requests and puts executions on a Redis queue, and multiple workers run them. The design already copes with this. The atomic UPDATE prevents lost updates between workers, ON CONFLICT dedupe stops parallel duplicate deliveries, and a unique index protects open drafts. What to check: the configured concurrency per worker and the Postgres connection limits, because many workers times the pool size can exhaust connections. Waiting executions are stored in the database, so approvals survive worker restarts. Redis and Postgres themselves need monitoring and backups.

Enable retry-on-fail with a few attempts and a wait between them on Postgres, Slack, WhatsApp and the draft insert, to absorb transient network errors, rate limits and brief outages. Do not expect retries to fix permanent errors such as bad SQL, an invalid template or an unknown SKU. Those should fail fast to the error workflow. The main risk is retrying a non-idempotent write that actually committed but timed out on the response. A retried decrement would then double-count. Per-line movement keys make the UPDATE safe to retry. Alerts can duplicate on retry, which is tolerable but avoidable by recording that an alert was sent. Keep the total retry time bounded so executions do not pile up during an outage.

The error workflow is set in the main workflow's settings and starts from an Error Trigger. That trigger receives details such as the execution ID, the failing node and the error message. It inserts a row into a workflow_errors table and sets the event's status in processed_events to failed. It then posts to the on-call Slack channel with the event ID, the node and a link to the execution. For replay, a person or a Schedule-triggered sweep picks up failed events, resets them to processing and re-runs the order logic. The original payload or a reference to it must be stored, because the store will not resend. Per-line idempotency makes partial replays safe. The error workflow should be very simple, so it does not fail itself.

A check-then-insert in the sub-workflow races under queue mode, because two executions can both see no open draft. Enforce it in the database instead, with a partial unique index on purchase_drafts(sku) where status = 'open'. The sub-workflow then runs INSERT … ON CONFLICT DO NOTHING RETURNING id. If a row comes back, this execution owns the draft and sends the approval link. If nothing comes back, a draft already exists, and it ends quietly or adds a note. Because the alert fires only on a crossing, concurrent crossings are rare anyway, but a constraint makes the guarantee absolute. When a draft is approved or rejected, its status changes, which frees the slot for a future crossing.

The resume URL is effectively a bearer token: anyone who has it can approve. Send it only through trusted channels, such as a direct Slack message or WhatsApp to the named buyer. Where the Wait node supports it, enable authentication on the resume webhook. Alternatively, point the link at a small approval page that checks the user's identity first. Make the approval idempotent: the draft moves from open to approved once, and a second click changes nothing. Record who approved and when. Use HTTPS only and give the link a time limit, ideally the Wait timeout. Do not put supplier pricing or other sensitive data in the URL query string, because links end up in logs and browser history.

Order webhooks contain customer names, addresses, phone numbers and emails, but inventory only needs SKU, quantity and location. Strip PII early with Set/Edit Fields and store only what is needed in processed_events. n8n saves execution data, including full webhook payloads, so set execution saving and pruning deliberately. For example, prune successful executions after a short period and limit who can view executions. Alerts to Slack and WhatsApp should carry only the SKU, on-hand count and reorder point, never customer details. For an Indian business, align retention and handling with the DPDP Act and the company's privacy policy. If replay needs the payload, store a minimal one in Postgres with a retention period.

The inventory UPDATE is the critical write, and alerts are side effects that come after it. If Slack or WhatsApp fails, the stock count is already correct, so we must not undo it or replay the whole event in a way that decrements again. Retry notifications on their own nodes. If they still fail, record the alert as pending in Postgres and let the error path or a sweep resend it. Do not reset the event. Consider running notifications in a sub-workflow or with the node set to continue on error but log the failure, so one bad message does not stop the remaining line items in the loop. Recording that an alert was sent also prevents duplicate alerts on replay.

It is a business decision with a technical consequence. The store has usually already accepted the order, so refusing the decrement does not undo the sale. It only makes our count wrong. I would normally let on_hand go negative, because a negative value honestly records oversold stock. Its reorder-point crossing still raises an alert, and an oversold flag can alert separately. The alternative is to add on_hand >= qty to the WHERE clause. That rejects the update, and the zero-row result must then go to an oversell path rather than being dropped. That approach fits when n8n is the source of truth for stock, but it needs a compensating action such as cancelling the order or putting it on backorder.

Webhooks are not guaranteed to arrive in order, and retries make reordering more likely. Keep per-order state, derived from processed_events or a small orders table, recording whether the order's decrements were applied. If a cancellation arrives for an order with no applied movements, do not add stock back. Record the cancellation as pending, or park it and retry it later with a Schedule-triggered sweep. When the order-created event then arrives, check for a recorded cancellation and skip the decrement entirely. Event timestamps or version numbers from the platform help resolve conflicts. The key rule is that every reversal is tied to a recorded forward movement and never applied blindly.

A waiting execution is saved to the database and resumed when its resume URL is called, so it survives restarts. But waits can pile up if buyers ignore approvals. Set a time limit on the Wait node so it resumes after, for example, a few days. Then route that timeout path to a reminder or escalation, or mark the draft expired. The draft's status in Postgres should be the source of truth, not the existence of a waiting execution. That way, approving in another tool or cancelling the draft stays consistent. If the workflow is changed while executions are waiting, they resume on their saved version, so test changes carefully. Finally, make sure the resume URL can reach n8n through your proxy.

Postgres, Slack and WhatsApp Business Cloud access should use n8n credentials. These are stored encrypted and referenced by nodes, so they never appear in workflow JSON or exports. The HMAC secret should also live in a credential or environment variable, not in Code node source. Keep the n8n encryption key backed up and separate, because losing it makes stored credentials unreadable. Use a dedicated Postgres role with only the rights it needs on these tables, not a superuser. Scope the Slack bot to the needed channels. Rotate the WhatsApp access token and the store webhook secret on a schedule. Limit who can edit workflows, since editors can use any credential the workflow references.

Business-initiated messages outside the 24-hour customer service window must use a pre-approved template. That is why the workflow sends a template message whose parameters are the SKU, on-hand count and reorder point. Templates are reviewed by Meta, so changing the wording means getting a template approved again. The buyer's number must be able to receive messages from the business, and messages may be charged depending on category and region, so check current pricing rather than assuming it is free. Rate limits and quality ratings apply, which is another reason alerts fire only on crossings. If WhatsApp fails after retries, Slack is still sent, and the error workflow records the failed notification.

Redeliveries hit the Webhook node quickly. Each one does only signature check, dedupe insert and 200, so the acknowledgement path stays light. Events we already processed hit ON CONFLICT and stop. In queue mode, new events are spread across workers. Loop Over Items batches the line items within each order, and worker concurrency limits how many orders run at once, so Postgres is not flooded. Watch the connection count and lock contention on popular SKUs, because many orders for one SKU queue on the same row lock. Alerts stay limited because only crossings fire. Also check that events the error workflow marked failed during the outage get replayed once dependencies recover.

Track execution success and failure counts, and alert when failures exceed a threshold, not just on each error. Also watch the age of the oldest event in received or failed status, which catches stuck processing. Track webhook response time against the store's timeout, the rate of signature rejections (a spike may mean a rotated secret or an attack), and duplicate counts from ON CONFLICT. Other useful signals are queue length and worker health in queue mode, Postgres connection usage, and the number of waiting approvals older than their SLA. A daily reconciliation report comparing our on_hand with the store's stock catches silent drift that execution logs would never show.

Key inventory on SKU plus location, and make sure each line item carries the fulfilling location from the store payload. The UPDATE's WHERE clause then matches both. The reorder point becomes per location, so crossings and alerts are per location, and alerts should name the location. Purchase drafts need a decision: one open draft per SKU per location, or one per SKU across locations with a combined quantity. Enforce whichever you choose with the partial unique index. Transfers between locations are a separate event type. They decrement one location and increment the other, ideally in one transaction, so stock is never counted twice or lost.

Drift comes from manual adjustments in the store, returns processed elsewhere, damaged goods or bugs. Add a Schedule-triggered workflow that pulls stock levels from the store or warehouse system, compares them with Postgres and reports differences above a tolerance to Slack. Corrections should be written as explicit adjustment movements with a reason, not silent overwrites, so the audit trail stays complete. If an adjustment moves a SKU across the reorder point, run the same crossing logic so alerts stay consistent. Decide which system is the source of truth for each field, so automatic corrections do not fight each other.

Use a staging n8n instance and a staging Postgres database, with separate credentials and test Slack channels. Send signed sample payloads, including a bad signature, a duplicate event ID, an unknown SKU, a multi-line order and a cancellation before its order. Test the crossing logic at the boundaries: a value just above the reorder point, exactly at it, already below it, and a single order that jumps from well above to well below. Run concurrent orders for one SKU to confirm there are no lost updates and only one alert and draft. Force failures, such as stopping Postgres, to check that retries, the error workflow and replay work. Pinned test data in n8n helps you iterate node by node.

First, queue mode with more workers, tuned concurrency and a Postgres connection pooler. Second, row-lock contention on hot SKUs during flash sales. Consider batching updates per SKU in each loop batch, or a reservation model. Third, execution data storage: prune more aggressively and avoid saving full payloads. Fourth, webhook ingestion: keep the acknowledgement path minimal, or put a durable queue in front so spikes never threaten store timeouts. At some point, high-volume inventory accounting may belong in a dedicated service, with n8n keeping orchestration, alerting and approvals, where it adds the most value. I would decide that from measured latency and failure data, not from assumptions.

The guarantees depend on database features. An atomic UPDATE … RETURNING prevents lost updates under concurrency. A primary key with ON CONFLICT DO NOTHING gives reliable dedupe. Partial unique indexes enforce one open draft per SKU. Transactions make multi-line changes all or nothing. Google Sheets offers none of these. Two executions reading and writing a cell can overwrite each other, and API rate limits get in the way during bursts. Sheets is fine as a read-only view or report for buyers, fed from Postgres, but it should not be the system of record for stock counts that must never double-count.

It has a different lifecycle. The order path should finish in seconds, while the draft path can wait days for approval on a Wait node. Keeping them apart means the order execution is not left waiting, and the draft logic can be reused, for example by the reconciliation workflow or a manual trigger. It can also be versioned and tested on its own. It also keeps the main workflow readable. I would usually not have the parent wait for the sub-workflow to finish, so a long approval does not hold the order execution open. Pass a clear input contract (SKU, location, on-hand count, reorder point) so callers stay decoupled.

Yes, as advice, not as the decision. Inside the draft sub-workflow, an AI Agent or a basic chat model node using an OpenAI-compatible credential pointed at Vercel AI Gateway (https://ai-gateway.vercel.sh/v1) could look at recent sales, lead time and the supplier's minimum order quantity and propose a quantity with a short reason. The gateway gives one credential, fallbacks and spend tracking, with no provider keys stored in n8n. Keep a deterministic formula as the default and as the fallback if the model call fails. Validate the output against bounds before inserting it. The human approval step stays mandatory. Send only aggregated sales figures to the model, never customer data.

1. AUsing 'Respond to Webhook' nodeCorrect answer
2. BNo response body
3. CRespond immediately
4. DRespond when last node finishes

Why: The Webhook node must be set to respond using the Respond to Webhook node. That lets the workflow persist the event first and then return 200 at a point it chooses.

1. ASELECT then INSERT if not found
2. BINSERT … ON CONFLICT DO NOTHING on a unique event_idCorrect answer
3. CUPSERT that overwrites the existing row
4. DDELETE then INSERT

Why: A unique key with ON CONFLICT DO NOTHING is atomic. A second delivery inserts nothing, which signals a duplicate without any race.

1. Anew on_hand < previous on_hand
2. Bprevious on_hand <= reorder_point
3. Cnew on_hand <= reorder_point
4. Dprevious on_hand > reorder_point AND new on_hand <= reorder_pointCorrect answer

Why: Only the transition from above to at-or-below fires. Later sales of an already-low SKU do not alert again.

1. AIt skips the need for an index
2. BIt bypasses row locks
3. CIt is easier to read
4. DIt avoids the lost-update race between concurrent ordersCorrect answer

Why: The read-modify-write happens atomically in one statement under a row lock, so concurrent orders cannot both act on the same stale value.

1. AThe line is decremented twice unless a per-line idempotency key is usedCorrect answer
2. BThe row is deleted
3. CThe webhook returns 500
4. DNone, because UPDATE is always idempotent

Why: A relative decrement is not idempotent. Retrying a committed write double-counts unless a movement key blocks the second apply.

1. AWait
2. BSchedule Trigger
3. CWebhook
4. DError TriggerCorrect answer

Why: An error workflow begins with the Error Trigger node and is assigned in the failing workflow's settings. It receives details of the failed execution.

1. ASwitch the Loop Over Items batch size to 1
2. BRead on_hand with a Postgres SELECT, subtract in a Code node, then UPDATE
3. CUse a single UPDATE … SET on_hand = on_hand - qty … RETURNING on_handCorrect answer
4. DAdd a Wait node of a few seconds before writing

Why: A single atomic UPDATE lets Postgres serialise the row change. Read-modify-write across nodes can interleave between workers and overwrite one of the updates.

1. AThe webhook header says it is a retry
2. BThe insert affected zero rows, for example RETURNING produced no rowCorrect answer
3. CThe Switch node sees a duplicate flag
4. DPostgres throws a unique-violation error

Why: With ON CONFLICT DO NOTHING, a duplicate inserts no row, so RETURNING produces nothing. The workflow stops on that result.

1. AThe request headers
2. BThe JSON re-serialised by n8n
3. CThe raw request body bytes exactly as sentCorrect answer
4. DOnly the order ID field

Why: The sender signs the exact bytes it sent. Re-serialised JSON can differ in whitespace or key order, which would break verification.

1. AAlert, because previous stock was 7, which is above 5, and new stock 4 is at or below 5Correct answer
2. BAlert only if on_hand reaches 0
3. CReject the update
4. DNo alert; stock is already low

Why: Previous stock is 4 + 3 = 7, which is above 5, and the new value 4 is at or below 5, so this update crossed the threshold.

1. AAlert again
2. BCreate a second purchase draft
3. CNo alert, because previous stock of 4 was already at or below 5Correct answer
4. DThrow an error

Why: Previous stock is 4, which is already at or below the reorder point, so no crossing occurred and no alert is raised.

1. AMerge
2. BSwitchCorrect answer
3. CWait
4. DExecute Workflow

Why: A Switch node routes items to different outputs based on a value such as the event type.

1. AA partial unique index on sku WHERE status = 'open', plus ON CONFLICT DO NOTHINGCorrect answer
2. BA Wait node before the insert
3. CRunning only one n8n worker
4. DAn IF node that checks for an open draft first

Why: A database constraint is atomic. A check-then-insert in the workflow can race when two executions run at the same time.

1. AIn the Postgres credential
2. BIn each node's retry settings
3. CIn the main workflow's settings, as its error workflowCorrect answer
4. DIn the Respond to Webhook node

Why: Each workflow's settings name an error workflow. That workflow starts with an Error Trigger when an execution fails.

1. AA second Postgres server
2. BKafka
3. CRedisCorrect answer
4. DRabbitMQ only

Why: Queue mode uses Redis as the queue from which workers pick up executions.

1. ASo the store does not time out and resend the eventCorrect answer
2. BBecause n8n requires it for Loop Over Items
3. CTo skip signature checks
4. DTo save n8n memory

Why: Slow responses make store platforms retry. A fast acknowledgement after durable persistence avoids needless redeliveries.

1. AIgnore it, since nothing changed
2. BTreat it as a failure: route to an error or unmatched path and alertCorrect answer
3. CInsert the SKU with on_hand = 0 silently
4. DRetry indefinitely

Why: Zero rows means the line was not applied. Ignoring it would silently drop an update, which the workflow must never do.

1. ANothing; the store will resend
2. BA status such as failed, so the event can be replayed despite the dedupe rowCorrect answer
3. CDeleting the inventory row
4. DReturning 500 to the store

Why: Otherwise the dedupe row would block reprocessing. The error workflow marks the event failed for replay, so nothing is dropped.

1. AExecute Workflow node
2. BRespond to Webhook node
3. CWait node resuming on a webhook callCorrect answer
4. DMerge node

Why: The Wait node can suspend an execution until its resume webhook is called, which suits approval links. Execute Workflow only calls the sub-workflow.

1. AWith a regular expression
2. BWith a constant-time comparisonCorrect answer
3. CWith a case-insensitive substring match
4. DBy comparing only the first 8 characters

Why: Constant-time comparison, such as crypto.timingSafeEqual, avoids leaking information through timing differences.

1. AMerge
2. BSet/Edit FieldsCorrect answer
3. CRespond to Webhook
4. DError Trigger

Why: The blueprint uses a Set/Edit Fields node to shape the order into line items before Loop Over Items.

1. ASets on_hand to zero
2. BAdds the line quantity back to on_handCorrect answer
3. CDeletes the inventory row
4. DDoes nothing

Why: Cancellations reverse the sale by adding the quantity back, using the same atomic UPDATE pattern.

1. AStore credentials
2. BPick up and run queued executionsCorrect answer
3. CServe only the editor UI
4. DReplace the database

Why: Workers take executions from the Redis queue and run them, which lets throughput scale horizontally.

1. ABusiness-initiated messages outside the 24-hour service window must use approved templatesCorrect answer
2. BTemplates skip authentication
3. Cn8n cannot send free text
4. DTemplates are cheaper than Slack

Why: WhatsApp Business rules require pre-approved templates for business-initiated messages outside the customer service window.

1. AExecute Once
2. BRetry On Fail
3. CPin Data
4. DAlways Output DataCorrect answer

Why: Always Output Data emits an empty item when there are no results, so an IF node can detect the zero-row case.

1. ATo process line items in batches, so large orders or replays do not hit Postgres all at onceCorrect answer
2. BTo deduplicate events
3. CTo send alerts in parallel
4. DTo encrypt line items

Why: The node splits items into batches and loops, which smooths load on Postgres.

1. AThe parent workflow ends
2. BA buyer replies in Slack
3. CA request hits the execution's resume URLCorrect answer
4. DA Schedule trigger fires

Why: The Wait node pauses until its unique resume webhook URL, sent as the approval link, is called.

1. ATyped into each node's parameters
2. BKept only in Code node variables
3. CStored as plain text in workflow JSON
4. DStored encrypted and referenced by nodesCorrect answer

Why: n8n stores credentials encrypted and nodes reference them, so secrets stay out of the workflow definition.

1. ADisable the error workflow
2. BTurn off HMAC checks
3. CStrip PII early and configure execution data saving and pruningCorrect answer
4. DSend full payloads to Slack

Why: Execution logs keep payloads. Minimising fields and pruning saved execution data limits how much PII is retained.

1. AResponding to the webhook
2. BVerifying HMAC
3. CCalling the purchase-draft sub-workflowCorrect answer
4. DStarting on schedule

Why: Execute Workflow calls the reusable purchase-draft sub-workflow from the main workflow.

1. ATrigger a low-stock alert
2. BAdd the stock back anyway
3. CDo not restock; record or park the cancellation until the order state is knownCorrect answer
4. DDelete processed_events

Why: Restocking without a matching forward movement would inflate inventory. Reversals must be tied to recorded decrements.

1. Ahttps://n8n.cloud/ai
2. Bhttp://localhost:11434
3. Chttps://api.openai.com/v1
4. Dhttps://ai-gateway.vercel.sh/v1Correct answer

Why: These blueprints route model calls through Vercel AI Gateway at that base URL, with an AI Gateway API key.

1. ACustomer name and address
2. BSKU, on-hand count and reorder pointCorrect answer
3. CFull order payload
4. DPayment details

Why: The alerts include only the SKU, on-hand count and reorder point, which is enough for purchasing and avoids exposing PII.