CommonSKU Integration Without the Enterprise Plan

CommonSKU's API sits behind the Enterprise plan. My CRM reads the share links you already send clients instead: paste one, and the estimate, sales order and invoice for that job land on one deal, no duplicates, no login. Verified on 7 live documents.

Has this ever happened to you? You open your pipeline and the same job is in it three times.

The estimate, the sales order and the invoice. Same client, same 400 polos, same in-hands date, which is just the day the boxes have to be in the room or somebody's getting yelled at. Three cards. Three values. One human, me, expected to remember they were one thing. That was my CRM three weeks into building it, and I'd built it.

I run a book of business at a promotional products distributorship. I also pull boxes in the warehouse. Every quote, order and invoice I write lives in CommonSKU. It's a good order system. It's also where the data stops, and I got tired of being the thing that carried it the rest of the way.

The Enterprise wall

CommonSKU puts API and webhook access on the Enterprise plan. It sits on the pricing page next to the NetSuite integration and BI exports, built for big multi-location distributors with an integrations team. If that's you, cool, go use it.

If you're a 3 to 15 person shop on a standard plan, there's no way to get your own order data out. Not a slow way. Not a limited way. None. You want your orders to talk to your CRM? That's another tier. You want a report your accountant doesn't have to build by hand? Another tier. You already pay for the software and then you pay again to reach the data you typed into it.

So every shop below that line builds the same integration out of a person. Someone reads the order on one screen and types it into another. The CRM. The pay sheet. The client portal. The reporting spreadsheet. Same job, retyped, four times, forever. And the retyping is where the wrong quantity, the transposed ship-to and the stale in-hands date come from.

Are you tired of companies doing this to you? So was I. I did the retyping for a year. Then I noticed something dumb about what I'd been sending my clients the whole time.

The link you already send

Every time I send a client a presentation, an estimate, or an invoice from CommonSKU, it gives me a share link. The client opens it without logging in. That page renders the whole document. Client and contact. Job name and job number. Every line item with quantity, SKU, unit cost, unit sell and the decoration detail (decoration is just what gets printed or stitched on the thing). Artwork files. Product photos. The in-hands date. The ship-to and bill-to addresses. On an invoice, whether it's been paid.

I authorized that page. My client reads it. It's a document I chose to publish. Which means the integration I'd been told to wait for had been sitting in my sent folder the entire time, and the only thing standing between me and it was the idea that I wasn't allowed to build it.

So I built the CRM to read the link the way the client does. No login. No stored password. No private endpoint. If a link isn't shared, the system can't see it, and that's the whole security model.

What one paste does

Here's the mechanism, in the order it actually runs. This is the part I wish somebody had shown me instead of selling me a tier.

It reads the page. A presentation link is server rendered HTML, so the reader parses it directly. An order link (estimate, sales order, invoice, purchase order) is a small app that loads its data from a public document endpoint, so the reader fetches that and maps it. Either way, the result is one normalized document: what kind it is, what number it carries, its job number, the client, the contact, the items, the money, the dates, the addresses, the artwork.

It cleans the job name. CommonSKU sometimes stuffs the whole ship-to contact block into the job name. That name becomes the deal title and the project name, and both of those show in the client portal. So the reader strips it, and it trims rep names by matching the real roster rather than guessing at capitalized words. I mention that because the first version guessed, and it ate "Pins" and "Totes" off two job names before I caught it. Tell on yourself early. It's cheaper.

It finds the deal. This is the part that kills the triple card. Every CommonSKU document for one job carries the same job identity, so the CRM checks that first. Exact match, done, the document joins that deal. If there's no job id on the doc, it looks for a deal that already absorbed any document with this job number, then this document number. If that fails too, it looks for a deal under the same client with the same job name, ignoring anything marked lost. Only when every rung fails does it create a new deal.

It finds the client without inventing one. Exact organization name first. If the name is a near miss, the system stops and asks. "Is this Acme Outfitters?" It doesn't merge and it doesn't mint a new client from a string that's one letter off. I'd rather answer one question than clean up a duplicate account six months later.

It finds the contact. Email inside that client first, then email anywhere, then first and last name inside the client, then the normalized full name, then create. And it's fill only. A document can add a missing phone number to a contact. It can never overwrite one.

It files the document. The doc joins the deal's trail, keyed on type plus number. Invoices also file into the Invoices tab. Purchase orders also file into Purchase Orders. The deal stays the one place you start from.

It moves the stage forward, and only forward. Presentation to estimate to sales order to production. A sales order or invoice pushes the deal straight through the won stages even if nobody ever pasted the estimate. A purchase order never touches the sales stage, because a PO is a production fact, not a sales one. And here's the rule that took me longest to get right: pasting an old estimate after the invoice already landed can't drag a closed job backwards. Stages move one direction.

Paste. Read. Match. File. Advance. Done.

Updating, and why re-pasting is safe

The first version of this treated a second paste of the same link as a duplicate and skipped it. That was wrong. Orders change. A client bumps 400 to 450, the sales order updates, and the CRM now has a stale copy and a confident look on its face.

So a re-paste of a known document refreshes the stored entry in place. Same type, same number, new items, new totals, new dates. That's also how older deals backfill line data they never had. One paste, and a deal from July suddenly knows its own line items.

Then there's the part that runs without me. A scheduled sweep re-pulls every stored order document older than 24 hours, capped at 25 documents per run so it stays polite to CommonSKU's servers. Whatever changed lands on the deal: value, close date, forward-only stage, line items, and the client's shop, which is the list of products that client has actually bought. The drift shows up on the deal timeline. An amber "may be stale" tag on a document clears the moment it's re-read. Nobody presses refresh. It runs on a cloud schedule, so it doesn't stop when my laptop closes.

Invoices, and the part where money gets watched

A public invoice page answers a simple question about itself: is this paid. The reader looks at three signals. The paid flag, which is the verdict. The PAID watermark on the rendered invoice, which confirms it. And the pay control, which is a button reading "Pay Credit Card" when unpaid and a greyed line reading "Paid With Credit Card" when paid. That third one also tells you the method and the amount actually charged, card fee included, which is the number an accounting person wants.

If the three signals disagree, the flag wins and the disagreement is logged so I can look. The page gives no paid date, so the sweep records the first time it saw the invoice as paid. I verified this on one unpaid and one paid invoice on 2026-09-05, saved both responses as fixtures, and the parser is tested against those files, never against the live network.

The first sweep after it deployed flipped 3 invoices to paid and closed out 1 finished job on its own. That's the moment it stopped being a demo for me.

One boundary that matters more than it sounds. Paid alone doesn't close a job. A job closes when the paid invoice and the delivered shipment both land. An invoice is a receipt, not a finish line, and a CRM that closes on payment will tell you a job is done while the boxes are still on a truck.

Presentations versus orders

Worth being precise here because it changes what you get. A presentation link carries products, images and specs but no commercials. There are no totals on it. So pasting a presentation opens the deal, names it, attaches the product images and puts it at the presentation stage, but it doesn't value it. The estimate does that. That's a property of the document, not a gap in the reader.

What it doesn't do

The reader only knows public share links. If a link isn't shared, nothing.

It touches no private API and no back door, which is exactly why none of this depends on the vendor deciding to let me in.

When CommonSKU changes a page layout, the reader breaks. Loudly. The affected job shows an error instead of importing half a document with a wrong number in it. That's on purpose, and it's the honest cost of building without an API. The fix is normally a small change to the parsing rules, because quote and invoice documents don't change shape often.

No language model reads the money. Quantities, costs and totals are parsed from the document structure with rules that assert on what they find. A model that reads 250 as 25 produces output that looks completely fine and is completely wrong, and you won't catch it by eye across a hundred line items. Deterministic code fails obviously. For money, I'll take obvious.

And it's a CRM. It's not accounting, not inventory, not payroll. I haven't built those and I'm not going to pretend I have.

Why this exists at all

I'll say the bigger thing plainly, because the absorb is a small example of it.

Nobody built this for shops my size because there aren't enough of us to make the dev time pay. That's the real math behind every "Enterprise only" line on every pricing page in every niche industry. Promo, dental labs, sign shops, landscapers with a route, body shops. The big platforms have to build the most generic version of a feature that works for everyone, because the generic version sells enough seats. The specific version, the one that knows your job numbers and your in-hands dates and your decoration lines, never gets written. Not because it's hard. Because it doesn't pencil for them. You're the leftover.

That stopped being true this year. The cost of building the specific version dropped through the floor. One rep, building at night after a day in the warehouse, can ship a working integration in a weekend and harden it over a month. I didn't set out to be a software guy. I got pushed into it by a stack that wouldn't talk to itself, and it turns out I like it, and it turns out I can see the bullshit from both sides now, because I still live inside the problem every day.

So the stack goes back into the hands of the shop that runs on it. You can own the bridge instead of renting the promise of one. If you want to get on board, get on board. If you'd rather keep retyping, I can't stop you, but I'm not going to pretend it makes sense either.

Software your industry never got. That's the whole reason Stout Intel exists, and we're not going anywhere.

The portable version

You don't have to be in promo for this to apply. Ask one question about any system you pay for. What does it already publish for my customers? Quotes, invoices, appointment confirmations, order statuses. Every one of those is a document you authorized, rendered in full, reachable without a login. Whatever a vendor locks behind a plan tier, it very often hands your customer for free on a link. Read the link.

Second question, the one I ask about every tool now. Does it fill itself, or does my team have to feed it? A CRM your team has to feed is a CRM that's empty by March. This one fills itself from a paste, and then keeps itself current from a schedule. That's the difference between software that gets used and software that gets an invoice.

Try this week, without building anything

Open your sent folder and find the last five share links you sent clients. Open each one in a private browser window. Notice everything on the page. That's your data, already out, already structured, waiting for something to read it.

Then count how many times last week you retyped something from one of those pages into another system. Multiply by your hourly cost. That's the integration budget you're already spending, on you. Well, now you know.

If you run a CommonSKU shop and want this running on your book, the absorb is part of SIPS, the platform I run my own desk on. You can request access and I'll walk you through it on a call. If you're not in promo but you just recognized your own vendor in the Enterprise wall paragraph, get in touch and tell me which system it is, because reading the link is a pattern and it transfers.

Related: how I built the first version without an API, the numbers when I measured my own software, and an honest comparison of CommonSKU alternatives. The pillar page for everything CommonSKU is here, and the build page with the stack and status is here. If you quote a lot, the promo quote calculator is free and needs no account.