An automated data pipeline that fetches paginated order and customer data, merges them into enriched records, and routes Enterprise-tier customer orders into a rate-limited, retry-safe priority queue — with a final reporting call summarizing the run.

This workflow pulls orders and customers from two separate APIs, joins them into a single enriched dataset by customer_id, pushes the full enriched set to a downstream queue, and additionally identifies pending orders from Enterprise-tier customers to fast-track through a batched priority queue.

E-commerce order data and customer data typically live in separate systems. Without automation:

Order records lack customer context (name, subscription tier, etc.), making downstream processing (support, fulfillment, billing) incomplete.

Enterprise/high-value customers get the same treatment as everyone else — no mechanism to prioritize their pending orders.

Bulk API calls to a downstream queue without batching can trip rate limits or overwhelm the receiving system.

No end-of-run summary means there's no visibility into how much data was processed or whether priority routing actually ran.

A single orchestrated pipeline:

Fetch in parallel — orders (paginated) and customers are retrieved concurrently from source APIs.

Enrich by join — orders are merged with matching customer records on customer_id, producing a single enriched dataset.

Dual routing — the full enriched set goes to a general orders queue; in parallel, Enterprise-tier customers with pending (non-delivered) orders are filtered out and routed to a priority queue.

Rate-limited delivery — priority orders are sent in controlled batches (5 at a time) rather than all at once.

Finalize — a summary call reports run totals once batching completes.

Parallel data fetching — orders and customers are pulled concurrently rather than sequentially, cutting total fetch time roughly in half.

Paginated API consumption — GetOrders is configured to walk through pages rather than assuming a single response page.

Data enrichment via Merge node — orders are joined with customer context in one step instead of manual lookups per item.

Tiered priority routing — Enterprise customers with undelivered orders are automatically segmented into a separate, fast-tracked path.

Batch-controlled downstream calls — priority orders are sent in fixed batch sizes (5), protecting the receiving API from bursty traffic.

Run-level reporting — a finalize step reports aggregate counts once the pipeline completes, giving operational visibility into each run.

Node Type Role When clicking 'Execute workflow' n8n-nodes-base.manualTrigger Pipeline entry point GetOrders n8n-nodes-base.httpRequest Paginated order fetch GetCustomers n8n-nodes-base.httpRequest Customer data fetch MergeOrdersCustomers n8n-nodes-base.merge Join on customer_id, enrich orders enriched_orders n8n-nodes-base.aggregate Collapses items into one payload for queue delivery SendToOrdersQueue n8n-nodes-base.httpRequest Delivers enriched dataset downstream CheckSubscriptionTier n8n-nodes-base.if Branches Enterprise vs. other tiers Non-Enterprise (not routed) n8n-nodes-base.noOp Explicit terminal for non-Enterprise orders — makes the "no further action" branch visible instead of a silent dead end FilterPendingOrders n8n-nodes-base.filter Keeps only orders not yet delivered (renamed from FilterDelivered for clarity) BatchPriorityOrders n8n-nodes-base.splitInBatches Controls throughput to the priority queue SendToPriorityQueue n8n-nodes-base.httpRequest Delivers priority batch WaitBetweenBatches n8n-nodes-base.wait Throttles the loop before the next batch fires, protecting the receiving API FinalizePipeline n8n-nodes-base.httpRequest Posts run summary (totals, batch size, retry flag)

An initial self-review of v1 surfaced several issues, resolved as follows:

Issue found Fix applied FilterDelivered name implied the opposite of its actual behavior (it kept non-delivered orders) Renamed to FilterPendingOrders CheckSubscriptionTier's false branch (non-Enterprise orders) silently dead-ended with no visible handling Added an explicit Non-Enterprise (not routed) No-Op node so the branch's behavior is documented in the workflow itself, not just in prose Priority queue batches fired back-to-back with no spacing, risking rate-limit issues on the receiving API Added a WaitBetweenBatches node in the loop, throttling each batch cycle No retry on external HTTP calls retryOnFail enabled (3 attempts, backoff) on all outbound HTTP Request nodes FinalizePipeline's enterprise_count metric was pulling from the wrong node output Corrected to reference the actual Enterprise-filtered item count

Pagination termination isn't fully explicit. GetOrders increments page on each call — worth double-checking the configured completion rule matches the API's actual "no more pages" signal (empty array vs. a has_next flag) rather than relying on defaults.

No dead-letter/alerting path. Retries now exist, but if all retries on a node are exhausted, there's still no notification or fallback logging — the run just fails. A dedicated Error Trigger workflow would close this gap.

These remaining items are the next milestone — retry logic buys resilience against transient failures; a proper error-workflow buys visibility into persistent ones.

Using the Merge node for data enrichment across two independently-fetched datasets, rather than nested lookups.

Designing conditional, tiered routing (Enterprise vs. standard) within a single pipeline run.

Applying batching (splitInBatches) to control downstream API load instead of firing all requests at once.

Recognizing that reporting/summary steps need the same scrutiny as the main logic — a wrong metric in a "finalize" call is just as much a bug as a broken main path.

Treating a self-review pass as part of the build, not an afterthought — catching a mislabeled node, a silent dead-end branch, and a missing throttle before anyone else has to.

Eliminates manual cross-referencing of order and customer records — enrichment happens automatically on every run.

Enterprise customers get automatic fast-tracking without manual triage.

Batched delivery protects downstream systems from being overwhelmed, making the pipeline safe to scale to larger order volumes.

Javeria Afzal n8n Workflow Automation | Building production-grade automation systems