HubSpot + Sage 300 integration

Sage 300, the midsize ERP Sage once sold as Accpac, is built around separate company databases. Each company has its own org ID, its own customers and its own transactions, stored in Microsoft SQL Server, the only database engine Sage 300 supports. Sage ships two sample companies that show the shape: SAMINC, a single-currency US company, and SAMLTD, a multicurrency Canadian one.

Sage also sells its own CRM, Sage CRM, and publishes a Sage CRM integration component for recent Sage 300 versions. A team that moves its selling into HubSpot gives up that link, and the questions it used to answer come back to the finance office. Which customers are on hold. What is still on order. Whether the last invoice was paid. Who created the customer that now has to be keyed a second time.

What decides the build is less the object list than where the Web API runs. It is an IIS application on a Windows server in your network, or on a Sage Partner Cloud host, configured through a Web.config file inside the Sage 300 installation. So the first scoping question is practical: can a service outside your network reach it over HTTPS, signed in as a Sage 300 user of its own? The second is which modules have Web API endpoints at all, because Sage’s endpoint reference calls the Web API a limited set of features, with more planned for later releases.

Five resources carry a first build, all read through the Web API and all moving one way into HubSpot. ARCustomers become companies, M/T contacts become contacts, OEOrders become deals, OEInvoices land on a custom invoice object and ICItems become products.

Contacts come from Sage 300’s Multiple Contacts program rather than from the customer record. A contact there is a record of its own with a contact code, which can be assigned to customers and to vendors, and a customer can carry any number of them. We match on email in HubSpot, keep the contact code as the tie breaker, and leave out contacts assigned only to vendors.

Keys come from Sage 300, never from a name, and they always carry the company. The same customer number can exist in two companies, so the key is the org ID plus the customer number. Orders and invoices key on the identifiers Sage 300 generates, which an insert returns and each company’s $metadata names, with the order and invoice numbers kept as readable labels.

The Web API also exposes read-only inquiry resources, such as ARPostedDocuments and OESalesHistory. They suit a later phase that puts receivables and sales history on the company, once the first five resources reconcile.

A sync service polls the Web API company by company, because Sage documents no webhook for it. Each request goes to a URL built from the host, the API version, the company org ID, the module and the resource. It carries a Basic authentication header for the integration’s Sage 300 user and a JSON content type.

Each run reads a resource in pages with $skip and $top. Customers carry DateLastMaintained, so their reads filter on it. Resources without a maintained date are read by key and compared on a row hash. Writes into HubSpot are batch upserts on the org ID and the Sage 300 key in custom properties, followed by an association pass that links orders and invoices to companies.

State is a watermark per company and resource, held by the service. A replay re-reads one resource over a key range, and a count request returns the total Sage 300 holds, which the nightly reconciliation compares with HubSpot. A later write back posts one record per request, which is all the Web API accepts.

On Sage 300 the choice turns on reach. A custom API integration needs HTTPS access to the IIS server that hosts the Web API. In return it reads every company the same way, keeps the keys and the run history in one service, and is the only route here that can post a customer or an order back through Sage 300’s business logic.

Commercient’s Sage 300 app is the packaged alternative. It is a third-party listing, so its mapping, support and roadmap stay with Commercient, which suits a standard customer and order copy with nobody of yours on call.

We steer away from a general automation platform. It can only call the Web API once that IIS server is published to the internet, with a Sage 300 user name and password in the header of every request. One naming trap to clear early: Sage 300 Construction and Real Estate is a separate Sage product whose APIs need a Sage development partner key, and this page does not cover it.

1. Scope. We confirm the Sage 300 version, where the Web API runs and how it is reached, which companies are live, and whether Sage CRM is still connected.
2. Architect. We fix the resources, the keys with their org ID, the watermark per company and resource, the page size, and which writes belong in a second phase.
3. Build. The service is built against SAMINC or a copy of a live company, signed in as its own Sage 300 user, with a portal allowlist from the first commit.
4. Validate. We reconcile customer counts and open order totals per company against Sage 300’s own inquiry screens, and walk the differences with finance.
5. Operate. We watch each company’s run history, keep replay available, and rerun the reads against each yearly Sage 300 release before it goes live.