CommonSKU Absorption Engine

What it is

Reads public CommonSKU share links and turns them into complete CRM deals: client, contact, value, stage, in-hands, ship-to, line items, images, artwork.

How it works

Deterministic HTML parsing of the pages CommonSKU already renders for clients. Exact job-number matching collapses estimate, sales order, and invoice into one deal. Invoices and POs auto-file to their own tabs; stages only move forward.

Development to deployment

Everyone said wait for an API. The share links my team already sends turned out to be all the API I needed.

Why there is no API, and what that actually costs you

CommonSKU does not publish a general purpose public API for the order data sitting inside your account. That single fact shapes how thousands of distributor desks run. Every shop that wants its order platform to talk to anything else, a CRM, a reporting tool, a client portal, a commission sheet, ends up building the same bridge out of a human being. Somebody reads the order on one screen and types it into another.

The cost of that bridge is invisible because it is spread thin. Five minutes here, a re-keyed ship-to there, a line item quantity that got transposed and nobody caught until the invoice. Add it up across a year and it is weeks of salaried time producing zero new value, plus a steady trickle of transcription errors that surface at exactly the wrong moment.

The standard advice is to wait for the vendor to ship an integration. That advice has been correct and useless for a long time. The interesting question is not when the API arrives. It is what data you are already allowed to read today.

What a public share link already contains

Every time you send a client a presentation, an estimate, or an invoice link, the platform renders a complete, publicly reachable HTML page. You authorized that page. Your client opens it. It is not a back door and it is not scraped private data, it is a document you deliberately published.

That page carries almost everything a CRM needs to open a real record: the client company and contact, the job name and number, every line item with SKU, quantity, unit cost and unit sell, the decoration detail including method, colors and locations, the artwork and product images, the in hands date, and the ship to address.

Which means the integration everyone is waiting for has been sitting in the outbox the whole time. The engine takes a link you already generated and reads it the way the client does, then writes the result into the pipeline as a structured deal.

The job number is the join key

The hard part was never reading one page. It was that a single job produces several of them. An estimate becomes a sales order becomes an invoice, each with its own document and its own link, and a naive importer creates three unrelated records out of one piece of work. Now your pipeline reports triple revenue and your team stops trusting it, which is worse than having no integration at all.

The fix is exact job number matching. Every absorbed document is keyed on the job number the platform already assigns, so the estimate, the sales order and the invoice collapse onto one living record. Absorb the invoice for a job you imported at estimate stage and it updates that deal rather than spawning a sibling.

Stage transitions only move forward. Re absorbing an old estimate after the invoice landed cannot drag a closed job back to quoting, which is the failure mode that quietly corrupts pipeline reporting in most home grown importers.

Deterministic parsing, not a language model

It would have been faster to hand each page to a language model and ask for JSON. I deliberately did not, and the reason matters if you are considering this pattern for your own systems.

Financial data has no tolerance for plausible. A model that reads a quantity of 250 as 25 produces output that looks completely correct and is completely wrong, and you will not catch it by eye across a hundred line items. Deterministic parsing has the opposite failure mode: when the input changes shape, it fails loudly and immediately instead of guessing well.

So the parser targets the actual document structure and asserts on what it finds. If a field it requires is missing, it stops and says so rather than filling the gap. That is a worse demo and a much better production system. This is the general rule I apply across every build that touches money: use a model where judgment helps, use deterministic code where correctness is the whole job.

What breaks, and how you find out

The honest cost of the no API approach is that the vendor owns the page layout and can change it without telling anyone. When they do, the parser breaks. Anyone who sells you this pattern without saying that out loud is selling you something.

It is built so that a layout change produces a visible, noisy failure rather than silently wrong data landing in your pipeline. A broken parse surfaces as an error on the job, not as a deal with three empty fields that somebody discovers a month later. Repair is usually a small update to the parsing rules rather than a rebuild, because the structure of a quote document does not change often or dramatically.

That is the real trade. You get an integration that exists today against a platform that offers none, and you accept a maintenance surface you can actually see. For most desks that trade is obviously worth making, and if the vendor ever ships a real API, the absorption layer swaps out behind the same interface.

Common questions