How I Built a CRM That Reads CommonSKU Without an API

CommonSKU has no public API. My CRM absorbs it anyway: paste any share link and a deal appears with the client, value, stage, items, and artwork attached. Estimate, sales order, and invoice collapse into one record automatically. Verified against five live presentations.

CommonSKU is where my orders live. My CRM is where my pipeline lives. For a year, the bridge between them was me, retyping. Nobody gets into sales because they love data entry, and I checked: I definitely did not.

The standard answer is "wait for an API." There is no public one, and waiting is not a strategy. So I built the bridge from the other side: the CRM reads the same public share links my team already sends to clients, and absorbs everything on them.

The claim

Paste one public CommonSKU share link into my CRM. The system parses the live page and a deal is born or updated: client and contact (found or created), order value, stage, in-hands date, ship-to, line items, product images, and artwork with file links. Paste the estimate link, then later the sales order, then the invoice, and they do not create three records. They collapse into one deal that moves itself forward.

Verified against five live presentations before I trusted it. In production on my own book of business now.

The mechanism

Three ideas make it work, and none of them require special access.

Share links are structured pages in disguise. A CommonSKU presentation link renders clean, predictable HTML: client name, contact, products, quantities, pricing, artwork. Predictable structure is parseable structure. The system fetches the page exactly like a browser would and extracts the fields deterministically. No AI guessing on the numbers; parsing rules only.

The job number is the spine. Every CommonSKU document carries its job identity. Estimate, sales order, and invoice for the same job share it. So the CRM matches on the exact job number: if a document arrives for a job the system knows, it updates the existing deal instead of spawning a duplicate. Cross-document matching is exact, not fuzzy. This one rule is the difference between a CRM and a pile of records.

Documents know their own type. An invoice link files itself into the deal's invoices. A purchase order files into production paperwork with the artwork attached, and deliberately never moves the sales stage, because production activity and sales progress are different facts. Stages only move forward automatically; walking a deal backward is a human decision.

What it changed

The half hour a day of retyping is gone, but the bigger change is trust. Pipeline numbers used to be as fresh as my last data-entry mood. Now the CRM reflects what actually happened in CommonSKU, because the same links that go to clients also feed the system. One paste, full record, no transcription errors on quantities or values.

The boundary: this reads documents, it does not run your platform. It will not create orders in CommonSKU, it cannot see anything that was never shared, and when CommonSKU changes their page layout it stops working until the rules are updated. It fails loudly instead of guessing quietly, which is exactly what you want from automation touching money.

The pattern is bigger than CommonSKU

"No API" turns out to mean "no permission needed to read what is already public." Supplier order confirmations, carrier tracking pages, portal screenshots your team forwards around: the same pattern applies. Find the documents that already flow through your operation, parse them at the moment they appear, and match on the identifiers the platform already gives you.

If you run on CommonSKU and want to know what this would look like against your workflow, the free teardown is the easiest way to find out. And if you are earlier in the automation journey, start with the full distributor's guide to see where this fits among the eight systems that matter.