Connecting commonsku to Your CRM: Your Options, Including the Enterprise API

Every way I know to get commonsku orders into a CRM without retyping them: commonsku's built-in connections, the Enterprise API, and the share links you already send clients. Paste one, and the estimate, sales order and invoice for that job land on one deal. Checked 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 ran a book of business at a promotional products distributorship, and I pulled boxes in the warehouse when a job blew up. Every quote, order and invoice I wrote lived in commonsku. It's a good order system. The problem was everything I kept outside it, the pipeline, the follow-ups, the client notes, and I was the thing carrying the job details across by hand.

Your options for getting commonsku data into a CRM

There's more than one way to do this, and the right one depends on your plan and who's on your team. Here's every route I know of.

commonsku's built-in integrations. commonsku's integrations page lists product search from ESP, SAGE and DistributorCentral, accounting with QuickBooks Online and Xero, and connections to Zapier, HubSpot, Mailchimp, ShipStation, Shopify and Stripe, among others. Start here. If one of those already covers the retype you hate, you're done, and it cost you nothing.

The Enterprise API. commonsku lists API access and webhooks on its Enterprise plan. It's built for shops with an integrations person or a developer who wants to wire commonsku into whatever they run. If that's you, use it. It's the most direct pipe there is.

The share links you already send. This is the route I built, and it's the rest of this post. It works on Essentials, Advanced or Enterprise, because it reads pages you've already published to your clients.

Before I found the third one, I was the integration. 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. And the retyping is where the wrong quantity, the transposed ship-to and the stale in-hands date come from.

Are you tired of being the integration? 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 sent a client a presentation, an estimate, or an invoice from commonsku, it gave 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 bridge I'd been carrying by hand 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.

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 endpoint and no back door. It reads what you already chose to publish, nothing more.

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.

Software for a niche industry gets built for the broadest version of the job, because that's what sells enough seats to pay for the dev time. The specific version, the one that knows your job numbers and your in-hands dates and your decoration lines and the client who always reorders in September, usually gets left to the shop to stitch together. Promo, dental labs, sign shops, landscapers with a route, body shops. Same story everywhere.

That changed recently. 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 I had to carry by hand, and it turns out I like it, and it turns out I can see the bullshit from both sides now, because I lived inside the problem long before I started building around it.

So the bridge goes back into the hands of the shop that runs on it. 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. Before you build anything heavier, check whether the thing you need is already sitting on a page you send out. 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 promo-focused CRM I built to manage the client's whole sales life around the job commonsku runs. 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 retyping habit in this post, 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 from share links, the numbers when I measured my own software, and getting more out of commonsku by connecting it to your pipeline. 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.

Stout Intel is independent and not affiliated with or endorsed by commonsku.