Stone City’s ERP, POS, and CRM, unified into a single sync layer. iSimplifyMe-built. iSimplifyMe-operated. In production today.
What is a multi-system retail integration?
A multi-system retail integration unifies a retail or distribution operation’s three core systems — the ERP (inventory and customer master), the point-of-sale (transaction capture), and the CRM (sales and marketing) — into a single sync layer. The layer carries daily reconciliation, vendor-API spec-drift handling, and idempotent upserts. iSimplifyMe operates one in production today for Stone City, a Chicago countertop showroom and fabricator, across its ERP, Square POS, and HubSpot CRM. Roughly 2,900 trade accounts, 1,600-plus POS orders, 26,000-plus quotes, roughly 400 sale orders, and roughly 1,400 receipts flow into the CRM through an iSimplifyMe-built Node and TypeScript sync layer running as six scheduled jobs on AWS Lambda + EventBridge, in an AWS account Stone City owns and iSimplifyMe administers. One of the six re-reads all 15,000-plus invoices every day and writes the amount paid and the balance due onto the sale-order deals. A twice-daily inventory and purchasing dashboard runs on the same ERP data: a catalog of roughly 11,800 products, its inventory, and its purchase orders.
The setup
Stone City is a Chicago countertop showroom and fabricator, named here with the client’s agreement. It sells to trade professionals and to individual and walk-in customers from a catalog of roughly 11,800 products.
Its three vendor systems did not talk to each other: an ERP, a Square POS, and a HubSpot CRM. Sales reps were re-typing qualified leads from the CRM into the ERP to generate a quote: double entry and data drift across systems.
iSimplifyMe was engaged to unify the three systems without a rip-and-replace. The mandate: keep the existing tools, build the integration layer, operate it.
Architecture
Everything below runs in production today. The six scheduled sync jobs are Node and TypeScript Lambdas on EventBridge schedules in a standalone AWS account Stone City owns and iSimplifyMe administers; the twice-daily inventory and purchasing publish runs in the same account on the same ERP data.
Why this is harder than it looks
Vendor API spec drift
Documented field names and enum values lag the live API. iSimplifyMe uses a probe-first methodology: hit the live endpoint with a sample of live records, dump field distributions, treat the probe as the source of truth. Without it, a sync built against the published documentation produces silently wrong stage mappings that look right in dev and break against real customer data.
Full-sweep timeouts
The ERP vendor’s 30-second SQL ceiling kills any full-customer sweep partway through. The fix is to chunk by sales rep and serialize the chunks. Same dataset, no timeouts.
Marketing-contact tier economics
Syncing some 25,000 individual and walk-in customers as HubSpot marketing contacts is uneconomic — the tier overage alone would run roughly $5,800 a month. The decision: sync the roughly 2,900 trade accounts only. Individual and walk-in customers stay in the ERP as the system of record.
Incremental sync without webhooks
Daily incremental polls on modified-since timestamps plus idempotent upserts keyed on the source-system ID close the loop without webhooks. The quotes pipe was built against the vendor’s staging endpoint, probed for the production URL, and flipped on its own when the cutover landed — no code change required. Invoices are the exception: recording a payment leaves the invoice’s modified date untouched, so a modified-since poll would never see the payment, and the invoice sync re-reads every invoice daily instead.
What’s running in production today
| Pipe | Direction | Volume | Schedule |
|---|---|---|---|
| POS orders | → CRM deals + line items | 1,600-plus orders, full history | Daily 10:00 UTC |
| ERP customers | → CRM companies + contacts | ~2,900 trade accounts, incremental | Daily 10:30 UTC (chunked) |
| ERP quotes | → CRM quotes pipeline | 26,000-plus quotes, one deal per opportunity | Daily 11:00 UTC |
| ERP sale orders | → CRM sale-order pipeline, staged by fulfillment | every sale order since January 2026 (~400), incremental | Daily 11:15 UTC |
| ERP receipts | → CRM receipts pipeline + payment rollups | ~1,400 receipts since January 2025 | Daily 11:30 UTC |
| ERP invoices | → amount paid + balance due on sale-order deals; open receivables on companies + contacts | 15,000-plus invoices, re-read in full | Daily 11:45 UTC |
| ERP products, inventory, purchase orders | → internal dashboard | ~11,800 products · ~5,300 purchase orders | Twice daily, 12:00 + 18:00 UTC |
| CRM customer card | → ERP customer create | one click per new account | On demand |
Six scheduled sync jobs daily plus a twice-daily inventory publish. Each carries logging, an error alarm, and a dead-man alarm that fires if a job does not run at all. Vendor spec drift is handled in the sync layer. Times are UTC; every sync is scheduled before 7 a.m. Chicago time. iSimplifyMe-operated. Not handed off.
Build log
- Phase 0
Audit + scope (April 2026)
CRM audit complete. Object counts mapped: ~2,000 contacts, ~700 companies, ~880 deals, custom lifecycle stages and lead statuses, two pipelines. Custom property schema, vendor API token validation, pipeline structure documented.
- Phase 1a
Read pipelines live (April 2026)
POS-to-CRM order sync went live mid-April; ~880 historical orders backfilled. ERP customer sync went live a few days later, trade accounts only and incremental, chunked by sales rep to stay under the vendor’s 30-second SQL timeout. Custom product, deal, company, and contact properties created in the CRM. Three scheduled daily jobs running: orders, customers, and the product catalog.
- Phase 1b
Quotes in production (May 2026)
ERP quotes sync code shipped May 1 against the vendor’s staging quotes endpoint. The vendor’s production quotes endpoint went live at the end of May, and the sync flipped over on its own via the probe. More than 26,000 quotes now sit in a dedicated CRM pipeline, one deal per opportunity — multiple revisions roll up into a single deal carrying the latest revision’s data. Sixteen custom deal properties added. The daily incremental run handles a dozen or so modified quotes per day in seconds.
- Phase 2
Off the local Mac, onto AWS (July 2026)
The three sync jobs then running — orders, customers, quotes — moved from local Mac LaunchAgents to AWS Lambda + EventBridge cron in a standalone AWS account Stone City owns and iSimplifyMe administers, with an error alarm and a dead-man alarm per job. The inventory publish moved to AWS in the same window, in iSimplifyMe’s own account, and the product catalog now feeds that publish rather than the CRM. The CRM card button went live on the vendor’s customer-create endpoint: a sales rep creates the ERP customer from inside HubSpot with one click. No more re-typing the customer record.
- Phase 3
Receipts + purchasing (September 2026)
A fourth sync pulls ERP receipts into their own CRM pipeline, with payment rollups on the associated companies and contacts, reconciled to the ERP to the cent. On the purchasing side, the vendor’s purchase-order endpoint feeds an internal inventory dashboard: last purchase cost per product, what is on order and from whom, refreshed twice a day.
- Phase 4
Sale orders + invoices (September–October 2026)
A fifth sync went live September 18. Every sale order since January 2026 now sits in a dedicated CRM pipeline, one deal per sale order, staged by how much of the order has been fulfilled or whether it was cancelled. A sixth, live since September 29, re-reads all 15,000-plus invoices every day in one-year windows, because a payment does not change an invoice’s modified date. It writes the amount paid and the balance due onto the sale-order deals, and open receivables onto the companies and contacts. Before anything is written, an independent query for open invoices checks the sweep, and a large disagreement stops the run. On October 7 the inventory and purchasing publish moved into the same client-owned account as the syncs.
Built and operated, not delivered.
Most integration engagements end with a slide deck and a handoff to the client’s internal team.
This one is a running production system iSimplifyMe operates daily. On AWS since July 2026; six scheduled sync jobs and a twice-daily inventory publish as of October 2026. Vendor API quirks tracked in our own probe scripts. Alarms that page us, not the client.
Frequently asked questions
How is this different from a typical integration engagement?
It did not stop at a recommendation. It started with a CRM audit and shipped a production sync layer iSimplifyMe operates daily: six scheduled sync jobs, a twice-daily inventory publish, vendor spec drift handled in the sync layer, and an error alarm and a dead-man alarm on every job. iSimplifyMe built the architecture and runs it.
How often does the data sync between the ERP, POS, and CRM?
Daily, on a fixed schedule. Square orders sync to HubSpot deals at 10:00 UTC, ERP customers to HubSpot companies and contacts at 10:30, and ERP quotes to the HubSpot quotes pipeline at 11:00. ERP sale orders sync to their own deal pipeline at 11:15, receipts to the receipts pipeline at 11:30, and invoices at 11:45 — all scheduled before 7 a.m. Chicago time. The invoice sync writes the amount paid and the balance due onto the sale-order deals, and open receivables onto the companies and contacts. The inventory and purchasing dashboard publishes twice daily, at 12:00 and 18:00 UTC. Every job carries an error alarm and a dead-man alarm.
Who operates the integration after it is built?
iSimplifyMe. The sync jobs and the inventory and purchasing publish run on AWS Lambda + EventBridge in an AWS account Stone City owns and iSimplifyMe administers. The sync logs, the vendor API probes, and the alarms all land on iSM-monitored channels. The client does not need an internal data engineering team to keep it running.
What if the vendor’s API does not support what you need?
Usually not all of it. Vendor APIs drift from their documentation, cover part of the surface, or lack an endpoint outright. iSimplifyMe treats the published spec as a starting point and probes the live API first, then files follow-up notes back to the vendor with reproducible evidence. Timeouts and rate limits are handled at the application layer, and when an endpoint is genuinely missing the build is phased: what is already exposed ships first, and the rest lights up as the vendor ships it.
How long until the first pipelines run in production?
Roughly 2–3 weeks for the CRM audit plus the first read pipelines — POS orders into CRM deals, ERP customers into CRM companies and contacts — running daily in production. Quote ingestion followed in May: the sync was built against the vendor’s staging endpoint and flipped to production on its own when the vendor’s production endpoint went live at the end of the month. Moving every job onto AWS Lambda + EventBridge took days once the account was in place. Each phase is independently useful — if the vendor takes longer on a downstream endpoint, the upstream pipes still ship.
Discuss a multi-system integration
If you are running an ERP + POS + CRM (or similar) and your team is hand-typing data between them, we can talk through what the integration layer looks like for your stack.
- Discovery call30 min · Free · No deck — actual mechanics
- Phase 1 timeline2–3 weeks to first pipes live in production
- iSM-operatedDeploys, monitoring, alarms, vendor follow-ups — all on us