UNIS Trigger

The UNIS Trigger starts a workflow when UNIS — a third-party logistics (3PL) warehouse and transportation provider — reports an event. When UNIS confirms a delivery (a shipped order) or confirms a receipt (an inbound PO received into the warehouse), it posts the event to Splice, and this trigger turns it into a workflow execution. Use it to react to UNIS warehouse activity in real time: sync orders and shipments into another system, generate and transmit EDI, reconcile receipts, or raise exceptions as they happen.

Overview

Use the UNIS Trigger when you need to:

• React to delivery confirmations - Start a workflow the moment UNIS ships an order and posts a delivery confirmation (DC)
• React to receipt confirmations - Act when UNIS receives an inbound PO and posts a receipt confirmation (RC)
• Keep systems in sync - Push outbound shipments and inbound receipts from UNIS into a WMS, ERP, billing system, or data warehouse
• Drive EDI from UNIS activity - Generate and send EDI (e.g. 945 from a DC, 944 from an RC) in response to UNIS events
• Bridge UNIS into your systems - Push order, shipment, and receipt data from UNIS into downstream automation without polling

Endpoint & Setup

The UNIS Trigger is delivered over the same HTTP ingress as the Webhook trigger. UNIS posts events to the workflow's public endpoint:

POST https://<your-splice-api-domain>/hook/{workflowId}

Configure UNIS to send events to this URL (copy it from the workflow), then choose which events should start the workflow with the Action setting below.

Trigger vs. the UNIS API

The trigger node itself takes no credential — it only receives the inbound event. If a workflow needs to call back into UNIS (for example to import an order or search receipts/shipments), use a UNIS service node with a separate UNIS Client credential. That credential holds the Username and Password used for outbound UNIS API calls.

Configuration

Action (required)

The set of UNIS events that may start the workflow. Select one or more; only the selected event types trigger a run.

Event	Value	Fires when
DC Event	dc	UNIS posts a delivery confirmation for a shipped (outbound) order
RC Event	rc	UNIS posts a receipt confirmation for a received (inbound) PO

Output

The trigger emits a single output keyed by the node's name. Both UNIS events share the same envelope — { PostId, Type, Data, PostedAt } — where Type identifies the event (DC or RC) and Data carries the event-specific payload. Branch on Type when one workflow handles both events.

• PostId - A unique identifier for the posted event (useful for de-duplication / idempotency).
• Type - The event type: DC or RC.
• Data - The event-specific payload (shapes below).
• PostedAt - When UNIS posted the event.

Because the Data shape differs by event type, and many fields are optional reference slots, inspect the captured sample for the events you actually receive before mapping fields downstream.

DC events

A DC Event (Type: "DC") carries a full delivery confirmation under Data — the order, ship-to/sold-to/bill-to parties, carrier, totals, the line Items, and the packed Cartons. It is large and nested; the representative shape is:

{
  "UNIS Trigger": {
    "PostId": "0213a5fa-5e15-40ba-8b71-4f62ebe3b4c6",
    "Type": "DC",
    "Data": {
      "CompanyID": "LT",
      "CustomerID": "AUKINT0001",
      "FacilityID": "889",
      "OrderNo": "DN-94800",
      "ReferenceNo": "Roy022501-3",
      "ShippedDate": "2020-06-18T02:09:01.083",
      "PONo": "8957515451-3",
      "BOLNo": "DN-94800",
      "SCACCode": "FEDG",
      "CarrierID": "FedEx",
      "TotalShippedQty": 2,
      "OrderType": "940",
      "ShipToName": "US FOODS",
      "ShipToCity": "ALTOONA",
      "ShipToState": "PA",
      "ShipToZipcode": "16601",
      "Items": [
        {
          "ItemNumber": "5CB0Z21087-1",
          "OrderedQty": 1,
          "ShippedQty": 1,
          "UOM": "EA",
          "LineNo": "2"
        }
      ],
      "Cartons": [
        {
          "CartonNo": "HLP-1110509831",
          "TrackingNo": "1119013",
          "PalletNo": "HLP-1110509831",
          "ItemLines": [ /* item-level carton contents */ ]
        }
      ]
    },
    "PostedAt": "2021-07-13T13:00:00Z"
  }
}

Commonly used fields:

• Data.OrderNo / Data.ReferenceNo - The UNIS order number and customer reference.
• Data.CustomerID / Data.CompanyID / Data.FacilityID - The account, company, and warehouse the shipment came from.
• Data.ShippedDate - When the order shipped.
• Data.BOLNo / Data.MasterBOLNo / Data.PONo - Bill-of-lading and purchase-order references.
• Data.SCACCode / Data.CarrierID - The carrier.
• Data.TotalShippedQty / Data.TotalWeight / Data.LadingQty - Shipment totals.
• Data.ShipTo* / Data.SoldTo* / Data.BillTo* - The party names and addresses.
• Data.Items[] - The shipped lines (ItemNumber, OrderedQty, ShippedQty, UOM, LineNo, plus many DTLMISC* reference slots).
• Data.Cartons[] - The packed cartons, each with CartonNo, TrackingNo, PalletNo, and nested ItemLines.

The DC payload is large

A DC event contains many fields, including numerous reference slots (ReferenceNo01–05, MISC01–10, and per-line DTLMISC01–20). Use a Set or Code node early in the workflow to pull out just the fields you need, and reference them by path (e.g. {{$json.Data.OrderNo}}) downstream. The contents of the reference slots depend on how the UNIS account is configured, so inspect the captured sample before mapping them.

RC events

An RC Event (Type: "RC") carries a receipt confirmation under Data — the inbound PO, the carrier, the received line Items, and any Cartons:

{
  "UNIS Trigger": {
    "PostId": "0213a5fa-5e15-40ba-8b71-4f62ebe3b4c6",
    "Type": "RC",
    "Data": {
      "CompanyID": "LT",
      "CustomerID": "AUKINT0001",
      "FacilityID": "889",
      "PONo": "12345678",
      "ReferenceNo": "",
      "WISEPOID": "RN-34198",
      "ReceivedDate": "2021-07-12T23:14:08.834",
      "ContainerNumber": "",
      "Note": "",
      "PalletQty": 2,
      "BOLNo": "0",
      "SCACCode": "SBFH",
      "CarrierName": "South Bay Freight",
      "TitleID": "ORG-3",
      "Items": [
        {
          "POLineNo": "2",
          "ItemNumber": "1234",
          "ItemShortDescription": "KAHLUA COFFEE",
          "ExpectedQty": 0,
          "ReceivedQuantity": 0,
          "UOM": "EA",
          "LotNo": "",
          "SupplierID": "ORG-3"
        }
      ],
      "Cartons": []
    },
    "PostedAt": "2021-07-13T13:00:00Z"
  }
}

Commonly used fields:

• Data.PONo / Data.WISEPOID / Data.ReferenceNo - The purchase-order number, UNIS/WISE receipt ID, and customer reference.
• Data.ReceivedDate - When the goods were received.
• Data.CustomerID / Data.CompanyID / Data.FacilityID - The account, company, and warehouse.
• Data.ContainerNumber / Data.BOLNo / Data.SCACCode / Data.CarrierName - Inbound carrier and container details.
• Data.PalletQty - The number of pallets received.
• Data.Items[] - The received lines (POLineNo, ItemNumber, ItemShortDescription / ItemDescription, ExpectedQty, ReceivedQuantity, UOM, LotNo, SupplierID, plus DynTxtPropertyValue01–20 reference slots).
• Data.Cartons[] - Any cartons received (may be empty).

RC reference slots vary

RC events include header- and line-level DynTxtPropertyValue01–20 slots, and some fields (ExpectedQty, ReceivedQuantity, and Oracle-style fields such as RECEIPT_SOURCE_CODE / ORGANIZATION_CODE / SHIPMENT_LINE_ID) may be 0, empty, or null depending on the UNIS account configuration. Inspect the captured sample for the events you actually receive and read defensively.

Example Usage & Common Use Cases

Sync a Shipment into Another System

[UNIS Trigger] → [Set: map OrderNo / ReferenceNo / ShippedDate / Items]
                   → [HTTP Request: upsert into TMS/ERP]

Generate EDI on a Delivery Confirmation

Action: DC Event

[UNIS Trigger] → [Set: extract DC fields] → [EDI: build 945/856] → [AS2 / FTP: send to customer]

Reconcile an Inbound Receipt

Action: RC Event

[UNIS Trigger] → [Set: map PONo / WISEPOID / Items.ReceivedQuantity]
                   → [HTTP Request: close PO / post receipt in ERP]

Branch on Event Type

[UNIS Trigger] → [If: Type == "DC"]
                    ↓ true                ↓ false (RC)
               [Process shipment]    [Process receipt]

How It Works

1. UNIS posts an event - UNIS sends a POST to the workflow's /hook/{workflowId} URL when a subscribed event occurs, with the { PostId, Type, Data, PostedAt } envelope.
2. Match the trigger - The webhook ingress resolves the workflow and selects its trigger node.
3. Filter by action - Only events whose type is enabled in Action start the workflow.
4. Enqueue - The event envelope becomes the trigger output and a workflow execution is started.

Best Practices

• Select only the events you handle - Enabling just the event types the workflow is built for avoids unnecessary runs.
• Branch on Type - When one workflow handles both UNIS events, switch on the Type field (DC / RC) rather than on the presence of a single field.
• Extract early - The DC payload is deep and verbose; map the handful of fields you need up front so downstream nodes stay readable.
• Use PostId for idempotency - Events may be re-posted; key downstream actions on PostId (or OrderNo / PONo) so repeats are safe.
• Guard against empty reference slots - The many ReferenceNo*, MISC*, DTLMISC*, and DynTxtPropertyValue* fields are often blank and depend on the UNIS account configuration; don't assume a fixed shape.

Troubleshooting

Common Issues

• No workflow runs on a UNIS event - Confirm UNIS is posting to the correct /hook/{workflowId} URL, the workflow is active, and the event type is enabled under Action.
• Wrong branch taken - When handling both event types, branch on Type (DC / RC), not on the presence of a single field.
• A field is missing from Data - UNIS leaves unused reference and address slots blank, and the available fields differ between DC and RC. Inspect the captured sample for the actual shape and code defensively.
• Outbound UNIS API call fails - The trigger and the UNIS API are separate concerns. Verify the UNIS Client credential (username, password) used by the downstream service node, not the trigger.

Debugging Tips

• Inspect the captured sample - The trigger output is stored as node sample data on each run; use it to navigate the nested payload and build downstream field paths.
• Test with a manual POST - Send a sample DC or RC body to the URL with curl to confirm the endpoint and downstream logic before relying on live UNIS events.

Related

• Webhook - The general-purpose HTTP trigger this node is built on
• UNIS - Call back into the UNIS API when the workflow needs more than the event payload
• Trigger Nodes - Overview of all available workflow trigger types