National Commerce Docs
n8n flows

SKU Information Handler

Central lookup service that resolves a single SKU from Supabase, parking unclassified codes in the review queue.

The shared SKU-resolution service. Given one SKU and its type, it returns the matching Product SKU, Base SKU, or Case SKU record from Supabase. Other flows offload SKU lookups to it.

The base, case, and product paths still create a record from ShipHero when one is missing. The resolve path does not: when a code has no classified SKU it parks the code in the review queue and answers "no SKU", leaving the caller to hold its line item unlinked.

At a glance

  • Status: Active
  • Trigger: Webhook (POST /webhook/ec1b458d-be51-46e8-9cd4-34057860441e), answered by a Respond-to-Webhook node.
  • Runs on: A single SKU lookup request carrying a SKU and its sku_type.
  • Talks to: Supabase (SKU, junction, inventory tables, and sku_pending_queue); the portal API (POST /api/sku/resolve); ShipHero (public GraphQL plus authenticated app/cookie endpoints); Gmail (new-SKU alerts); Slack (error notifications).

How it works

  1. The webhook parses and validates the payload (Store Payload Arguments, Valid Payload?).
  2. A switch on sku_type branches into product, base, case, resolve, plus a fallback.
  3. The product, base, and case paths look the record up in Supabase and respond; if missing they query ShipHero, create the record, and link Product to Base and Case to Base through junction tables.
  4. The resolve path reads sku_pending_queue through Get Queued Lookup, matched on shiphero_sku and brand_id.
  5. Is Resolved? routes on what the queue row holds. If the code has already been classified, the matching Base, Case, or Product SKU is returned.
  6. If the code has no resolution, Queue SKU For Classification calls POST https://portal.nationalcommerce.com/api/sku/resolve with the service-role key. That endpoint upserts the code into sku_pending_queue and creates nothing.
  7. Return Not Found answers 200 with a body carrying no id and no sku_type, so the caller links no SKU and holds its line item.

The resolve path no longer auto-creates a Base SKU

It used to. A code with no classified SKU triggered a ShipHero lookup, a base-versus-case guess, and a Base SKU created outside the review queue. A wrong guess put stock on the wrong SKU and corrupted on-hand until someone noticed.

The legacy subtree behind that behavior is still on the canvas but unreachable, roughly 39 nodes starting at Look Up SKU Info From Shiphero and including Create Case SKU Record1 and the recursion node Get Base SKU2 that reached Try To Create Base SKU Record. The base, case, and product branches are untouched and other callers still use them.

Notes

  • Large orchestration workflow (~130 nodes). It is the shared SKU-resolution backbone other scenarios rely on.
  • Get Queued Lookup is scoped by brand. sku_pending_queue is unique on (brand_id, shiphero_sku), so the same code can exist for two brands and an unscoped match could return another brand's SKU.
  • The switch output In Queue - Unresolved was removed. The node runs with allMatchingOutputs, so that output fired alongside No Resolution on every held code and dead-ended at a Slack node with no responder. Parking the code in the queue is the notification now.
  • saveDataSuccessExecution: all.
  • Shared error-handler set as the error workflow.

Clear Voided Labels (Manual)

A manually-run counterpart to the daily voided-label cleanup, used to clear voided ShipHero labels from Supabase on demand.

Pull Brand SKUs

Bulk-syncs a brand's product, base, and case SKUs plus per-warehouse inventory from ShipHero into Supabase.

On this page

At a glanceHow it worksNotesRelated