ShipperHQ

ShipperHQ's shipping groups, origins and dimensional rules sync as custom fields on each channel SKU, connected in one click from the channel's settings.

ShipperHQ quotes rates from three attributes it reads off each product: which shipping groups the item belongs to, which origins it can ship from, and which dimensional rules describe how it packs. On a BigCommerce store they are stored on each product (and, where set, each variant) as metafields in ShipperHQ’s own namespace. A product listed from Foundry used to reach the store without them, so ShipperHQ fell back to its defaults for every new SKU.

Foundry treats them as what they are: three custom fields, kept per channel SKU, mapped to the store’s metafields. Nothing about them is special-cased, so the same machinery serves the next app that keeps its settings on the product.

Connecting ShipperHQ

Open the BigCommerce channel, go to Settings, and find Apps & channel-wide fields. Press Connect ShipperHQ. That does two things:

• Adds three fields to your field library if they are not there already: ShipperHQ shipping groups, ShipperHQ shipping origins and ShipperHQ dimensional rules (keys shipperhq_shipping_groups, shipperhq_shipping_origins, shipperhq_dimensional_rules). They are list fields, hidden from storefronts, and apply to products, variants and channel SKUs.
• Maps each one to the matching ShipperHQ metafield for every SKU on the channel. This is a channel-wide mapping: it applies whether or not the product uses a template.

You usually do not need to press the button. A pull from a store that already runs ShipperHQ notices the metafields and connects the preset on its own, in pull direction, so the first pull after upgrading lands the values. Foundry only does this when none of the three fields exist in your organization yet; if you disconnect ShipperHQ on purpose, a later pull leaves it disconnected.

Connecting a second BigCommerce store is the same button on that store’s channel. The fields are shared; each store has its own mapping, so two stores with different ShipperHQ group names do not fight.

Where the values live

Every value is a list of names exactly as they appear in your ShipperHQ account. Foundry stores the names and never interprets them, so a group called Freight in ShipperHQ is Freight here, case and spacing included. An item can be in several groups at once.

A pull writes the values onto the channel SKU, because the ShipperHQ account is tied to that store. Open a channel SKU and its custom fields show the three lists with a chip editor: press Enter after each name, or paste a comma-separated list. You can also set the lists on the variant, which acts as the default for every channel the variant is listed on; a channel SKU’s own value wins over it.

The channel SKU export includes the three as customField: columns, like every other custom field.

Direction

The preset’s direction is shown next to it in Apps & channel-wide fields:

• Pull only (the default). The store is the truth. A pull writes exactly what the store holds, including “nothing”. Edits in Foundry stay in Foundry.
• Pull & push. Pulls copy the store in; a listing push sends Foundry’s values out.
• Push only. Foundry owns the values; pulls never overwrite them.

While pull is on, a BigCommerce pull reads the ShipperHQ metafields for the whole catalog at the same time as the products, in one paged request per level rather than one per product. For each SKU it takes the variant-level value where the store has one and the product-level value otherwise, which is the precedence ShipperHQ itself uses. If Foundry cannot read the store’s metafields at all (an API error, for instance) the pull leaves your values untouched rather than clearing them.

While push is on, a product listed from Foundry carries its values with it. A simple product gets them at product level, which is what the ShipperHQ tab in the BigCommerce product editor shows. A family gets them on each child variant, because ShipperHQ reads a variant’s values in preference to the product’s and the children may differ. Adding a child to a family that is already listed writes the child’s values too. Pushing a listing that is already on the store makes the store’s metafields equal yours: it adds the ones that are missing, updates the ones that changed, removes the ones you emptied, and leaves matching ones alone. A product whose three lists are all empty has nothing written at listing time, so a listing that never had a ShipperHQ setup does not grow one.

Setting up a store that already uses ShipperHQ

1. Run a pull from the channel page. The preset connects itself and every channel SKU picks up its values.
2. Open a few channel SKUs and confirm the names match what you see in ShipperHQ.
3. Decide who owns the values going forward. If you will manage them in Foundry, switch the preset to Pull & push. If you will keep managing them in the BigCommerce product editor, leave it on Pull only and pull keeps Foundry current.

Other apps and other platforms

Any app that keeps per-product settings in BigCommerce metafields can be mapped the same way without a preset: in a template’s channel mappings, choose the App metafield destination and give the namespace and key. Lists are sent JSON-encoded, which is what ShipperHQ and most apps expect.

ShipperHQ also runs on Shopify and Magento with the same three attributes. The fields are platform-neutral, so one catalog serves every store you connect. Today the BigCommerce channel reads and writes them; other channels keep the values in Foundry but do not yet send them to the store.