Hi team,

Requesting new columns be added to our synced data. Details below.

Connector name: ShipHero

Table name: shipment_line_item

Columns to add: line_item_id(sku, price, quantity), shipping_label_id

API documentation links:
1) https://developer.shiphero.com/schema/types/shipment-line-item.html — the ShipmentLineItem type. Confirms every field available on a shipment line item: id, legacy_id, line_item_id, shipment_id, shipping_label_id, quantity, and a nested line_item object.

2) https://developer.shiphero.com/schema/types/line-item.html — the LineItem type nested inside each ShipmentLineItem above. This is where sku, price, product_name, quantity, and other product-level fields live.

Additional details:
Our current shipment_line_item table only has shipment_id, id, and quantity. It's missing two fields that the API documentation confirms exist on every shipment line item record:

- line_item_id: links a shipped quantity back to the specific order line item (and from there, to its sku/price via the nested LineItem object).
- shipping_label_id: links a shipped quantity to the specific physical label/package it belongs to. This matters because a single shipment can legitimately produce multiple labels (split packages), so shipment_id alone is not granular enough.

Without these two fields, we have no way to determine which SKU(s), at which price, went out on which specific label. This directly breaks our Monthly Shipping Report, whose grain is one row per shipping label: for any order that ships across multiple labels, we can only compute a value total for the entire order, not for the specific label that row represents — and that wrong total then gets repeated identically across every label belonging to that order.

We validated this against a real order: 4 line items, 3 shipments (1 shipped outside ShipHero, 1 voided/reprinted label, 1 valid label). Only 2 of the 4 line items actually belonged to the surviving valid label, but our BigQuery-based total incorrectly included all 4 — producing a value nearly 4x too high for that specific label. We confirmed the correct per-label breakdown directly via the live GraphQL API, using exactly the line_item_id and shipping_label_id fields referenced above; the data exists, it's just not present in what's synced to BigQuery today.

This isn't an edge case. Split shipments and reprinted/voided labels are common enough in normal warehouse operations that this gap affects a meaningful share of the report validation discrepancies we're finding. Since both fields are already exposed by the API (confirmed via the documentation links above and by live query), this should be a straightforward addition to the existing sync rather than new instrumentation on ShipHero's end.

Thanks,
Vishal Khode