Connect your catalog to ShirtMath

How do I connect a product catalog to ShirtMath?

Three transports are built today: a CSV upload, a JSON feed at a URL, and a custom retailer API ShirtMath reads. Platform connections for Shopify, WooCommerce and BigCommerce, and signed webhooks fired on product events, are declared and not built — asking for one returns an error that says so rather than a half-working import. All of them land in the same record shape.

ShirtMath is a fit search engine, so the import has one job beyond stocking a catalog: get the garment measurements in. A product with no measurements still imports and still appears in the catalog. It simply does not compete in fit matching, because there is nothing to compare it against. The ShirtMath for brands hub covers the commercial side of that boundary. The field-level contract, the authentication scheme and the error codes are agreed with you during setup rather than published here.

1. Scope the connection — decide which catalog, which locales and which product types you are sending, and who owns the credentials.
2. Choose a transport — push, pull, file, feed URL or platform app. Mixing is normal: a nightly full snapshot plus webhooks for same-day changes is a common shape.
3. Map your fields — SKU, parent product, size label, and every measurement field you already hold. Mapping is agreed once and stored, so later imports do not need re-mapping.
4. Run a dry import — the first pass validates and reports without publishing, so you see the rejected rows and the blank measurement fields before anything is live.
5. Turn updates on — full snapshots on a schedule, incremental delta sync, webhooks, or a combination of the three.

Which connection methods are supported?

Three are built — CSV upload, JSON feed and a custom retailer API. The platform connections listed below are declared, not built. Nothing here requires a rebuild of your product data model; the mapping layer sits between your field names and ours.

How does a Shopify product feed work?

A Shopify product feed gives you products, variants, option values, product type, tags and metafields. Identity comes out of it cleanly: the variant carries the SKU, the barcode and the size option. Measurements do not, because Shopify has no standard field for a chest width. Where a merchant holds real numbers they usually sit in a metafield, in a size-chart app, or in a table pasted into the description HTML.

So the connection does two things. It reads variants for identity, and it reads a nominated metafield namespace for measurements. Which namespace, and which key holds which point of measure, is agreed during setup rather than guessed, and it is stored with the mapping so it survives later syncs. WooCommerce and BigCommerce work the same way in principle: product and variation attributes carry the size letter, custom fields carry any dimensions.

If the numbers only exist in a size chart image or a PDF, say so at setup. An image is not a feed field, and nothing in the import will read it. Size chart integration is the route for catalogs whose measurements live in a chart rather than on the product.

What does ShirtMath import, and what does it never touch?

Only your own products. A connection authorised by a retailer imports that retailer's own catalog and nothing else: no competitor catalogs, no marketplace listings you do not own, and no customer records. The import wants product data, not people.

How do updates and deletions propagate?

Two update models, and the difference between them is where most integration bugs live.

A full snapshot is the complete truth for that catalog at that moment. A product absent from a snapshot is treated as withdrawn and drops out of matching. A CSV upload is always a snapshot; a feed or a pull endpoint can be either.

Incremental delta sync sends only what changed. Absence means unchanged, not gone, so deletions have to be explicit: a delete webhook, a status field, or a discontinued flag on the record. A delta feed that quietly omits a discontinued line will leave that line live in the catalog. That single difference is worth a line in your integration tests.

Signed webhooks work in both directions. Your platform can notify ShirtMath on product create, update and delete; ShirtMath can notify your endpoint when a run finishes. Every call carries a signature computed from a shared secret so the receiver can verify it. Treat delivery as at-least-once and make your handler idempotent on product identifier plus version. The signing scheme and the retry schedule are fixed with you at setup, before the first live event is sent.

What happens if an import fails part way?

Validation runs per record, not per file, so one malformed row does not take a batch down. Each rejected row comes back with its identifier and the reason it failed, and the previously accepted version of that product stays live until a valid replacement arrives. You never end up serving a half-written product.

A transport failure during a paginated pull resumes from the last acknowledged cursor rather than restarting the catalog. Every run closes with a report: records seen, accepted, rejected with reasons, and unchanged. A full snapshot that arrives dramatically smaller than the previous one is held for confirmation instead of being treated as a mass withdrawal, because the usual cause of a catalog shrinking by ninety per cent overnight is a broken export, not a closing-down sale.

What happens to products with no measurements?

They are excluded from fit matching rather than guessed at. The product imports, keeps every field you sent, and remains browsable. It just cannot be ranked against a scanned shirt, because a fit comparison needs two sets of numbers and there is only one.

ShirtMath does not estimate a chest width from a size letter, and the reason is in the published specs. These are the flat chest measurements at Medium for five common blanks.

The ladies' cut publishes 17.5" at Medium against 20.0" to 20.5" for the unisex Mediums, a three inch gap on the same letter, and the gap is 3.0" at Large too. A letter is a label, not a dimension, so an imputed measurement would be wrong by more than the tolerance band on a real one. A blank field is honest; a guessed field is a fit recommendation built on nothing. That is also why the same letter behaves differently between brands, which is the subject of vanity sizing. How the numbers are compared once they are in is set out in the methodology.

What does disconnecting do?

Revoke the API key, uninstall the platform app, or stop serving the feed. Fetching stops at that point; there is no background path that keeps reading a catalog after its credential is gone. Imported products stop being served in fit results, and you can request deletion of the imported records under the terms of your agreement. Nothing about disconnecting depends on giving notice, and reconnecting later re-runs the same mapping rather than starting the setup again.

What do integration teams ask most?

Where to go next